From owner-freebsd-stable@FreeBSD.ORG Sun Aug 26 03:43:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7434B106566C for ; Sun, 26 Aug 2012 03:43:41 +0000 (UTC) (envelope-from greglmiller@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id B14188FC08 for ; Sun, 26 Aug 2012 03:43:39 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so2278970wgb.31 for ; Sat, 25 Aug 2012 20:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wL0UxiBmz6Wb+3flhH8bSdAGfxyNBAlUgmYlzk8RQ68=; b=G1iTqMRUqLLyEQhz5SacjSCA8FvyFIcV50+jhgGNzAc22tDNBu/4dKThWa+3RI9tTD NJNALwgEZYeV5yQfP8IQBGSnhgrp0PLH4gWk85lBeNkTcooO0NhqTgZBQhI+eNv6miVL XzFE/N58saJ/kocfyQ6h1YjKNRzVLycflodbTdEzhZu+qaAl2Rasb7aXXzaZFRxU17HG TtUhaFXl5uFQrUpElVX7lH29W0Jsp7VZwYwdaj1V0ZH8kW3JaiUCFMlm/iZXhGZYvikL SqpzEJ53aW+DGukR3AOM6LaCl0+GXtv8SOaT9xrQDb47ly0JrOj955buY0uFp9lL8xiU vcjQ== MIME-Version: 1.0 Received: by 10.216.24.140 with SMTP id x12mr5218314wex.101.1345952618718; Sat, 25 Aug 2012 20:43:38 -0700 (PDT) Received: by 10.216.178.65 with HTTP; Sat, 25 Aug 2012 20:43:38 -0700 (PDT) Date: Sat, 25 Aug 2012 22:43:38 -0500 Message-ID: From: Greg Miller To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1 Subject: 9.1 USB flash drive: Medium not present X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 03:43:41 -0000 I csup'd to RELENG_9_1, and ran into a new regression (relative to 9.0p3). When I connect my PNY flash drive, I get this: ugen0.3: at usbus0 umass2: on usbus0 umass2: SCSI over Bulk-Only; quirks = 0x4100 umass2:5:2:-1: Attached to scbus5 da2 at umass-sim2 bus 2 scbus5 target 0 lun 0 da2: Removable Direct Access SCSI-0 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: UNIT ATTENTION, Medium not present My full dmesg is as follows: Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-PRERELEASE #22: Sat Aug 11 17:50:08 CDT 2012 root@desktop.resnet.tntech.edu:/usr/obj/usr/src/sys/CUSTOM amd64 CPU: Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz (3399.70-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Features=0xbfebfbff Features2=0x1f9ae3bf AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 8589934592 (8192 MB) avail memory = 8208252928 (7828 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard ACPI Error: [RAMB] Namespace lookup failure, AE_NOT_FOUND (20110527/psargs-392) ACPI Exception: AE_NOT_FOUND, Could not execute arguments for [RAMW] (Region) (20110527/nsinit-380) acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 atrtc0: port 0x70-0x71 irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 550 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Event timer "HPET4" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe07f mem 0xf8000000-0xf9ffffff,0xe8000000-0xefffffff,0xf0000000-0xf3ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io hdac0: mem 0xfa080000-0xfa083fff irq 17 at device 0.1 on pci1 pci0: at device 22.0 (no driver attached) ehci0: mem 0xfa307000-0xfa3073ff irq 23 at device 26.0 on pci0 usbus0: EHCI version 1.0 usbus0 on ehci0 hdac1: mem 0xfa300000-0xfa303fff irq 22 at device 27.0 on pci0 pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 18 at device 28.2 on pci0 pci3: on pcib3 pcib4: irq 19 at device 28.3 on pci0 pci4: on pcib4 pcib5: irq 17 at device 28.4 on pci0 pci5: on pcib5 pcib6: irq 16 at device 28.5 on pci0 pci6: on pcib6 xhci0: mem 0xfa200000-0xfa207fff irq 17 at device 0.0 on pci6 xhci0: 32 byte context size. usbus1 on xhci0 pcib7: irq 18 at device 28.6 on pci0 pci7: on pcib7 re0: port 0xd000-0xd0ff mem 0xf4104000-0xf4104fff,0xf4100000-0xf4103fff irq 18 at device 0.0 on pci7 re0: Using 1 MSI-X message re0: Chip rev. 0x2c800000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-flow re0: Ethernet address: 14:da:e9:f4:8c:58 pcib8: irq 19 at device 28.7 on pci0 pci8: on pcib8 pcib9: irq 17 at device 0.0 on pci8 pci9: on pcib9 ath0: mem 0xfa100000-0xfa10ffff irq 17 at device 2.0 on pci9 ath0: AR2413 mac 7.8 RF2413 phy 4.5 ehci1: mem 0xfa306000-0xfa3063ff irq 23 at device 29.0 on pci0 usbus2: EHCI version 1.0 usbus2 on ehci1 isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf070-0xf077,0xf060-0xf063,0xf050-0xf057,0xf040-0xf043,0xf020-0xf03f mem 0xfa305000-0xfa3057ff irq 20 at device 31.2 on pci0 ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich2: at channel 2 on ahci0 pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 orm0: at iomem 0xc0000-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ctl: CAM Target Layer loaded coretemp0: on cpu0 est0: on cpu0 p4tcc0: on cpu0 coretemp1: on cpu1 est1: on cpu1 p4tcc1: on cpu1 coretemp2: on cpu2 est2: on cpu2 p4tcc2: on cpu2 coretemp3: on cpu3 est3: on cpu3 p4tcc3: on cpu3 ZFS filesystem version 5 ZFS storage pool version 28 Timecounters tick every 10.000 msec vboxdrv: fAsync=0 offMin=0x200 offMax=0x3d8 hdacc0: at cad 0 on hdac0 hdaa0: at nid 1 on hdacc0 pcm0: at nid 5 on hdaa0 hdacc1: at cad 1 on hdac0 hdaa1: at nid 1 on hdacc1 pcm1: at nid 5 on hdaa1 hdacc2: at cad 2 on hdac0 hdaa2: at nid 1 on hdacc2 pcm2: at nid 5 on hdaa2 hdacc3: at cad 3 on hdac0 hdaa3: at nid 1 on hdacc3 pcm3: at nid 5 on hdaa3 hdacc4: at cad 0 on hdac1 hdaa4: at nid 1 on hdacc4 pcm4: at nid 20,22,21,23 and 24,26 on hdaa4 pcm5: at nid 27 and 25 on hdaa4 pcm6: at nid 30 on hdaa4 pcm7: at nid 17 on hdaa4 usbus0: 480Mbps High Speed USB v2.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: <0x1b21> at usbus1 uhub1: <0x1b21 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 uhub1: 4 ports with 4 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered ugen0.2: at usbus0 uhub3: on usbus0 ugen2.2: at usbus2 uhub4: on usbus2 ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:3:0:-1: Attached to scbus3 uhub3: 6 ports with 6 removable, self powered uhub4: 8 ports with 8 removable, self powered (probe1:umass-sim0:0:0:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0 (probe1:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe1:umass-sim0:0:0:0): SCSI status: Check Condition (probe1:umass-sim0:0:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (probe1:umass-sim0:0:0:0): Error 22, Unretryable error ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 cd0 at ahcich2 bus 0 scbus1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, SMP: AP CPU #2 Launched! ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 400.000MB/s transfers da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) Timecounter "TSC-low" frequency 13280068 Hz quality 1000 ugen2.3: at usbus2 uhub5: on usbus2 uhub5: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 ugen2.4: at usbus2 ulpt0: on usbus2 ulpt0: using bi-directional mode umass1: on usbus2 umass1: SCSI over Bulk-Only; quirks = 0x0000 umass1:4:1:-1: Attached to scbus4 (probe0:umass-sim1:1:0:0): REPORT LUNS. CDB: a0 0 0 0 0 0 0 0 0 10 0 0 (probe0:umass-sim1:1:0:0): CAM status: SCSI Status Error (probe0:umass-sim1:1:0:0): SCSI status: Check Condition (probe0:umass-sim1:1:0:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid command operation code) (probe0:umass-sim1:1:0:0): Error 22, Unretryable error da1 at umass-sim1 bus 1 scbus4 target 0 lun 0 da1: Removable Direct Access SCSI-5 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present Root mount waiting for: usbus2 ugen2.5: at usbus2 uaudio0: on usbus2 uaudio0: No playback. uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format. uaudio0: No midi sequencer. pcm8: on uaudio0 Trying to mount root from zfs:zroot []... From owner-freebsd-stable@FreeBSD.ORG Sun Aug 26 11:51:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E79D1065676; Sun, 26 Aug 2012 11:51:44 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 497CF8FC19; Sun, 26 Aug 2012 11:51:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at BSDLabs AB Message-ID: <503A0DBF.2090307@intersonic.se> Date: Sun, 26 Aug 2012 13:51:27 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120525 Thunderbird/12.0.1 MIME-Version: 1.0 To: John Baldwin References: <5007CFE6.6030808@intersonic.se> <201207311632.30938.jhb@freebsd.org> <201208211509.35488.jhb@freebsd.org> In-Reply-To: <201208211509.35488.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, jb , Martin Dieringer Subject: Re: Thinkpad X61s cannot boot 9.1-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 11:51:44 -0000 On 08/21/12 21:09, John Baldwin wrote: > On Tuesday, August 21, 2012 1:50:27 pm Martin Dieringer wrote: >> On Tue, 31 Jul 2012, John Baldwin wrote: >> >>> On Friday, July 20, 2012 10:11:33 am jb wrote: >> >>>>>>> Did anyone else experience this? With 9.1-BETA1 the boot process >>>>>>> freezes, among the last lines with verbose boot are >>>>>>> >>>>>>> acpi_acad0: On Line >>>>>>> acpi_acad0: acline initialization done, tried 1 times >>>>>>> >>>>>>> after this, dead. >>>>>>> ... >> >>>> set debug.acpi.disabled="hostres" >>>> boot >>>> >>>> Or, put the following line into /boot/loader.conf: >>>> >>>> debug.acpi.disabled="hostres" >>>> ..." >>>> >>>> Anyway, regardless of this attempt, file a PR# for 9.1-BETA1. >>> >>> Please try this and let me know if it works. The bugs that I knew of > related to >>> "hostres" should be fixed in 9.1, so if there are still problems I'd like > to >>> know about it. >> >> >> this seems to work on a T410, at least it can boot the latest USB-image now. >> T61 has the same problem, btw. > > So the "hostres" hint fixes your T410 on 9.1 that was broken without it? > On our X61s's setting 'debug.acpi.disabled="hostres"' does not change the inability to boot 9-BETA1, 9-RC1 or -current. What does fix it however, is to change the Kingston SSD drive to a standard mechanical one. This is verified on three different X61s's, see http://www.freebsd.org/cgi/query-pr.cgi?pr=amd64/170487 Is there something else I could try or should I just switch drive and be fine with it? I'm happy to try anything you suggest. Thanks, From owner-freebsd-stable@FreeBSD.ORG Sun Aug 26 16:37:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1F1D106566B for ; Sun, 26 Aug 2012 16:37:34 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 990608FC22 for ; Sun, 26 Aug 2012 16:37:34 +0000 (UTC) Received: from pi by home.opsec.eu with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T5fqA-000K4g-27 for freebsd-stable@freebsd.org; Sun, 26 Aug 2012 18:37:34 +0200 Date: Sun, 26 Aug 2012 18:37:34 +0200 From: Kurt Jaeger To: freebsd-stable@freebsd.org Message-ID: <20120826163733.GA3324@home.opsec.eu> References: <5007CFE6.6030808@intersonic.se> <201207311632.30938.jhb@freebsd.org> <201208211509.35488.jhb@freebsd.org> <503A0DBF.2090307@intersonic.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <503A0DBF.2090307@intersonic.se> Subject: Re: Thinkpad X61s cannot boot 9.1-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 16:37:35 -0000 Hi! > On our X61s's setting 'debug.acpi.disabled="hostres"' does not change > the inability to boot 9-BETA1, 9-RC1 or -current. I tested 9.1-RC1 on X61, and it worked without any troubles. -- pi@opsec.eu +49 171 3101372 8 years to go ! From owner-freebsd-stable@FreeBSD.ORG Sun Aug 26 17:07:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B73C41065670 for ; Sun, 26 Aug 2012 17:07:42 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 704E48FC17 for ; Sun, 26 Aug 2012 17:07:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at BSDLabs AB Message-ID: <503A57DB.3020503@intersonic.se> Date: Sun, 26 Aug 2012 19:07:39 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:12.0) Gecko/20120525 Thunderbird/12.0.1 MIME-Version: 1.0 To: Kurt Jaeger References: <5007CFE6.6030808@intersonic.se> <201207311632.30938.jhb@freebsd.org> <201208211509.35488.jhb@freebsd.org> <503A0DBF.2090307@intersonic.se> <20120826163733.GA3324@home.opsec.eu> In-Reply-To: <20120826163733.GA3324@home.opsec.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Thinkpad X61s cannot boot 9.1-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 17:07:42 -0000 On 08/26/12 18:37, Kurt Jaeger wrote: > Hi! > >> On our X61s's setting 'debug.acpi.disabled="hostres"' does not change >> the inability to boot 9-BETA1, 9-RC1 or -current. > > I tested 9.1-RC1 on X61, and it worked without any troubles. > Yes, it does on this one too if I install a mechanical disk. The problem is related to installing on a SSD drive, Kingston SSDNow SV200S37A/128G. This must be related to a change in the base system some time between 9.0-RELEASE and -BETA1 as 9.0 runs and installs fine. Perhaps someone could suggest anther SSD drive with equal capacity that works? Thanks, From owner-freebsd-stable@FreeBSD.ORG Sun Aug 26 22:59:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E761B106564A for ; Sun, 26 Aug 2012 22:59:34 +0000 (UTC) (envelope-from martin.dieringer@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id 2E8458FC0A for ; Sun, 26 Aug 2012 22:59:33 +0000 (UTC) Received: (qmail invoked by alias); 26 Aug 2012 22:59:26 -0000 Received: from pD9E31527.dip0.t-ipconnect.de (EHLO thinkpad.nowhere.local) [217.227.21.39] by mail.gmx.net (mp035) with SMTP; 27 Aug 2012 00:59:26 +0200 X-Authenticated: #21464393 X-Provags-ID: V01U2FsdGVkX1+l6S5zBdmlnR2UTFPKYh6mOCCZJ4yCd+wv9nOjCs 6nHnlm7f+gDLTx Received: by thinkpad.nowhere.local (Postfix, from userid 1001) id 6630FDD43; Mon, 27 Aug 2012 00:59:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by thinkpad.nowhere.local (Postfix) with ESMTP id 46C70DD42; Mon, 27 Aug 2012 00:59:22 +0200 (CEST) Date: Mon, 27 Aug 2012 00:59:22 +0200 (CEST) From: Martin Dieringer To: Per olof Ljungmark In-Reply-To: <503A57DB.3020503@intersonic.se> Message-ID: References: <5007CFE6.6030808@intersonic.se> <201207311632.30938.jhb@freebsd.org> <201208211509.35488.jhb@freebsd.org> <503A0DBF.2090307@intersonic.se> <20120826163733.GA3324@home.opsec.eu> <503A57DB.3020503@intersonic.se> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Y-GMX-Trusted: 0 Cc: Kurt Jaeger , freebsd-stable@freebsd.org Subject: Re: Thinkpad X61s cannot boot 9.1-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Martin Dieringer List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 22:59:35 -0000 On Sun, 26 Aug 2012, Per olof Ljungmark wrote: > On 08/26/12 18:37, Kurt Jaeger wrote: >> Hi! >> >>> On our X61s's setting 'debug.acpi.disabled="hostres"' does not change >>> the inability to boot 9-BETA1, 9-RC1 or -current. >> >> I tested 9.1-RC1 on X61, and it worked without any troubles. >> > > Yes, it does on this one too if I install a mechanical disk. The problem is > related to installing on a SSD drive, Kingston SSDNow SV200S37A/128G. > > This must be related to a change in the base system some time between > 9.0-RELEASE and -BETA1 as 9.0 runs and installs fine. Perhaps someone could > suggest anther SSD drive with equal capacity that works? debug.acpi.disabled="hostres" fixed it for me on T61 and T410 with normal HD and (older) SSD (OCZ Summit) FreeBSD 9.1-PRERELEASE #16: Tue Aug 21 m. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 06:48:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 981D3106566C for ; Mon, 27 Aug 2012 06:48:43 +0000 (UTC) (envelope-from orientalsensation@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7E28FC0A for ; Mon, 27 Aug 2012 06:48:43 +0000 (UTC) Received: by ialo14 with SMTP id o14so9451861ial.13 for ; Sun, 26 Aug 2012 23:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=uYGoUa0Xh10iRuCdN5+G574VkGv0X+7q4bA7Rc606MM=; b=yTrscNZpodSrHfCIkAg3k76aVpt2I5YR/kkJ3bUAcRgeb7Fz/OZD1L5eL4kebm1JW7 JTh6r5+8ZUggmsXevABN65dcB5h5NYOvS0UKdfAV3dHqPMhP/E+vhg7FMVzOJ59WuLec 6p+Pv8xUK4zSU7ja5khDbYyF+oAaEYMj3XyR6UDSoDbjzdoDvOZ69G+83G9Xipa/Bt7o 5QxVRo0V+3NZmWwI5sZzJydHp+lg7oYmF1t5WQq+KdBG2GERdtZMhNdIAOgf4j5ugoeu uoe+REsAHqaF6larUBIe7ElJMvo+FfPcIGCehJsrW9YTTX1zvR66ihhHxUmI5+cBveKG 1Khg== MIME-Version: 1.0 Received: by 10.50.187.228 with SMTP id fv4mr9181926igc.37.1346050121848; Sun, 26 Aug 2012 23:48:41 -0700 (PDT) Sender: orientalsensation@gmail.com Received: by 10.64.81.226 with HTTP; Sun, 26 Aug 2012 23:48:41 -0700 (PDT) Date: Mon, 27 Aug 2012 08:48:41 +0200 X-Google-Sender-Auth: viyqj4eFRldw0VYtDJdgghNyhME Message-ID: From: OriS To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 06:48:43 -0000 Hello all, I have a strange warning message in dmesg: warning: total configured swap (15728640 pages) exceeds maximum recommended amount (22369984 pages). warning: increase kern.maxswzone or reduce amount of swap. (The configured pages are actually less than maximum) The value of kern.maxswzone in /boot/loader.conf is: kern.maxswzone=201326592 Anyone knows what's going on?! /OriS From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 08:26:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 96A73106564A; Mon, 27 Aug 2012 08:26:50 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4EB708FC1A; Mon, 27 Aug 2012 08:26:49 +0000 (UTC) Received: by ialo14 with SMTP id o14so9641922ial.13 for ; Mon, 27 Aug 2012 01:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2gF3QRdKTew7aZPi2JugdNBNAeGP3K7SGcAqvh5eZkw=; b=PbJ9qU2xw3g6H2WeYZ3aRiFyOzJZ8ufQ2QFqQR6AdyCZD0ghLjNi5NZdAPwHU0sE2F nLHhgTcL1M8TeivVhGbiIcgctXa/75BxgYKjBF3VbgLsLttiImTLJiBjtIAYI4bspsTF ODm04zqaFLRQ2JSR3YP7xGBboMqolrvAoSiDLzm9BrVMvHZ0cmN1AWQ7xqQp7u4ZLqON FHP/ocgaaWq31yBYaulMDXTnA49j1+2u/uCqnBDbv9iFPxUy9fF8G0qeDKdk6TmXJA/L uUiH53EXT18BRIgNFC8z7Fh+cY7OhTFaz1VJw2OCfVP7qjKmzqI5rC/BwFWUnQTG5P9x taaA== MIME-Version: 1.0 Received: by 10.42.180.201 with SMTP id bv9mr10246449icb.43.1346056009643; Mon, 27 Aug 2012 01:26:49 -0700 (PDT) Sender: pluknet@gmail.com Received: by 10.64.165.34 with HTTP; Mon, 27 Aug 2012 01:26:49 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Aug 2012 12:26:49 +0400 X-Google-Sender-Auth: BlBsIc1kDJxyqZKv90pjmFy9NcI Message-ID: From: Sergey Kandaurov To: OriS Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org, =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= Subject: Re: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:26:50 -0000 On 27 August 2012 10:48, OriS wrote: > Hello all, > > I have a strange warning message in dmesg: > > warning: total configured swap (15728640 pages) exceeds maximum > recommended amount (22369984 pages). > warning: increase kern.maxswzone or reduce amount of swap. > > (The configured pages are actually less than maximum) > > The value of kern.maxswzone in /boot/loader.conf is: > > kern.maxswzone=201326592 > > Anyone knows what's going on?! I think there is a typo. Should be: Index: /usr/src/sys/vm/swap_pager.c =================================================================== --- /usr/src/sys/vm/swap_pager.c (revision 239722) +++ /usr/src/sys/vm/swap_pager.c (working copy) @@ -2135,7 +2135,7 @@ swapon_check_swzone(unsigned long npages) if (npages > maxpages / 2) { printf("warning: total configured swap (%lu pages) " "exceeds maximum recommended amount (%lu pages).\n", - npages, maxpages); + npages, maxpages / 2); printf("warning: increase kern.maxswzone " "or reduce amount of swap.\n"); return (-1); -- wbr, pluknet From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 08:52:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BB29106566C; Mon, 27 Aug 2012 08:52:00 +0000 (UTC) (envelope-from orientalsensation@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id C74C48FC1F; Mon, 27 Aug 2012 08:51:59 +0000 (UTC) Received: by ialo14 with SMTP id o14so9690625ial.13 for ; Mon, 27 Aug 2012 01:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ribgMRgUmGbX9CyLizZUR1paZb47T8jPsOPXDHFR160=; b=HAAU1qhcfRjWAhWhAN9WxSCBFUFu3aLVaz9nqBFdZdquSgJtkVX8tEZBQN74H9ccnu pqTpPqEojXayoan0Gf+5Ektqke95Bny7g0xha+bXJgizPMX4vaxKMDGXSunoEfAA6gxi bhInOoRLFKQeJmZmADzFY+tk4R2hZwaw3/CrzPO/szCOCUXRi6TwpGSSNDc+Tes0jJG7 nHhXLclF1xAE3iW5ZIwiaO5Otr362sOSor76OUeuQL82/s3O9XiMVcNWWbljvJBkP2IR jiV1bNHfARfNoCeCDqsP6iKhAy8dyWkyJCUiIBSvCDjVnP0Zbdenfm8Ts+ztJpT3UjDC b8OQ== MIME-Version: 1.0 Received: by 10.50.183.231 with SMTP id ep7mr9275400igc.66.1346057519342; Mon, 27 Aug 2012 01:51:59 -0700 (PDT) Sender: orientalsensation@gmail.com Received: by 10.64.81.226 with HTTP; Mon, 27 Aug 2012 01:51:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 27 Aug 2012 10:51:59 +0200 X-Google-Sender-Auth: mvxNc1qwv-ap1LfpjhuQsWsxeQU Message-ID: From: OriS To: Sergey Kandaurov Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org, =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Subject: Re: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 08:52:00 -0000 Yup, that seems to be the issue... I kept bumping up the value of kern.maxswzone until the warning disappeared. Should be incorporated into sources I guess. Thanks! :) Noor On Mon, Aug 27, 2012 at 10:26 AM, Sergey Kandaurov wrote: > On 27 August 2012 10:48, OriS wrote: > > Hello all, > > > > I have a strange warning message in dmesg: > > > > warning: total configured swap (15728640 pages) exceeds maximum > > recommended amount (22369984 pages). > > warning: increase kern.maxswzone or reduce amount of swap. > > > > (The configured pages are actually less than maximum) > > > > The value of kern.maxswzone in /boot/loader.conf is: > > > > kern.maxswzone=201326592 > > > > Anyone knows what's going on?! > > I think there is a typo. Should be: > > Index: /usr/src/sys/vm/swap_pager.c > =================================================================== > --- /usr/src/sys/vm/swap_pager.c (revision 239722) > +++ /usr/src/sys/vm/swap_pager.c (working copy) > @@ -2135,7 +2135,7 @@ swapon_check_swzone(unsigned long npages) > if (npages > maxpages / 2) { > printf("warning: total configured swap (%lu pages) " > "exceeds maximum recommended amount (%lu pages).\n", > - npages, maxpages); > + npages, maxpages / 2); > printf("warning: increase kern.maxswzone " > "or reduce amount of swap.\n"); > return (-1); > > -- > wbr, > pluknet > From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 09:06:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC786106564A for ; Mon, 27 Aug 2012 09:06:05 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id A688D8FC08 for ; Mon, 27 Aug 2012 09:06:05 +0000 (UTC) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.xtaz.co.uk (Postfix) with ESMTPS id 262C2DEF21B for ; Mon, 27 Aug 2012 10:06:04 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 Aug 2012 10:06:03 +0100 From: Matt Smith To: Message-ID: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> X-Sender: matt@xtaz.co.uk User-Agent: Roundcube Webmail/0.8.1 Subject: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:06:06 -0000 I posted on this mailing list two weeks ago and never received any replies so I decided to raise a PR via the web form. But I think I submitted it under the wrong category and it's marked as low priority as well. But I think this is something that is a potential serious problem if I end up getting a corrupted filesystem so I'm posting here again in the hope somebody can help this time. The PR is amd64/170646. I'm now running the latest RELENG_9 code as of 25th August as I've done a new buildworld/kernel. I still get the same problem. When I reboot it I get WARNING: / was not properly dismounted and it rebuilds from journal. On shutdown I get the messages pasted below. I'm running amd64 with GPT partitioning, UFS2 with softupdates and softupdates journalling enabled. I have a custom kernel but I don't think I took anything important out of it. Syncing disks, vnodes remaining...7 7 2 0 0 done All buffers synced. fsync: giving up on dirty 0xfffffe0007102780: tag devfs, type VCHR usecount 1, writecount 0, refcount 2292 mountedhere 0xfffffe000000729ca00 flags (VI(0x200)) v_object 0xfffffe0005101910 ref 0 pages 23509 lock type devfs: EXCL by thread 0xfffffe00018fe08e0 (pid 1) dev label/root umount of / failed (35) Then when the box comes back up again it detects that / was not unmounted cleanly and recovers from journal before marking it clean once more. My uname: FreeBSD tao.xtaz.co.uk 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Aug 25 12:34:52 BST 2012 root@tao.xtaz.co.uk:/usr/obj/usr/src/sys/TAO amd64 My glabel status: Name Status Components gpt/gptboot N/A ada0p1 gptid/bfe99d62-e00f-11e1-8623-00012e475ffb N/A ada0p1 label/root N/A ada0p2 label/swap N/A ada0p3 My fstab: /dev/label/root / ufs rw 1 1 /dev/label/swap none swap sw 0 0 My gpart: => 34 1250263661 ada0 GPT (596G) 34 1024 1 freebsd-boot (512k) 1058 990 - free - (495k) 2048 1228931072 2 freebsd-ufs (586G) 1228933120 21330575 3 freebsd-swap (10G) From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 09:19:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 800AC106566B; Mon, 27 Aug 2012 09:19:58 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 403488FC0C; Mon, 27 Aug 2012 09:19:58 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 87BDF6EEC; Mon, 27 Aug 2012 11:19:57 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 578588FD9; Mon, 27 Aug 2012 11:19:57 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Sergey Kandaurov References: Date: Mon, 27 Aug 2012 11:19:56 +0200 In-Reply-To: (Sergey Kandaurov's message of "Mon, 27 Aug 2012 12:26:49 +0400") Message-ID: <86harozo77.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: OriS , freebsd-stable@freebsd.org Subject: Re: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:19:58 -0000 Sergey Kandaurov writes: > Index: /usr/src/sys/vm/swap_pager.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- /usr/src/sys/vm/swap_pager.c (revision 239722) > +++ /usr/src/sys/vm/swap_pager.c (working copy) > @@ -2135,7 +2135,7 @@ swapon_check_swzone(unsigned long npages) > if (npages > maxpages / 2) { > printf("warning: total configured swap (%lu pages) " > "exceeds maximum recommended amount (%lu pages).\n", > - npages, maxpages); > + npages, maxpages / 2); > printf("warning: increase kern.maxswzone " > "or reduce amount of swap.\n"); > return (-1); Correct. The theoretical maximum is maxpages, but due to fragmentation, you can run out of space well before that. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 09:22:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1C4161065673 for ; Mon, 27 Aug 2012 09:22:01 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D2F518FC17 for ; Mon, 27 Aug 2012 09:22:00 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id E331D6EEF; Mon, 27 Aug 2012 11:21:59 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id B33C98FDB; Mon, 27 Aug 2012 11:21:59 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: OriS References: Date: Mon, 27 Aug 2012 11:21:59 +0200 In-Reply-To: (OriS's message of "Mon, 27 Aug 2012 08:48:41 +0200") Message-ID: <86d32czo3s.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:22:01 -0000 OriS writes: > The value of kern.maxswzone in /boot/loader.conf is: > > kern.maxswzone=3D201326592 On an amd64 system, you should just set it to 0. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 09:28:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23972106566B for ; Mon, 27 Aug 2012 09:28:24 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id B08FC8FC0C for ; Mon, 27 Aug 2012 09:28:23 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 1A72412E599; Mon, 27 Aug 2012 09:28:16 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> Date: Mon, 27 Aug 2012 11:28:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> To: Matt Smith X-Mailer: Apple Mail (2.1278) Cc: freebsd-stable@freebsd.org Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:28:24 -0000 Am 27.08.2012 um 11:06 schrieb Matt Smith: > I posted on this mailing list two weeks ago and never received any = replies so I decided to raise a PR via the web form. But I think I = submitted it under the wrong category and it's marked as low priority as = well. But I think this is something that is a potential serious problem = if I end up getting a corrupted filesystem so I'm posting here again in = the hope somebody can help this time. The PR is amd64/170646. >=20 > I'm now running the latest RELENG_9 code as of 25th August as I've = done a new buildworld/kernel. I still get the same problem. When I = reboot it I get WARNING: / was not properly dismounted and it rebuilds = from journal. On shutdown I get the messages pasted below. I'm running = amd64 with GPT partitioning, UFS2 with softupdates and softupdates = journalling enabled. I have a custom kernel but I don't think I took = anything important out of it. >=20 > Syncing disks, vnodes remaining...7 7 2 0 0 done > All buffers synced. > fsync: giving up on dirty > 0xfffffe0007102780: tag devfs, type VCHR > usecount 1, writecount 0, refcount 2292 mountedhere = 0xfffffe000000729ca00 > flags (VI(0x200)) > v_object 0xfffffe0005101910 ref 0 pages 23509 > lock type devfs: EXCL by thread 0xfffffe00018fe08e0 (pid 1) > dev label/root > umount of / failed (35) >=20 > Then when the box comes back up again it detects that / was not = unmounted > cleanly and recovers from journal before marking it clean once more. > My fstab: > /dev/label/root / ufs rw 1 1 > /dev/label/swap none swap sw 0 0 Is there a particular reason you've decided to glabel your partitions = instead of using GPT labels? Which device did you do the newfs on, the = GPT partition or the glabel device? My hunch is that the label metadata = sector at the end of the GPT partition is interfering with the = filesystem. I'd try labelling my partitions (gpart modify -i 2 -l root ada0; gpart = modify -i 3 -l swap), then change fstab to reference the gpt labels = (dev(gpt/root) instead of the glabel ones. Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 09:30:04 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2C25106567C for ; Mon, 27 Aug 2012 09:30:04 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from lisa.milos.co.za (lisa.milos.co.za [109.169.49.137]) by mx1.freebsd.org (Postfix) with ESMTP id 124D28FC0C for ; Mon, 27 Aug 2012 09:30:03 +0000 (UTC) Received: (qmail 51618 invoked by uid 80); 27 Aug 2012 09:25:15 -0000 To: X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 Aug 2012 10:25:15 +0100 From: clay@milos.co.za In-Reply-To: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> Message-ID: X-Sender: clay@milos.co.za User-Agent: Roundcube Webmail/0.7.2 Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:30:04 -0000 On 27.08.2012 10:06, Matt Smith wrote: > I posted on this mailing list two weeks ago and never received any > replies so I decided to raise a PR via the web form. But I think I > submitted it under the wrong category and it's marked as low priority > as well. But I think this is something that is a potential serious > problem if I end up getting a corrupted filesystem so I'm posting > here > again in the hope somebody can help this time. The PR is > amd64/170646. > > I'm now running the latest RELENG_9 code as of 25th August as I've > done a new buildworld/kernel. I still get the same problem. When I > reboot it I get WARNING: / was not properly dismounted and it > rebuilds > from journal. On shutdown I get the messages pasted below. I'm > running > amd64 with GPT partitioning, UFS2 with softupdates and softupdates > journalling enabled. I have a custom kernel but I don't think I took > anything important out of it. > > Syncing disks, vnodes remaining...7 7 2 0 0 done > All buffers synced. > fsync: giving up on dirty > 0xfffffe0007102780: tag devfs, type VCHR > usecount 1, writecount 0, refcount 2292 mountedhere > 0xfffffe000000729ca00 > flags (VI(0x200)) > v_object 0xfffffe0005101910 ref 0 pages 23509 > lock type devfs: EXCL by thread 0xfffffe00018fe08e0 (pid 1) > dev label/root > umount of / failed (35) > > Then when the box comes back up again it detects that / was not > unmounted > cleanly and recovers from journal before marking it clean once more. > > My uname: > FreeBSD tao.xtaz.co.uk 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat > Aug 25 12:34:52 BST 2012 > root@tao.xtaz.co.uk:/usr/obj/usr/src/sys/TAO amd64 > > My glabel status: > Name Status Components > gpt/gptboot N/A ada0p1 > gptid/bfe99d62-e00f-11e1-8623-00012e475ffb N/A ada0p1 > label/root N/A ada0p2 > label/swap N/A ada0p3 > > My fstab: > /dev/label/root / ufs rw 1 1 > /dev/label/swap none swap sw 0 0 > > My gpart: > => 34 1250263661 ada0 GPT (596G) > 34 1024 1 freebsd-boot (512k) > 1058 990 - free - (495k) > 2048 1228931072 2 freebsd-ufs (586G) > 1228933120 21330575 3 freebsd-swap (10G) > Hi Matt I'm far from anything near an expert on file systems but I'd suggest you remove softupdates and leave journaling on. tunefs -n disable There's no need to have both on and although I agree that both SHOULD work together there's no reason to have them on together. It will only slow down writes to the file system. Effectively soft updates was a go-between before journalin was introduced. //Clay _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 09:39:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8617106564A for ; Mon, 27 Aug 2012 09:39:15 +0000 (UTC) (envelope-from orientalsensation@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6AB2D8FC19 for ; Mon, 27 Aug 2012 09:39:15 +0000 (UTC) Received: by ialo14 with SMTP id o14so9792664ial.13 for ; Mon, 27 Aug 2012 02:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=G6z94U0b5hvIm9JD6RO4rcY3pbkGHZp3IsP6IaTF7Hk=; b=XtTSn7IfR/niJrnAzlJD+l6Gxolilv9+4e8uLdMtVtHRAfwI+5riV2+ruC8Rr9jB3r kdGyaGZjQwk7vkb0p4RypsZKr+yB3ZilttwrixSiMfC8mNn02gmcyKX/o98A37Vg4lOa M4wVKXLHqREwQ7++IHRqJ19TNsSkjIypY/nL+HV+Ayk1fqG+MlR8xQ13lfDPyWJ/97xE 1NnOKqikfqppKgb3nmZc+n2JqbGOo1nl+FRA6XRAQipIM5BEaULRErzDPgbWOpUqM5F1 vNQU9ze7E0m2YHpB/Yq9YKlCWeSOT3lOdSQS8D8bcLfo16g0Ns0ekz/8tMl9OOvLb8De mYAw== MIME-Version: 1.0 Received: by 10.50.213.97 with SMTP id nr1mr9562832igc.40.1346060354708; Mon, 27 Aug 2012 02:39:14 -0700 (PDT) Sender: orientalsensation@gmail.com Received: by 10.64.81.226 with HTTP; Mon, 27 Aug 2012 02:39:14 -0700 (PDT) In-Reply-To: <86d32czo3s.fsf@ds4.des.no> References: <86d32czo3s.fsf@ds4.des.no> Date: Mon, 27 Aug 2012 11:39:14 +0200 X-Google-Sender-Auth: t-Jqb--qsYT9NzcCXYdK4dXvXWc Message-ID: From: OriS To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Subject: Re: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:39:15 -0000 Yep, this also causes the warning not to be emitted at all. Well, maybe it'd be a good idea to set it to 0 on amd64 systems for amd64-RELEASE's. OriS On Mon, Aug 27, 2012 at 11:21 AM, Dag-Erling Sm=C3=B8rgrav wro= te: > OriS writes: > > The value of kern.maxswzone in /boot/loader.conf is: > > > > kern.maxswzone=3D201326592 > > On an amd64 system, you should just set it to 0. > > DES > -- > Dag-Erling Sm=C3=B8rgrav - des@des.no > From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 09:50:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F17A106567B for ; Mon, 27 Aug 2012 09:50:55 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id C44248FC0A for ; Mon, 27 Aug 2012 09:50:54 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 253CD6F0A; Mon, 27 Aug 2012 11:50:53 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id ECDF68FE3; Mon, 27 Aug 2012 11:50:52 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: OriS References: <86d32czo3s.fsf@ds4.des.no> Date: Mon, 27 Aug 2012 11:50:52 +0200 In-Reply-To: (OriS's message of "Mon, 27 Aug 2012 11:39:14 +0200") Message-ID: <86zk5gy877.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:50:55 -0000 OriS writes: > "Dag-Erling Sm=C3=B8rgrav" writes: > > On an amd64 system, you should just set it to 0. > Well, maybe it'd be a good idea to set it to 0 on amd64 systems for > amd64-RELEASE's. Already done. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 10:11:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C520106566B for ; Mon, 27 Aug 2012 10:11:55 +0000 (UTC) (envelope-from christer.solskogen@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6151A8FC18 for ; Mon, 27 Aug 2012 10:11:54 +0000 (UTC) Received: by ialo14 with SMTP id o14so9869591ial.13 for ; Mon, 27 Aug 2012 03:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=ee1tQsojZb8/mHs/a2ETThCkwxBHpwwkrKFOn2VbycE=; b=qT5E1vL2Dl5f6FfJrAvOWjBM1Oa4s9i2LN7a4PGcWiu+/nxV4ZRJpUbXh/CdTvNFpH SFklN4l3aQLOBbdbyudMHu4v3uwYitN20Mx5aR9bCMvWubahAgUHzyKzyrd58wFkDCiX n77B/HtR883NqcMAB+qHcrRy2CzkB71g9mWAw7eP6iXODa8ORL/qZPbxlMnBVf5j9AOX QgC5V4eba1HyQ+5AWK0kOPhs6kTMNqVU2DeSNmhkYUW3fwh289wBPetP8MEZ6osaNPvY deQL9DB5UHO//7AZKlYF20WjqzQ1l0PM1s6lJENiOlWcSqLXA5a8BM1xF1dQTWhaQaLN AAjA== Received: by 10.50.154.225 with SMTP id vr1mr9456812igb.70.1346062314716; Mon, 27 Aug 2012 03:11:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.103.103 with HTTP; Mon, 27 Aug 2012 03:11:34 -0700 (PDT) In-Reply-To: <86zk5gy877.fsf@ds4.des.no> References: <86d32czo3s.fsf@ds4.des.no> <86zk5gy877.fsf@ds4.des.no> From: Christer Solskogen Date: Mon, 27 Aug 2012 12:11:34 +0200 Message-ID: To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: OriS , freebsd-stable@freebsd.org Subject: Re: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 10:11:55 -0000 On Mon, Aug 27, 2012 at 11:50 AM, Dag-Erling Sm=C3=B8rgrav wro= te: > OriS writes: >> "Dag-Erling Sm=C3=B8rgrav" writes: >> > On an amd64 system, you should just set it to 0. >> Well, maybe it'd be a good idea to set it to 0 on amd64 systems for >> amd64-RELEASE's. > > Already done. > Mine is 33554432 without any modifications to loader.conf on 9.1-RC1. Is that the default? --=20 chs, From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 10:12:54 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 769121065676 for ; Mon, 27 Aug 2012 10:12:54 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3338FC21 for ; Mon, 27 Aug 2012 10:12:54 +0000 (UTC) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.xtaz.co.uk (Postfix) with ESMTPS id 3365DDEF21B; Mon, 27 Aug 2012 11:12:53 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 Aug 2012 11:12:52 +0100 From: Matt Smith To: Stefan Bethke In-Reply-To: <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> Message-ID: X-Sender: matt@xtaz.co.uk User-Agent: Roundcube Webmail/0.8.1 Cc: freebsd-stable@freebsd.org Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 10:12:54 -0000 On 2012-08-27 10:28, Stefan Bethke wrote: > Is there a particular reason you've decided to glabel your partitions > instead of using GPT labels? Which device did you do the newfs on, > the > GPT partition or the glabel device? My hunch is that the label > metadata sector at the end of the GPT partition is interfering with > the filesystem. > > I'd try labelling my partitions (gpart modify -i 2 -l root ada0; > gpart modify -i 3 -l swap), then change fstab to reference the gpt > labels (dev(gpt/root) instead of the glabel ones. > No reason at all really. I had just used it like that on a previous MBR based system and it worked fine. I have just booted it using the USB stick again and removed both labels metadata using glabel stop and clear and changed the fstab to use /dev/gpt/ labels now. Unfortunately the same issue persists. It mounted fine, but when I rebooted it it synced all buffers successfully but then gave the same error saying that it couldn't unmount /. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 10:15:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BCE91065673 for ; Mon, 27 Aug 2012 10:15:21 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id 567328FC14 for ; Mon, 27 Aug 2012 10:15:21 +0000 (UTC) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.xtaz.co.uk (Postfix) with ESMTPS id 7942CDEF24C; Mon, 27 Aug 2012 11:15:20 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 Aug 2012 11:15:20 +0100 From: Matt Smith To: In-Reply-To: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> Message-ID: X-Sender: matt@xtaz.co.uk User-Agent: Roundcube Webmail/0.8.1 Cc: freebsd-stable@freebsd.org Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 10:15:21 -0000 On 2012-08-27 10:25, clay@milos.co.za wrote: > I'm far from anything near an expert on file systems but I'd suggest > you remove softupdates and leave journaling on. > tunefs -n disable > There's no need to have both on and although I agree that both SHOULD > work together there's no reason to have them on together. It will > only > slow down writes to the file system. Effectively soft updates was a > go-between before journalin was introduced. > Really? This is SU+J journalling that I'm using. Not gjournal. Surely SU+J does require softupdates to be on as it's part of the same thing? Output from tunefs -p: tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 10:27:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3796F1065678 for ; Mon, 27 Aug 2012 10:27:08 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id DD1AD8FC14 for ; Mon, 27 Aug 2012 10:27:07 +0000 (UTC) Received: from AMD620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q7RAQq5O012930; Mon, 27 Aug 2012 04:26:57 -0600 Date: Mon, 27 Aug 2012 17:26:50 +0700 From: Erich Dollansky To: Matt Smith Message-ID: <20120827172650.7e6a7685@AMD620.ovitrap.com> In-Reply-To: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 10:27:08 -0000 Hi, On Mon, 27 Aug 2012 11:12:52 +0100 Matt Smith wrote: > On 2012-08-27 10:28, Stefan Bethke wrote: > > Is there a particular reason you've decided to glabel your > > partitions instead of using GPT labels? Which device did you do the > > newfs on, the > > GPT partition or the glabel device? My hunch is that the label > > metadata sector at the end of the GPT partition is interfering with > > the filesystem. > > > > I'd try labelling my partitions (gpart modify -i 2 -l root ada0; > > gpart modify -i 3 -l swap), then change fstab to reference the gpt > > labels (dev(gpt/root) instead of the glabel ones. > > > > No reason at all really. I had just used it like that on a previous > MBR based system and it worked fine. I have just booted it using the > USB stick again and removed both labels metadata using glabel stop > and clear and changed the fstab to use /dev/gpt/ labels now. > Unfortunately the same issue persists. It mounted fine, but when I > rebooted it it synced all buffers successfully but then gave the same > error saying that it couldn't unmount /. I would run plain UFS for / /var and /tmp and see what will happen then. I know what you will answer. But it will help to isolate the problem. Erich From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 10:40:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA5EC106564A for ; Mon, 27 Aug 2012 10:40:49 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id 819418FC12 for ; Mon, 27 Aug 2012 10:40:49 +0000 (UTC) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.xtaz.co.uk (Postfix) with ESMTPS id 605DADEF21B; Mon, 27 Aug 2012 11:40:48 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 Aug 2012 11:40:47 +0100 From: Matt Smith To: Erich Dollansky In-Reply-To: <20120827172650.7e6a7685@AMD620.ovitrap.com> References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> Message-ID: X-Sender: matt@xtaz.co.uk User-Agent: Roundcube Webmail/0.8.1 Cc: freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 10:40:49 -0000 On 2012-08-27 11:26, Erich Dollansky wrote: > I would run plain UFS for / /var and /tmp and see what will happen > then. > > I know what you will answer. But it will help to isolate the problem. > Did you mean not use the label at all? If so I just tried this. Set /dev/ada0p2 in the fstab. No change. Still get the same issue. This might help investigations as I wrote down what I did to install it. The way I created this filesystem was that I dropped out of the installer to a shell because I wanted to do the 4k alignment. And I ran this: gpart create -s gpt ada0 gpart add -t freebsd-boot -l gptboot -s 512k ada0 gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0 gpart add -t freebsd-ufs -l gptroot -b 1M -s 586G ada0 gpart add -t freebsd-swap -l gptswap ada0 gpart show => 34 1250263661 ada0 GPT (596G) 34 1024 1 freebsd-boot (512k) 1058 990 - free - (495k) 2048 1228931072 2 freebsd-ufs (586G) 1228933120 21330575 3 freebsd-swap (10G) newfs -U -j -L root /dev/gpt/gptroot glabel label root /dev/ada0p2 glabel label swap /dev/ada0p3 mount /dev/gpt/gptroot /mnt vi /tmp/bsdinstall_etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/label/root / ufs rw 1 1 /dev/label/swap none swap sw 0 0 exit From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 11:16:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AD661065670 for ; Mon, 27 Aug 2012 11:16:35 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 381E78FC15 for ; Mon, 27 Aug 2012 11:16:34 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id F1B206F4D; Mon, 27 Aug 2012 13:16:33 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 9EE048FF3; Mon, 27 Aug 2012 13:16:33 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Christer Solskogen References: <86d32czo3s.fsf@ds4.des.no> <86zk5gy877.fsf@ds4.des.no> Date: Mon, 27 Aug 2012 13:16:33 +0200 In-Reply-To: (Christer Solskogen's message of "Mon, 27 Aug 2012 12:11:34 +0200") Message-ID: <86vcg4y48e.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: OriS , freebsd-stable@freebsd.org Subject: Re: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 11:16:35 -0000 Christer Solskogen writes: > Mine is 33554432 without any modifications to loader.conf on 9.1-RC1. > Is that the default? It is the hardcoded default for both i386 and amd64 in 9.1 and earlier releases. I have not merged the new limits and warning code yet. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 12:06:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B81121065670 for ; Mon, 27 Aug 2012 12:06:55 +0000 (UTC) (envelope-from clay@milos.co.za) Received: from lisa.milos.co.za (lisa.milos.co.za [109.169.49.137]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9998FC12 for ; Mon, 27 Aug 2012 12:06:54 +0000 (UTC) Received: (qmail 65810 invoked by uid 80); 27 Aug 2012 12:06:53 -0000 To: Matt Smith X-PHP-Originating-Script: 0:main.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 Aug 2012 13:06:53 +0100 From: clay@milos.co.za In-Reply-To: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> Message-ID: <12a12894ae0617e5782093c6ce4139e3@milos.co.za> X-Sender: clay@milos.co.za User-Agent: Roundcube Webmail/0.7.2 Cc: freebsd-stable@freebsd.org Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 12:06:55 -0000 On 27.08.2012 11:15, Matt Smith wrote: > On 2012-08-27 10:25, clay@milos.co.za wrote: >> I'm far from anything near an expert on file systems but I'd suggest >> you remove softupdates and leave journaling on. >> tunefs -n disable >> There's no need to have both on and although I agree that both >> SHOULD >> work together there's no reason to have them on together. It will >> only >> slow down writes to the file system. Effectively soft updates was a >> go-between before journalin was introduced. >> > > Really? This is SU+J journalling that I'm using. Not gjournal. Surely > SU+J does require softupdates to be on as it's part of the same > thing? > Output from tunefs -p: > > tunefs: soft updates: (-n) enabled > tunefs: soft update journaling: (-j) enabled > tunefs: gjournal: (-J) disabled I saw that you had soft updates and soft updates journaling in your original email. What you have is correct. That is how 9.x sets up the FS by default nowadays. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 12:59:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9D35106566C; Mon, 27 Aug 2012 12:59:43 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) by mx1.freebsd.org (Postfix) with ESMTP id 8DD438FC18; Mon, 27 Aug 2012 12:59:43 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1T5ytr-0002Qo-Tm; Mon, 27 Aug 2012 19:58:39 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q7RD0HLq098150; Mon, 27 Aug 2012 20:00:17 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q7RCxi1D096564; Mon, 27 Aug 2012 19:59:44 +0700 (NOVT) (envelope-from danfe) Date: Mon, 27 Aug 2012 19:59:43 +0700 From: Alexey Dokuchaev To: Hans Petter Selasky Message-ID: <20120827125943.GA68575@regency.nsu.ru> References: <20120227152238.GA2940@regency.nsu.ru> <201203030911.29633.hselasky@c2i.net> <20120305041759.GA87746@regency.nsu.ru> <201203050710.22871.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201203050710.22871.hselasky@c2i.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jung-uk Kim Subject: Re: Resume broken in 8.3-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 12:59:44 -0000 On Mon, Mar 05, 2012 at 07:10:22AM +0100, Hans Petter Selasky wrote: > On Monday 05 March 2012 05:17:59 Alexey Dokuchaev wrote: > > On Sat, Mar 03, 2012 at 09:11:29AM +0100, Hans Petter Selasky wrote: > > > On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote: > > > > Try the attached patch. At least, it fixed my problem. > > > > > > I've committed your patch with some minor modifications. > > > > > > http://svn.freebsd.org/changeset/base/232448 > > > > Unfortunately, it does not fix resume for me; and hw.usb.no_shutdown_wait > > flipping did not make any difference either. Any other ideas? > > Particularly, I'm curious why disabling all USB modules still does not > > allow this laptop to resume. What are USB debugging techniques? > > USB debugging: > > Have "options USB_DEBUG" in kernel config. Then set xxx.debug = 15 under > hw.usb, typically hw.usb.uhub.debug=15 Today I've csupped to latest RELENG_8 (hoping that maybe the problem was fixed during last few months), rebuilt the kernel with USB_DEBUG option. After fresh reboot, the following snippet releately pop up on the console (hand-copied): usb_needs_explore: usb_bus_powerd: bus=0xc55cccf0 <-- bus= number changes usb_bus_powerd: Recomputing power masks uhub_explore: udev=0xc5647400 addr=1 <-- udev= number changes uhub_read_port_status: port 1, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION (USB<->CRC32 has plugged in, no other USB devices) Aroung zzz(8) time (keyboard die upon wake-up as described earlier with 100% CPU load -- fans are at full burst) debug mode yielded these: uhub_child_pnpinfo_string: device not on bub uhub_child_location_string: device not on bub uhub_child_pnpinfo_string: device not on bub usb_bus_powerd: bus=0xc55e2c78 usb_bus_powerd: Recomputing power masks uhub_read_port_status: port 1, wPortStatus=0x0500, wPortChange=0x0000, err=USB uhub_read_port_status: port 2, wPortStatus=0x0500, wPortChange=0x0000, err=USB ... up to port 8 ... uhub_read_port_status: port 8, wPortStatus=0x0500, wPortChange=0x0000, err=USB << usual "(disconnected)" messages >> usb_buf_port_set_device: bus 0xc55cccf0 devices[2] = 0 usb_needs_explore: usb_needs_explore: usb_needs_explore: usb_needs_explore: usb_needs_explore: uhub0: on usbus4 uhub0: on usbus1 ... UHCI also found on usbus 2, 3, 0 (in that order) uhub_attach: depth=0 selfpowered=1, parent=0, parent->selfpowered=0 uhub_attach: Getting HUB descriptior uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 1 power uhub_attach: turn on port 2 power uhub_attach: turn on port 2 power uhub_attach: turn on port 2 power uhub_attach: turn on port 2 power uhub1: 2 ports with 2 removable, self powered ... usb_needs_explore: loop quoted above repeats; system unusable Any ideas? ./danfe From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 13:13:13 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16359106566C for ; Mon, 27 Aug 2012 13:13:13 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id DFF7F8FC17 for ; Mon, 27 Aug 2012 13:13:12 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q7RDDBZf009280 for ; Mon, 27 Aug 2012 06:13:11 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q7RDDBjm009279 for stable@freebsd.org; Mon, 27 Aug 2012 06:13:11 -0700 (PDT) (envelope-from david) Date: Mon, 27 Aug 2012 06:13:11 -0700 From: David Wolfskill To: stable@freebsd.org Message-ID: <20120827131311.GE1442@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gDGSpKKIBgtShtf+" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Subject: FreeBSD/i386 stable/9 @239722: REDZONE: Buffer underflow detected X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:13:13 -0000 --gDGSpKKIBgtShtf+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've been tracking stable/9 on a daily basis on one of the slices of my laptop for a while now, b ut just happened to review the scrollback on vty0 this morning, and noticed the (hightlighted, though that doesn't show up in the below cut/paste) whines "REDZONE: Buffer underflow detected...." I included a few line before & after to provide some context. As far as I have been able to tell, it's running OK; still, perhaps there's something worth chasing down? The uname -a output is: FreeBSD g1-227.catwhisker.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #228 23= 9646M: Fri Aug 24 04:58:07 PDT 2012 root@g1-227.catwhisker.org:/usr/obj= /usr/src/sys/CANARY i386 though the GRN there is a little bit misleading, as both kernel & userland were rebuilt with sources @239722M around 05:00 hrs. this morning US/Pacific time. Anyway, here's the cut/paster: =2E.. Mounting local file systems:. Setting hostname: localhost. Starting dhclient. em0: no link .............. giving up /etc/rc.d/dhclient: WARNING: failed to start dhclient wlan0: Ethernet address: 00:21:6a:26:34:c0 Starting wpa_supplicant. Starting dhclient. wlan0: no link ......wlan0: link state changed to UP got link dhclient: /etc/dhclient-enter-hooks invoked with reason PREINIT dhclient: Setting hostname from localhost to null string dhclient: /etc/dhclient-exit-hooks invoked with reason PREINIT dhclient: reason was PREINIT; no action taken dhclient: Exiting /etc/dhclient-exit-hooks (PREINIT) with exit_status 0 DHCPREQUEST on wlan0 to 255.255.255.255 port 67 DHCPACK from 172.17.0.1 Expensive timeout(9) function: 0xc0b91b10(0) 0.010922407 s bound to 172.17.1.227 -- renewal in 43200 seconds. Starting Network: lo0 em0 iwn0 fwe0 fwip0 ipfw0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xe inet 127.0.0.1 netmask 0xff000000 nd6 options=3D21 em0: flags=3D8843 metric 0 mtu 1500 options=3D4219b ether 00:24:e8:9c:11:0f nd6 options=3D29 media: Ethernet autoselect status: no carrier iwn0: flags=3D8843 metric 0 mtu 2290 ether 00:21:6a:26:34:c0 nd6 options=3D29 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated fwe0: flags=3D8802 metric 0 mtu 1500 options=3D8 ether 4a:4f:c0:37:06:01 nd6 options=3D29 ch 1 dma -1 fwip0: flags=3D8802 metric 0 mtu 1500 lladdr 4a.4f.c0.0.10.37.6.1.a.2.ff.fe.0.0.0.0 nd6 options=3D29 ipfw0: flags=3D8801 metric 0 mtu 65536 nd6 options=3D29 Starting devd. REDZONE: Buffer underflow detected. 1 byte corrupted before 0xced40080 (429= 49667 96 bytes allocated). Allocation backtrace: #0 0xc0ce5fef at redzone_setup+0xcf #1 0xc0a5a959 at malloc+0x1d9 #2 0xc0a9b200 at devctl_queue_data_f+0x40 #3 0xc0aa066a at devaddq+0x20a #4 0xc0a9d58c at device_attach+0x46c #5 0xc0a9e35b at bus_generic_attach+0x2b #6 0xc0530cf5 at acpi_pci_attach+0x185 #7 0xc0a9d489 at device_attach+0x369 #8 0xc0a9e35b at bus_generic_attach+0x2b #9 0xc0532e52 at acpi_pcib_attach+0x262 #10 0xc053414f at acpi_pcib_pci_attach+0x9f #11 0xc0a9d489 at device_attach+0x369 #12 0xc0a9e35b at bus_generic_attach+0x2b #13 0xc0530cf5 at acpi_pci_attach+0x185 #14 0xc0a9d489 at device_attach+0x369 #15 0xc0a9e35b at bus_generic_attach+0x2b #16 0xc0532e52 at acpi_pcib_attach+0x262 #17 0xc0533845 at acpi_pcib_acpi_attach+0x2c5 Free backtrace: #0 0xc0ce62aa at redzone_check+0x1ca #1 0xc0a5a9a8 at free+0x38 #2 0xc0a9b086 at devread+0x1a6 #3 0xc0a256d7 at giant_read+0x87 #4 0xc096e292 at devfs_read_f+0xc2 #5 0xc0ab6f29 at dofileread+0x99 #6 0xc0ab6b48 at sys_read+0x98 #7 0xc0ddc197 at syscall+0x387 #8 0xc0dc4f51 at Xint0x80_syscall+0x21 REDZONE: Buffer overflow detected. 10 bytes corrupted after 0xced3fe8c (429= 49667 96 bytes allocated). Allocation backtrace: #0 0xc0ce5fef at redzone_setup+0xcf #1 0xc0a5a959 at malloc+0x1d9 #2 0xc0a9b200 at devctl_queue_data_f+0x40 #3 0xc0aa066a at devaddq+0x20a #4 0xc0a9d58c at device_attach+0x46c #5 0xc0a9e35b at bus_generic_attach+0x2b #6 0xc0530cf5 at acpi_pci_attach+0x185 #7 0xc0a9d489 at device_attach+0x369 #8 0xc0a9e35b at bus_generic_attach+0x2b #9 0xc0532e52 at acpi_pcib_attach+0x262 #10 0xc053414f at acpi_pcib_pci_attach+0x9f #11 0xc0a9d489 at device_attach+0x369 #12 0xc0a9e35b at bus_generic_attach+0x2b #13 0xc0530cf5 at acpi_pci_attach+0x185 #14 0xc0a9d489 at device_attach+0x369 #15 0xc0a9e35b at bus_generic_attach+0x2b #16 0xc0532e52 at acpi_pcib_attach+0x262 #17 0xc0533845 at acpi_pcib_acpi_attach+0x2c5 Free backtrace: #0 0xc0ce63f2 at redzone_check+0x312 #1 0xc0a5a9a8 at free+0x38 #2 0xc0a9b086 at devread+0x1a6 #3 0xc0a256d7 at giant_read+0x87 #4 0xc096e292 at devfs_read_f+0xc2 #5 0xc0ab6f29 at dofileread+0x99 #6 0xc0ab6b48 at sys_read+0x98 #7 0xc0ddc197 at syscall+0x387 #8 0xc0dc4f51 at Xint0x80_syscall+0x21 Starting Network: usbus0. Starting Network: usbus1. Starting Network: usbus2. Starting Network: usbus3. Starting Network: usbus4. Starting Network: usbus5. Starting Network: usbus6. Starting Network: usbus7. Starting Network: fwe0. fwe0: flags=3D8802 metric 0 mtu 1500 options=3D8 ether 4a:4f:c0:37:06:01 nd6 options=3D29 ch 1 dma -1 Starting Network: fwip0. fwip0: flags=3D8802 metric 0 mtu 1500 lladdr 4a.4f.c0.0.10.37.6.1.a.2.ff.fe.0.0.0.0 nd6 options=3D29 dhclient already running? (pid=3D699). add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 add net fe80::: gateway ::1 add net ff02::: gateway ::1 =2E.. I'll be happy to test patches. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --gDGSpKKIBgtShtf+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA7cmYACgkQmprOCmdXAD0GqgCggSqEeaOQu7IzVrvYYEdbAGnW MHsAn36dZvbV/NGgoOpYNId/LB0sGTaY =XUS4 -----END PGP SIGNATURE----- --gDGSpKKIBgtShtf+-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 13:21:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA00A1065670 for ; Mon, 27 Aug 2012 13:21:21 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 82B128FC1B for ; Mon, 27 Aug 2012 13:21:20 +0000 (UTC) Received: by dadr6 with SMTP id r6so2510877dad.13 for ; Mon, 27 Aug 2012 06:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=Pzx4TOALJrhGO8dSfpz51ESlsstp7bZXEYf++YkyE2U=; b=P0nPwMpckf2v4z6Il4M/dwiq+JKYTOvpQihqNISCFNJRLYbLAZZVRLhVn+L3oDeJYz tqVVi1n7MfrMfre7qhZQn8vh8z2Ad5h74JIaCmYIPhhdHs8CJ0o0+N9zgQf5yOj35VWc Q3nebRF3+A3Ji7VHsoEdAsKJHKsha4L5yZUz4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Pzx4TOALJrhGO8dSfpz51ESlsstp7bZXEYf++YkyE2U=; b=VFMn5OyocbWvEknttK2ok7cAaZDnRVawiyaf4+Tnyw2VQZ220wdht4RtXvC97/FhWF zv1tcyGcHf6wDe+yFwApTR4JPDKLcBFyjhGGb9jFvZb6hamhCwgB2LYaZRyAAGLWaUWL 4p7l7xZu8WRjaAdIU8050v+pV04OgDH2oJFV/42Wzmw3FlonvOwv3LLKC3QoAHUAumr5 avidRFNgs0SwwzbbFnL3L3Z55kuHtS+7DpPbofy6BxBsHsU+UOHYgNarYOw/bzKYAqVI DNByowPrdidHsR95kSSAG1UZUj2GU5C/mvbv9Lo2msA9WaTKXFN/ZGF7eZDubJkUImfU mv1g== Received: by 10.66.83.129 with SMTP id q1mr30312871pay.4.1346073680603; Mon, 27 Aug 2012 06:21:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.67.4.227 with HTTP; Mon, 27 Aug 2012 06:20:50 -0700 (PDT) In-Reply-To: <86zk5gy877.fsf@ds4.des.no> References: <86d32czo3s.fsf@ds4.des.no> <86zk5gy877.fsf@ds4.des.no> From: Eitan Adler Date: Mon, 27 Aug 2012 09:20:50 -0400 Message-ID: To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmwMLvi7Mw3WM0e2F4NwSJXOHnpE4W0R4E/GAn3v6T/0IC0hNtwSTzJGXS9pyG8tgh8WEUU Cc: OriS , freebsd-stable@freebsd.org Subject: Re: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:21:21 -0000 On 27 August 2012 05:50, Dag-Erling Sm=C3=B8rgrav wrote: > OriS writes: >> "Dag-Erling Sm=C3=B8rgrav" writes: >> > On an amd64 system, you should just set it to 0. >> Well, maybe it'd be a good idea to set it to 0 on amd64 systems for >> amd64-RELEASE's. Can we put this advice into the printf? --=20 Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 13:47:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3D40106566B for ; Mon, 27 Aug 2012 13:47:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 61E8E8FC0C for ; Mon, 27 Aug 2012 13:47:28 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 8E5CA605D; Mon, 27 Aug 2012 15:47:27 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 519538038; Mon, 27 Aug 2012 15:47:27 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Eitan Adler References: <86d32czo3s.fsf@ds4.des.no> <86zk5gy877.fsf@ds4.des.no> Date: Mon, 27 Aug 2012 15:47:26 +0200 In-Reply-To: (Eitan Adler's message of "Mon, 27 Aug 2012 09:20:50 -0400") Message-ID: <868vd08n0x.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: OriS , freebsd-stable@freebsd.org Subject: Re: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:47:28 -0000 Eitan Adler writes: > "Dag-Erling Sm=C3=B8rgrav" writes: > > On an amd64 system, you should just set it to 0. > Can we put this advice into the printf? There is no need for that, as 0 is already the default for amd64 in head, and I intend to MFC that change very soon. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 13:49:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77F5D106564A for ; Mon, 27 Aug 2012 13:49:15 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3F9548FC21 for ; Mon, 27 Aug 2012 13:49:15 +0000 (UTC) Received: by pbbrp2 with SMTP id rp2so7601650pbb.13 for ; Mon, 27 Aug 2012 06:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=0TX1f0tiGjmYZGmwQ0F6qgRRl53RUZWK2LKQNF1N1TU=; b=HamZfsnWJ//zsC5uu/Yb/zDH2XH9Afo79spEt0sEHuU8wCEAq+PuLPz9Q2tv771+Uz 8C9WJlZIYeY/sdDaoHxH+7EwDaEAqQtt1FfSCBE8cVmI8rn/b1vgkUcE0uwFqrljvlCU qBAvBwSLARgeP9Ut9nWKmaJk8LRBCOrcPGp28= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=0TX1f0tiGjmYZGmwQ0F6qgRRl53RUZWK2LKQNF1N1TU=; b=Lqlhc7RKQeU/w098OpCaAElF4uxFNIdoMRIjAaoUHUX0yJiV1VOAMQIh1NMG6cPDkE lsdSd1YduxxMdwh6GSmkqfFi8gtXfF7XdfpTfLfajs++X2KvlnDZho5dXIzgUvtEBHcB KdMgC/sgAi84GjM52HAT8xW/0qXXCadltYHDjAbXahAdn/hnmvYprUZUkOqJh/ccXa1q 66u6InBKwmMRGWcTFhjTryH4rDmvy7in6dbZYaZVueR8RmRz2CaSIZvoUgSqvVZqaCe0 TJ09j3GGBrnwIshZE+P6lywxLC33M43gkdYDykULuQDaR/so9n/mMnSVwucomx4MkE2+ omrQ== Received: by 10.66.89.6 with SMTP id bk6mr21577876pab.81.1346075354716; Mon, 27 Aug 2012 06:49:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.67.4.227 with HTTP; Mon, 27 Aug 2012 06:48:44 -0700 (PDT) In-Reply-To: <868vd08n0x.fsf@ds4.des.no> References: <86d32czo3s.fsf@ds4.des.no> <86zk5gy877.fsf@ds4.des.no> <868vd08n0x.fsf@ds4.des.no> From: Eitan Adler Date: Mon, 27 Aug 2012 09:48:44 -0400 Message-ID: To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkxalDiCLvRRgj51LOF08JO7itlmqd55a16F1WxpGXg7kjn+VJ/DN6bss0iuilJAjKBzz5/ Cc: OriS , freebsd-stable@freebsd.org Subject: Re: Weird message in dmesg X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:49:15 -0000 On 27 August 2012 09:47, Dag-Erling Sm=C3=B8rgrav wrote: > Eitan Adler writes: >> "Dag-Erling Sm=C3=B8rgrav" writes: >> > On an amd64 system, you should just set it to 0. >> Can we put this advice into the printf? > > There is no need for that, as 0 is already the default for amd64 in > head, and I intend to MFC that change very soon. good enough :) --=20 Eitan Adler From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 13:51:19 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA30B106567D for ; Mon, 27 Aug 2012 13:51:19 +0000 (UTC) (envelope-from crtmike@gmx.us) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 7DCCF8FC2A for ; Mon, 27 Aug 2012 13:51:19 +0000 (UTC) Received: (qmail invoked by alias); 27 Aug 2012 12:45:10 -0000 Received: from unknown (EHLO bsd.laptop.mike) [124.89.80.204] by mail.gmx.com (mp-us003) with SMTP; 27 Aug 2012 08:45:10 -0400 X-Authenticated: #137061016 X-Provags-ID: V01U2FsdGVkX1+2G8IaLY62q0+tm4d87g6RxWBYzCYql1I2z/Sgky uxuSN8qhifBQov Message-ID: <503B6BCB.10407@gmx.us> Date: Mon, 27 Aug 2012 20:44:59 +0800 From: Mike Manilone User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120823 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Temperature too high when high overload X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:51:19 -0000 Hi all, I just switched from Fedora Linux to FreeBSD. But I noticed a problem, the CPU temperature will be very high when the load is high. Especially while I am building C++ programs. It shut down for even 3 times while I was building Firefox/Thunderbird, just because of high temperature (86.5C). One of my friends told me, "FreeBSD doesn't support your ACPI well" but I noticed that while I'm not compiling ports, the temperature will be not too high. Just now I'm building LLVM, here's what I've seen: > sysctl hw.acpi.thermal.tz0.temperature hw.acpi.thermal.tz0.temperature: 84.5C > pkill make > sysctl hw.acpi.thermal.tz0.temperature hw.acpi.thermal.tz0.temperature: 67.5C I'm using Dell Vostro 3400 laptop PC with FreeBSD 9.1-RC1. > uname -a FreeBSD bsd.laptop.mike 9.1-RC1 FreeBSD 9.1-RC1 #0: Tue Aug 14 04:25:06 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 There's my dmesg message: http://slexy.org/view/s21b7xTTsu Anyone knows how to fix this problem? Thank you. Yours Sincerely, Mike Manilone From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 13:56:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9914D106566B for ; Mon, 27 Aug 2012 13:56:18 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 369948FC14 for ; Mon, 27 Aug 2012 13:56:17 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q7RDuFHP046743; Mon, 27 Aug 2012 07:56:15 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q7RDuERQ046740; Mon, 27 Aug 2012 07:56:15 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 27 Aug 2012 07:56:14 -0600 (MDT) From: Warren Block To: Matt Smith In-Reply-To: Message-ID: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 27 Aug 2012 07:56:15 -0600 (MDT) Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 13:56:18 -0000 On Mon, 27 Aug 2012, Matt Smith wrote: > On 2012-08-27 11:26, Erich Dollansky wrote: >> I would run plain UFS for / /var and /tmp and see what will happen then. >> >> I know what you will answer. But it will help to isolate the problem. >> > > Did you mean not use the label at all? If so I just tried this. Set > /dev/ada0p2 in the fstab. No change. Still get the same issue. > > This might help investigations as I wrote down what I did to install it. > > The way I created this filesystem was that I dropped out of the installer to > a shell because I wanted to do the 4k alignment. And I ran this: > > gpart create -s gpt ada0 > gpart add -t freebsd-boot -l gptboot -s 512k ada0 > gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0 > gpart add -t freebsd-ufs -l gptroot -b 1M -s 586G ada0 > gpart add -t freebsd-swap -l gptswap ada0 > gpart show > > => 34 1250263661 ada0 GPT (596G) > 34 1024 1 freebsd-boot (512k) > 1058 990 - free - (495k) > 2048 1228931072 2 freebsd-ufs (586G) > 1228933120 21330575 3 freebsd-swap (10G) > > newfs -U -j -L root /dev/gpt/gptroot > glabel label root /dev/ada0p2 > glabel label swap /dev/ada0p3 > mount /dev/gpt/gptroot /mnt > vi /tmp/bsdinstall_etc/fstab > > # Device Mountpoint FStype Options Dump Pass# > /dev/label/root / ufs rw 1 1 > /dev/label/swap none swap sw 0 0 Stefan called it. The newfs is done on /dev/gpt/gptroot, no problem there. But when glabel writes to /dev/ada0p2--which is /dev/gpt/gptroot, same thing, it overwrites the last block. And then the filesystem is mounted with the glabel device, which is actually one block smaller than the filesystem expects. Could be either the filesystem or GEOM that's causing the failure at shutdown. Happily, those glabels aren't accomplishing anything useful and can be skipped. Removing the glabels and changing the devices in fstab might be enough. A more cautious approach would be to back up, newfs, skip the glabel step, and then change the devices in fstab. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 14:04:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C44E61065674 for ; Mon, 27 Aug 2012 14:04:58 +0000 (UTC) (envelope-from erichfreebsdlist@ovitrap.com) Received: from alogreentechnologies.com (alogreentechnologies.com [67.212.224.110]) by mx1.freebsd.org (Postfix) with ESMTP id 918D98FC19 for ; Mon, 27 Aug 2012 14:04:58 +0000 (UTC) Received: from AMD620.ovitrap.com ([49.128.188.2]) (authenticated bits=0) by alogreentechnologies.com (8.13.1/8.13.1) with ESMTP id q7RE4lfm030397; Mon, 27 Aug 2012 08:04:53 -0600 Date: Mon, 27 Aug 2012 21:04:44 +0700 From: Erich Dollansky To: Mike Manilone Message-ID: <20120827210444.190ec5b1@AMD620.ovitrap.com> In-Reply-To: <503B6BCB.10407@gmx.us> References: <503B6BCB.10407@gmx.us> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.6; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Temperature too high when high overload X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:04:58 -0000 Gi, On Mon, 27 Aug 2012 20:44:59 +0800 Mike Manilone wrote: > I just switched from Fedora Linux to FreeBSD. But I noticed a I did the same on my notebook some time ago. > problem, the CPU temperature will be very high when the load is high. It was the same for me while Fedora was running. > One of my friends told me, "FreeBSD doesn't support your ACPI well" > but I noticed that while I'm not compiling ports, the temperature > will be not too high. This could be true. > > Just now I'm building LLVM, here's what I've seen: > > > sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 84.5C > > pkill make > > sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 67.5C > > I'm using Dell Vostro 3400 laptop PC with FreeBSD 9.1-RC1. I did not look for the CPU this machine has. My notebook has a i7 and it runs on 96 degree centigrade when the CPU is under 100% load. It would shut down at 99 degree centigrade. > > uname -a > FreeBSD bsd.laptop.mike 9.1-RC1 FreeBSD 9.1-RC1 #0: Tue Aug 14 > 04:25:06 UTC 2012 > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > There's my dmesg message: http://slexy.org/view/s21b7xTTsu > > Anyone knows how to fix this problem? Thank you. I do not know much about the differences between i3 and i7 but I would expect that both can run until 99 degree centigrade before they have to shut down. Erich From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 14:09:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 587DE106566B for ; Mon, 27 Aug 2012 14:09:02 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0BEEF8FC08 for ; Mon, 27 Aug 2012 14:09:02 +0000 (UTC) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.xtaz.co.uk (Postfix) with ESMTPS id A78B2DEE7A7; Mon, 27 Aug 2012 15:09:00 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 Aug 2012 15:09:00 +0100 From: Matt Smith To: Warren Block In-Reply-To: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> Message-ID: <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> X-Sender: matt@xtaz.co.uk User-Agent: Roundcube Webmail/0.8.1 Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:09:02 -0000 On 2012-08-27 14:56, Warren Block wrote: > > Stefan called it. The newfs is done on /dev/gpt/gptroot, no problem > there. But when glabel writes to /dev/ada0p2--which is > /dev/gpt/gptroot, same thing, it overwrites the last block. And then > the filesystem is mounted with the glabel device, which is actually > one block smaller than the filesystem expects. > > Could be either the filesystem or GEOM that's causing the failure at > shutdown. > > Happily, those glabels aren't accomplishing anything useful and can > be skipped. Removing the glabels and changing the devices in fstab > might be enough. A more cautious approach would be to back up, > newfs, > skip the glabel step, and then change the devices in fstab. As I said on a previous mail I did boot it with a USB stick and cleared the glabel metadata and altered the fstab to point to both the GPT labels and the raw UFS device and I still get the issue. So am I right in thinking then that this has caused irreparable damage and the only way I can fix this now is to newfs the filesystem again, this time just using GPT labels and not using glabel at all? This is the first time I've ever done a manually partitioned installation with GPT and alignment, previously I've only ever used sysinstall with non-aligned MBR installations, so it was a bit of a learning curve. If I do have to newfs it again then I want to be sure that I'm doing the correct things so that I don't find myself with any other issues. So does the rest of what I did look fine? If it is clearly my own fault then the PR can obviously be closed and chalked up to learning! From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 14:44:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 335401065674 for ; Mon, 27 Aug 2012 14:44:24 +0000 (UTC) (envelope-from christian.mangin@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id E9FFA8FC20 for ; Mon, 27 Aug 2012 14:44:23 +0000 (UTC) Received: by ialo14 with SMTP id o14so10554040ial.13 for ; Mon, 27 Aug 2012 07:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=KLOPFxnshcPU76kkRruVGki0gupfdr5o9TtQXk6AskA=; b=sYuasr6UTGsaIEsY+9S5aZUMK6X5ffDyjx8xecNsZNMuXdFBMHkFkW11RT8ggPvlLH gjvcphm/XuOCA/9o4y8VhrRJdvcYDghxtGkSNvIn4TT9U0olHoIGNwAp9VV8Wv/ZBUSz Ov/cPKh/9+ASAaJHuvnZVZ+xCNKlaAVKfxCxJIRZsCqgQdYA4ubaipUXYvTb2Xw8gOKo 47sYTfsOT+kBCr+faNoDAr3Goscm3Sntbglbk3b0LLboOfUNNueLJW8B5NHXHnGXp85L H2yAi2/yEYr69qRxOVBK6F2hQwrxuo5X5Csv702XpW+PIje5DVPOPMpQzBARbSO8QLSy mlSQ== Received: by 10.50.159.130 with SMTP id xc2mr10472181igb.33.1346078663078; Mon, 27 Aug 2012 07:44:23 -0700 (PDT) Received: from [192.168.80.173] (cable-10-157-60.b2b2c.ca. [72.10.157.60]) by mx.google.com with ESMTPS id ce10sm6607371igb.1.2012.08.27.07.44.22 (version=SSLv3 cipher=OTHER); Mon, 27 Aug 2012 07:44:22 -0700 (PDT) Message-ID: <503B87C2.5080308@gmail.com> Date: Mon, 27 Aug 2012 10:44:18 -0400 From: Christian Mangin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120809 Thunderbird/14.0 MIME-Version: 1.0 To: Mike Manilone References: <503B6BCB.10407@gmx.us> In-Reply-To: <503B6BCB.10407@gmx.us> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@freebsd.org Subject: Re: Temperature too high when high overload X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 14:44:24 -0000 Le 27.08.2012 08:44, Mike Manilone a écrit : > Hi all, > > I just switched from Fedora Linux to FreeBSD. But I noticed a problem, > the CPU temperature will be very high when the load is high. > Especially while I am building C++ programs. It shut down for even 3 > times while I was building Firefox/Thunderbird, just because of high > temperature (86.5C). > > One of my friends told me, "FreeBSD doesn't support your ACPI well" > but I noticed that while I'm not compiling ports, the temperature will > be not too high. > > Just now I'm building LLVM, here's what I've seen: > > > sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 84.5C > > pkill make > > sysctl hw.acpi.thermal.tz0.temperature > hw.acpi.thermal.tz0.temperature: 67.5C > > I'm using Dell Vostro 3400 laptop PC with FreeBSD 9.1-RC1. > > uname -a > FreeBSD bsd.laptop.mike 9.1-RC1 FreeBSD 9.1-RC1 #0: Tue Aug 14 > 04:25:06 UTC 2012 > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > There's my dmesg message: http://slexy.org/view/s21b7xTTsu > > Anyone knows how to fix this problem? Thank you. > > Yours Sincerely, > Mike Manilone > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Hello, I used to have the same problem with my laptop (i5) and this can be fixed by lowering the temperature threshold for passive cooling. (_PSV) hw.acpi.thermal.user_override=1 hw.acpi.thermal.tz0._PSV=80C You should try to adjust _PSV to be significantly lower (> 15-20C) than the _CRT (critical shutdown temp) so that _CRT is never reached. Christian From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 15:39:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04F08106564A; Mon, 27 Aug 2012 15:39:12 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.c2i.net [212.247.155.2]) by mx1.freebsd.org (Postfix) with ESMTP id E9EFE8FC31; Mon, 27 Aug 2012 15:39:10 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe09.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 138006919; Mon, 27 Aug 2012 17:34:01 +0200 From: Hans Petter Selasky To: Alexey Dokuchaev Date: Mon, 27 Aug 2012 17:34:54 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <20120227152238.GA2940@regency.nsu.ru> <201203050710.22871.hselasky@c2i.net> <20120827125943.GA68575@regency.nsu.ru> In-Reply-To: <20120827125943.GA68575@regency.nsu.ru> X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208271734.54814.hselasky@c2i.net> Cc: freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jung-uk Kim Subject: Re: Resume broken in 8.3-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:39:12 -0000 On Monday 27 August 2012 14:59:43 Alexey Dokuchaev wrote: > On Mon, Mar 05, 2012 at 07:10:22AM +0100, Hans Petter Selasky wrote: > > On Monday 05 March 2012 05:17:59 Alexey Dokuchaev wrote: > > > On Sat, Mar 03, 2012 at 09:11:29AM +0100, Hans Petter Selasky wrote: > > > > On Friday 02 March 2012 20:25:32 Jung-uk Kim wrote: > > > > > Try the attached patch. At least, it fixed my problem. > > > > > > > > I've committed your patch with some minor modifications. > > > > > > > > http://svn.freebsd.org/changeset/base/232448 > > > > > > Unfortunately, it does not fix resume for me; and > > > hw.usb.no_shutdown_wait flipping did not make any difference either. > > > Any other ideas? Particularly, I'm curious why disabling all USB > > > modules still does not allow this laptop to resume. What are USB > > > debugging techniques? > > > > USB debugging: > > > > Have "options USB_DEBUG" in kernel config. Then set xxx.debug = 15 under > > hw.usb, typically hw.usb.uhub.debug=15 > > Today I've csupped to latest RELENG_8 (hoping that maybe the problem was > fixed during last few months), rebuilt the kernel with USB_DEBUG option. > > After fresh reboot, the following snippet releately pop up on the console > (hand-copied): > > usb_needs_explore: > usb_bus_powerd: bus=0xc55cccf0 <-- bus= number changes > usb_bus_powerd: Recomputing power masks > uhub_explore: udev=0xc5647400 addr=1 <-- udev= number changes > uhub_read_port_status: port 1, wPortStatus=0x0100, wPortChange=0x0000, > err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, > wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION > > (USB<->CRC32 has plugged in, no other USB devices) > > Aroung zzz(8) time (keyboard die upon wake-up as described earlier with > 100% CPU load -- fans are at full burst) debug mode yielded these: > > uhub_child_pnpinfo_string: device not on bub > uhub_child_location_string: device not on bub > uhub_child_pnpinfo_string: device not on bub > usb_bus_powerd: bus=0xc55e2c78 > usb_bus_powerd: Recomputing power masks > uhub_read_port_status: port 1, wPortStatus=0x0500, wPortChange=0x0000, > err=USB uhub_read_port_status: port 2, wPortStatus=0x0500, > wPortChange=0x0000, err=USB ... up to port 8 ... > uhub_read_port_status: port 8, wPortStatus=0x0500, wPortChange=0x0000, > err=USB << usual "(disconnected)" messages >> > usb_buf_port_set_device: bus 0xc55cccf0 devices[2] = 0 > usb_needs_explore: > usb_needs_explore: > usb_needs_explore: > usb_needs_explore: > usb_needs_explore: > uhub0: on usbus4 > uhub0: on usbus1 > ... UHCI also found on usbus 2, 3, 0 (in that order) > uhub_attach: depth=0 selfpowered=1, parent=0, parent->selfpowered=0 > uhub_attach: Getting HUB descriptior > uhub_attach: turn on port 1 power > uhub_attach: turn on port 1 power > uhub_attach: turn on port 1 power > uhub_attach: turn on port 1 power > uhub_attach: turn on port 1 power > uhub_attach: turn on port 2 power > uhub_attach: turn on port 2 power > uhub_attach: turn on port 2 power > uhub_attach: turn on port 2 power > uhub1: 2 ports with 2 removable, self powered > ... usb_needs_explore: loop quoted above repeats; system unusable > > Any ideas? > > ./danfe If the USB HC is feeding too many such IRQ's it will be stuck. However, if you see that "uhub_read_port_status()" is called, the kernel is at least running, though it might be that some IRQ is stuck, hence the 100% CPU usage. Could you try to get some IRQ stats? --HPS From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 15:41:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 606DD1065675 for ; Mon, 27 Aug 2012 15:41:31 +0000 (UTC) (envelope-from crtmike@gmx.us) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 02DD18FC15 for ; Mon, 27 Aug 2012 15:41:30 +0000 (UTC) Received: (qmail invoked by alias); 27 Aug 2012 15:41:29 -0000 Received: from unknown (EHLO bsd.laptop.mike) [124.89.80.204] by mail.gmx.com (mp-us004) with SMTP; 27 Aug 2012 11:41:29 -0400 X-Authenticated: #137061016 X-Provags-ID: V01U2FsdGVkX1+z43d43Lmzd9uwQ6meoyde1+sUG8Hu3CgoSwT0am AQNEjjaarjlu+b Message-ID: <503B9522.7080500@gmx.us> Date: Mon, 27 Aug 2012 23:41:22 +0800 From: Mike Manilone User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120823 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <503B6BCB.10407@gmx.us> <503B87C2.5080308@gmail.com> In-Reply-To: <503B87C2.5080308@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: Temperature too high when high overload X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 15:41:31 -0000 On 2012/08/27 22:44, Christian Mangin wrote: > You should try to adjust _PSV to be significantly lower (> 15-20C) than > the _CRT (critical shutdown temp) so that _CRT is never reached. Well, I think this is very useful for all the situations. Why not set them by default? From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 16:38:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9434106564A for ; Mon, 27 Aug 2012 16:38:05 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id A067B8FC0C for ; Mon, 27 Aug 2012 16:38:05 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T62K1-0005NX-Cs for freebsd-stable@freebsd.org; Mon, 27 Aug 2012 18:37:53 +0200 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Aug 2012 18:37:53 +0200 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Aug 2012 18:37:53 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Date: Mon, 27 Aug 2012 16:37:41 +0000 (UTC) Lines: 76 Message-ID: References: <503B6BCB.10407@gmx.us> <503B87C2.5080308@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20100101 Firefox/14.0.1) Subject: Re: Temperature too high when high overload X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 16:38:06 -0000 Christian Mangin gmail.com> writes: > > Le 27.08.2012 08:44, Mike Manilone a écrit : > > Hi all, > > > > I just switched from Fedora Linux to FreeBSD. But I noticed a problem, > > the CPU temperature will be very high when the load is high. > > Especially while I am building C++ programs. It shut down for even 3 > > times while I was building Firefox/Thunderbird, just because of high > > temperature (86.5C). > > ... > I used to have the same problem with my laptop (i5) and this can be > fixed by lowering the temperature threshold for passive cooling. (_PSV) > > hw.acpi.thermal.user_override=1 > hw.acpi.thermal.tz0._PSV=80C > > You should try to adjust _PSV to be significantly lower (> 15-20C) than > the _CRT (critical shutdown temp) so that _CRT is never reached. > > Christian I too have the same problem (Lenovo dual core r61i). You should see the relevant data before making any changes - below it is explained why. This is my data: $ sysctl -a | grep -i thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 42.0C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 127.0C hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 hw.acpi.thermal.tz1.temperature: 42.0C hw.acpi.thermal.tz1.active: -1 hw.acpi.thermal.tz1.passive_cooling: 1 hw.acpi.thermal.tz1.thermal_flags: 0 hw.acpi.thermal.tz1._PSV: 95.5C hw.acpi.thermal.tz1._HOT: -1 hw.acpi.thermal.tz1._CRT: 100.0C hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz1._TC1: 5 hw.acpi.thermal.tz1._TC2: 4 hw.acpi.thermal.tz1._TSP: 600 dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.1.%desc: Thermal Zone dev.p4tcc.0.%desc: CPU Frequency Thermal Control dev.p4tcc.1.%desc: CPU Frequency Thermal Control $ As you can see in my case: hw.acpi.thermal.tz0.passive_cooling: 0 which is NOT available (so obviously any settings in tz0 zone are irrelevant). This is explained here: ACPI_THERMAL(4): ... hw.acpi.thermal.tz%d.passive_cooling If set to 1, passive cooling is enabled. It does cooling without fans using cpufreq(4) as the mechanism for controlling CPU speed. Default is enabled for tz0 where it is available. ... In my case tz1 zone is available and active. jb From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 16:50:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B2631065670 for ; Mon, 27 Aug 2012 16:50:46 +0000 (UTC) (envelope-from hirez@libeljournal.com) Received: from outbound-queue-2.mail.thdo.gradwell.net (outbound-queue-2.mail.thdo.gradwell.net [212.11.70.35]) by mx1.freebsd.org (Postfix) with ESMTP id B23098FC0C for ; Mon, 27 Aug 2012 16:50:45 +0000 (UTC) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-2.mail.thdo.gradwell.net (Postfix) with ESMTP id C17E7225B5 for ; Mon, 27 Aug 2012 17:49:52 +0100 (BST) Received: from cpc2-chap5-0-0-cust256.aztw.cable.virginmedia.com (HELO propellor.libeljournal.com) (77.103.165.1) (smtp-auth username hirez, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (AES256-SHA encrypted) ESMTPSA; Mon, 27 Aug 2012 18:30:16 +0100 Received: from propellor.libeljournal.com (localhost [127.0.0.1]) by propellor.libeljournal.com (Postfix) with ESMTP id 5E88817080 for ; Mon, 27 Aug 2012 17:49:51 +0100 (BST) X-Virus-Scanned: amavisd-new at libeljournal.com Received: from propellor.libeljournal.com ([127.0.0.1]) by propellor.libeljournal.com (propellor.libeljournal.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIs3GmqjwNVx for ; Mon, 27 Aug 2012 17:49:46 +0100 (BST) Received: from [172.16.0.10] (twister.libeljournal.com [172.16.0.10]) by propellor.libeljournal.com (Postfix) with ESMTPA id DAD2717030 for ; Mon, 27 Aug 2012 17:49:45 +0100 (BST) Message-ID: <503BA51E.4030103@libeljournal.com> Date: Mon, 27 Aug 2012 17:49:34 +0100 From: John Hawkes-Reed User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gradwell-MongoId: 503baea8.f5f3-1cec-2 X-Gradwell-Auth-Method: smtpauth X-Gradwell-Auth-Credentials: hirez Subject: IPv6 default route. Can't see the wood for the trees. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 16:50:46 -0000 I'm sure this is a FAQ, but I've been staring at it too long to spot the obvious. BSD-box (9.1-PRE) is acting as default router/NAT gateway for local LAN. IP4 works. IP6 rig, per the setup on tunnelbroker.net, appears to work on the BSD box. However, while LAN clients (XP, OSX) manage to acquire addresses with the right prefix, the autoconfigured default route is a link-local address. Some bits of the internet think that's ok. Other bits don't. Trying to ping6/traceroute6 out to (say) Google works on the BSD box, but not on the clients. Do I need to be running a routing daemon, or is there some ip6 handwaving I'm missing? rc.conf: (I'm not convinced that obfuscating the addresses is worth the confusion) ipv6_gateway_enable="YES" ip6addrctl_verbose="YES" rtadvd_enable="YES" rtadvd_interfaces="rl0" ipv6_cpe_wanif="pcn0" ipv6_defaultrouter="2001:470:1f0a:b5a::1" gif_interfaces="gif0" gifconfig_gif0="192.168.1.100 216.66.80.30" ifconfig_gif0_ipv6="inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 prefixlen 128" ifconfig_pcn0_ipv6="inet6 2001:470:1f0b:b5a::4 prefixlen 64" ifconfig_rl0_ipv6="inet6 2001:470:1f0b:b5a::3 prefixlen 64 -accept_rtadv" -- JH-R From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 17:05:11 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78B251065674 for ; Mon, 27 Aug 2012 17:05:11 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 324178FC0C for ; Mon, 27 Aug 2012 17:05:10 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T62kK-0006DG-49 for freebsd-stable@freebsd.org; Mon, 27 Aug 2012 19:05:04 +0200 Received: from d135-185.icpnet.pl ([109.173.135.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Aug 2012 19:05:04 +0200 Received: from sthalik by d135-185.icpnet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Aug 2012 19:05:04 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: =?UTF-8?B?U3RhbmlzxYJhdyBIYWxpaw==?= Date: Mon, 27 Aug 2012 18:56:35 +0200 Lines: 13 Message-ID: References: <503BA51E.4030103@libeljournal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: d135-185.icpnet.pl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: <503BA51E.4030103@libeljournal.com> Subject: Re: IPv6 default route. Can't see the wood for the trees. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:05:11 -0000 On 2012-08-27 18:49, John Hawkes-Reed wrote: > I'm sure this is a FAQ, but I've been staring at it too long to spot the > obvious. > rtadvd_interfaces="rl0" Show also /etc/rtadvd.conf. Here's mine: kronstadt ~# cat /etc/rtadvd.conf vr0::rdnss="2001:470:600d:dead::1":dnssl="misaki.pl":addr="2001:470:600d:dead::": vr2::rdnss="2001:470:600d:cafe::1":dnssl="misaki.pl":addr="2001:470:600d:cafe::": Show also ifconfig for rl0, which should be the local interface. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 17:15:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F104610657D8 for ; Mon, 27 Aug 2012 17:15:31 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 4DF218FC08 for ; Mon, 27 Aug 2012 17:15:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q7RHFNxS051510; Tue, 28 Aug 2012 03:15:23 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 28 Aug 2012 03:15:23 +1000 (EST) From: Ian Smith To: jb In-Reply-To: Message-ID: <20120828024834.K33776@sola.nimnet.asn.au> References: <503B6BCB.10407@gmx.us> <503B87C2.5080308@gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-204813080-1346087723=:33776" Cc: Mike Manilone , freebsd-stable@freebsd.org, Christian Mangin Subject: Re: Temperature too high when high overload X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:15:32 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-204813080-1346087723=:33776 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Mon, 27 Aug 2012 16:37:41 +0000 (UTC), jb wrote: > Christian Mangin gmail.com> writes: > > Le 27.08.2012 08:44, Mike Manilone a écrit : > > > Hi all, > > > > > > I just switched from Fedora Linux to FreeBSD. But I noticed a problem, > > > the CPU temperature will be very high when the load is high. > > > Especially while I am building C++ programs. It shut down for even 3 > > > times while I was building Firefox/Thunderbird, just because of high > > > temperature (86.5C). Mike, 86.5C isn't really all that hot for a modern 4-core laptop under load; like jb below, show us `sysctl -a | grep thermal` so we can see its passive cooling and critical temperatures. > > I used to have the same problem with my laptop (i5) and this can be > > fixed by lowering the temperature threshold for passive cooling. (_PSV) > > > > hw.acpi.thermal.user_override=1 > > hw.acpi.thermal.tz0._PSV=80C > > > > You should try to adjust _PSV to be significantly lower (> 15-20C) than > > the _CRT (critical shutdown temp) so that _CRT is never reached. > > > > Christian Modulo adjusting the right thermal zone, this is safe advice; you can always edge it up later, assuming it helps stay at say 10C below _CRT. > I too have the same problem (Lenovo dual core r61i). > You should see the relevant data before making any changes - below it is > explained why. > > This is my data: > $ sysctl -a | grep -i thermal > hw.acpi.thermal.min_runtime: 0 > hw.acpi.thermal.polling_rate: 10 > hw.acpi.thermal.user_override: 0 > hw.acpi.thermal.tz0.temperature: 42.0C > hw.acpi.thermal.tz0.active: -1 > hw.acpi.thermal.tz0.passive_cooling: 0 > hw.acpi.thermal.tz0.thermal_flags: 0 > hw.acpi.thermal.tz0._PSV: -1 > hw.acpi.thermal.tz0._HOT: -1 > hw.acpi.thermal.tz0._CRT: 127.0C > hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz0._TC1: -1 > hw.acpi.thermal.tz0._TC2: -1 > hw.acpi.thermal.tz0._TSP: -1 > hw.acpi.thermal.tz1.temperature: 42.0C > hw.acpi.thermal.tz1.active: -1 > hw.acpi.thermal.tz1.passive_cooling: 1 > hw.acpi.thermal.tz1.thermal_flags: 0 > hw.acpi.thermal.tz1._PSV: 95.5C > hw.acpi.thermal.tz1._HOT: -1 > hw.acpi.thermal.tz1._CRT: 100.0C > hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 > hw.acpi.thermal.tz1._TC1: 5 > hw.acpi.thermal.tz1._TC2: 4 > hw.acpi.thermal.tz1._TSP: 600 > dev.acpi_tz.0.%desc: Thermal Zone > dev.acpi_tz.1.%desc: Thermal Zone > dev.p4tcc.0.%desc: CPU Frequency Thermal Control > dev.p4tcc.1.%desc: CPU Frequency Thermal Control > $ > > As you can see in my case: > hw.acpi.thermal.tz0.passive_cooling: 0 > which is NOT available (so obviously any settings in tz0 zone are irrelevant). That tz0 seems not to be a CPU, nor a fan. Maybe just informational? > This is explained here: > ACPI_THERMAL(4): > ... > hw.acpi.thermal.tz%d.passive_cooling > If set to 1, passive cooling is enabled. It does cooling without > fans using cpufreq(4) as the mechanism for controlling CPU speed. > Default is enabled for tz0 where it is available. > ... > > In my case tz1 zone is available and active. And your _PSV 95.5C and _CRT 100.0C aren't uncommon sort of values these days, hence my surprise at Mike's (apparent) CRT shutdown showing 86.5C. On the other hand, even my 1133MHz P3-M can go from <50C to >60C inside one 10-second polling interval under applied high load, so a shorter hw.acpi.thermal.polling_rate may help trigger _PSV well before _CRT. cheers, Ian --0-204813080-1346087723=:33776-- From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 17:22:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 901A2106564A for ; Mon, 27 Aug 2012 17:22:42 +0000 (UTC) (envelope-from hirez@libeljournal.com) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by mx1.freebsd.org (Postfix) with ESMTP id 409438FC14 for ; Mon, 27 Aug 2012 17:22:41 +0000 (UTC) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id E569A21BD7 for ; Mon, 27 Aug 2012 18:22:34 +0100 (BST) Received: from cpc2-chap5-0-0-cust256.aztw.cable.virginmedia.com (HELO propellor.libeljournal.com) (77.103.165.1) (smtp-auth username hirez, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (AES256-SHA encrypted) ESMTPSA; Mon, 27 Aug 2012 19:03:04 +0100 Received: from propellor.libeljournal.com (localhost [127.0.0.1]) by propellor.libeljournal.com (Postfix) with ESMTP id 644CA17080 for ; Mon, 27 Aug 2012 18:22:31 +0100 (BST) X-Virus-Scanned: amavisd-new at libeljournal.com Received: from propellor.libeljournal.com ([127.0.0.1]) by propellor.libeljournal.com (propellor.libeljournal.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfXbIX0r3z2b for ; Mon, 27 Aug 2012 18:22:27 +0100 (BST) Received: from [172.16.0.10] (twister.libeljournal.com [172.16.0.10]) by propellor.libeljournal.com (Postfix) with ESMTPA id 1873817030 for ; Mon, 27 Aug 2012 18:22:26 +0100 (BST) Message-ID: <503BACCB.7070507@libeljournal.com> Date: Mon, 27 Aug 2012 18:22:19 +0100 From: John Hawkes-Reed User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <503BA51E.4030103@libeljournal.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Gradwell-MongoId: 503bb658.f26d-1b74-2 X-Gradwell-Auth-Method: smtpauth X-Gradwell-Auth-Credentials: hirez Subject: Re: IPv6 default route. Can't see the wood for the trees. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:22:42 -0000 On 27/08/2012 17:56, StanisÅ‚aw Halik wrote: > On 2012-08-27 18:49, John Hawkes-Reed wrote: >> I'm sure this is a FAQ, but I've been staring at it too long to spot the >> obvious. > >> rtadvd_interfaces="rl0" > > Show also /etc/rtadvd.conf. Here's mine: > > kronstadt ~# cat /etc/rtadvd.conf > vr0::rdnss="2001:470:600d:dead::1":dnssl="misaki.pl":addr="2001:470:600d:dead::": > > vr2::rdnss="2001:470:600d:cafe::1":dnssl="misaki.pl":addr="2001:470:600d:cafe::": The man page seemed to suggest that the defaults should work: # rtadvctl -v show rl0: flags= status= mtu 1500 DefaultLifetime: 30m MinAdvInterval/MaxAdvInterval: 3m20s/10m AdvLinkMTU: , Flags: , Preference: medium ReachableTime: 0s, RetransTimer: 0s, CurHopLimit: 64 AdvIfPrefixes: yes Next RA send: Mon Aug 27 18:24:48 2012 Last RA sent: Mon Aug 27 18:17:28 2012 Prefixes (1): 2001:470:1f0b:b5a::/64 (KERNEL, vltime=30d, pltime=7d, flags=LA) > Show also ifconfig for rl0, which should be the local interface. rl0: flags=8843 metric 0 mtu 1500 options=8 ether 00:20:18:8c:4e:8c inet 172.16.0.2 netmask 0xffffff00 broadcast 172.16.0.255 inet6 fe80::220:18ff:fe8c:4e8c%rl0 prefixlen 64 scopeid 0x3 inet6 2001:470:1f0b:b5a::3 prefixlen 64 nd6 options=21 media: Ethernet autoselect (100baseTX ) status: active -- JH-R From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 17:40:05 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF9BE106575B for ; Mon, 27 Aug 2012 17:40:05 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6000A8FC16 for ; Mon, 27 Aug 2012 17:40:04 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T63IA-0004FK-J2 for freebsd-stable@freebsd.org; Mon, 27 Aug 2012 19:40:02 +0200 Received: from d135-185.icpnet.pl ([109.173.135.185]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Aug 2012 19:40:02 +0200 Received: from sthalik by d135-185.icpnet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 27 Aug 2012 19:40:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: =?UTF-8?B?U3RhbmlzxYJhdyBIYWxpaw==?= Date: Mon, 27 Aug 2012 19:39:50 +0200 Lines: 12 Message-ID: References: <503BA51E.4030103@libeljournal.com> <503BACCB.7070507@libeljournal.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: d135-185.icpnet.pl User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: <503BACCB.7070507@libeljournal.com> Subject: Re: IPv6 default route. Can't see the wood for the trees. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 17:40:05 -0000 On 2012-08-27 19:22, John Hawkes-Reed wrote: > The man page seemed to suggest that the defaults should work: Try this option for each interface. Given that it's present in my config, it must've been necessary to use for a one reason or other. addr (str) The address filled into Prefix field. Since “:†is used for termcap(5) file format as well as IPv6 numeric address, the field MUST be quoted by doublequote character. Sorry I couldn't be much help. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 18:06:34 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DDE1106566B for ; Mon, 27 Aug 2012 18:06:34 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from kazon.borderworlds.dk (kazon.borderworlds.dk [IPv6:2a01:4f8:101:4201::1:1]) by mx1.freebsd.org (Postfix) with ESMTP id CAC068FC12 for ; Mon, 27 Aug 2012 18:06:33 +0000 (UTC) Received: from talaxian.borderworlds.dk (localhost [127.0.0.1]) by kazon.borderworlds.dk (Postfix) with ESMTP id 1A4B55C34 for ; Mon, 27 Aug 2012 20:06:26 +0200 (CEST) Message-ID: <503BB721.9000108@borderworlds.dk> Date: Mon, 27 Aug 2012 20:06:25 +0200 From: Christian Laursen Organization: The Border Worlds User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <503BA51E.4030103@libeljournal.com> In-Reply-To: <503BA51E.4030103@libeljournal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: IPv6 default route. Can't see the wood for the trees. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:06:34 -0000 On 08/27/12 18:49, John Hawkes-Reed wrote: > BSD-box (9.1-PRE) is acting as default router/NAT gateway for local LAN. > IP4 works. > > IP6 rig, per the setup on tunnelbroker.net, appears to work on the BSD box. > > However, while LAN clients (XP, OSX) manage to acquire addresses with > the right prefix, the autoconfigured default route is a link-local > address. Some bits of the internet think that's ok. Other bits don't. Bits of the internet does not see anything about whether your default gateway is link-local or not and do not care. The default gateway on the box that I'm writing this from is link-local and IPv6 works quite nicely. > Trying to ping6/traceroute6 out to (say) Google works on the BSD box, > but not on the clients. > > Do I need to be running a routing daemon, or is there some ip6 > handwaving I'm missing? If you are running pf or another firewall, you should have rules that allow traffic to pass through. > rc.conf: > > (I'm not convinced that obfuscating the addresses is worth the confusion) > > ipv6_gateway_enable="YES" > ip6addrctl_verbose="YES" > rtadvd_enable="YES" > rtadvd_interfaces="rl0" > ipv6_cpe_wanif="pcn0" > ipv6_defaultrouter="2001:470:1f0a:b5a::1" > gif_interfaces="gif0" > gifconfig_gif0="192.168.1.100 216.66.80.30" > ifconfig_gif0_ipv6="inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 > prefixlen 128" > ifconfig_pcn0_ipv6="inet6 2001:470:1f0b:b5a::4 prefixlen 64" > ifconfig_rl0_ipv6="inet6 2001:470:1f0b:b5a::3 prefixlen 64 -accept_rtadv" It looks like you are trying to use the /64 used for your tunnel on the inside network. That's probably what causes the problem. You should use the "Routed /64" on the inside. If you need more than one /64, you can request a /48. I'm not exactly sure what ipv6_cpe_wanif does, but I have never needed it and I run a setup similar to what you describe. -- Christian Laursen From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 18:40:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0844106564A; Mon, 27 Aug 2012 18:40:40 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id B51128FC23; Mon, 27 Aug 2012 18:40:40 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 1648AB9A8; Mon, 27 Aug 2012 14:40:40 -0400 (EDT) From: John Baldwin To: Per olof Ljungmark , Alexander Motin Date: Mon, 27 Aug 2012 13:14:07 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <5007CFE6.6030808@intersonic.se> <201208211509.35488.jhb@freebsd.org> <503A0DBF.2090307@intersonic.se> In-Reply-To: <503A0DBF.2090307@intersonic.se> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208271314.07376.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 27 Aug 2012 14:40:40 -0400 (EDT) Cc: freebsd-stable@freebsd.org, jb , Martin Dieringer Subject: Re: Thinkpad X61s cannot boot 9.1-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:40:41 -0000 On Sunday, August 26, 2012 7:51:27 am Per olof Ljungmark wrote: > On our X61s's setting 'debug.acpi.disabled="hostres"' does not change > the inability to boot 9-BETA1, 9-RC1 or -current. > > What does fix it however, is to change the Kingston SSD drive to a > standard mechanical one. This is verified on three different X61s's, see > > http://www.freebsd.org/cgi/query-pr.cgi?pr=amd64/170487 > > Is there something else I could try or should I just switch drive and be > fine with it? > > I'm happy to try anything you suggest. Hmm, I have no idea on this one. You'd have to ask Alexander Motin (cc'd) about that. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 18:40:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 339D31065679 for ; Mon, 27 Aug 2012 18:40:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0777A8FC26 for ; Mon, 27 Aug 2012 18:40:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 48814B99A; Mon, 27 Aug 2012 14:40:42 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org, Martin Dieringer Date: Mon, 27 Aug 2012 13:54:17 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <5007CFE6.6030808@intersonic.se> <503A57DB.3020503@intersonic.se> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208271354.17832.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 27 Aug 2012 14:40:42 -0400 (EDT) Cc: Kurt Jaeger Subject: Re: Thinkpad X61s cannot boot 9.1-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:40:43 -0000 On Sunday, August 26, 2012 6:59:22 pm Martin Dieringer wrote: > On Sun, 26 Aug 2012, Per olof Ljungmark wrote: > > > On 08/26/12 18:37, Kurt Jaeger wrote: > >> Hi! > >> > >>> On our X61s's setting 'debug.acpi.disabled="hostres"' does not change > >>> the inability to boot 9-BETA1, 9-RC1 or -current. > >> > >> I tested 9.1-RC1 on X61, and it worked without any troubles. > >> > > > > Yes, it does on this one too if I install a mechanical disk. The problem is > > related to installing on a SSD drive, Kingston SSDNow SV200S37A/128G. > > > > This must be related to a change in the base system some time between > > 9.0-RELEASE and -BETA1 as 9.0 runs and installs fine. Perhaps someone could > > suggest anther SSD drive with equal capacity that works? > > > debug.acpi.disabled="hostres" fixed it for me on T61 and T410 > with normal HD and (older) SSD (OCZ Summit) > > FreeBSD 9.1-PRERELEASE #16: Tue Aug 21 Can you get a verbose dmesg both with and without the "hostres" setting? -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 18:40:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 271B4106567A for ; Mon, 27 Aug 2012 18:40:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id F184E8FC27 for ; Mon, 27 Aug 2012 18:40:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 56BF2B9B3; Mon, 27 Aug 2012 14:40:43 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 27 Aug 2012 14:07:58 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <20120827131311.GE1442@albert.catwhisker.org> In-Reply-To: <20120827131311.GE1442@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201208271407.58146.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 27 Aug 2012 14:40:43 -0400 (EDT) Cc: Subject: Re: FreeBSD/i386 stable/9 @239722: REDZONE: Buffer underflow detected X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:40:44 -0000 On Monday, August 27, 2012 9:13:11 am David Wolfskill wrote: > Starting devd. > REDZONE: Buffer underflow detected. 1 byte corrupted before 0xced40080 (4294966796 bytes allocated). This size seems wait outlandish. The only malloc in devctl_queue_data_f() is: struct dev_event_info *n1 = NULL, *n2 = NULL; ... n1 = malloc(sizeof(*n1), M_BUS, flags); On amd64 that structure's size is 24 bytes. On i386 it is probably similar. Certainly not 4GB. I cannot see any overflow bugs with 'struct dev_event_info' objects. In this case I think the redzone metadata that specified the object's size was corrupted, but I've no idea how that could occur. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 18:42:15 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18A9B106589A for ; Mon, 27 Aug 2012 18:42:15 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id A8C168FC22 for ; Mon, 27 Aug 2012 18:42:14 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q7RIg7T5048598; Mon, 27 Aug 2012 12:42:07 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q7RIg7Q0048595; Mon, 27 Aug 2012 12:42:07 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 27 Aug 2012 12:42:07 -0600 (MDT) From: Warren Block To: Matt Smith In-Reply-To: <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> Message-ID: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 27 Aug 2012 12:42:07 -0600 (MDT) Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:42:15 -0000 On Mon, 27 Aug 2012, Matt Smith wrote: > On 2012-08-27 14:56, Warren Block wrote: >> >> Stefan called it. The newfs is done on /dev/gpt/gptroot, no problem >> there. But when glabel writes to /dev/ada0p2--which is >> /dev/gpt/gptroot, same thing, it overwrites the last block. And then >> the filesystem is mounted with the glabel device, which is actually >> one block smaller than the filesystem expects. >> >> Could be either the filesystem or GEOM that's causing the failure at >> shutdown. >> >> Happily, those glabels aren't accomplishing anything useful and can >> be skipped. Removing the glabels and changing the devices in fstab >> might be enough. A more cautious approach would be to back up, newfs, >> skip the glabel step, and then change the devices in fstab. > > As I said on a previous mail I did boot it with a USB stick and cleared the > glabel metadata and altered the fstab to point to both the GPT labels and the > raw UFS device and I still get the issue. So am I right in thinking then that > this has caused irreparable damage To the filesystem? Probably (weasel word) not. The old instructions for gmirror used the last block out of a filesystem and there have been no notable reports of data loss. One thing to mention is that SU+J might change what the filesystem does with that last block. I'm avoiding SU+J until the dump problem is fixed, so have not experimented with that. > and the only way I can fix this now is to newfs the filesystem again, > this time just using GPT labels and not using glabel at all? I'll commit to it and say yes, that will work. > This is the first time I've ever done a manually partitioned installation > with GPT and alignment, previously I've only ever used sysinstall with > non-aligned MBR installations, so it was a bit of a learning curve. If I do > have to newfs it again then I want to be sure that I'm doing the correct > things so that I don't find myself with any other issues. So does the rest of > what I did look fine? No obvious problems jumped out at me. Here are my notes: http://www.wonkity.com/~wblock/docs/html/disksetup.html The gpart version is halfway down. I really need to switch that around. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 18:58:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 800E11065670 for ; Mon, 27 Aug 2012 18:58:30 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 3665E8FC21 for ; Mon, 27 Aug 2012 18:58:30 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q7RIwTpv048857; Mon, 27 Aug 2012 12:58:29 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q7RIwTcx048854; Mon, 27 Aug 2012 12:58:29 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 27 Aug 2012 12:58:29 -0600 (MDT) From: Warren Block To: Matt Smith In-Reply-To: Message-ID: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 27 Aug 2012 12:58:29 -0600 (MDT) Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 18:58:30 -0000 On Mon, 27 Aug 2012, Warren Block wrote: > No obvious problems jumped out at me. Here are my notes: > http://www.wonkity.com/~wblock/docs/html/disksetup.html > > The gpart version is halfway down. I really need to switch that around. Changed now so that the gpart(8) version is first. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 19:04:10 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5420106566C for ; Mon, 27 Aug 2012 19:04:10 +0000 (UTC) (envelope-from hirez@libeljournal.com) Received: from outbound-queue-1.mail.thdo.gradwell.net (outbound-queue-1.mail.thdo.gradwell.net [212.11.70.34]) by mx1.freebsd.org (Postfix) with ESMTP id 49C9C8FC18 for ; Mon, 27 Aug 2012 19:04:09 +0000 (UTC) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-1.mail.thdo.gradwell.net (Postfix) with ESMTP id 26D2E21D45 for ; Mon, 27 Aug 2012 20:04:09 +0100 (BST) Received: from cpc2-chap5-0-0-cust256.aztw.cable.virginmedia.com (HELO propellor.libeljournal.com) (77.103.165.1) (smtp-auth username hirez, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (AES256-SHA encrypted) ESMTPSA; Mon, 27 Aug 2012 20:45:05 +0100 Received: from propellor.libeljournal.com (localhost [127.0.0.1]) by propellor.libeljournal.com (Postfix) with ESMTP id 23A0A170BD for ; Mon, 27 Aug 2012 20:04:07 +0100 (BST) X-Virus-Scanned: amavisd-new at libeljournal.com Received: from propellor.libeljournal.com ([127.0.0.1]) by propellor.libeljournal.com (propellor.libeljournal.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1Rm4LA65Rwd for ; Mon, 27 Aug 2012 20:03:58 +0100 (BST) Received: from [172.16.0.10] (twister.libeljournal.com [172.16.0.10]) by propellor.libeljournal.com (Postfix) with ESMTPA id 988E817082 for ; Mon, 27 Aug 2012 20:03:58 +0100 (BST) Message-ID: <503BC497.3060206@libeljournal.com> Date: Mon, 27 Aug 2012 20:03:51 +0100 From: John Hawkes-Reed User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <503BA51E.4030103@libeljournal.com> <503BB721.9000108@borderworlds.dk> In-Reply-To: <503BB721.9000108@borderworlds.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gradwell-MongoId: 503bce41.14c71-46b0-2 X-Gradwell-Auth-Method: smtpauth X-Gradwell-Auth-Credentials: hirez Subject: Re: IPv6 default route. Can't see the wood for the trees. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:04:10 -0000 On 27/08/2012 19:06, Christian Laursen wrote: > On 08/27/12 18:49, John Hawkes-Reed wrote: >> BSD-box (9.1-PRE) is acting as default router/NAT gateway for local LAN. >> IP4 works. >> >> IP6 rig, per the setup on tunnelbroker.net, appears to work on the BSD >> box. >> >> However, while LAN clients (XP, OSX) manage to acquire addresses with >> the right prefix, the autoconfigured default route is a link-local >> address. Some bits of the internet think that's ok. Other bits don't. > > Bits of the internet does not see anything about whether your default > gateway is link-local or not and do not care. > > The default gateway on the box that I'm writing this from is link-local > and IPv6 works quite nicely. Aha. Good. > >> Trying to ping6/traceroute6 out to (say) Google works on the BSD box, >> but not on the clients. >> >> Do I need to be running a routing daemon, or is there some ip6 >> handwaving I'm missing? > > If you are running pf or another firewall, you should have rules that > allow traffic to pass through. Yep. firewall_type="OPEN" - I wondered if 'allow ip from any to any' included ipv6, and it would seem that it does. >> rc.conf: >> >> (I'm not convinced that obfuscating the addresses is worth the confusion) >> >> ipv6_gateway_enable="YES" >> ip6addrctl_verbose="YES" >> rtadvd_enable="YES" >> rtadvd_interfaces="rl0" >> ipv6_cpe_wanif="pcn0" >> ipv6_defaultrouter="2001:470:1f0a:b5a::1" >> gif_interfaces="gif0" >> gifconfig_gif0="192.168.1.100 216.66.80.30" >> ifconfig_gif0_ipv6="inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 >> prefixlen 128" >> ifconfig_pcn0_ipv6="inet6 2001:470:1f0b:b5a::4 prefixlen 64" >> ifconfig_rl0_ipv6="inet6 2001:470:1f0b:b5a::3 prefixlen 64 >> -accept_rtadv" > > It looks like you are trying to use the /64 used for your tunnel on the > inside network. That's probably what causes the problem. > > You should use the "Routed /64" on the inside. If you need more than one > /64, you can request a /48. I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B: > I'm not exactly sure what ipv6_cpe_wanif does, but I have never needed > it and I run a setup similar to what you describe. -- JH-R From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 19:06:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A03A106566C for ; Mon, 27 Aug 2012 19:06:16 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0B33A8FC1C for ; Mon, 27 Aug 2012 19:06:16 +0000 (UTC) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.xtaz.co.uk (Postfix) with ESMTPS id C59F4DEF24C; Mon, 27 Aug 2012 20:06:14 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 27 Aug 2012 20:06:14 +0100 From: Matt Smith To: Warren Block In-Reply-To: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> Message-ID: <79cd5f15b21566846e5ef3579f67668b@xtaz.co.uk> X-Sender: matt@xtaz.co.uk User-Agent: Roundcube Webmail/0.8.1 Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:06:16 -0000 On 2012-08-27 19:42, Warren Block wrote: > No obvious problems jumped out at me. Here are my notes: > http://www.wonkity.com/~wblock/docs/html/disksetup.html > > The gpart version is halfway down. I really need to switch that > around. Oooooh! You're the owner of that site. As it happens those were the exact instructions that I used to try and figure out how to do it as you are first in google for "freebsd gpt newfs"! It's just a shame that I then decided to use the same method that I had used before on my old system for the labelling. On my old system I had used MBR partitioning and so needed to use glabel for labelling the swap and I then used the same thing for the UFS partition for consistency in the fstab. It never occurred to me when I was labelling the GPT partitions that I could have used those directly. One thing that is still bugging me though is I'm wondering why I had no problem with this on my old system. That was using a dangerously dedicated disk with MBR where the root partition was just /dev/ada4a. It was also using UFS2 with SU+J enabled and I had used glabel in exactly the same way but on this box it had not done any damage. Shutdown etc worked perfectly fine. Is there something different with the way GPT partitions work? Thank you for your help anyway, and your wonkity site, which I also once used for converting my procmail to maildrop. And thanks also to Erich and Stefan for your help. When I get some spare time I'll redo the filesystem and hope that it works. Matt. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 19:06:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EAA8B106568D for ; Mon, 27 Aug 2012 19:06:50 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 6EEBE8FC1D for ; Mon, 27 Aug 2012 19:06:50 +0000 (UTC) Received: by wicr5 with SMTP id r5so2950311wic.13 for ; Mon, 27 Aug 2012 12:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vIWir2FyfTQMGXpG4FgKOwjHzSgBRScV4NRkFH7cdVc=; b=LmVfPFViKI7MSfVmaENF/KSUj/aiOb+7L3JEU20yRJG/tI/quHktr9zd7REkL9VFR7 9tF331yorEgt8N3S0nJhsKR3S+ofiMUe+nnff10LJb2b8Z5sxwi9uwW7b1Fi4OFdYrXv 7wtLmejHhb5fMrK9ukXBehX0wrBn3yr3JPm/ZF8HhW3ZuPPtDcCB6XLDd9SLFaWvoSzz cRx9jJEl0TaVRDeJ47wf9fiZcD/eL3/D43RRKwIWwHKC9ZPvMODJsc/GanfBSNFOtKY6 8oPUbM8ra7XRTMr4JPlEJhHgwsSeF6m1v6qyXpSr+k3RSU3XB7vGB1YgeHOJVBnn0QnU 4flw== MIME-Version: 1.0 Received: by 10.216.237.161 with SMTP id y33mr810172weq.62.1346094409277; Mon, 27 Aug 2012 12:06:49 -0700 (PDT) Received: by 10.223.63.76 with HTTP; Mon, 27 Aug 2012 12:06:49 -0700 (PDT) In-Reply-To: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> Date: Mon, 27 Aug 2012 12:06:49 -0700 Message-ID: From: Kevin Oberman To: Warren Block Content-Type: text/plain; charset=UTF-8 Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke , Matt Smith Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:06:51 -0000 On Mon, Aug 27, 2012 at 11:42 AM, Warren Block wrote: > On Mon, 27 Aug 2012, Matt Smith wrote: > >> On 2012-08-27 14:56, Warren Block wrote: >>> >>> >>> Stefan called it. The newfs is done on /dev/gpt/gptroot, no problem >>> there. But when glabel writes to /dev/ada0p2--which is >>> /dev/gpt/gptroot, same thing, it overwrites the last block. And then >>> the filesystem is mounted with the glabel device, which is actually >>> one block smaller than the filesystem expects. >>> >>> Could be either the filesystem or GEOM that's causing the failure at >>> shutdown. >>> >>> Happily, those glabels aren't accomplishing anything useful and can >>> be skipped. Removing the glabels and changing the devices in fstab >>> might be enough. A more cautious approach would be to back up, newfs, >>> skip the glabel step, and then change the devices in fstab. >> >> >> As I said on a previous mail I did boot it with a USB stick and cleared >> the glabel metadata and altered the fstab to point to both the GPT labels >> and the raw UFS device and I still get the issue. So am I right in thinking >> then that this has caused irreparable damage > > > To the filesystem? Probably (weasel word) not. The old instructions for > gmirror used the last block out of a filesystem and there have been no > notable reports of data loss. > > One thing to mention is that SU+J might change what the filesystem does with > that last block. I'm avoiding SU+J until the dump problem is fixed, so have > not experimented with that. > >> and the only way I can fix this now is to newfs the filesystem again, this >> time just using GPT labels and not using glabel at all? > > > I'll commit to it and say yes, that will work. > >> This is the first time I've ever done a manually partitioned installation >> with GPT and alignment, previously I've only ever used sysinstall with >> non-aligned MBR installations, so it was a bit of a learning curve. If I do >> have to newfs it again then I want to be sure that I'm doing the correct >> things so that I don't find myself with any other issues. So does the rest >> of what I did look fine? > > > No obvious problems jumped out at me. Here are my notes: > http://www.wonkity.com/~wblock/docs/html/disksetup.html > > The gpart version is halfway down. I really need to switch that around. Pretty good page, but I would really suggest that you also do either 4k or 1M alignment on your partitions. If you don't and use a disk with 4K blocks (internally), you will have terrible performance. 1M is recommended by Microsoft and used by Windows, but seems a bit excessive to me. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 19:22:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58BBA1065670; Mon, 27 Aug 2012 19:22:41 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.giulioferro.ch (mx1.giulioferro.ch [217.150.252.208]) by mx1.freebsd.org (Postfix) with ESMTP id EDEB38FC14; Mon, 27 Aug 2012 19:22:40 +0000 (UTC) Received: from mailscan.giulioferro.ch (unknown [192.168.115.2]) by mx1.giulioferro.ch (Postfix) with ESMTP id 28DDE7382F; Mon, 27 Aug 2012 21:22:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from mx1.giulioferro.ch ([192.168.114.4]) by mailscan.giulioferro.ch (mailscan.giulioferro.ch [192.168.115.2]) (amavisd-new, port 10024) with ESMTP id 2wz4yVuiiZ04; Mon, 27 Aug 2012 21:22:31 +0200 (CEST) Received: from mail.zirakzigil.org (net-93-70-48-129.cust.dsl.vodafone.it [93.70.48.129]) by mx1.giulioferro.ch (Postfix) with ESMTP id 6972C73824; Mon, 27 Aug 2012 21:22:31 +0200 (CEST) Received: from ext.zirakzigil.org (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id 2B50F19BDA0; Mon, 27 Aug 2012 21:18:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by ext.zirakzigil.org (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id vpKMhPtnNxgB; Mon, 27 Aug 2012 21:18:11 +0200 (CEST) Received: from [192.168.231.11] (ext [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 0F49119BD9B; Mon, 27 Aug 2012 21:18:10 +0200 (CEST) Message-ID: <503BC8F5.3040208@zirakzigil.org> Date: Mon, 27 Aug 2012 21:22:29 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:22:41 -0000 Hi, thanks for the answer Here is what you asked for: # ifconfig igb0 igb0: flags=8843 metric 0 mtu 1500 options=4401bb ether ... inet 192.168.9.60 netmask 0xffffff00 broadcast 192.168.9.255 inet6 .... prefixlen 64 scopeid 0x1 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active # netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.9.1 UGS 0 0 igb0 127.0.0.1 link#12 UH 0 0 lo0 192.168.9.0/24 link#1 U 0 14 igb0 192.168.9.60 link#1 UHS 0 0 lo0 192.168.12.0/24 link#13 U 0 109 lagg0 192.168.12.21 link#13 UHS 0 0 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#12 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%igb0/64 link#1 U igb0 fe80::ea39:35ff:feb6:a0d4%igb0 link#1 UHS lo0 fe80::%igb1/64 link#2 U igb1 fe80::ea39:35ff:feb6:a0d5%igb1 link#2 UHS lo0 fe80::%igb2/64 link#3 U igb2 fe80::ea39:35ff:feb6:a0d6%igb2 link#3 UHS lo0 fe80::%igb3/64 link#4 U igb3 fe80::ea39:35ff:feb6:a0d7%igb3 link#4 UHS lo0 fe80::%lo0/64 link#12 U lo0 fe80::1%lo0 link#12 UHS lo0 fe80::%lagg0/64 link#13 U lagg0 fe80::ea39:35ff:feb6:a0d5%lagg0 link#13 UHS lo0 ff01::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 ff01::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 ff01::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 ff01::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 ff01::%lo0/32 ::1 U lo0 ff01::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U lagg0 ff02::/16 ::1 UGRS lo0 ff02::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 ff02::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 ff02::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 ff02::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 ff02::%lo0/32 ::1 U lo0 ff02::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U lagg0 # netstat -aln | grep 22 tcp4 0 0 *.22 *.* LISTEN tcp6 0 0 *.22 *.* LISTEN Note that I already tried to only listen on igb0 interface (192.168.9.60) in sshd_config, but the results are exactly the same described below. On 08/25/2012 01:22 PM, Damien Fleuriot wrote: > In the meantime kindly post: > > > Ifconfig for your igb0 > Netstat -rn > Netstat -aln | grep 22 > > > > On 25 Aug 2012, at 13:18, Damien Fleuriot wrote: > >> I'll get back to you regarding link aggregation when I'm done with groceries. >> >> We use it here in production and it works flawlessly. >> >> >> >> On 25 Aug 2012, at 09:54, Giulio Ferro wrote: >> >>> No answer, so it seems that link aggregation doesn't really work in freebsd, >>> this may help others with the same problem... >>> >>> I reverted back to one link for management and one for service, and ssh >>> works as it should... >>> >>> >>> On 08/21/2012 11:18 PM, Giulio Ferro wrote: >>>> Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (igb) >>>> >>>> 1 nic is connected standalone to the management switch, the 3 other nics >>>> are connected to a switch configured for aggregation. >>>> >>>> If I configure the first nic (igb0) there is no problem, I can operate >>>> as I normally do and sshd functions normally. >>>> >>>> The problems start when I configure the 3 other nics for aggregation: >>>> >>>> in /etc/rc.conf >>>> ... >>>> ifconfig_igb1="up" >>>> ifconfig_igb2="up" >>>> ifconfig_igb3="up" >>>> >>>> cloned_interfaces=lagg0 >>>> ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport igb3 192.168.12.7/24" >>>> ... >>>> >>>> I restart the server and the aggregation seems to work correctly, in >>>> fact ifconfig returns the correct lagg0 interface with the aggregated >>>> links, the correct protocol (lacp) and the correct ip address and the >>>> status is active. I can ping other IPs on the aggregated link. >>>> >>>> Also the other (standalone) link seems to work correctly. I can ping >>>> that address from other machines, and I can ping other IPs from that >>>> server. >>>> >>>> DNS lookups work ok too I can also use telnet to connect to pop3 >>>> servers so there seems to be no problem on the network stack. >>>> >>>> But if I try to connect to the sshd service on that server, it hangs >>>> indefinitely. On the server I find two sshd processes: >>>> /usr/sbin/sshd >>>> /usr/sbin/sshd -R >>>> >>>> There is no message in the logs. >>>> >>>> If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays there >>>> forever waiting for the pid to die (it never does) >>>> >>>> Even ssh client doesn't seem to work. In fact, if I try to connect to >>>> another server, the ssh client may start to work correctly, then soon >>>> or later it just hangs there forever, and I can't kill it with ctrl-c. >>>> >>>> No firewall is configured, there is nothing else working on this server. >>>> >>>> Thanks for any suggestions... >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 19:27:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 77A631065670 for ; Mon, 27 Aug 2012 19:27:07 +0000 (UTC) (envelope-from xi@borderworlds.dk) Received: from kazon.borderworlds.dk (kazon.borderworlds.dk [IPv6:2a01:4f8:101:4201::1:1]) by mx1.freebsd.org (Postfix) with ESMTP id 1217F8FC19 for ; Mon, 27 Aug 2012 19:27:07 +0000 (UTC) Received: from talaxian.borderworlds.dk (localhost [127.0.0.1]) by kazon.borderworlds.dk (Postfix) with ESMTP id 598435C34 for ; Mon, 27 Aug 2012 21:27:06 +0200 (CEST) Message-ID: <503BCA0A.1020904@borderworlds.dk> Date: Mon, 27 Aug 2012 21:27:06 +0200 From: Christian Laursen Organization: The Border Worlds User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120727 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <503BA51E.4030103@libeljournal.com> <503BB721.9000108@borderworlds.dk> <503BC497.3060206@libeljournal.com> In-Reply-To: <503BC497.3060206@libeljournal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: IPv6 default route. Can't see the wood for the trees. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:27:07 -0000 On 08/27/12 21:03, John Hawkes-Reed wrote: > On 27/08/2012 19:06, Christian Laursen wrote: >> On 08/27/12 18:49, John Hawkes-Reed wrote: >>> rc.conf: >>> >>> (I'm not convinced that obfuscating the addresses is worth the >>> confusion) >>> >>> ipv6_gateway_enable="YES" >>> ip6addrctl_verbose="YES" >>> rtadvd_enable="YES" >>> rtadvd_interfaces="rl0" >>> ipv6_cpe_wanif="pcn0" >>> ipv6_defaultrouter="2001:470:1f0a:b5a::1" >>> gif_interfaces="gif0" >>> gifconfig_gif0="192.168.1.100 216.66.80.30" >>> ifconfig_gif0_ipv6="inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 >>> prefixlen 128" >>> ifconfig_pcn0_ipv6="inet6 2001:470:1f0b:b5a::4 prefixlen 64" >>> ifconfig_rl0_ipv6="inet6 2001:470:1f0b:b5a::3 prefixlen 64 >>> -accept_rtadv" >> >> It looks like you are trying to use the /64 used for your tunnel on the >> inside network. That's probably what causes the problem. >> >> You should use the "Routed /64" on the inside. If you need more than one >> /64, you can request a /48. > > I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B: Sorry, my bad. Are pcn0 and rl0 both connected to internal networks? Having the same /64 configured on both is probably bad. -- Christian Laursen From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 19:31:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id D3A98106566C for ; Mon, 27 Aug 2012 19:31:52 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 8C54414DACA; Mon, 27 Aug 2012 19:31:21 +0000 (UTC) Message-ID: <503BCB0A.6000702@FreeBSD.org> Date: Mon, 27 Aug 2012 12:31:22 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Christian Laursen References: <503BA51E.4030103@libeljournal.com> <503BB721.9000108@borderworlds.dk> <503BC497.3060206@libeljournal.com> <503BCA0A.1020904@borderworlds.dk> In-Reply-To: <503BCA0A.1020904@borderworlds.dk> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: IPv6 default route. Can't see the wood for the trees. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 19:31:52 -0000 On 8/27/2012 12:27 PM, Christian Laursen wrote: > On 08/27/12 21:03, John Hawkes-Reed wrote: >> On 27/08/2012 19:06, Christian Laursen wrote: >>> On 08/27/12 18:49, John Hawkes-Reed wrote: >>>> rc.conf: >>>> >>>> (I'm not convinced that obfuscating the addresses is worth the >>>> confusion) >>>> >>>> ipv6_gateway_enable="YES" >>>> ip6addrctl_verbose="YES" >>>> rtadvd_enable="YES" >>>> rtadvd_interfaces="rl0" >>>> ipv6_cpe_wanif="pcn0" >>>> ipv6_defaultrouter="2001:470:1f0a:b5a::1" >>>> gif_interfaces="gif0" >>>> gifconfig_gif0="192.168.1.100 216.66.80.30" >>>> ifconfig_gif0_ipv6="inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 >>>> prefixlen 128" >>>> ifconfig_pcn0_ipv6="inet6 2001:470:1f0b:b5a::4 prefixlen 64" >>>> ifconfig_rl0_ipv6="inet6 2001:470:1f0b:b5a::3 prefixlen 64 >>>> -accept_rtadv" >>> >>> It looks like you are trying to use the /64 used for your tunnel on the >>> inside network. That's probably what causes the problem. >>> >>> You should use the "Routed /64" on the inside. If you need more than one >>> /64, you can request a /48. >> >> I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B: > > Sorry, my bad. > > Are pcn0 and rl0 both connected to internal networks? > > Having the same /64 configured on both is probably bad. Why would it be? -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 20:07:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5112F1065673; Mon, 27 Aug 2012 20:07:41 +0000 (UTC) (envelope-from peo@intersonic.se) Received: from neonpark.inter-sonic.com (neonpark.inter-sonic.com [212.247.8.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0DFC08FC16; Mon, 27 Aug 2012 20:07:40 +0000 (UTC) X-Virus-Scanned: amavisd-new at BSDLabs AB Message-ID: <503BD37E.9070801@intersonic.se> Date: Mon, 27 Aug 2012 22:07:26 +0200 From: Per olof Ljungmark Organization: Intersonic AB User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: John Baldwin References: <5007CFE6.6030808@intersonic.se> <503A57DB.3020503@intersonic.se> <201208271354.17832.jhb@freebsd.org> In-Reply-To: <201208271354.17832.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kurt Jaeger , freebsd-stable@freebsd.org, Martin Dieringer Subject: Re: Thinkpad X61s cannot boot 9.1-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 20:07:41 -0000 On 2012-08-27 19:54, John Baldwin wrote: > On Sunday, August 26, 2012 6:59:22 pm Martin Dieringer wrote: >> On Sun, 26 Aug 2012, Per olof Ljungmark wrote: >> >>> On 08/26/12 18:37, Kurt Jaeger wrote: >>>> Hi! >>>> >>>>> On our X61s's setting 'debug.acpi.disabled="hostres"' does not change >>>>> the inability to boot 9-BETA1, 9-RC1 or -current. >>>> >>>> I tested 9.1-RC1 on X61, and it worked without any troubles. >>>> >>> >>> Yes, it does on this one too if I install a mechanical disk. The problem > is >>> related to installing on a SSD drive, Kingston SSDNow SV200S37A/128G. >>> >>> This must be related to a change in the base system some time between >>> 9.0-RELEASE and -BETA1 as 9.0 runs and installs fine. Perhaps someone > could >>> suggest anther SSD drive with equal capacity that works? >> >> >> debug.acpi.disabled="hostres" fixed it for me on T61 and T410 >> with normal HD and (older) SSD (OCZ Summit) >> >> FreeBSD 9.1-PRERELEASE #16: Tue Aug 21 > > Can you get a verbose dmesg both with and without the "hostres" setting? > OK, will post tomorrow, a quick check with "debug.acpi.disabled="hostres"" yields same output excluding the "ata0: reset ..." lines. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 20:16:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E5F9106564A for ; Mon, 27 Aug 2012 20:16:08 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 199E48FC12 for ; Mon, 27 Aug 2012 20:16:07 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q7RKG6qA049540; Mon, 27 Aug 2012 14:16:06 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q7RKG5sj049537; Mon, 27 Aug 2012 14:16:06 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 27 Aug 2012 14:16:05 -0600 (MDT) From: Warren Block To: Kevin Oberman In-Reply-To: Message-ID: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 27 Aug 2012 14:16:06 -0600 (MDT) Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke , Matt Smith Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 20:16:08 -0000 On Mon, 27 Aug 2012, Kevin Oberman wrote: >> No obvious problems jumped out at me. Here are my notes: >> http://www.wonkity.com/~wblock/docs/html/disksetup.html >> >> The gpart version is halfway down. I really need to switch that around. > > Pretty good page, but I would really suggest that you also do either > 4k or 1M alignment on your partitions. If you don't and use a disk > with 4K blocks (internally), you will have terrible performance. You mean add the -a parameter for gpart? All that -a does is round partition starting blocks and sizes to even values. If the numbers given are already even multiples, it does nothing. The reason -a4k is not shown there is because until a few months ago, -a overrode -b. So # gpart add -t freebsd-ufs -l gprootfs -a4k -b 1M -s 2G da0 did not start that partition at 1M, but instead at the next even 4K block after the first 512K partition; block 1064 instead of block 2048, AFAIR. The fix to gpart (thanks to ae@) is in 9-stable and 9.1, but not earlier releases. Mentioned a little farther down in the article is that keeping additional partitions to even multiples of 1M or 1G size will keep them in alignment. > 1M is recommended by Microsoft and used by Windows, but seems a bit > excessive to me. Also by some Sun RAID controllers and other systems. 1M is a nice even multiple of a lot of common block sizes. From owner-freebsd-stable@FreeBSD.ORG Mon Aug 27 20:35:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 343CB106564A for ; Mon, 27 Aug 2012 20:35:12 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id C40188FC18 for ; Mon, 27 Aug 2012 20:35:11 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q7RKZAdd049623; Mon, 27 Aug 2012 14:35:11 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q7RKZAXK049620; Mon, 27 Aug 2012 14:35:10 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 27 Aug 2012 14:35:10 -0600 (MDT) From: Warren Block To: Matt Smith In-Reply-To: <79cd5f15b21566846e5ef3579f67668b@xtaz.co.uk> Message-ID: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> <79cd5f15b21566846e5ef3579f67668b@xtaz.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 27 Aug 2012 14:35:11 -0600 (MDT) Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 20:35:12 -0000 On Mon, 27 Aug 2012, Matt Smith wrote: > On 2012-08-27 19:42, Warren Block wrote: >> No obvious problems jumped out at me. Here are my notes: >> http://www.wonkity.com/~wblock/docs/html/disksetup.html >> >> The gpart version is halfway down. I really need to switch that around. > > Oooooh! You're the owner of that site. As it happens those were the exact > instructions that I used to try and figure out how to do it as you are first > in google for "freebsd gpt newfs"! Hah--I'm famous! > It's just a shame that I then decided to use the same method that I had used > before on my old system for the labelling. On my old system I had used MBR > partitioning and so needed to use glabel for labelling the swap and I then > used the same thing for the UFS partition for consistency in the fstab. It > never occurred to me when I was labelling the GPT partitions that I could > have used those directly. "Experience is what you get when you didn't get what you wanted." > One thing that is still bugging me though is I'm wondering why I had no > problem with this on my old system. That was using a dangerously dedicated > disk with MBR where the root partition was just /dev/ada4a. > It was also using UFS2 with SU+J enabled and I had used glabel in > exactly the same way but on this box it had not done any damage. > Shutdown etc worked perfectly fine. Is there something different with > the way GPT partitions work? In use, GPT partitioning should work just the same. Without recreating it, hard to define the difference that caused the shutdown problem. > Thank you for your help anyway, and your wonkity site, which I also once used > for converting my procmail to maildrop. And thanks also to Erich and Stefan > for your help. When I get some spare time I'll redo the filesystem and hope > that it works. Please post a followup after that. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 01:16:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 58591106566B for ; Tue, 28 Aug 2012 01:16:26 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id D30648FC18 for ; Tue, 28 Aug 2012 01:16:25 +0000 (UTC) Received: by weyx56 with SMTP id x56so11759310wey.13 for ; Mon, 27 Aug 2012 18:16:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yumxrXpil2pv+zk9MrPYTBJ30WiK8DlqVhLi7s7ggCE=; b=JuQ9LxHWywh4PJSSqIf8jGttglWd5MjtsdVwMLhAcYxQyXDYTI87X6wdWvehtEsBCn 57L8t++9xAy6Zc7RDJvJ402Aux78Mt5+gAW3QFdRJKGdkfvcDx7mQW06ID6a5ttfb5zr dZ94Zb25spexoMCITsw9DieKtk53TW04JQJ5cGT05uD9PPqaZVdS9Dps4EzSosCaOHH9 yLYrAd4RPO5TeccQVZrt5IPl1WVVQ4D4AmLdCu1fcBmPaptWuKf+LMpGjMaLoZDKKCp1 g30xLc/XtdRucBunm1jebMnX0iZ1D7JoIn+YcXE2FZDPA9SgWrud1JU3I/LdVA7h4yGa A3cQ== MIME-Version: 1.0 Received: by 10.180.103.136 with SMTP id fw8mr29197223wib.20.1346116583792; Mon, 27 Aug 2012 18:16:23 -0700 (PDT) Received: by 10.223.63.76 with HTTP; Mon, 27 Aug 2012 18:16:23 -0700 (PDT) In-Reply-To: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> Date: Mon, 27 Aug 2012 18:16:23 -0700 Message-ID: From: Kevin Oberman To: Warren Block Content-Type: text/plain; charset=UTF-8 Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke , Matt Smith Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 01:16:26 -0000 On Mon, Aug 27, 2012 at 1:16 PM, Warren Block wrote: > On Mon, 27 Aug 2012, Kevin Oberman wrote: > >>> No obvious problems jumped out at me. Here are my notes: >>> http://www.wonkity.com/~wblock/docs/html/disksetup.html >>> >>> The gpart version is halfway down. I really need to switch that around. >> >> >> Pretty good page, but I would really suggest that you also do either >> 4k or 1M alignment on your partitions. If you don't and use a disk >> with 4K blocks (internally), you will have terrible performance. > > > You mean add the -a parameter for gpart? All that -a does is round > partition starting blocks and sizes to even values. If the numbers given > are already even multiples, it does nothing. You can force alignment by use of -b. I just managed to miss that you were doing that. '-a' simply does the alignment and I have no reason to forces the location of any partition as all are multiples of 1M and 4K. Use of -a and -b on the same command seems rather useless, but it seems that ignoring -b is still a bug. I'm not sure I get your statement that "All that -a does is round partition starting blocks and sizes to even values. " -a aligns the start of every partition to the stated size (as your example showed). > > The reason -a4k is not shown there is because until a few months ago, -a > overrode -b. So > > # gpart add -t freebsd-ufs -l gprootfs -a4k -b 1M -s 2G da0 > > did not start that partition at 1M, but instead at the next even 4K block > after the first 512K partition; block 1064 instead of block 2048, AFAIR. > The fix to gpart (thanks to ae@) is in 9-stable and 9.1, but not earlier > releases. > > Mentioned a little farther down in the article is that keeping additional > partitions to even multiples of 1M or 1G size will keep them in alignment. > >> 1M is recommended by Microsoft and used by Windows, but seems a bit >> excessive to me. > > > Also by some Sun RAID controllers and other systems. 1M is a nice even > multiple of a lot of common block sizes. True, but so is 4K (8-512 byte blocks). Obviously 1M is also a multiple of all powers of 2 below it as is 4K. Even in this age of cheap disks, 1G alignment seems a bit extreme, but in most cases, it really is insignificant for general purpose systems. It is an argument for single partitions, but I always worry that something screwy will blow up /var with log messages and I would not want this to fill all disk space, so I like to keep that, as well as a read-only root. Just old-fashioned, I guess. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 01:23:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26520106566B; Tue, 28 Aug 2012 01:23:27 +0000 (UTC) (envelope-from marka@isc.org) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by mx1.freebsd.org (Postfix) with ESMTP id EF68B8FC0A; Tue, 28 Aug 2012 01:23:26 +0000 (UTC) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS id 14F47C9508; Tue, 28 Aug 2012 01:23:25 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (unknown [IPv6:2001:470:1f00:820:6cc7:25d4:d972:8f06]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id C5625216C6B; Tue, 28 Aug 2012 01:23:24 +0000 (UTC) (envelope-from marka@isc.org) Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 8EBFE24416C4; Tue, 28 Aug 2012 11:23:22 +1000 (EST) To: Doug Barton From: Mark Andrews References: <503BA51E.4030103@libeljournal.com> <503BB721.9000108@borderworlds.dk> <503BC497.3060206@libeljournal.com> <503BCA0A.1020904@borderworlds.dk> <503BCB0A.6000702@FreeBSD.org> In-reply-to: Your message of "Mon, 27 Aug 2012 12:31:22 MST." <503BCB0A.6000702@FreeBSD.org> Date: Tue, 28 Aug 2012 11:23:22 +1000 Message-Id: <20120828012322.8EBFE24416C4@drugs.dv.isc.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mx.pao1.isc.org Cc: freebsd-stable@freebsd.org, Christian Laursen Subject: Re: IPv6 default route. Can't see the wood for the trees. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 01:23:27 -0000 In message <503BCB0A.6000702@FreeBSD.org>, Doug Barton writes: > On 8/27/2012 12:27 PM, Christian Laursen wrote: > > On 08/27/12 21:03, John Hawkes-Reed wrote: > >> On 27/08/2012 19:06, Christian Laursen wrote: > >>> On 08/27/12 18:49, John Hawkes-Reed wrote: > >>>> rc.conf: > >>>> > >>>> (I'm not convinced that obfuscating the addresses is worth the > >>>> confusion) > >>>> > >>>> ipv6_gateway_enable="YES" > >>>> ip6addrctl_verbose="YES" > >>>> rtadvd_enable="YES" > >>>> rtadvd_interfaces="rl0" > >>>> ipv6_cpe_wanif="pcn0" > >>>> ipv6_defaultrouter="2001:470:1f0a:b5a::1" > >>>> gif_interfaces="gif0" > >>>> gifconfig_gif0="192.168.1.100 216.66.80.30" > >>>> ifconfig_gif0_ipv6="inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 > >>>> prefixlen 128" > >>>> ifconfig_pcn0_ipv6="inet6 2001:470:1f0b:b5a::4 prefixlen 64" > >>>> ifconfig_rl0_ipv6="inet6 2001:470:1f0b:b5a::3 prefixlen 64 > >>>> -accept_rtadv" > >>> > >>> It looks like you are trying to use the /64 used for your tunnel on the > >>> inside network. That's probably what causes the problem. > >>> > >>> You should use the "Routed /64" on the inside. If you need more than one > >>> /64, you can request a /48. > >> > >> I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B: > > > > Sorry, my bad. > > > > Are pcn0 and rl0 both connected to internal networks? > > > > Having the same /64 configured on both is probably bad. > > Why would it be? Unless you bridge the two interface, yes. Which interface do you start ND on? For the OP, here is my ipv6 configuration. tx0 is the internal net and is running with ULA as well as the /64 from HE. sis0 is the external cable connection. gif0 is the tunneled connection back to HE. sft0 sends 6to4 reply traffic directly it is out bound only. % ifconfig -a inet6 tx0: flags=28943 mtu 1500 inet6 fe80::2e0:29ff:fe19:c02d%tx0 prefixlen 64 scopeid 0x1 inet6 2001:470:1f00:820:2e0:29ff:fe19:c02d prefixlen 64 inet6 2001:470:1f00:820:: prefixlen 64 anycast inet6 fd92:7065:b8e:0:2e0:29ff:fe19:c02d prefixlen 64 inet6 fd92:7065:b8e:: prefixlen 64 anycast sis0: flags=8843 mtu 1500 inet6 fe80::209:5bff:fe1e:e13e%sis0 prefixlen 64 scopeid 0x2 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 gif0: flags=8051 mtu 1280 tunnel inet 211.30.172.21 --> 64.71.128.82 inet6 fe80::2e0:29ff:fe19:c02d%gif0 prefixlen 64 scopeid 0x8 inet6 2001:470:1f00:ffff::5a1 --> 2001:470:1f00:ffff::5a0 prefixlen 128 stf0: flags=1001 mtu 1280 inet6 2002:d31e:ac15:: prefixlen 16 anycast % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 02:07:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EFE86106564A; Tue, 28 Aug 2012 02:07:01 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) by mx1.freebsd.org (Postfix) with ESMTP id 9239C8FC0A; Tue, 28 Aug 2012 02:07:01 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1T6BCN-00008f-1f; Tue, 28 Aug 2012 09:06:35 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q7S28D6m065978; Tue, 28 Aug 2012 09:08:13 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q7S27pLD065942; Tue, 28 Aug 2012 09:07:51 +0700 (NOVT) (envelope-from danfe) Date: Tue, 28 Aug 2012 09:07:51 +0700 From: Alexey Dokuchaev To: Hans Petter Selasky Message-ID: <20120828020750.GA61543@regency.nsu.ru> References: <20120227152238.GA2940@regency.nsu.ru> <201203050710.22871.hselasky@c2i.net> <20120827125943.GA68575@regency.nsu.ru> <201208271734.54814.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201208271734.54814.hselasky@c2i.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jung-uk Kim Subject: Re: Resume broken in 8.3-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 02:07:02 -0000 On Mon, Aug 27, 2012 at 05:34:54PM +0200, Hans Petter Selasky wrote: > If the USB HC is feeding too many such IRQ's it will be stuck. However, > if you see that "uhub_read_port_status()" is called, the kernel is at least > running, though it might be that some IRQ is stuck, hence the 100% CPU > usage. Could you try to get some IRQ stats? Before zzz'ing: db> show intrcnt irq1: atkbd0 168 irq9: acpi0 8300 irc12: psm0 2 irq14: ata0 6301 irq16: bge0 uhci3 13 irq23: uhci0 ehci0 2 cpu0: timer 7306385 irq256: hdac0 30 After (within a minute after botched resume) db> show intrcnt irq1: atkbd0 479 irq9: cdpi0 8379 irc12: psm0 2 irq14: ata0 6377 irq16: bge0 uhci3 26 irq23: uhci0 ehci0 5 cpu0: timer 7731880 irq256: hdac0 34 Not too much difference. Anything else I might get from DDB? Unfortunately, I am yet unable to save crashdump for later gdb analysis. ./danfe From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 02:51:56 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44281106564A for ; Tue, 28 Aug 2012 02:51:56 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 0962F8FC08 for ; Tue, 28 Aug 2012 02:51:55 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q7S2ptxW073119; Mon, 27 Aug 2012 20:51:55 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q7S2pq7X073116; Mon, 27 Aug 2012 20:51:52 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Mon, 27 Aug 2012 20:51:52 -0600 (MDT) From: Warren Block To: Kevin Oberman In-Reply-To: Message-ID: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Mon, 27 Aug 2012 20:51:55 -0600 (MDT) Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke , Matt Smith Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 02:51:56 -0000 On Mon, 27 Aug 2012, Kevin Oberman wrote: > On Mon, Aug 27, 2012 at 1:16 PM, Warren Block wrote: >> On Mon, 27 Aug 2012, Kevin Oberman wrote: >> >>>> No obvious problems jumped out at me. Here are my notes: >>>> http://www.wonkity.com/~wblock/docs/html/disksetup.html >>>> >>>> The gpart version is halfway down. I really need to switch that around. >>> >>> >>> Pretty good page, but I would really suggest that you also do either >>> 4k or 1M alignment on your partitions. If you don't and use a disk >>> with 4K blocks (internally), you will have terrible performance. >> >> >> You mean add the -a parameter for gpart? All that -a does is round >> partition starting blocks and sizes to even values. If the numbers given >> are already even multiples, it does nothing. > > You can force alignment by use of -b. I just managed to miss that you > were doing that. '-a' simply does the alignment and I have no reason > to forces the location of any partition as all are multiples of 1M and > 4K. Use of -a and -b on the same command seems rather useless, Might make more sense if -a is seen as a safety check. And yes, -b is an exception, done in this case to get the first partition at a specific spot. > but it seems that ignoring -b is still a bug. Works for me in 9-stable. Here's the change in -head: http://svnweb.freebsd.org/base/head/sbin/geom/class/part/geom_part.c?r1=229916&r2=235033 It was MFCed to 8-stable and 9-stable on 2012-05-11. > I'm not sure I get your statement that "All that -a does is round > partition starting blocks and sizes to even values. " -a aligns the > start of every partition to the stated size (as your example showed). Sorry, I should have been more precise with the wording. By "even" I meant even multiple of the given block value. >> The reason -a4k is not shown there is because until a few months ago, -a >> overrode -b. So >> >> # gpart add -t freebsd-ufs -l gprootfs -a4k -b 1M -s 2G da0 >> >> did not start that partition at 1M, but instead at the next even 4K block >> after the first 512K partition; block 1064 instead of block 2048, AFAIR. >> The fix to gpart (thanks to ae@) is in 9-stable and 9.1, but not earlier >> releases. >> >> Mentioned a little farther down in the article is that keeping additional >> partitions to even multiples of 1M or 1G size will keep them in alignment. >> >>> 1M is recommended by Microsoft and used by Windows, but seems a bit >>> excessive to me. >> >> >> Also by some Sun RAID controllers and other systems. 1M is a nice even >> multiple of a lot of common block sizes. > > True, but so is 4K (8-512 byte blocks). Obviously 1M is also a > multiple of all powers of 2 below it as is 4K. Even in this age of > cheap disks, 1G alignment seems a bit extreme, but in most cases, it Er, 1M. It leaves a little less than 512K of unused space. Starting at 1G would be a more difficult decision for me, though you're right that it's a trivial amount of space on a lot of computers. > really is insignificant for general purpose systems. It is an argument > for single partitions, but I always worry that something screwy will > blow up /var with log messages and I would not want this to fill all > disk space, so I like to keep that, as well as a read-only root. Just > old-fashioned, I guess. Understood. Usually separate filesystems for me, although I recently took to using tmpfs for /tmp. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 08:57:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71130106566C; Tue, 28 Aug 2012 08:57:14 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C02938FC08; Tue, 28 Aug 2012 08:57:13 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q7S8vAO7090502; Tue, 28 Aug 2012 11:57:10 +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.5/8.14.5) with ESMTP id q7S8uvVT063866; Tue, 28 Aug 2012 11:56:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q7S8uujn063865; Tue, 28 Aug 2012 11:56:56 +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, 28 Aug 2012 11:56:56 +0300 From: Konstantin Belousov To: Alexey Dokuchaev Message-ID: <20120828085656.GI33100@deviant.kiev.zoral.com.ua> References: <20120227152238.GA2940@regency.nsu.ru> <201203050710.22871.hselasky@c2i.net> <20120827125943.GA68575@regency.nsu.ru> <201208271734.54814.hselasky@c2i.net> <20120828020750.GA61543@regency.nsu.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5BSwYavaev5qNTlX" Content-Disposition: inline In-Reply-To: <20120828020750.GA61543@regency.nsu.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 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 Cc: freebsd-stable@freebsd.org, Jung-uk Kim , freebsd-usb@freebsd.org, Hans Petter Selasky Subject: Re: Resume broken in 8.3-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 08:57:14 -0000 --5BSwYavaev5qNTlX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2012 at 09:07:51AM +0700, Alexey Dokuchaev wrote: > On Mon, Aug 27, 2012 at 05:34:54PM +0200, Hans Petter Selasky wrote: > > If the USB HC is feeding too many such IRQ's it will be stuck. However, > > if you see that "uhub_read_port_status()" is called, the kernel is at l= east > > running, though it might be that some IRQ is stuck, hence the 100% CPU > > usage. Could you try to get some IRQ stats? >=20 > Before zzz'ing: >=20 > db> show intrcnt > irq1: atkbd0 168 > irq9: acpi0 8300 > irc12: psm0 2 > irq14: ata0 6301 > irq16: bge0 uhci3 13 > irq23: uhci0 ehci0 2 > cpu0: timer 7306385 > irq256: hdac0 30 >=20 > After (within a minute after botched resume) >=20 > db> show intrcnt > irq1: atkbd0 479 > irq9: cdpi0 8379 Was the output pasted verbatim ? I am curious about the irq9 name mangling in the second paste. > irc12: psm0 2 > irq14: ata0 6377 > irq16: bge0 uhci3 26 > irq23: uhci0 ehci0 5 > cpu0: timer 7731880 > irq256: hdac0 34 >=20 > Not too much difference. Anything else I might get from DDB? Unfortunat= ely, > I am yet unable to save crashdump for later gdb analysis. >=20 > ./danfe > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" --5BSwYavaev5qNTlX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlA8h9gACgkQC3+MBN1Mb4hoFgCcDrVNfWzzPWdtYDvqgerPOQF0 fx0AoM8YhmxftpauanAk/XKPALJMpz6x =pk5H -----END PGP SIGNATURE----- --5BSwYavaev5qNTlX-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 09:12:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 364BA1065675 for ; Tue, 28 Aug 2012 09:12:08 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id EB4198FC15 for ; Tue, 28 Aug 2012 09:12:07 +0000 (UTC) Received: by ialo14 with SMTP id o14so12956988ial.13 for ; Tue, 28 Aug 2012 02:12:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lBH6YS4ZVhKpAODA1kyBPr7eMzjNOfwX0UXIILyyCtA=; b=YdCBy07dKeeojbTVISVSPRXfFpztbbtgh4DyMvm7j+5Qj67eTdZ0wfaIBOK6RuAPY/ /q3jOc7PurNxRvBhmkP4G4T7mbJSmk6l4SnOaK6hpHx7JItKcfIxp1dNRnjgiZBjESew fOV7rhxGR/98fJRJaRABxB8/J5pyKw5aFYWmdQofW65UYt1+/V05+kbbpvTnLEcATUms AsB51twZyBukFKBFo1kNv3KDBCq+wxtvZbcl3gyN66cmYlZFNYvYSYDKDvfzOCFoLZZf cFJdacySWr7txaNWnFmJLdlrWiVDFom99gO5rqSNvsgJ8iv+y+VS97Gd8Jk4OlCMNEiD NwbA== MIME-Version: 1.0 Received: by 10.42.156.1 with SMTP id x1mr13079767icw.51.1346145127251; Tue, 28 Aug 2012 02:12:07 -0700 (PDT) Received: by 10.64.96.131 with HTTP; Tue, 28 Aug 2012 02:12:07 -0700 (PDT) In-Reply-To: <503BC8F5.3040208@zirakzigil.org> References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org> <503BC8F5.3040208@zirakzigil.org> Date: Tue, 28 Aug 2012 11:12:07 +0200 Message-ID: From: Damien Fleuriot To: Giulio Ferro Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlUEb9c7Wh6w3FrKuoI8vrS9k3hKodcDywCjSXvbhGuJi6lhz00KGhajvM4xN81tf8HunCM Cc: "freebsd-net@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 09:12:08 -0000 Hi Giulio, Just to clear things up: igb0: 192.168.9.60/24 lagg0: 192.168.12.21/24 What's the IP of the host you're trying ssh connections from ? Also, just in case, did you enable any firewall ? (PF, ipfw) On 27 August 2012 21:22, Giulio Ferro wrote: > Hi, thanks for the answer > > Here is what you asked for: > > # ifconfig igb0 > igb0: flags=8843 metric 0 mtu 1500 > > options=4401bb > ether ... > inet 192.168.9.60 netmask 0xffffff00 broadcast 192.168.9.255 > inet6 .... prefixlen 64 scopeid 0x1 > nd6 options=29 > media: Ethernet autoselect (1000baseT ) > status: active > > > > # netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 192.168.9.1 UGS 0 0 igb0 > 127.0.0.1 link#12 UH 0 0 lo0 > 192.168.9.0/24 link#1 U 0 14 igb0 > 192.168.9.60 link#1 UHS 0 0 lo0 > 192.168.12.0/24 link#13 U 0 109 lagg0 > 192.168.12.21 link#13 UHS 0 0 lo0 > > Internet6: > Destination Gateway Flags > Netif Expire > ::/96 ::1 UGRS lo0 > ::1 link#12 UH lo0 > ::ffff:0.0.0.0/96 ::1 UGRS lo0 > fe80::/10 ::1 UGRS lo0 > fe80::%igb0/64 link#1 U igb0 > fe80::ea39:35ff:feb6:a0d4%igb0 link#1 UHS lo0 > fe80::%igb1/64 link#2 U igb1 > fe80::ea39:35ff:feb6:a0d5%igb1 link#2 UHS lo0 > fe80::%igb2/64 link#3 U igb2 > fe80::ea39:35ff:feb6:a0d6%igb2 link#3 UHS lo0 > fe80::%igb3/64 link#4 U igb3 > fe80::ea39:35ff:feb6:a0d7%igb3 link#4 UHS lo0 > fe80::%lo0/64 link#12 U lo0 > fe80::1%lo0 link#12 UHS lo0 > fe80::%lagg0/64 link#13 U lagg0 > fe80::ea39:35ff:feb6:a0d5%lagg0 link#13 UHS lo0 > ff01::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 > ff01::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 > ff01::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 > ff01::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 > ff01::%lo0/32 ::1 U lo0 > ff01::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U > lagg0 > ff02::/16 ::1 UGRS lo0 > ff02::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 > ff02::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 > ff02::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 > ff02::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 > ff02::%lo0/32 ::1 U lo0 > ff02::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U > lagg0 > > > > # netstat -aln | grep 22 > tcp4 0 0 *.22 *.* LISTEN > tcp6 0 0 *.22 *.* LISTEN > > Note that I already tried to only listen on igb0 interface (192.168.9.60) in > sshd_config, but the results are exactly > the same described below. > > > > > > > > On 08/25/2012 01:22 PM, Damien Fleuriot wrote: >> >> In the meantime kindly post: >> >> >> Ifconfig for your igb0 >> Netstat -rn >> Netstat -aln | grep 22 >> >> >> >> On 25 Aug 2012, at 13:18, Damien Fleuriot wrote: >> >>> I'll get back to you regarding link aggregation when I'm done with >>> groceries. >>> >>> We use it here in production and it works flawlessly. >>> >>> >>> >>> On 25 Aug 2012, at 09:54, Giulio Ferro wrote: >>> >>>> No answer, so it seems that link aggregation doesn't really work in >>>> freebsd, >>>> this may help others with the same problem... >>>> >>>> I reverted back to one link for management and one for service, and ssh >>>> works as it should... >>>> >>>> >>>> On 08/21/2012 11:18 PM, Giulio Ferro wrote: >>>>> >>>>> Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic >>>>> (igb) >>>>> >>>>> 1 nic is connected standalone to the management switch, the 3 other >>>>> nics >>>>> are connected to a switch configured for aggregation. >>>>> >>>>> If I configure the first nic (igb0) there is no problem, I can operate >>>>> as I normally do and sshd functions normally. >>>>> >>>>> The problems start when I configure the 3 other nics for aggregation: >>>>> >>>>> in /etc/rc.conf >>>>> ... >>>>> ifconfig_igb1="up" >>>>> ifconfig_igb2="up" >>>>> ifconfig_igb3="up" >>>>> >>>>> cloned_interfaces=lagg0 >>>>> ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport >>>>> igb3 192.168.12.7/24" >>>>> ... >>>>> >>>>> I restart the server and the aggregation seems to work correctly, in >>>>> fact ifconfig returns the correct lagg0 interface with the aggregated >>>>> links, the correct protocol (lacp) and the correct ip address and the >>>>> status is active. I can ping other IPs on the aggregated link. >>>>> >>>>> Also the other (standalone) link seems to work correctly. I can ping >>>>> that address from other machines, and I can ping other IPs from that >>>>> server. >>>>> >>>>> DNS lookups work ok too I can also use telnet to connect to pop3 >>>>> servers so there seems to be no problem on the network stack. >>>>> >>>>> But if I try to connect to the sshd service on that server, it hangs >>>>> indefinitely. On the server I find two sshd processes: >>>>> /usr/sbin/sshd >>>>> /usr/sbin/sshd -R >>>>> >>>>> There is no message in the logs. >>>>> >>>>> If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays >>>>> there >>>>> forever waiting for the pid to die (it never does) >>>>> >>>>> Even ssh client doesn't seem to work. In fact, if I try to connect to >>>>> another server, the ssh client may start to work correctly, then soon >>>>> or later it just hangs there forever, and I can't kill it with ctrl-c. >>>>> >>>>> No firewall is configured, there is nothing else working on this >>>>> server. >>>>> >>>>> Thanks for any suggestions... >>>>> _______________________________________________ >>>>> freebsd-stable@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>> To unsubscribe, send any mail to >>>>> "freebsd-stable-unsubscribe@freebsd.org" >>>> >>>> >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to >>>> "freebsd-stable-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 09:49:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7B231065670; Tue, 28 Aug 2012 09:48:59 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id 670858FC08; Tue, 28 Aug 2012 09:48:59 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1T6IPp-000GWe-UA; Tue, 28 Aug 2012 10:48:58 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.77 (FreeBSD)) (envelope-from ) id 1T6IPp-00068O-TS; Tue, 28 Aug 2012 10:48:57 +0100 To: auryn@zirakzigil.org, freebsd-net@freebsd.org, freebsd-stable@freebsd.org In-Reply-To: <503884A0.50708@zirakzigil.org> Message-Id: From: Pete French Date: Tue, 28 Aug 2012 10:48:57 +0100 Cc: Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 09:49:00 -0000 > No answer, so it seems that link aggregation doesn't really work in freebsd, > this may help others with the same problem... I used to use LCAP a lot - this was a few years ago, but the critical point was that it only worked if all the cables went to the same logcial switch. Using a pair of switches for redundancy works fine, as long as they are of the type which stacvk and look like a single physical switch software-wise. Saying "it doesnt really work in freebsd" is, to be honest, not so far off the mark (if somewhat harshly phrased) - but it can be made to behave if you do it in a certain way, and when it does it runs very nicely. Note that I havent tried it since 2008, so it maye have been improved since then, or had regressions, but I suggest trying it into a single switch and seeing what happens. cheers, -pete. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 11:31:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16223106566B for ; Tue, 28 Aug 2012 11:31:57 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id C98278FC0C for ; Tue, 28 Aug 2012 11:31:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=Message-Id:From:Mime-Version:Subject:Date:To:Content-Type; bh=tS2i6fdu+w8AE1CcPPk3oNbWNlAcX+W/yUbvwcP1yAg=; b=OLCAvuut8+0WVR7qIP6JTr35d1sUva/oaRIEgKgfV/gJDWF5seuuD4dAY5YjZNnxxrZ2wELSSYNOLOK6DSgsurOcDb1hShzb1WGBKR9Pr0siBQXA3BHHOkuKrhFzE5zz; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T6K1P-0008Jp-53 for freebsd-stable@freebsd.org; Tue, 28 Aug 2012 06:31:55 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1346153505-3058-3056/5/4; Tue, 28 Aug 2012 11:31:45 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Date: Tue, 28 Aug 2012 06:31:44 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: User-Agent: Opera Mail/12.01 (FreeBSD) X-SA-Report: ALL_TRUSTED=-1 X-SA-Score: -1.0 Subject: ipv6 connection hang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 11:31:57 -0000 Hi all, mwi1# uname -a FreeBSD mwi1.coffeenet.org 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #5 r239731: Mon Aug 27 09:53:18 CDT 2012 root@mwi1.coffeenet.org:/usr/obj/usr/src/sys/GENERIC amd64 My ipv6 connections hang for several seconds when this scrub rule is enabled: scrub all reassemble tcp no-df random-id This really agitates my browser and email client making them nearly useless at times. Disabling that rule makes ipv6 connections respond instantly as expected. Is this a known regression? My network interface is using the re(4) driver. Thanks! From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 14:34:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8533106566B; Tue, 28 Aug 2012 14:34:33 +0000 (UTC) (envelope-from arno@heho.snv.jussieu.fr) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.freebsd.org (Postfix) with ESMTP id 46BE48FC14; Tue, 28 Aug 2012 14:34:32 +0000 (UTC) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.14.4/jtpda-5.4) with ESMTP id q7SEY2JX020111 ; Tue, 28 Aug 2012 16:34:02 +0200 (CEST) X-Ids: 164 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) by heho.snv.jussieu.fr (8.14.3/8.14.3) with ESMTP id q7SEXaJr047976; Tue, 28 Aug 2012 16:33:36 +0200 (CEST) (envelope-from arno@heho.snv.jussieu.fr) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.14.3/8.14.3/Submit) id q7SEXa1o047973; Tue, 28 Aug 2012 16:33:36 +0200 (CEST) (envelope-from arno) To: Jim Pingle From: "Arno J. Klaassen" References: <1345697446.84337.11.camel@neo.cse.buffalo.edu> <20120823225855.U33776@sola.nimnet.asn.au> <1345729674.52121.4.camel@bauer.cse.buffalo.edu> <5036497F.7020501@icarz.com> <1345736581.27688.403.camel@revolution.hippie.lan> <50384172.3090706@pingle.org> Date: Tue, 28 Aug 2012 16:33:36 +0200 In-Reply-To: <50384172.3090706@pingle.org> (Jim Pingle's message of "Fri\, 24 Aug 2012 23\:07\:30 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at jchkmail.jussieu.fr with ID 503CD6DA.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 503CD6DA.000/134.157.184.22/heho.snv.jussieu.fr/heho.snv.jussieu.fr/ Cc: re@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.1-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:34:34 -0000 Jim Pingle writes: > On 8/23/2012 11:43 AM, Ian Lepore wrote: >> On Thu, 2012-08-23 at 11:17 -0400, Ken Menzel wrote: >>> >>> I found two good primers: >>> http://mebsd.com/configure-freebsd-servers/update-freebsd-source-tree-using-subversion-svn.html >>> http://www.freebsd.org/doc/en/articles/committers-guide/article.html#SUBVERSION-PRIMER >>> >>> The second primer in the committer handbook seems to indicate that it >>> is difficult to run an SVN mirror. This appears to me to be the >>> biggest drawback. I have been using CVS and perforce for years, but >>> subversion is new to me. >> >> It may be difficult to run an svn mirror that allows you to commit >> locally and get those changes back to the project, but running a >> read-only mirror is trivial. The script I run nightly from cron to sync >> my local mirror is: >> >> #!/bin/sh >> # >> # svnsync to pull in changes from FreeBSD to my local mirror. >> # >> svnsync sync file:///local/vc/svn/base >> >> I can't remember how I initially created and populated the mirror, but >> it's likely I grabbed a snapshot of the mirror at work and brought it >> home on a thumb drive (just to avoid initial network DL time). > > I spent a little time today setting up an SVN mirror after reading this > thread and wrote up a how-to for those looking to do the same. > > http://www.pingle.org/2012/08/24/freebsd-svn-mirror > > Comments/Flames/Corrections welcome... thanx; works out of the box for me (using the "svnserve_enable" path). That said : I glanced at a diff of a stable/8 checkout both from /home/ncvs repo and new /home/freebsd-svn one, and saw a (maybe well-known ..) 'feature' : diff ./src/contrib/amd/include/am_defs.h /raid1/bsd/8/src/contrib/amd/include/am_defs.h 42c42 < * $FreeBSD: stable/8/contrib/amd/include/am_defs.h 174299 2007-12-05 16:03:52Z obrien $ --- > * $FreeBSD: src/contrib/amd/include/am_defs.h,v 1.15.2.1 2009/08/03 08:13:06 kensmith Exp $ I wondered why the date (and commiter ...) in the expansion were different (from the svn log ): ------------------------------------------------------------------------ r196045 | kensmith | 2009-08-03 10:13:06 +0200 (Mon, 03 Aug 2009) | 4 lines Copy head to stable/8 as part of 8.0 Release cycle. Approved by: re (Implicit) ------------------------------------------------------------------------ r174299 | obrien | 2007-12-05 17:03:52 +0100 (Wed, 05 Dec 2007) | 3 lines So the 'Copy head' chain does not update the $FreeBSD tag, whereas the consequent svn to cvs chain does. FYI, Arno > Jim > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 14:46:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E25E106566B for ; Tue, 28 Aug 2012 14:46:27 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0A3FA8FC15 for ; Tue, 28 Aug 2012 14:46:26 +0000 (UTC) Received: by vbmv11 with SMTP id v11so7510452vbm.13 for ; Tue, 28 Aug 2012 07:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=LXvHwxlsnLaMJH7B05ZUXEYpnj+WbtdTUg2a8OvtHiQ=; b=V5NNEhY/6Yk+h0wWXud8Ckp0i4duRwfvLGsb4RvEzC2Am8svaIUVYZZFQW/X0Ty/gX MPew/PWWNg+11faqKNKksEVVdR26Hz838ttaYQ4D3vKYR7U2fuYoLP8L4zJ+T4LM2ZcI 5Clk1zuXWm71yCpIgZGvpo6UZ0NCXmhcgtZm72AR59Fnuw/jaMXGhgXMzX9d9v284vzv rsPYtDWMVZAwL9dSnkn5EPZetzC5z+Tflz1lbQa/CB+vpSq2RxqvlRKhJRKzuufKP/dX s1jydnjjfgExj5CZ9zbf438v+jbyW0hm7ChlYCyaJ1zsqviDt3+OKGZQa1d2+OPlarsS Es7A== MIME-Version: 1.0 Received: by 10.220.142.79 with SMTP id p15mr13905315vcu.24.1346165186170; Tue, 28 Aug 2012 07:46:26 -0700 (PDT) Received: by 10.58.230.134 with HTTP; Tue, 28 Aug 2012 07:46:26 -0700 (PDT) Date: Tue, 28 Aug 2012 17:46:26 +0300 Message-ID: From: Kimmo Paasiala To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 Subject: Re: IPv6 default route. Can't see the wood for the trees. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:46:27 -0000 > On 8/27/2012 12:27 PM, Christian Laursen wrote: >> On 08/27/12 21:03, John Hawkes-Reed wrote: >>> On 27/08/2012 19:06, Christian Laursen wrote: >>>> On 08/27/12 18:49, John Hawkes-Reed wrote: >>>>> rc.conf: >>>>> >>>>> (I'm not convinced that obfuscating the addresses is worth the >>>>> confusion) >>>>> >>>>> ipv6_gateway_enable="YES" >>>>> ip6addrctl_verbose="YES" >>>>> rtadvd_enable="YES" >>>>> rtadvd_interfaces="rl0" >>>>> ipv6_cpe_wanif="pcn0" >>>>> ipv6_defaultrouter="2001:470:1f0a:b5a::1" >>>>> gif_interfaces="gif0" >>>>> gifconfig_gif0="192.168.1.100 216.66.80.30" >>>>> ifconfig_gif0_ipv6="inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 >>>>> prefixlen 128" >>>>> ifconfig_pcn0_ipv6="inet6 2001:470:1f0b:b5a::4 prefixlen 64" >>>>> ifconfig_rl0_ipv6="inet6 2001:470:1f0b:b5a::3 prefixlen 64 >>>>> -accept_rtadv" >>>> >>>> It looks like you are trying to use the /64 used for your tunnel on the >>>> inside network. That's probably what causes the problem. >>>> >>>> You should use the "Routed /64" on the inside. If you need more than one >>>> /64, you can request a /48. >>> >>> I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B: >> >> Sorry, my bad. >> >> Are pcn0 and rl0 both connected to internal networks? >> >> Having the same /64 configured on both is probably bad. > > Why would it be? > > > -- You can't have the exact same prefix on two different interfaces, there's no way to decide where to route traffic going to that prefix if there's two equal routes in the routing table. -Kimmo From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 15:32:12 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08661065677 for ; Tue, 28 Aug 2012 15:32:12 +0000 (UTC) (envelope-from jamie@kode5.net) Received: from kontrol.kode5.net (kontrol.kode5.net [80.229.5.32]) by mx1.freebsd.org (Postfix) with ESMTP id 64EED8FC14 for ; Tue, 28 Aug 2012 15:32:11 +0000 (UTC) Received: from kontrol.kode5.net (localhost [127.0.0.1]) by kontrol.kode5.net (8.14.5/8.14.5) with ESMTP id q7SFW4cN076921 for ; Tue, 28 Aug 2012 16:32:04 +0100 (BST) (envelope-from jamie@kode5.net) Received: (from jamie@localhost) by kontrol.kode5.net (8.14.5/8.14.5/Submit) id q7SFW33D076920 for freebsd-stable@freebsd.org; Tue, 28 Aug 2012 16:32:03 +0100 (BST) (envelope-from jamie@kode5.net) X-Authentication-Warning: kontrol.kode5.net: jamie set sender to jamie@kode5.net using -f Date: Tue, 28 Aug 2012 16:32:03 +0100 From: Jamie Paul Griffin To: freebsd-stable@freebsd.org Message-ID: <20120828153203.GC38854@kontrol.kode5.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="RIYY1s2vRbPFwWeW" Content-Disposition: inline x-operating-system: FreeBSD 9.1-PRERELEASE amd64 x-pgp-fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38 x-pgp-key: 1D31DC38 User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.5 at kontrol.kode5.net X-Virus-Status: Clean Subject: Building the kernel and userland with llvm/clang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:32:13 -0000 --RIYY1s2vRbPFwWeW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi I've been reading some information about building my system, FreeBSD Stable= /9, using llvm/clang; the site I've been looking at is http://wiki.freebsd.= org/BuildingFreeBSDWithClang. I was wondering about the benefits of doing so and also - and probably more= importantly - if there are potential problems that might mean it's not wor= thwhile doing. Having read it again today there doesn't seem to be any like= ly problems I'd appreciate any thoughts or advice about this if possible.=20 There's no particular reason I am thinking of doing this, I'm a student and= so I just like to try things out and tinker with my system.=20 Best Wishes, Jamie. --RIYY1s2vRbPFwWeW Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIRngYJKoZIhvcNAQcCoIIRjzCCEYsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DuIwggUfMIIEB6ADAgECAhB0kD49oFhImiM1TNmYDSf/MA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDgyNTAwMDAwMFoX DTEzMDgyNTIzNTk1OVowIDEeMBwGCSqGSIb3DQEJARYPamFtaWVAa29kZTUubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArCcH9jqYDuhBs0LslWkupsEzY7j7D0okrqe9 k1eoafySH8/JL5x2Ly5XdQY+D//SRhaonnQO4vZxf/48I/ErXJnQ12Q7nv8x0OUbHUCsSDuM o+XdCHNhw6cabwP/lkn+yKQOucl8jL4DXZbUxvZdxkd5xajHi3/OOOkdxuz09gKY5kh5aTaV cg9KA5WzZ3oJ8LENEVbPnwj7AIbyALaE0N45/GN0rG7KKn5DZSjqwd40+XEMCSaw5qNYNiFz iS9S2ow0P+aQz3WUaUcFHUnTyo84CkTWRGtCS5FfWEjX7UjTZbvLAmxdndbqfahJVIL/ch+o d9WQAXIGwHBSOZtWXwIDAQABo4IB3zCCAdswHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+Kg W7x5xXswHQYDVR0OBBYEFFzXVMl5Ia5RjMxe7WhQ66w5ceGXMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDov L2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNv bW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGgYDVR0RBBMwEYEP amFtaWVAa29kZTUubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQBl+DsCE7TM7c8SgKiqwE0DSxqU CfsPA/PtqSMIZYesr9Aelod/OzawPhjUmqsliqR3s9e0e+O0s7H+PSOaf10Nn9GVc6Ej6tqt ctFPr6AeU8NUvlyqhPK4kj4DZRcJM0ervslzva8TUHWk7mC2gahmPVJ0Zl8WR2TCVdLGXrWH jz4csIw03GxRqivg86PpTnm1R9uutVem6kNWfqSdYmKqwABJ71f0N1WWJWhGUlgf5kpoRXrp AyrjFIoeD1egIbuBwf+24ynID9MSuHSqRgPxf8WWtTmpbgpnRL2TKbF9vMojXOFJ0dEeRvlF +DTbmbLPrUBQSQELOIyY2+WV6V6wMIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jAN BgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5T YWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQL ExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAx MDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958y fVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8f SG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmV WRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uD D216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDf RBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHze Pa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjAS BgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJ hkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50 aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0dHA6 Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhX VW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp1 1tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5 IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJ M75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0 M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggSdMIIDhaADAgECAhA0Pekr rCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtB ZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAg BgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAw NTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfH TrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4 vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i 5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDre CqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOB9DCB 8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUiYJnfcSdJnAA S7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAow CDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9B ZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGG GWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAAG8nONjKLDz MQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90FrmRh5H1iib6ZHAA2B75CwRiUIeT gdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC0cyJX7F88D5R8jXzfOxgmGs6K+Dv 37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol 6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBxYO7CcYIM6Yg249ogtKOgbKqWS7iA jnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUxggKEMIICgAIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQdJA+PaBYSJojNUzZmA0n/zAJ BgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEyMDgyODE1MzIwM1owIwYJKoZIhvcNAQkEMRYEFMJ5guEt5IecTQntUwWqWrb7+IJbMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAKUkN6e/y9/6 UlzO6PNlPtCaAD54yeG+jRY20Z7+8Rtxp4KP8yTbg9u3xHGZmg0sBTDj1ullusUFIuFV/w3I TzhXeDC42R8SLYjLt9K6NEtP2zXikPonp2uj4XCNcVrTDTafVWNC9ilbJTs927H11NXvqW3Y b5rsvJVXejR5HDA969+9VOS/Wu1+3vsYhREKnOIKPG3r1PHID5+PFHQOz9hlnOkjsT1JhweD 00pHShMbRbME47eryVVsOAek+paHCDO8VoIIyFRA1cscRKE2iVQp3JlGAR1svBUfMDkEFQgp 19hYXqUdrKapqaf+LGucJKnFIJPKbYgykNyVakEIoE0= --RIYY1s2vRbPFwWeW-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 15:38:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71897106566C for ; Tue, 28 Aug 2012 15:38:58 +0000 (UTC) (envelope-from norbert.aschendorff@yahoo.de) Received: from nm32-vm8.bullet.mail.bf1.yahoo.com (nm32-vm8.bullet.mail.bf1.yahoo.com [72.30.238.134]) by mx1.freebsd.org (Postfix) with SMTP id 010488FC14 for ; Tue, 28 Aug 2012 15:38:57 +0000 (UTC) Received: from [98.139.215.141] by nm32.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 15:38:57 -0000 Received: from [98.139.211.206] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 15:38:57 -0000 Received: from [127.0.0.1] by smtp215.mail.bf1.yahoo.com with NNFMP; 28 Aug 2012 15:38:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1346168337; bh=+OtMU8yQCAIZxtO9y7XJT9r8nwv6fSWMZEm8CFkDjoE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=Xa8/tWrvKksDcW98Bx7eaiGR0wmaK1DLlXB29FvhVjWRUshHOeHUSIQTeMbSV06lrd3QLmSViZ7ln9Qb8oNpL9x6jH1NDehs2JfE2qZ1kwVJ4+yLVYL/rl1gkNrqDVSxbcP9v+Dhjdv+Ci7Ff3Qokfe9Haq6QHh9K0uKOPP5GzI= X-Yahoo-Newman-Id: 159498.68753.bm@smtp215.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-5 X-YMail-OSG: BllgsjQVM1kUCL3NsLlzf_JDsboT1SU7fZpS6n3sDPBiBXY LJUoj2b0KfArtkeNe.dkSDP_ooq9NR8.ESxNpkH.AbVUrpy168aMyz1f6q_7 ODfaRpDEvfeboONBI9PbW4K8OwhQ69UhxH0AS7rCWb7evbdn2dkLW8j7DUhy tZn9MJOit9U9nET0RIg_fL6DoRAQTG0u8lSnog4P5a6WZlHy62F7Oed_1aUj puqnkij6Nr1_Ca7keOyEXztmAdy0nepkhwejlKVvLgIW9OZH55zK.oq335.a oPzAo364SZopMm48USriq90EKZ._DY.dbTMd8nU8ymrXdF_mN9cNL.5N7TYS vkAw2kDxYLuWq6Rh5f4gHjbuxb7irqTiRNzptXWHmhLLtO_1wB.aNyu9ZEIq X87oIzWrDyPn5Z79EpnxbHO1txApNn.R7pq51piL2B3IUC2KXky35HFajSKO zvZy_shf1zvWqWbX3WTfzMlimKlo3XlKLfVPADN7WtnE- X-Yahoo-SMTP: d20YFqmswBAWc4wd23BcX3DKFU.SSFWadKORXj_BQPQ- Received: from vostro-linux.goebo.site (norbert.aschendorff@85.216.84.153 with plain) by smtp215.mail.bf1.yahoo.com with SMTP; 28 Aug 2012 08:38:57 -0700 PDT Message-ID: <503CE60F.8040007@yahoo.de> Date: Tue, 28 Aug 2012 17:38:55 +0200 From: Norbert Aschendorff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120418 Icedove/11.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: IPv4 vs. IPv6 Ethernet Performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:38:58 -0000 Hi, I'm using here a Gigabit Ethernet network and some UN*X machines, among others some Linux-based (Kernel 3.x) and one running FreeBSD 9.1-RC1. Using iperf (in TCP mode), the IPv6 bandwith between two Linux machines (directly attached to the same switch) is about 925 Mbit/s, IPv4 bandwith is about 935 Mbit/s. But now it gets exciting: The IPv6 bandwith between a Linux machine and the FreeBSD machine is around 450 Mbit/s (each direction). But the IPv4 bandwith between the same machines is 700 (Linux -> FreeBSD) to 920 (FreeBSD -> Linux) Mbit/s. Little table (values in Mbit/s): Configuration v6 v4 ======================================= Linux -> Linux 925 935 # <= This could be v6's 40B header # vs. v4's 20B Linux -> FreeBSD 450 700 FreeBSD -> Linux 455 920 ======================================= The FreeBSD->Linux value shows that the ethernet chip on the FreeBSD machine (it's Intel stuff on both sides, using the em(4) driver on FreeBSD) is able to send at full 1G speed. But why is IPv6 so slow? Regards, Norbert From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 15:46:22 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E3E6106564A for ; Tue, 28 Aug 2012 15:46:22 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id E7B678FC0C for ; Tue, 28 Aug 2012 15:46:21 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q7SFkL51032799; Tue, 28 Aug 2012 08:46:21 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q7SFkLNe032798; Tue, 28 Aug 2012 08:46:21 -0700 (PDT) (envelope-from david) Date: Tue, 28 Aug 2012 08:46:21 -0700 From: David Wolfskill To: Jamie Paul Griffin Message-ID: <20120828154621.GJ10869@albert.catwhisker.org> References: <20120828153203.GC38854@kontrol.kode5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NyChO5MpGs3JHJbz" Content-Disposition: inline In-Reply-To: <20120828153203.GC38854@kontrol.kode5.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Building the kernel and userland with llvm/clang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:46:22 -0000 --NyChO5MpGs3JHJbz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2012 at 04:32:03PM +0100, Jamie Paul Griffin wrote: > Hi >=20 > I've been reading some information about building my system, FreeBSD Stab= le/9, using llvm/clang; the site I've been looking at is http://wiki.freebs= d.org/BuildingFreeBSDWithClang. >=20 > I was wondering about the benefits of doing so and also - and probably mo= re importantly - if there are potential problems that might mean it's not w= orthwhile doing. Having read it again today there doesn't seem to be any li= kely problems >=20 > I'd appreciate any thoughts or advice about this if possible.=20 > ... I have been doing this (on a daily basis) with both head & stable/9 on my home "build machine" and my laptop since 12 Jul 2012; I have seen no problems or issues. (I build my ports under stable/8 & have /usr/local in common across all 4 slices on each machine.) Here's what's in my /etc/src.conf for stable/9: CC=3Dclang CXX=3Dclang++ CPP=3Dclang-cpp WITH_LIBCPLUSPLUS=3Dyes When I update my "production" machines at home from stable/8 to stable/9 (probably shortly after 9.1 is released), they will (by necessity) also migrate to FreeBSD built with llvm/clang (as they get installed what the build machine builds). Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --NyChO5MpGs3JHJbz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA858wACgkQmprOCmdXAD32KACcDL/6m+uAMeNqOS7649W6M2Hs n70An3mSFSWf6uEMS5rScXQRVcE4zx80 =7Rk/ -----END PGP SIGNATURE----- --NyChO5MpGs3JHJbz-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 15:51:43 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 965651065675 for ; Tue, 28 Aug 2012 15:51:43 +0000 (UTC) (envelope-from feld@feld.me) Received: from feld.me (unknown [IPv6:2607:f4e0:100:300::2]) by mx1.freebsd.org (Postfix) with ESMTP id 61F6D8FC19 for ; Tue, 28 Aug 2012 15:51:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=feld.me; s=blargle; h=In-Reply-To:Message-Id:From:Mime-Version:Cc:Date:References:Subject:To:Content-Type; bh=yrqBaXbkRd0ledfS3gZhxcwerQDLYI27XMHk6RqWRtQ=; b=VGe4fTxFtwUnGtyK1aUO29lnCKw9Mc71g2RPa4NRCBDDU80/YPD2vozBqfRGyQ4XBLjA430qMYM5KxYHf+JkHHACX5VgnvbSIcFHrXf9zto+M7+ieMoA743Quhkm0bu2; Received: from localhost ([127.0.0.1] helo=mwi1.coffeenet.org) by feld.me with esmtp (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T6O4r-000HgD-Di; Tue, 28 Aug 2012 10:51:42 -0500 Received: from feld@feld.me by mwi1.coffeenet.org (Archiveopteryx 3.1.4) with esmtpa id 1346169093-3058-3056/5/7; Tue, 28 Aug 2012 15:51:33 +0000 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org References: <503CE60F.8040007@yahoo.de> Date: Tue, 28 Aug 2012 10:51:33 -0500 Mime-Version: 1.0 From: Mark Felder Message-Id: In-Reply-To: <503CE60F.8040007@yahoo.de> User-Agent: Opera Mail/12.01 (FreeBSD) X-SA-Report: ALL_TRUSTED=-1, KHOP_THREADED=-0.5 X-SA-Score: -1.5 Cc: Norbert Aschendorff Subject: Re: IPv4 vs. IPv6 Ethernet Performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 15:51:43 -0000 I'd guess it has to do with incomplete offload code for ipv6, but I'm sure you'll see bz chiming in with details. :-) From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 16:10:07 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C55D1065673 for ; Tue, 28 Aug 2012 16:10:07 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 006848FC1A for ; Tue, 28 Aug 2012 16:10:06 +0000 (UTC) Received: from www.dweimer.net (webmail.dweimer.net [192.168.5.1]) by webmail.dweimer.net (8.14.5/8.14.5) with ESMTP id q7SFkZid002886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 28 Aug 2012 10:46:36 -0500 (CDT) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 28 Aug 2012 10:46:35 -0500 From: dweimer To: FreeBSD Stable Organization: dweimer.net Mail-Reply-To: Message-ID: <9fa99b69aab3afdd72f5776406eb1b65@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/0.8.0 Subject: cdrtools port installation failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dweimer@dweimer.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:10:07 -0000 Anyone else not able to get cdrtools to install on a Stable System? I have just recently synced my source and rebuilt world, and kernel, then installed. Now while trying to install the livecd port, the cdrtools dependency is failing to install. The port compiles fine (at least it doesn't stop reporting an error), but dies on the installation portion reporting a missing file. install: /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav: No such file or directory *** [do-install] Error code 71 There is a cdda2wav.d and cdda2wav.o file in the directory its searching, however when I run this on my FreeBSD 9.0-RELEASE-p4 system, there is also a cdda2wav file with no extension. ls /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/ Dnull Inull aifc.d aifc.o aiff.d aiff.o base64.d base64.o cd_misc.d cd_misc.o cdda2wav.d cdda2wav.o config.cache config.log config.status interface.d interface.o ioctl.d ioctl.o lconfig.h local.cnf parse.d parse.o raw.d raw.o resample.d resample.o ringbuff.d ringbuff.o scsi_cdr.d scsi_cdr.o scsi_cmds.d scsi_cmds.o scsi_scan.d scsi_scan.o semshm.d semshm.o setuid.d setuid.o sndconfig.d sndconfig.o sun.d sun.o toc.d toc.o wav.d wav.o -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 16:54:57 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2AAE21065670 for ; Tue, 28 Aug 2012 16:54:57 +0000 (UTC) (envelope-from jamie@kode5.net) Received: from kontrol.kode5.net (kontrol.kode5.net [80.229.5.32]) by mx1.freebsd.org (Postfix) with ESMTP id 88AEE8FC28 for ; Tue, 28 Aug 2012 16:54:56 +0000 (UTC) Received: from kontrol.kode5.net (localhost [127.0.0.1]) by kontrol.kode5.net (8.14.5/8.14.5) with ESMTP id q7SGrGVl077216; Tue, 28 Aug 2012 17:53:16 +0100 (BST) (envelope-from jamie@kode5.net) Received: (from jamie@localhost) by kontrol.kode5.net (8.14.5/8.14.5/Submit) id q7SGrF6m077215; Tue, 28 Aug 2012 17:53:15 +0100 (BST) (envelope-from jamie@kode5.net) X-Authentication-Warning: kontrol.kode5.net: jamie set sender to jamie@kode5.net using -f Date: Tue, 28 Aug 2012 17:53:15 +0100 From: Jamie Paul Griffin To: David Wolfskill Message-ID: <20120828165315.GE38854@kontrol.kode5.net> References: <20120828153203.GC38854@kontrol.kode5.net> <20120828154621.GJ10869@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="fWddYNRDgTk9wQGZ" Content-Disposition: inline In-Reply-To: <20120828154621.GJ10869@albert.catwhisker.org> x-operating-system: FreeBSD 9.1-PRERELEASE amd64 x-pgp-fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38 x-pgp-key: 1D31DC38 User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.5 at kontrol.kode5.net X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Building the kernel and userland with llvm/clang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:54:57 -0000 --fWddYNRDgTk9wQGZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ David Wolfskill wrote on Tue 28.Aug'12 at 8:46:21 -0700 ] > On Tue, Aug 28, 2012 at 04:32:03PM +0100, Jamie Paul Griffin wrote: > > Hi > >=20 > > I've been reading some information about building my system, FreeBSD St= able/9, using llvm/clang; the site I've been looking at is http://wiki.free= bsd.org/BuildingFreeBSDWithClang. > >=20 > > I was wondering about the benefits of doing so and also - and probably = more importantly - if there are potential problems that might mean it's not= worthwhile doing. Having read it again today there doesn't seem to be any = likely problems > >=20 > > I'd appreciate any thoughts or advice about this if possible.=20 > > ... >=20 > I have been doing this (on a daily basis) with both head & stable/9 on > my home "build machine" and my laptop since 12 Jul 2012; I have seen no > problems or issues. (I build my ports under stable/8 & have /usr/local > in common across all 4 slices on each machine.) >=20 > Here's what's in my /etc/src.conf for stable/9: >=20 > CC=3Dclang > CXX=3Dclang++ > CPP=3Dclang-cpp > WITH_LIBCPLUSPLUS=3Dyes >=20 > When I update my "production" machines at home from stable/8 to stable/9 > (probably shortly after 9.1 is released), they will (by necessity) also > migrate to FreeBSD built with llvm/clang (as they get installed what the > build machine builds). >=20 > Peace, > david Thanks David, that's helpful information. I'll likely give it a go. So does= clang create better binaries and libraries, in terms of performance and su= ch-like? I'm currently reading as much as I can find about clang and its as= sociated tools; however, compilers are quite complex software and learning = about them is, for me at least, a lot to take in.=20 Best wishes, Jamie. --fWddYNRDgTk9wQGZ Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIRngYJKoZIhvcNAQcCoIIRjzCCEYsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DuIwggUfMIIEB6ADAgECAhB0kD49oFhImiM1TNmYDSf/MA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDgyNTAwMDAwMFoX DTEzMDgyNTIzNTk1OVowIDEeMBwGCSqGSIb3DQEJARYPamFtaWVAa29kZTUubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArCcH9jqYDuhBs0LslWkupsEzY7j7D0okrqe9 k1eoafySH8/JL5x2Ly5XdQY+D//SRhaonnQO4vZxf/48I/ErXJnQ12Q7nv8x0OUbHUCsSDuM o+XdCHNhw6cabwP/lkn+yKQOucl8jL4DXZbUxvZdxkd5xajHi3/OOOkdxuz09gKY5kh5aTaV cg9KA5WzZ3oJ8LENEVbPnwj7AIbyALaE0N45/GN0rG7KKn5DZSjqwd40+XEMCSaw5qNYNiFz iS9S2ow0P+aQz3WUaUcFHUnTyo84CkTWRGtCS5FfWEjX7UjTZbvLAmxdndbqfahJVIL/ch+o d9WQAXIGwHBSOZtWXwIDAQABo4IB3zCCAdswHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+Kg W7x5xXswHQYDVR0OBBYEFFzXVMl5Ia5RjMxe7WhQ66w5ceGXMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDov L2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNv bW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGgYDVR0RBBMwEYEP amFtaWVAa29kZTUubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQBl+DsCE7TM7c8SgKiqwE0DSxqU CfsPA/PtqSMIZYesr9Aelod/OzawPhjUmqsliqR3s9e0e+O0s7H+PSOaf10Nn9GVc6Ej6tqt ctFPr6AeU8NUvlyqhPK4kj4DZRcJM0ervslzva8TUHWk7mC2gahmPVJ0Zl8WR2TCVdLGXrWH jz4csIw03GxRqivg86PpTnm1R9uutVem6kNWfqSdYmKqwABJ71f0N1WWJWhGUlgf5kpoRXrp AyrjFIoeD1egIbuBwf+24ynID9MSuHSqRgPxf8WWtTmpbgpnRL2TKbF9vMojXOFJ0dEeRvlF +DTbmbLPrUBQSQELOIyY2+WV6V6wMIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jAN BgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5T YWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQL ExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAx MDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958y fVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8f SG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmV WRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uD D216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDf RBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHze Pa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjAS BgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJ hkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50 aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0dHA6 Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhX VW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp1 1tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5 IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJ M75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0 M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggSdMIIDhaADAgECAhA0Pekr rCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtB ZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAg BgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAw NTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfH TrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4 vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i 5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDre CqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOB9DCB 8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUiYJnfcSdJnAA S7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAow CDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9B ZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGG GWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAAG8nONjKLDz MQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90FrmRh5H1iib6ZHAA2B75CwRiUIeT gdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC0cyJX7F88D5R8jXzfOxgmGs6K+Dv 37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol 6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBxYO7CcYIM6Yg249ogtKOgbKqWS7iA jnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUxggKEMIICgAIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQdJA+PaBYSJojNUzZmA0n/zAJ BgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEyMDgyODE2NTMxNVowIwYJKoZIhvcNAQkEMRYEFLQASjpkn2wIrlN4c6dUZfbJ6mCMMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAE6b4JINlzFy R02h9FcrXpB9zPh0AxK0vwlgViPo83TG0pZ9dGnHl5sP5LUsEjpsjFJ5S//6xuhRvMEMX1sH x51cCY3VTW+Z9MX/1xtkA/sCHePM7XyngvtP9vE/SImucnwPEEeXG1yzCMcqez3ckEtHcTs/ WU9bumHVzFALO6xcw+KLONYsdY7j5EU8g4EWXjyhiHPq8i2ptJ1wWN5s/hUO6QKyuoBabQk9 uGetFlSkClTbthPq6F/kygRq3utfnUliSyLsn+T5IyUGgO2glhM+PDzOqELKjTTRbt75vfr+ BhhpmixHuzw99zfF+l2NZw7Aj1IlOgGgy02H+kqL5uc= --fWddYNRDgTk9wQGZ-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 17:13:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FEFF106564A for ; Tue, 28 Aug 2012 17:13:13 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id CDADB8FC1A for ; Tue, 28 Aug 2012 17:13:12 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q7SHDBTT034609; Tue, 28 Aug 2012 10:13:11 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q7SHDBFd034608; Tue, 28 Aug 2012 10:13:11 -0700 (PDT) (envelope-from david) Date: Tue, 28 Aug 2012 10:13:11 -0700 From: David Wolfskill To: Jamie Paul Griffin Message-ID: <20120828171311.GL10869@albert.catwhisker.org> References: <20120828153203.GC38854@kontrol.kode5.net> <20120828154621.GJ10869@albert.catwhisker.org> <20120828165315.GE38854@kontrol.kode5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XjbSsFHOHxvQpKib" Content-Disposition: inline In-Reply-To: <20120828165315.GE38854@kontrol.kode5.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Building the kernel and userland with llvm/clang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 17:13:13 -0000 --XjbSsFHOHxvQpKib Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2012 at 05:53:15PM +0100, Jamie Paul Griffin wrote: > ... > Thanks David, that's helpful information. Good; that was the intent. :-) > I'll likely give it a go. So does clang create better binaries and librar= ies, in terms of performance and such-like? I'm currently reading as much a= s I can find about clang and its associated tools; however, compilers are q= uite complex software and learning about them is, for me at least, a lot to= take in.=20 > .... I don't know that it creates "better" code, but I believe that at least some of its error/warning checking may be a bit better: it certainly whines about a fair bit of GNUish code, citing (e.g.) "Tautological compares" ... and that sort of thing seems as if it's something I'd want to know about if it were my code, so I could fix it. =46rom the time (a few weeks) when I was building stable/9 with both gcc & clang (on different slices, sources updated to the same GRN), I got the impression that clang was slower (to compile) than gcc was. I note that I've had no issues at all with interoperation of executables & libraries built with gcc & clang. I consider this a Good Thing. :-) As I understand the issues, FreeBSD uses a (somewhat modified) version of the last GPLv2-licensed version of gcc, and there is strong incentive to avoid "tainting" FreeBSD with a GPLv3-licensed version of gcc. Thus, if we want to be able to move forward with our "system compiler," we have little choice but to use something other than gcc. clang appears to work, so I plan to exercise it & report issues if I encounter them. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --XjbSsFHOHxvQpKib Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA8/CYACgkQmprOCmdXAD1jeQCeMHHBByeKLfvYC9q13u6qs8s4 8XQAnjiPdn4hedz3XZdj0iyMSWZCQtyV =uZiY -----END PGP SIGNATURE----- --XjbSsFHOHxvQpKib-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 18:01:00 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C720106566C for ; Tue, 28 Aug 2012 18:01:00 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 04D878FC22 for ; Tue, 28 Aug 2012 18:00:59 +0000 (UTC) Received: by obbun3 with SMTP id un3so14548566obb.13 for ; Tue, 28 Aug 2012 11:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CH3ZKdaQ/ZizQ+I2iePIuc7x4uykeaYGkYTzMGsPQaI=; b=QXkkAyQHqtHARYXx33w/j/wnj1iS+LKGRdJUfXzUVk8yV6aazV4ZMsoCzNxMbFbG/j chd2hQ4btR4ETrMbW1ySKWl938ZszmETTEwjF3XdZATPXUnVoQxgrH/KvcNFis0wBdEf ckKBx3oeKlu59/Bc4Q9PalqVd2fyFWCbJFgN3tRWUzGEVN4tH7fybcQF6oEdlIFLLOtX dFgBK4b7AmN+Sb7WxC4u1tKguS9774yzuQVQo7mFtclvilHIGJcXXy1hnh/lUvUoIEnn bfBUwHAdU9LXvUjFSnXENCtMIbI8rm7BfwLGDazC5cw4rJN2huSolPniye2NfDXYaKm7 u54A== MIME-Version: 1.0 Received: by 10.60.20.69 with SMTP id l5mr12939980oee.114.1346176859410; Tue, 28 Aug 2012 11:00:59 -0700 (PDT) Received: by 10.182.141.66 with HTTP; Tue, 28 Aug 2012 11:00:59 -0700 (PDT) In-Reply-To: <20120828171311.GL10869@albert.catwhisker.org> References: <20120828153203.GC38854@kontrol.kode5.net> <20120828154621.GJ10869@albert.catwhisker.org> <20120828165315.GE38854@kontrol.kode5.net> <20120828171311.GL10869@albert.catwhisker.org> Date: Tue, 28 Aug 2012 11:00:59 -0700 Message-ID: From: Mehmet Erol Sanliturk To: David Wolfskill Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jamie Paul Griffin , freebsd-stable@freebsd.org Subject: Re: Building the kernel and userland with llvm/clang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:01:00 -0000 On Tue, Aug 28, 2012 at 10:13 AM, David Wolfskill wrote: > On Tue, Aug 28, 2012 at 05:53:15PM +0100, Jamie Paul Griffin wrote: > > ... > > Thanks David, that's helpful information. > > Good; that was the intent. :-) > > > I'll likely give it a go. So does clang create better binaries and > libraries, in terms of performance and such-like? I'm currently reading as > much as I can find about clang and its associated tools; however, compilers > are quite complex software and learning about them is, for me at least, a > lot to take in. > > .... > > I don't know that it creates "better" code, but I believe that at least > some of its error/warning checking may be a bit better: it certainly > whines about a fair bit of GNUish code, citing (e.g.) "Tautological > compares" ... and that sort of thing seems as if it's something I'd want > to know about if it were my code, so I could fix it. > > From the time (a few weeks) when I was building stable/9 with both gcc & > clang (on different slices, sources updated to the same GRN), I got the > impression that clang was slower (to compile) than gcc was. > > I note that I've had no issues at all with interoperation of executables > & libraries built with gcc & clang. I consider this a Good Thing. :-) > > As I understand the issues, FreeBSD uses a (somewhat modified) version > of the last GPLv2-licensed version of gcc, and there is strong incentive > to avoid "tainting" FreeBSD with a GPLv3-licensed version of gcc. > > Thus, if we want to be able to move forward with our "system compiler," > we have little choice but to use something other than gcc. clang > appears to work, so I plan to exercise it & report issues if I encounter > them. > > Peace, > david > -- > David H. Wolfskill david@catwhisker.org > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. > With respect to messages from FreeBSD mailing lists , my understanding about GPL issue is as follows : The GPL v3 has severe restrictions about use of its licensed software , especially Libraries . Some commercial companies supporting FreeBSD are using FreeBSD in their proprietary products . The GPL v3 is forcing them to legally in a difficult position . Their rescue from this legal threat is to remove GPL parts from the FreeBSD . The reason of switching to a permissive licensed compiler such as clang/LLVM is that . And reason to stay GPL v2 gcc compiler is that . This gcc compiler blocking is NOT permitting to follow new processor developments . Thank you very much . Mehmet Erol Sanliturk From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 18:10:58 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CD341065673 for ; Tue, 28 Aug 2012 18:10:58 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E52998FC08 for ; Tue, 28 Aug 2012 18:10:57 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 42F60B97F; Tue, 28 Aug 2012 14:10:57 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Tue, 28 Aug 2012 13:39:26 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <5007CFE6.6030808@intersonic.se> <201208271354.17832.jhb@freebsd.org> <503BD37E.9070801@intersonic.se> In-Reply-To: <503BD37E.9070801@intersonic.se> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208281339.26265.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 28 Aug 2012 14:10:57 -0400 (EDT) Cc: Kurt Jaeger , Martin Dieringer Subject: Re: Thinkpad X61s cannot boot 9.1-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:10:58 -0000 On Monday, August 27, 2012 4:07:26 pm Per olof Ljungmark wrote: > On 2012-08-27 19:54, John Baldwin wrote: > > On Sunday, August 26, 2012 6:59:22 pm Martin Dieringer wrote: > >> On Sun, 26 Aug 2012, Per olof Ljungmark wrote: > >> > >>> On 08/26/12 18:37, Kurt Jaeger wrote: > >>>> Hi! > >>>> > >>>>> On our X61s's setting 'debug.acpi.disabled="hostres"' does not change > >>>>> the inability to boot 9-BETA1, 9-RC1 or -current. > >>>> > >>>> I tested 9.1-RC1 on X61, and it worked without any troubles. > >>>> > >>> > >>> Yes, it does on this one too if I install a mechanical disk. The problem > > is > >>> related to installing on a SSD drive, Kingston SSDNow SV200S37A/128G. > >>> > >>> This must be related to a change in the base system some time between > >>> 9.0-RELEASE and -BETA1 as 9.0 runs and installs fine. Perhaps someone > > could > >>> suggest anther SSD drive with equal capacity that works? > >> > >> > >> debug.acpi.disabled="hostres" fixed it for me on T61 and T410 > >> with normal HD and (older) SSD (OCZ Summit) > >> > >> FreeBSD 9.1-PRERELEASE #16: Tue Aug 21 > > > > Can you get a verbose dmesg both with and without the "hostres" setting? > > > > OK, will post tomorrow, a quick check with > "debug.acpi.disabled="hostres"" yields same output excluding the "ata0: > reset ..." lines. I don't think the "hostres" bit is relevant to your case (where a different SSD fixed your issue). I think that is related to the ATA driver in some way. I am curious about Martin's case where he reports that "hostres" does make a difference however. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 18:12:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5A6F0106567F for ; Tue, 28 Aug 2012 18:12:17 +0000 (UTC) (envelope-from jamie@kode5.net) Received: from kontrol.kode5.net (kontrol.kode5.net [80.229.5.32]) by mx1.freebsd.org (Postfix) with ESMTP id BEE898FC21 for ; Tue, 28 Aug 2012 18:12:15 +0000 (UTC) Received: from kontrol.kode5.net (localhost [127.0.0.1]) by kontrol.kode5.net (8.14.5/8.14.5) with ESMTP id q7SIAr1D077475; Tue, 28 Aug 2012 19:10:53 +0100 (BST) (envelope-from jamie@kode5.net) Received: (from jamie@localhost) by kontrol.kode5.net (8.14.5/8.14.5/Submit) id q7SIAr86077474; Tue, 28 Aug 2012 19:10:53 +0100 (BST) (envelope-from jamie@kode5.net) X-Authentication-Warning: kontrol.kode5.net: jamie set sender to jamie@kode5.net using -f Date: Tue, 28 Aug 2012 19:10:53 +0100 From: Jamie Paul Griffin To: David Wolfskill Message-ID: <20120828181053.GF38854@kontrol.kode5.net> References: <20120828153203.GC38854@kontrol.kode5.net> <20120828154621.GJ10869@albert.catwhisker.org> <20120828165315.GE38854@kontrol.kode5.net> <20120828171311.GL10869@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="DO5DiztRLs659m5i" Content-Disposition: inline In-Reply-To: <20120828171311.GL10869@albert.catwhisker.org> x-operating-system: FreeBSD 9.1-PRERELEASE amd64 x-pgp-fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38 x-pgp-key: 1D31DC38 User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.5 at kontrol.kode5.net X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Building the kernel and userland with llvm/clang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:12:17 -0000 --DO5DiztRLs659m5i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ David Wolfskill wrote on Tue 28.Aug'12 at 10:13:11 -0700 ] =20 > As I understand the issues, FreeBSD uses a (somewhat modified) version > of the last GPLv2-licensed version of gcc, and there is strong incentive > to avoid "tainting" FreeBSD with a GPLv3-licensed version of gcc. >=20 > Thus, if we want to be able to move forward with our "system compiler," > we have little choice but to use something other than gcc. clang > appears to work, so I plan to exercise it & report issues if I encounter > them. Yes we're thinking along similar lines then. I will do that as well and hop= efully that will benefit the project to "move forward" as you say.=20 Thanks again for your time. Jamie --DO5DiztRLs659m5i Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIRngYJKoZIhvcNAQcCoIIRjzCCEYsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DuIwggUfMIIEB6ADAgECAhB0kD49oFhImiM1TNmYDSf/MA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDgyNTAwMDAwMFoX DTEzMDgyNTIzNTk1OVowIDEeMBwGCSqGSIb3DQEJARYPamFtaWVAa29kZTUubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArCcH9jqYDuhBs0LslWkupsEzY7j7D0okrqe9 k1eoafySH8/JL5x2Ly5XdQY+D//SRhaonnQO4vZxf/48I/ErXJnQ12Q7nv8x0OUbHUCsSDuM o+XdCHNhw6cabwP/lkn+yKQOucl8jL4DXZbUxvZdxkd5xajHi3/OOOkdxuz09gKY5kh5aTaV cg9KA5WzZ3oJ8LENEVbPnwj7AIbyALaE0N45/GN0rG7KKn5DZSjqwd40+XEMCSaw5qNYNiFz iS9S2ow0P+aQz3WUaUcFHUnTyo84CkTWRGtCS5FfWEjX7UjTZbvLAmxdndbqfahJVIL/ch+o d9WQAXIGwHBSOZtWXwIDAQABo4IB3zCCAdswHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+Kg W7x5xXswHQYDVR0OBBYEFFzXVMl5Ia5RjMxe7WhQ66w5ceGXMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDov L2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNv bW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGgYDVR0RBBMwEYEP amFtaWVAa29kZTUubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQBl+DsCE7TM7c8SgKiqwE0DSxqU CfsPA/PtqSMIZYesr9Aelod/OzawPhjUmqsliqR3s9e0e+O0s7H+PSOaf10Nn9GVc6Ej6tqt ctFPr6AeU8NUvlyqhPK4kj4DZRcJM0ervslzva8TUHWk7mC2gahmPVJ0Zl8WR2TCVdLGXrWH jz4csIw03GxRqivg86PpTnm1R9uutVem6kNWfqSdYmKqwABJ71f0N1WWJWhGUlgf5kpoRXrp AyrjFIoeD1egIbuBwf+24ynID9MSuHSqRgPxf8WWtTmpbgpnRL2TKbF9vMojXOFJ0dEeRvlF +DTbmbLPrUBQSQELOIyY2+WV6V6wMIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jAN BgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5T YWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQL ExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAx MDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958y fVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8f SG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmV WRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uD D216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDf RBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHze Pa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjAS BgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJ hkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50 aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0dHA6 Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhX VW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp1 1tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5 IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJ M75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0 M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggSdMIIDhaADAgECAhA0Pekr rCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtB ZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAg BgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAw NTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfH TrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4 vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i 5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDre CqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOB9DCB 8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUiYJnfcSdJnAA S7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAow CDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9B ZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGG GWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAAG8nONjKLDz MQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90FrmRh5H1iib6ZHAA2B75CwRiUIeT gdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC0cyJX7F88D5R8jXzfOxgmGs6K+Dv 37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol 6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBxYO7CcYIM6Yg249ogtKOgbKqWS7iA jnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUxggKEMIICgAIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQdJA+PaBYSJojNUzZmA0n/zAJ BgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEyMDgyODE4MTA1M1owIwYJKoZIhvcNAQkEMRYEFK5iRHklmXLNAkP//xkJUUXMTUsQMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAHWY4dEnacPz wbARe1Fv7awPtMn9JIMJ4E6LHxlfruC71q2j4jKqVBu4sHkEZORMaQkhmbSkapsHWwWAq8e5 qTTi05wLEvPo7gjkdckEpeyAuCUooDXfiKU54gPR/g1ByLsTwmG0Tt828dbZVEKL8/DkvDBV RcaRuKgSOLIozfDYwVpG5KfJHKRTjRzHCU5WD2637+yI/uTt9nhx+N/s47m5nb2tolGOd4fE yWQANZK865fDdeVFdZG581Z3y4afizLGioHUXOnirQ2W8Ah8UoBr3cLkSTDDm7TlEJE64pjg M7QBGrcCzIkV4ousZ1zmmmBTkzsndyMLPkGcc5g1RHU= --DO5DiztRLs659m5i-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 18:53:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 049D41065745; Tue, 28 Aug 2012 18:53:52 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6063E8FC1A; Tue, 28 Aug 2012 18:53:51 +0000 (UTC) Received: by weyx56 with SMTP id x56so12355989wey.13 for ; Tue, 28 Aug 2012 11:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QU/e4L60XGIOoz85bhFwycfHbn62GivExQqV23De5jQ=; b=eVXeZ286TogHHLcJ2y0wMDpfTcBu9NPt4+hTVdAUu8rrr8xe6ncBtC7oU5D2IemcqJ 7VPJ3uRgVkcstZIMRDW46i1bod3mJt+CXnThS2n8pgCHOur98PdUEVcODpeJ6ZiPORxm hsAS9fyUysagmqifwVqBs/SxExnRFKDwblaEzZ20TxG9aaIDh773Wv7GHgRh3idODv46 4eobx78EMy6mMWo1rsDW6Am01fhDgHDNHGt6RcsG2TQyfOfAbjcOPeGpSzQrdzZAI6mj D5g8kotdxEVu92p8LL0xMUxxUXH8HeVgkU1NEgjY0dmO8VsTYTqr+Q4qlCjRu/Kupql2 ojiA== MIME-Version: 1.0 Received: by 10.216.54.146 with SMTP id i18mr9064396wec.187.1346180030497; Tue, 28 Aug 2012 11:53:50 -0700 (PDT) Received: by 10.216.71.1 with HTTP; Tue, 28 Aug 2012 11:53:50 -0700 (PDT) In-Reply-To: <1345697446.84337.11.camel@neo.cse.buffalo.edu> References: <1345697446.84337.11.camel@neo.cse.buffalo.edu> Date: Tue, 28 Aug 2012 20:53:50 +0200 Message-ID: From: Andreas Nilsson To: Ken Smith Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: re , freebsd-stable Subject: Re: FreeBSD 9.1-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 18:53:52 -0000 On Thu, Aug 23, 2012 at 6:50 AM, Ken Smith wrote: > .... The freebsd-update(8) utility supports binary upgrades of i386 and amd64 > systems running earlier FreeBSD releases. Systems running 9.0-RELEASE > can upgrade as follows: > > # freebsd-update upgrade -r 9.1-RC1 > > This has not been working for me on i386 for the last few days. It fails with: [root@mist /usr/home/andrnils]# freebsd-update upgrade -r 9.1-RC1 Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching public key from update4.FreeBSD.org... failed. Fetching public key from update5.FreeBSD.org... failed. Fetching public key from update3.FreeBSD.org... failed. No mirrors remaining, giving up. Best regards Andreas ... > -- > Ken Smith > - From there to here, from here to | kensmith@buffalo.edu > there, funny things are everywhere. | > - Theodore Geisel | > From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 20:14:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F6E9106566B; Tue, 28 Aug 2012 20:14:33 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 728BD8FC26; Tue, 28 Aug 2012 20:14:32 +0000 (UTC) Received: by bkcje9 with SMTP id je9so2765085bkc.13 for ; Tue, 28 Aug 2012 13:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m8cRX5gctoUutzY3+1eLTZ5StbeAtI/A4lGhiHfv9cA=; b=h5wkkLMpwEQLlpSdIuvcXN5LJ0oVUTP0Y3PD5RR0zB/U9mY9P41qcAk/mPKlHSmnBN lmIfO0SGvfQYqzA8YpR75j+3dyryPT+5hAyZQpqmDVBObFRnodz+fLbS0Q0n6XV428/a OLeWIR/2x7Gb4Lkx4QJ+MQeBaPdVaHpjwUx1OLDpgDJib7/bTrEozkH/LSSJbfheSr2e sf3orB/CaZfNka81Wrm7Z+WF9w4g2Hrn0pyiXd/GalK5qMG5XS+hWrveXcAI2MXuiUu1 Q8eHWRAC/MBlzmjd4elqExfru+i7amHnaNthhBP4pMySK+rY/f+06KnwMb7dXIHo+zWg jxvg== MIME-Version: 1.0 Received: by 10.204.8.84 with SMTP id g20mr5489040bkg.126.1346184871155; Tue, 28 Aug 2012 13:14:31 -0700 (PDT) Received: by 10.204.10.141 with HTTP; Tue, 28 Aug 2012 13:14:30 -0700 (PDT) In-Reply-To: References: <1345697446.84337.11.camel@neo.cse.buffalo.edu> <20120823225855.U33776@sola.nimnet.asn.au> <1345729674.52121.4.camel@bauer.cse.buffalo.edu> <5036497F.7020501@icarz.com> <1345736581.27688.403.camel@revolution.hippie.lan> <50384172.3090706@pingle.org> Date: Tue, 28 Aug 2012 21:14:30 +0100 Message-ID: From: Chris Rees To: "Arno J. Klaassen" Content-Type: text/plain; charset=ISO-8859-1 Cc: re@freebsd.org, freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.1-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 20:14:33 -0000 On 28/08/2012, Arno J. Klaassen wrote: > Jim Pingle writes: > >> On 8/23/2012 11:43 AM, Ian Lepore wrote: >>> On Thu, 2012-08-23 at 11:17 -0400, Ken Menzel wrote: >>>> >>>> I found two good primers: >>>> http://mebsd.com/configure-freebsd-servers/update-freebsd-source-tree-using-subversion-svn.html >>>> http://www.freebsd.org/doc/en/articles/committers-guide/article.html#SUBVERSION-PRIMER >>>> >>>> The second primer in the committer handbook seems to indicate that it >>>> is difficult to run an SVN mirror. This appears to me to be the >>>> biggest drawback. I have been using CVS and perforce for years, but >>>> subversion is new to me. >>> >>> It may be difficult to run an svn mirror that allows you to commit >>> locally and get those changes back to the project, but running a >>> read-only mirror is trivial. The script I run nightly from cron to sync >>> my local mirror is: >>> >>> #!/bin/sh >>> # >>> # svnsync to pull in changes from FreeBSD to my local mirror. >>> # >>> svnsync sync file:///local/vc/svn/base >>> >>> I can't remember how I initially created and populated the mirror, but >>> it's likely I grabbed a snapshot of the mirror at work and brought it >>> home on a thumb drive (just to avoid initial network DL time). >> >> I spent a little time today setting up an SVN mirror after reading this >> thread and wrote up a how-to for those looking to do the same. >> >> http://www.pingle.org/2012/08/24/freebsd-svn-mirror >> >> Comments/Flames/Corrections welcome... > > thanx; works out of the box for me (using the "svnserve_enable" path). > > That said : I glanced at a diff of a stable/8 checkout both from > /home/ncvs repo and new /home/freebsd-svn one, and saw a (maybe well-known > ..) > 'feature' : > > diff ./src/contrib/amd/include/am_defs.h > /raid1/bsd/8/src/contrib/amd/include/am_defs.h > > 42c42 > < * $FreeBSD: stable/8/contrib/amd/include/am_defs.h 174299 2007-12-05 > 16:03:52Z obrien $ > --- >> * $FreeBSD: src/contrib/amd/include/am_defs.h,v 1.15.2.1 2009/08/03 >> 08:13:06 kensmith Exp $ > > > I wondered why the date (and commiter ...) in the expansion were > different (from the svn log ): > > ------------------------------------------------------------------------ > r196045 | kensmith | 2009-08-03 10:13:06 +0200 (Mon, 03 Aug 2009) | 4 > lines > > Copy head to stable/8 as part of 8.0 Release cycle. > > Approved by: re (Implicit) > > ------------------------------------------------------------------------ > r174299 | obrien | 2007-12-05 17:03:52 +0100 (Wed, 05 Dec 2007) | 3 > lines > > > So the 'Copy head' chain does not update the $FreeBSD tag, whereas the > consequent svn to cvs chain does. That's because CVS does not consider tagging/branching a commit, whereas Subversion does. Chris From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 20:31:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC308106566C for ; Tue, 28 Aug 2012 20:31:33 +0000 (UTC) (envelope-from jamie@kode5.net) Received: from kontrol.kode5.net (kontrol.kode5.net [80.229.5.32]) by mx1.freebsd.org (Postfix) with ESMTP id 493508FC0A for ; Tue, 28 Aug 2012 20:31:32 +0000 (UTC) Received: from kontrol.kode5.net (localhost [127.0.0.1]) by kontrol.kode5.net (8.14.5/8.14.5) with ESMTP id q7SKVUZ8078477 for ; Tue, 28 Aug 2012 21:31:31 +0100 (BST) (envelope-from jamie@kode5.net) Received: (from jamie@localhost) by kontrol.kode5.net (8.14.5/8.14.5/Submit) id q7SKVUxt078476 for freebsd-stable@freebsd.org; Tue, 28 Aug 2012 21:31:30 +0100 (BST) (envelope-from jamie@kode5.net) X-Authentication-Warning: kontrol.kode5.net: jamie set sender to jamie@kode5.net using -f Date: Tue, 28 Aug 2012 21:31:30 +0100 From: Jamie Paul Griffin To: freebsd-stable@freebsd.org Message-ID: <20120828203130.GB78051@kontrol.kode5.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline x-operating-system: FreeBSD 9.1-PRERELEASE amd64 x-pgp-fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38 User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.5 at kontrol.kode5.net X-Virus-Status: Clean Subject: Question About Tracking the Stable Branch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 20:31:33 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi I am following 9 Stable. I have read the handbook information and I am now = subscribed to this list and the svn-src-stable-9@ list. Even after reading the handbook, what i'm not clear about is this: I see individual commits being submitted to the source tree; do I: - patch and update each individual commit, or; - rebuild world say once every couple of days or even each day to incorpor= ate the changes, and; - does the kernel need to be rebuilt and reinstalled each time if using th= e first option. Obviously I would have to if rebuilding world (the second o= ption). Am I right in thinking that it also depends on the type of change; i.e. if = the change is to a kernel and/or a kernel module then clearly I need to reb= uild the kernel. But, then would I need to rebuild the userland as well? I hope I am making sense and not asking dumb questions, I just want to be c= lear about the process.=20 Essentially, I want to know if it's necessary to rebuild the entire userlan= d and kernel sources just to incorporate a small number of changes. Obvious= ly that's a lot of time compiling. Or, do I just patch the commited files a= nd rebuild that bit of the sourse tree and the kernel if necessary due to t= he type of change made.=20 I've not followed a FreeBSD stable branch before so just wanted to clarify = those points. I'd like to be involved with testing things for the project, = etc.=20 Best wishes,=20 Jamie. --envbJBWh7q8WU6mo Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIRngYJKoZIhvcNAQcCoIIRjzCCEYsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DuIwggUfMIIEB6ADAgECAhB0kD49oFhImiM1TNmYDSf/MA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDgyNTAwMDAwMFoX DTEzMDgyNTIzNTk1OVowIDEeMBwGCSqGSIb3DQEJARYPamFtaWVAa29kZTUubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArCcH9jqYDuhBs0LslWkupsEzY7j7D0okrqe9 k1eoafySH8/JL5x2Ly5XdQY+D//SRhaonnQO4vZxf/48I/ErXJnQ12Q7nv8x0OUbHUCsSDuM o+XdCHNhw6cabwP/lkn+yKQOucl8jL4DXZbUxvZdxkd5xajHi3/OOOkdxuz09gKY5kh5aTaV cg9KA5WzZ3oJ8LENEVbPnwj7AIbyALaE0N45/GN0rG7KKn5DZSjqwd40+XEMCSaw5qNYNiFz iS9S2ow0P+aQz3WUaUcFHUnTyo84CkTWRGtCS5FfWEjX7UjTZbvLAmxdndbqfahJVIL/ch+o d9WQAXIGwHBSOZtWXwIDAQABo4IB3zCCAdswHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+Kg W7x5xXswHQYDVR0OBBYEFFzXVMl5Ia5RjMxe7WhQ66w5ceGXMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDov L2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNv bW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGgYDVR0RBBMwEYEP amFtaWVAa29kZTUubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQBl+DsCE7TM7c8SgKiqwE0DSxqU CfsPA/PtqSMIZYesr9Aelod/OzawPhjUmqsliqR3s9e0e+O0s7H+PSOaf10Nn9GVc6Ej6tqt ctFPr6AeU8NUvlyqhPK4kj4DZRcJM0ervslzva8TUHWk7mC2gahmPVJ0Zl8WR2TCVdLGXrWH jz4csIw03GxRqivg86PpTnm1R9uutVem6kNWfqSdYmKqwABJ71f0N1WWJWhGUlgf5kpoRXrp AyrjFIoeD1egIbuBwf+24ynID9MSuHSqRgPxf8WWtTmpbgpnRL2TKbF9vMojXOFJ0dEeRvlF +DTbmbLPrUBQSQELOIyY2+WV6V6wMIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jAN BgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5T YWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQL ExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAx MDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958y fVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8f SG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmV WRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uD D216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDf RBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHze Pa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjAS BgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJ hkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50 aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0dHA6 Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhX VW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp1 1tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5 IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJ M75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0 M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggSdMIIDhaADAgECAhA0Pekr rCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtB ZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAg BgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAw NTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfH TrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4 vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i 5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDre CqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOB9DCB 8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUiYJnfcSdJnAA S7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAow CDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9B ZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGG GWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAAG8nONjKLDz MQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90FrmRh5H1iib6ZHAA2B75CwRiUIeT gdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC0cyJX7F88D5R8jXzfOxgmGs6K+Dv 37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol 6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBxYO7CcYIM6Yg249ogtKOgbKqWS7iA jnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUxggKEMIICgAIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQdJA+PaBYSJojNUzZmA0n/zAJ BgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEyMDgyODIwMzEzMFowIwYJKoZIhvcNAQkEMRYEFF7WPmApTXVxjDsTESXdsnwAqLpIMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAEpXXlXgAu95 qzaPqhSTzo8i1iRaKHdpIaWPlhDpwgOGxCLsqKeMZ2IF172w0epAzEp2c+Mc1/yIVLAVo5/D kGXjC1wnJf6XQlaZz1X2TZZIibNGdcLavcozGn8BLaK/19pW5z8wDApOtqV7h1L+ai8m+EEQ Hnp06KEic8aDORrX3FCGdop6jGTUOeQa7Wib0Ns6r/qQmzUnBIOWy4nqJoqTFUb+cblm4ZDn FfMPiqxTKGK76sDmyB3sDQFVkjhE6YyXrBPsC6EoR9ToXU3Ng16oxYkvfNHGSmUwWd2ydYOb 8f98+tX8tIwuu+iFC6RlZk3E1vGLFbWNPe7WL5TQUz0= --envbJBWh7q8WU6mo-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 20:37:42 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75BE2106566B for ; Tue, 28 Aug 2012 20:37:42 +0000 (UTC) (envelope-from bryan@shatow.net) Received: from secure.xzibition.com (secure.xzibition.com [173.160.118.92]) by mx1.freebsd.org (Postfix) with ESMTP id 1A12F8FC1A for ; Tue, 28 Aug 2012 20:37:39 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sweb; b=kMdhqz ttqTH7ZTenhcVz7ckbZ6I+RMDcC9lf6wrrXzjEw1V54O4vpDZe1vgH92fB7nWZfb Q1BQEOMJzL7dFtiNwKafnf9FUC3DNE1qRtAINCK2esVZAJlFdHUYS3k1v7uKYOP/ lz5C6tAakdXTH0d96iLD4/Ez8JHV314Douzjw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=shatow.net; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sweb; bh=fWTA6N5NYW8Y m4f7K+n9LXpTRFSPFeYXjeB7TBcuxXI=; b=G7gBhkY1DDBM/z/Y1WoQvsHm83+Q PUItBjSJNtI91ge7Z/11DKVlgt3pUCoz2r6giGookgeLl294qDExcIgmsKEIuva+ hwSnIK0NiQ8u9o6I2bB8D1RYPkpvVOaVd3cQup27xcCjwKmK5lqT0Lux+bnU77Qh Te+qC1H03sSHKYc= Received: (qmail 63599 invoked from network); 28 Aug 2012 15:37:37 -0500 Received: from unknown (HELO ?192.168.0.74?) (bryan@shatow.net@74.94.87.209) by sweb.xzibition.com with ESMTPA; 28 Aug 2012 15:37:37 -0500 Message-ID: <503D2C0F.6000403@shatow.net> Date: Tue, 28 Aug 2012 15:37:35 -0500 From: Bryan Drewery User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: h.schmalzbauer@omnilan.de References: <1345697446.84337.11.camel@neo.cse.buffalo.edu> <20120823225855.U33776@sola.nimnet.asn.au> <1345729674.52121.4.camel@bauer.cse.buffalo.edu> <3E419978-37B5-434B-BB54-A4C069A9A887@FreeBSD.org> <50389BFC.8050300@omnilan.de> In-Reply-To: <50389BFC.8050300@omnilan.de> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 9.1-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 20:37:42 -0000 On 8/25/2012 4:33 AM, Harald Schmalzbauer wrote: > But my real problem is that svn is not in the base system. And for > example installing subversion package on my cvsup mirror failed because > pkg-config-0-25_1 was installed and sqlite, a dependency of subversion, > wants to install pkgconf-0.8.5. So I'm hit by the henn-egg problem. This is because pkg-config was removed and moved from devel/pkg-config to devel/pkgconf. To update or install any port, you'll need to deinstall pkg-config and install pkgconf. There is an associated UPDATING entry: 20120726: AFFECTS: users of devel/pkg-config AUTHOR: bapt@FreeBSD.org devel/pkg-config has been replaced by devel/pkgconf # portmaster -o devel/pkgconf devel/pkg-config or # portupgrade -fo devel/pkgconf pkg-config-\* pkgng: # pkg set -o devel/pkg-config:devel/pkgconf # pkg install -f devel/pkgconf Bryan From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 20:38:24 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 081211065676 for ; Tue, 28 Aug 2012 20:38:24 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9169B8FC16 for ; Tue, 28 Aug 2012 20:38:23 +0000 (UTC) Received: by weyx56 with SMTP id x56so12421966wey.13 for ; Tue, 28 Aug 2012 13:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fVooWbuHSmuy6mp6Of8YcXMKHTxPeNYsx1/XGrG1qz0=; b=qzeXR6JMRoZZ0Qv+jS8/+WILBJLEbzEHf1rfvXBVbzLB1CU9qpfOP4JLtkhw6B+JTa KGpr/+fd+yok80DlT0BYr3FB6ge8q0eeCITtK4gTBJ68h0ev8ergE04nAcNgxPkrJGOP +Zf4fC4fe/G1hMIpDl8kxvDOPr/TXbJOgXmE/fMs+yzLlxFH1m4HSJpY8PFpyCU8MKki SS7pShISSwTHsZvaYW15ZWJoxhaWN0kqX1ZsC9dUGZkrjsrLVHYrUts3w9HhbvKk+QoX +kV4lWB/30EDtTnGmnBnBixwkzYa4da12DTDHXj+17qBwx+o0kjz8VW19e37qS1cNlde busQ== MIME-Version: 1.0 Received: by 10.180.100.37 with SMTP id ev5mr35392393wib.5.1346186302417; Tue, 28 Aug 2012 13:38:22 -0700 (PDT) Received: by 10.223.63.76 with HTTP; Tue, 28 Aug 2012 13:38:22 -0700 (PDT) In-Reply-To: <9fa99b69aab3afdd72f5776406eb1b65@dweimer.net> References: <9fa99b69aab3afdd72f5776406eb1b65@dweimer.net> Date: Tue, 28 Aug 2012 13:38:22 -0700 Message-ID: From: Kevin Oberman To: dweimer@dweimer.net Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Stable Subject: Re: cdrtools port installation failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 20:38:24 -0000 On Tue, Aug 28, 2012 at 8:46 AM, dweimer wrote: > Anyone else not able to get cdrtools to install on a Stable System? > > I have just recently synced my source and rebuilt world, and kernel, then > installed. Now while trying to install the livecd port, the cdrtools > dependency is failing to install. > > The port compiles fine (at least it doesn't stop reporting an error), but > dies on the installation portion reporting a missing file. > > install: > /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav: > No such file or directory *** [do-install] Error code 71 > > There is a cdda2wav.d and cdda2wav.o file in the directory its searching, > however when I run this on my FreeBSD 9.0-RELEASE-p4 system, there is also a > cdda2wav file with no extension. > > ls > /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/ > Dnull > Inull > aifc.d > aifc.o > aiff.d > aiff.o > base64.d > base64.o > cd_misc.d > cd_misc.o > cdda2wav.d > cdda2wav.o > config.cache > config.log > config.status > interface.d > interface.o > ioctl.d > ioctl.o > lconfig.h > local.cnf > parse.d > parse.o > raw.d > raw.o > resample.d > resample.o > ringbuff.d > ringbuff.o > scsi_cdr.d > scsi_cdr.o > scsi_cmds.d > scsi_cmds.o > scsi_scan.d > scsi_scan.o > semshm.d > semshm.o > setuid.d > setuid.o > sndconfig.d > sndconfig.o > sun.d > sun.o > toc.d > toc.o > wav.d > wav.o > > > -- > Thanks, > Dean E. Weimer > http://www.dweimer.net/ How odd! I can't replicate this at all. I just made cdrtools-3.00_2 and I have: cc -o OBJ/amd64-freebsd-cc/cdda2wav OBJ/amd64-freebsd-cc/cdda2wav.o OBJ/amd64-freebsd-cc/interface.o OBJ/amd64-freebsd-cc/semshm.o OBJ/amd64-freebsd-cc/resample.o OBJ/amd64-freebsd-cc/scsi_scan.o OBJ/amd64-freebsd-cc/toc.o OBJ/amd64-freebsd-cc/wav.o OBJ/amd64-freebsd-cc/sun.o OBJ/amd64-freebsd-cc/raw.o OBJ/amd64-freebsd-cc/setuid.o OBJ/amd64-freebsd-cc/ringbuff.o OBJ/amd64-freebsd-cc/sndconfig.o OBJ/amd64-freebsd-cc/scsi_cmds.o OBJ/amd64-freebsd-cc/aiff.o OBJ/amd64-freebsd-cc/aifc.o OBJ/amd64-freebsd-cc/scsi_cdr.o OBJ/amd64-freebsd-cc/cd_misc.o OBJ/amd64-freebsd-cc/ioctl.o OBJ/amd64-freebsd-cc/base64.o OBJ/amd64-freebsd-cc/parse.o -L../libs/amd64-freebsd-cc -L../libs/amd64-freebsd-cc -L/usr/local/lib -L/usr/local/lib -lscgcmd -lrscg -lscg -lparanoia -lcdrdeflt -ldeflt -lmdigest -lschily -lcam And, as I expected, I find it: # find work/cdrtools-3.00/ -name cdda2wav work/cdrtools-3.00/cdda2wav work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav Look trough the log of your make and see if anything "odd" happened in that step. It should be at the end of the section : ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc/Inull" ==> CONFIGURING LOCAL RULES "OBJ/amd64-freebsd-cc/local.cnf" and just before: ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdrecord" This was on a stable system updated on Aug. 16. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 20:48:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29DE2106568C for ; Tue, 28 Aug 2012 20:48:31 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id D8A878FC12 for ; Tue, 28 Aug 2012 20:48:30 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q7SKmOYR037649; Tue, 28 Aug 2012 13:48:24 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q7SKmOvX037648; Tue, 28 Aug 2012 13:48:24 -0700 (PDT) (envelope-from david) Date: Tue, 28 Aug 2012 13:48:24 -0700 From: David Wolfskill To: Jamie Paul Griffin Message-ID: <20120828204824.GM10869@albert.catwhisker.org> References: <20120828203130.GB78051@kontrol.kode5.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EEx6GiKZGZ1wKUra" Content-Disposition: inline In-Reply-To: <20120828203130.GB78051@kontrol.kode5.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Question About Tracking the Stable Branch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 20:48:31 -0000 --EEx6GiKZGZ1wKUra Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 28, 2012 at 09:31:30PM +0100, Jamie Paul Griffin wrote: > Hi >=20 > I am following 9 Stable. I have read the handbook information and I am no= w subscribed to this list and the svn-src-stable-9@ list. >=20 > Even after reading the handbook, what i'm not clear about is this: >=20 > I see individual commits being submitted to the source tree; do I: >=20 > - patch and update each individual commit, or; >=20 > - rebuild world say once every couple of days or even each day to incorp= orate the changes, and; >=20 > - does the kernel need to be rebuilt and reinstalled each time if using = the first option. Obviously I would have to if rebuilding world (the second= option). > ... Errmmm... Well, here's what I do (briefly): * I maintain /usr/src as an SVN "working copy" -- that is, I created it by (the logical equivalent of): * # cd /usr && rm -fr src && mkdir src && chown david src * $ cd /usr/src && svn co ${repo}/stable/9 . (where "$repo" is a URL for the SVN repo used). Periodically (daily, in my case), after the repo that I use has been updated, I issue: * $ svn update /usr/src and if there were updates, I rebuild. If the only updates are to the kernel sources, I often only rebuild the kernel. If any updates were not for the kernel, I rebuild both userland and kernel. See /usr/src/UPDATING; look for the string "COMMON ITEMS" (about 87% of the way into the file). I use the "To rebuild everything and install it on the current system." with the variation that I usually specify -DNOCLEAN, and I haven't actually needed to perform the "" step in longer than I can remember. I do all builds within a script(1) invocation (so I have a record), and usually within screen(1), as well (just in case Something Weird happens). I also usually specify a -j value, in order to take advantage of multiple cores. I hope that helps a bit. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --EEx6GiKZGZ1wKUra Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA9LpcACgkQmprOCmdXAD1zygCfVmJPq6UXgYPs/MmKTOAg1PZ0 6pgAn09r55C5oO9dHCKQlTr1CtJtoz4B =r6qd -----END PGP SIGNATURE----- --EEx6GiKZGZ1wKUra-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 21:03:35 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5BAB6106566B for ; Tue, 28 Aug 2012 21:03:35 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id D29708FC16 for ; Tue, 28 Aug 2012 21:03:34 +0000 (UTC) Received: by lbbgg13 with SMTP id gg13so4213618lbb.13 for ; Tue, 28 Aug 2012 14:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h0LWOTuUdUP6MWia0VNUC2J1/8pmJAgfpmAD2ii8XLU=; b=KV5mytXLZETGqtU6gtMC6IAsZLoNkvq0kXcFsdXzQ14bWnZorfuJG7u6GNqa+55vcv gnFCrb5RLsxYqfIr0eNyy/qB3Fyoa+a8qqn7oMiAMyo23TFM6Ax86Mm9UL9+bMbOkYpe IktwObhs48qqURQiZ1jylJ6hDxyB/acfoI/S+AkjbDUHLWrP1Mb1FpTfHm5yzlupw+o0 JccVrILXoIn2SizvPKo1pWYf1/t42NfsiMK/OIyQqY7gvz7V/Sc8ioM0Xo2P57n9yxX+ x8maKw5jRnYoMDCW0jOeHYOgHiuz6Q/rYKSw48tbaiw7K2ViflJbkHvFZFvK7NMxrr9G a30A== MIME-Version: 1.0 Received: by 10.112.82.33 with SMTP id f1mr8658198lby.35.1346187813503; Tue, 28 Aug 2012 14:03:33 -0700 (PDT) Received: by 10.114.23.230 with HTTP; Tue, 28 Aug 2012 14:03:33 -0700 (PDT) In-Reply-To: <20120828203130.GB78051@kontrol.kode5.net> References: <20120828203130.GB78051@kontrol.kode5.net> Date: Tue, 28 Aug 2012 14:03:33 -0700 Message-ID: From: Freddie Cash To: Jamie Paul Griffin Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: Question About Tracking the Stable Branch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 21:03:35 -0000 On Tue, Aug 28, 2012 at 1:31 PM, Jamie Paul Griffin wrote: > I am following 9 Stable. I have read the handbook information and I am now subscribed to this list and the svn-src-stable-9@ list. > > Even after reading the handbook, what i'm not clear about is this: > > I see individual commits being submitted to the source tree; do I: > - patch and update each individual commit, or; > - rebuild world say once every couple of days or even each day to incorporate the changes, and; > - does the kernel need to be rebuilt and reinstalled each time if using the first option. Obviously I would have to if rebuilding world (the second option). Personally, I don't update -STABLE boxes unless a specific change that's useful for my setups comes through. And then I'll usually wait 1-2 days after the specific commit hits the tree in case there's a last-minute fix to that commit. If there's nothing I want to test, or that I need, though, I don't update. So, it all depends on your needs: - are you tracking -STABLE to do development? - are you tracking -STABLE to get updated drivers? - are you tracking -STABLE to get specific functionality? - are you tracking -STABLE to help with bug finding/fixing? - etc ... What your needs are will dictate how often you update the source tree, rebuild the world, and run with the latest bits. > Am I right in thinking that it also depends on the type of change; i.e. if the change is to a kernel and/or a kernel module then clearly I need to rebuild the kernel. But, then would I need to rebuild the userland as well? Most commit logs will include information on whether it's kernel-only, userland-only, 1-module only, kernel+userland, multiple modules, etc. Depending on the speed of your machine, you can do a full buildworld cycle for every update. Or limit it to just the kernel/userland component that's updated. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 21:04:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0F1A106566B for ; Tue, 28 Aug 2012 21:04:00 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by mx1.freebsd.org (Postfix) with ESMTP id 7307B8FC15 for ; Tue, 28 Aug 2012 21:04:00 +0000 (UTC) Received: by wgbed3 with SMTP id ed3so3404691wgb.8 for ; Tue, 28 Aug 2012 14:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gbr1B/Bjo44i52VFU9ObLUOMpueBX43NSPEbmjLg2fA=; b=h1dFEA8w8cjCCIHXsQIrkDAWc/MLSHW9Uqvat9d1GHYDOs3ai28F1ZzIeAwqiqA7rB VtLANDhj9F8ZJKkzCPkWAVDeh82N6cJtDzW4w9XyftTFpMZiKswWgl52WaONzuraug1b uDbA5mZmECGQ1aSGJ1Lwq0PGJ94dXGCuOLPfTdsG+adiq5jgIARNwb+xYGN8+J+ouTL2 LMBl1DtQvUmPToFUKFUD4nJWpS7iP74P6kaxa4o+4PMTllVaNPyhrq2ci5eM68Qox++u 2QtNiWV1d61XLZSb+3rqluhV3RJEBR32GgIQtRPb6n7qVAz6p2bzTRrlfBM9vr76nyuo pk6A== MIME-Version: 1.0 Received: by 10.180.107.103 with SMTP id hb7mr35517861wib.3.1346187839089; Tue, 28 Aug 2012 14:03:59 -0700 (PDT) Received: by 10.223.63.76 with HTTP; Tue, 28 Aug 2012 14:03:59 -0700 (PDT) In-Reply-To: <20120828203130.GB78051@kontrol.kode5.net> References: <20120828203130.GB78051@kontrol.kode5.net> Date: Tue, 28 Aug 2012 14:03:59 -0700 Message-ID: From: Kevin Oberman To: Jamie Paul Griffin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: Question About Tracking the Stable Branch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 21:04:01 -0000 On Tue, Aug 28, 2012 at 1:31 PM, Jamie Paul Griffin wrote= : > Hi > > I am following 9 Stable. I have read the handbook information and I am no= w subscribed to this list and the svn-src-stable-9@ list. > > Even after reading the handbook, what i'm not clear about is this: > > I see individual commits being submitted to the source tree; do I: > > - patch and update each individual commit, or; > > - rebuild world say once every couple of days or even each day to= incorporate the changes, and; > > - does the kernel need to be rebuilt and reinstalled each time if= using the first option. Obviously I would have to if rebuilding world (the= second option). > > Am I right in thinking that it also depends on the type of change; i.e. i= f the change is to a kernel and/or a kernel module then clearly I need to r= ebuild the kernel. But, then would I need to rebuild the userland as well? > > I hope I am making sense and not asking dumb questions, I just want to be= clear about the process. > > Essentially, I want to know if it's necessary to rebuild the entire userl= and and kernel sources just to incorporate a small number of changes. Obvio= usly that's a lot of time compiling. Or, do I just patch the commited files= and rebuild that bit of the sourse tree and the kernel if necessary due to= the type of change made. > > I've not followed a FreeBSD stable branch before so just wanted to clarif= y those points. I'd like to be involved with testing things for the project= , etc. Most people DON'T try to update for every commit. Many will rebuild on a daily basis. Many weekly or monthly. Some only when they see a need (such as a fix for a problem they are experiencing) or just get around to it. How you choose to do do it is entirely up to you. Manually applying updates and just rebuilding things that use that change is certainly possible, but requires careful insight as to what a given patch will impact. Does it result in a new library that my, in turn, require the rebuild of code that uses it? Kernel patches can be integrated but it is far easier to just update modules if the patch is to a part of the kernel that can be loaded as a module. In all cases, if you rebuild the kernel, be sure that the old kernel is saved to kernel.old so you can go back to it if there si a problem. 'make installkernel' does this) and, should you fix a problem and re-link the kernel, be sure NOT to overwrite the working kernel ('make reinstallkernel' does this. Also, many kernel changes impact the KBI, so some userland tools that use kernel structures (e.g. top) my fail after a kernel update that is not accompanied by a userland rebuild. In general, I update stable about once a month. I use 'svn up' to update my source tree and then follow the "standard" instructions: cd /usr/src rm -rf /usr/obj/* make -j6 -DNO_CLEAN buildworld mergemaster -p (usually a no-op) make -j6 buildkernel make installkernel shutdown -r now (to single user mode) fsck -p adjkerntz -i (if the hardware clock is not running UTC) swapon -a mount -a -t ufs cd /usr/src/ make installworld mergemaster -iPF (Use -U at your own risk. It saves time, but you might miss something on rare occasion.) make check-old rm -rf any deleted directories (saves time) make delete-old reboot --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 21:12:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6F54106564A for ; Tue, 28 Aug 2012 21:12:18 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 557218FC08 for ; Tue, 28 Aug 2012 21:12:17 +0000 (UTC) Received: by lage12 with SMTP id e12so4229058lag.13 for ; Tue, 28 Aug 2012 14:12:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OKbJAX3bCjjynNmC65Mi2ZmcXXFpo8celr4ApX4rsys=; b=k2a+hT88js8JnEAVlAPYuNIhZa7x7Pfy3ZrZ+gf1fntXVwOK89aXCKfTny6a5DFeWF SFjMhjy7ae8YV7P1i6ck/OceKFI7DgGCyokXVBf9+VHgWwuHRCR+mbs6QX0pgcxPjnKl bVnDXUAMmzk9OFHnYAVYCXH0M/xLB3rehloI5Dte6pB0GhnN0TsWNTwvlTZFXTP/3WPW BxuQcfNrvbxPDV3etIslWVgpgN5WMORMTKWIzt0uqfr5gp6G/bKsIF735FJ6I7x+3yim 7UR0aIz0TqQ3Ey4HUdLXVgYKOcip2atC5vN/Od8b28X7K7k6eEZwGFZ75Y08wxNAvRCA d0Tg== MIME-Version: 1.0 Received: by 10.112.48.193 with SMTP id o1mr5525520lbn.62.1346188330850; Tue, 28 Aug 2012 14:12:10 -0700 (PDT) Received: by 10.114.23.230 with HTTP; Tue, 28 Aug 2012 14:12:10 -0700 (PDT) In-Reply-To: References: <20120828203130.GB78051@kontrol.kode5.net> Date: Tue, 28 Aug 2012 14:12:10 -0700 Message-ID: From: Freddie Cash To: Kevin Oberman Content-Type: text/plain; charset=UTF-8 Cc: Jamie Paul Griffin , freebsd-stable@freebsd.org Subject: Re: Question About Tracking the Stable Branch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 21:12:18 -0000 On Tue, Aug 28, 2012 at 2:03 PM, Kevin Oberman wrote: > In all cases, if you rebuild the kernel, be sure that the old kernel > is saved to kernel.old so you can go back to it if there si a problem. > 'make installkernel' does this) and, should you fix a problem and > re-link the kernel, be sure NOT to overwrite the working kernel ('make > reinstallkernel' does this. It's not mentioned often on the lists, but KODIR and nextboot(8) are wonderful things: # make buildworld # make KERNCONF=MYKERNEL buildkernel # make KERNCONF=MYKERNEL KODIR=/boot/MYKERNEL installkernel # nextboot -k MYKERNEL # shutdown -r now That will install your new kernel into /boot/MYKERNEL, leaving /boot/kernel alone. nextboot configures the boot process to use /boot/MYKERNEL, again leaving /boot/kernel along. If anything goes wrong, a simple reboot of the box returns you to using /boot/kernel as before. If the new kernel works correctly, then you can manually copy/moves things around as needed: # mv /boot/kernel /boot/kernel.old # cp -Rvp /boot/MYKERNEL /boot/kernel Especially useful when testing new kernels on remote systems, as "hit the reset switch" on a locked up box puts things back to the way they were before. No loader commands required. :) -- Freddie Cash fjwcash@gmail.com From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 21:51:14 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D0C4106566B for ; Tue, 28 Aug 2012 21:51:14 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3E5BE8FC0C for ; Tue, 28 Aug 2012 21:51:14 +0000 (UTC) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.xtaz.co.uk (Postfix) with ESMTPS id 4A9A31005357; Tue, 28 Aug 2012 22:51:13 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 28 Aug 2012 22:51:12 +0100 From: Matt Smith To: Warren Block In-Reply-To: References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> <79cd5f15b21566846e5ef3579f67668b@xtaz.co.uk> Message-ID: <50385abc5b84946693ca34bced9d0537@xtaz.co.uk> X-Sender: matt@xtaz.co.uk User-Agent: Roundcube Webmail/0.8.1 Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 21:51:14 -0000 On 2012-08-27 21:35, Warren Block wrote: > On Mon, 27 Aug 2012, Matt Smith wrote: >> Thank you for your help anyway, and your wonkity site, which I also >> once used for converting my procmail to maildrop. And thanks also to >> Erich and Stefan for your help. When I get some spare time I'll redo >> the filesystem and hope that it works. > > Please post a followup after that. Here is the followup! I have just rebuilt the server from scratch using a 9.1-RC1 amd64 memstick image. Used the GPT labels directly in the fstab and ignored glabel. And guess what? It works fine as you probably expected. So it was definitely user error and the glabel broke it. At least I've learnt a lot more about partitioning and filesystems than I knew before anyway! So once again, thank you for all your help. There is an open PR for this that I raised which is amd64/170646 , I don't think there is any way for me to close this myself is there? If somebody reads this who has the rights to do so then please close it with "user is an idiot" :) Matt. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 22:18:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E35BE106566B for ; Tue, 28 Aug 2012 22:18:40 +0000 (UTC) (envelope-from hirez@libeljournal.com) Received: from outbound-queue-2.mail.thdo.gradwell.net (outbound-queue-2.mail.thdo.gradwell.net [212.11.70.35]) by mx1.freebsd.org (Postfix) with ESMTP id 767298FC23 for ; Tue, 28 Aug 2012 22:18:40 +0000 (UTC) Received: from outbound-edge-2.mail.thdo.gradwell.net (bonnie.gradwell.net [212.11.70.2]) by outbound-queue-2.mail.thdo.gradwell.net (Postfix) with ESMTP id 38B942265B for ; Tue, 28 Aug 2012 23:18:34 +0100 (BST) Received: from cpc2-chap5-0-0-cust256.aztw.cable.virginmedia.com (HELO propellor.libeljournal.com) (77.103.165.1) (smtp-auth username hirez, mechanism cram-md5) by outbound-edge-2.mail.thdo.gradwell.net (qpsmtpd/0.83) with (AES256-SHA encrypted) ESMTPSA; Wed, 29 Aug 2012 00:06:08 +0100 Received: from propellor.libeljournal.com (localhost [127.0.0.1]) by propellor.libeljournal.com (Postfix) with ESMTP id C346217083 for ; Tue, 28 Aug 2012 23:18:32 +0100 (BST) X-Virus-Scanned: amavisd-new at libeljournal.com Received: from propellor.libeljournal.com ([127.0.0.1]) by propellor.libeljournal.com (propellor.libeljournal.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vh-h8efGlHv2 for ; Tue, 28 Aug 2012 23:18:23 +0100 (BST) Received: from [172.16.0.10] (twister.libeljournal.com [172.16.0.10]) by propellor.libeljournal.com (Postfix) with ESMTPA id 051BA17082 for ; Tue, 28 Aug 2012 23:18:22 +0100 (BST) Message-ID: <503D43A7.4030900@libeljournal.com> Date: Tue, 28 Aug 2012 23:18:15 +0100 From: John Hawkes-Reed User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <503BA51E.4030103@libeljournal.com> <503BB721.9000108@borderworlds.dk> <503BC497.3060206@libeljournal.com> <503BCA0A.1020904@borderworlds.dk> <503BCB0A.6000702@FreeBSD.org> <20120828012322.8EBFE24416C4@drugs.dv.isc.org> In-Reply-To: <20120828012322.8EBFE24416C4@drugs.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gradwell-MongoId: 503d4ee0.64a7-e72-2 X-Gradwell-Auth-Method: smtpauth X-Gradwell-Auth-Credentials: hirez Subject: Re: [Solved, I think] IPv6 default route. Can't see the wood for the trees. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 22:18:41 -0000 On 28/08/2012 02:23, Mark Andrews wrote: > In message <503BCB0A.6000702@FreeBSD.org>, Doug Barton writes: >> On 8/27/2012 12:27 PM, Christian Laursen wrote: >>> On 08/27/12 21:03, John Hawkes-Reed wrote: >>>> On 27/08/2012 19:06, Christian Laursen wrote: >>>>> On 08/27/12 18:49, John Hawkes-Reed wrote: >>>>>> rc.conf: >>>>>> >>>>>> (I'm not convinced that obfuscating the addresses is worth the >>>>>> confusion) >>>>>> >>>>>> ipv6_gateway_enable="YES" >>>>>> ip6addrctl_verbose="YES" >>>>>> rtadvd_enable="YES" >>>>>> rtadvd_interfaces="rl0" >>>>>> ipv6_cpe_wanif="pcn0" >>>>>> ipv6_defaultrouter="2001:470:1f0a:b5a::1" >>>>>> gif_interfaces="gif0" >>>>>> gifconfig_gif0="192.168.1.100 216.66.80.30" >>>>>> ifconfig_gif0_ipv6="inet6 2001:470:1f0a:b5a::2 2001:470:1f0a:b5a::1 >>>>>> prefixlen 128" >>>>>> ifconfig_pcn0_ipv6="inet6 2001:470:1f0b:b5a::4 prefixlen 64" >>>>>> ifconfig_rl0_ipv6="inet6 2001:470:1f0b:b5a::3 prefixlen 64 >>>>>> -accept_rtadv" >>>>> >>>>> It looks like you are trying to use the /64 used for your tunnel on the >>>>> inside network. That's probably what causes the problem. >>>>> >>>>> You should use the "Routed /64" on the inside. If you need more than one >>>>> /64, you can request a /48. >>>> >>>> I think I am. The endpoints are ...:1f0A: and the /64 is ...:1f0B: >>> >>> Sorry, my bad. >>> >>> Are pcn0 and rl0 both connected to internal networks? >>> >>> Having the same /64 configured on both is probably bad. >> >> Why would it be? > > Unless you bridge the two interface, yes. Which interface do you start ND on? > > For the OP, here is my ipv6 configuration. > tx0 is the internal net and is running with ULA as well as the /64 from HE. > sis0 is the external cable connection. > gif0 is the tunneled connection back to HE. > sft0 sends 6to4 reply traffic directly it is out bound only. > > % ifconfig -a inet6 > tx0: flags=28943 mtu 1500 > inet6 fe80::2e0:29ff:fe19:c02d%tx0 prefixlen 64 scopeid 0x1 > inet6 2001:470:1f00:820:2e0:29ff:fe19:c02d prefixlen 64 > inet6 2001:470:1f00:820:: prefixlen 64 anycast > inet6 fd92:7065:b8e:0:2e0:29ff:fe19:c02d prefixlen 64 > inet6 fd92:7065:b8e:: prefixlen 64 anycast > sis0: flags=8843 mtu 1500 > inet6 fe80::209:5bff:fe1e:e13e%sis0 prefixlen 64 scopeid 0x2 > lo0: flags=8049 mtu 16384 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 > gif0: flags=8051 mtu 1280 > tunnel inet 211.30.172.21 --> 64.71.128.82 > inet6 fe80::2e0:29ff:fe19:c02d%gif0 prefixlen 64 scopeid 0x8 > inet6 2001:470:1f00:ffff::5a1 --> 2001:470:1f00:ffff::5a0 prefixlen 128 > stf0: flags=1001 mtu 1280 > inet6 2002:d31e:ac15:: prefixlen 16 anycast Not hand-configuring the external i/f seems to be the fix. In that I have spent a cheerful few hours chopping stuff from rc.conf and rebooting, and that appeared to toggle the failure. Thank you all for your patience. -- JH-R From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 22:34:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2876106564A for ; Tue, 28 Aug 2012 22:34:16 +0000 (UTC) (envelope-from jamie@kode5.net) Received: from kontrol.kode5.net (kontrol.kode5.net [80.229.5.32]) by mx1.freebsd.org (Postfix) with ESMTP id 395D88FC12 for ; Tue, 28 Aug 2012 22:34:15 +0000 (UTC) Received: from kontrol.kode5.net (localhost [127.0.0.1]) by kontrol.kode5.net (8.14.5/8.14.5) with ESMTP id q7SMYELG078981; Tue, 28 Aug 2012 23:34:14 +0100 (BST) (envelope-from jamie@kode5.net) Received: (from jamie@localhost) by kontrol.kode5.net (8.14.5/8.14.5/Submit) id q7SMYEO0078980; Tue, 28 Aug 2012 23:34:14 +0100 (BST) (envelope-from jamie@kode5.net) X-Authentication-Warning: kontrol.kode5.net: jamie set sender to jamie@kode5.net using -f Date: Tue, 28 Aug 2012 23:34:14 +0100 From: Jamie Paul Griffin To: Freddie Cash Message-ID: <20120828223413.GB78518@kontrol.kode5.net> References: <20120828203130.GB78051@kontrol.kode5.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: x-operating-system: FreeBSD 9.1-PRERELEASE amd64 x-pgp-fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38 x-pgp-key: 1D31DC38 User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.5 at kontrol.kode5.net X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Question About Tracking the Stable Branch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 22:34:16 -0000 --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Freddie Cash wrote on Tue 28.Aug'12 at 14:12:10 -0700 ] > On Tue, Aug 28, 2012 at 2:03 PM, Kevin Oberman wrote: > > In all cases, if you rebuild the kernel, be sure that the old kernel > > is saved to kernel.old so you can go back to it if there si a problem. > > 'make installkernel' does this) and, should you fix a problem and > > re-link the kernel, be sure NOT to overwrite the working kernel ('make > > reinstallkernel' does this. >=20 > It's not mentioned often on the lists, but KODIR and nextboot(8) are > wonderful things: > # make buildworld > # make KERNCONF=3DMYKERNEL buildkernel > # make KERNCONF=3DMYKERNEL KODIR=3D/boot/MYKERNEL options> installkernel > # nextboot -k MYKERNEL > # shutdown -r now >=20 > That will install your new kernel into /boot/MYKERNEL, leaving > /boot/kernel alone. nextboot configures the boot process to use > /boot/MYKERNEL, again leaving /boot/kernel along. If anything goes > wrong, a simple reboot of the box returns you to using /boot/kernel as > before. >=20 > If the new kernel works correctly, then you can manually copy/moves > things around as needed: > # mv /boot/kernel /boot/kernel.old > # cp -Rvp /boot/MYKERNEL /boot/kernel >=20 > Especially useful when testing new kernels on remote systems, as "hit > the reset switch" on a locked up box puts things back to the way they > were before. No loader commands required. :) OK, thanks for each response, some really useful info for me. I've always updated my -RELEASE systems using the traditional method so it = seems it's no different other than perhaps updating more frequently and dec= iding whether or not both kernel code and userland code needs to be rebuilt= together. It certainly seems a bad idea for me as someone with a lot to learn, to pat= ch specific parts of the source tree and rebuild those parts as something i= s bound to go wrong at some point for me.=20 I want to be able to test the new code and report issues to help in that wa= y with a view to adding code fixes to the project.=20 Jamie. --BwCQnh7xodEAoBMC Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIRngYJKoZIhvcNAQcCoIIRjzCCEYsCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DuIwggUfMIIEB6ADAgECAhB0kD49oFhImiM1TNmYDSf/MA0GCSqGSIb3DQEBBQUAMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTEyMDgyNTAwMDAwMFoX DTEzMDgyNTIzNTk1OVowIDEeMBwGCSqGSIb3DQEJARYPamFtaWVAa29kZTUubmV0MIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArCcH9jqYDuhBs0LslWkupsEzY7j7D0okrqe9 k1eoafySH8/JL5x2Ly5XdQY+D//SRhaonnQO4vZxf/48I/ErXJnQ12Q7nv8x0OUbHUCsSDuM o+XdCHNhw6cabwP/lkn+yKQOucl8jL4DXZbUxvZdxkd5xajHi3/OOOkdxuz09gKY5kh5aTaV cg9KA5WzZ3oJ8LENEVbPnwj7AIbyALaE0N45/GN0rG7KKn5DZSjqwd40+XEMCSaw5qNYNiFz iS9S2ow0P+aQz3WUaUcFHUnTyo84CkTWRGtCS5FfWEjX7UjTZbvLAmxdndbqfahJVIL/ch+o d9WQAXIGwHBSOZtWXwIDAQABo4IB3zCCAdswHwYDVR0jBBgwFoAUehNOAHRbxnhjZCfBL+Kg W7x5xXswHQYDVR0OBBYEFFzXVMl5Ia5RjMxe7WhQ66w5ceGXMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwVwYDVR0fBFAwTjBMoEqgSIZGaHR0cDov L2NybC5jb21vZG9jYS5jb20vQ09NT0RPQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVF bWFpbENBLmNybDCBiAYIKwYBBQUHAQEEfDB6MFIGCCsGAQUFBzAChkZodHRwOi8vY3J0LmNv bW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wGgYDVR0RBBMwEYEP amFtaWVAa29kZTUubmV0MA0GCSqGSIb3DQEBBQUAA4IBAQBl+DsCE7TM7c8SgKiqwE0DSxqU CfsPA/PtqSMIZYesr9Aelod/OzawPhjUmqsliqR3s9e0e+O0s7H+PSOaf10Nn9GVc6Ej6tqt ctFPr6AeU8NUvlyqhPK4kj4DZRcJM0ervslzva8TUHWk7mC2gahmPVJ0Zl8WR2TCVdLGXrWH jz4csIw03GxRqivg86PpTnm1R9uutVem6kNWfqSdYmKqwABJ71f0N1WWJWhGUlgf5kpoRXrp AyrjFIoeD1egIbuBwf+24ynID9MSuHSqRgPxf8WWtTmpbgpnRL2TKbF9vMojXOFJ0dEeRvlF +DTbmbLPrUBQSQELOIyY2+WV6V6wMIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi5iIyeqpx3jAN BgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5T YWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQL ExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBaFw0yMDA1MzAx MDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NYX2Zl8TJO958y fVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqiQfZq4aP/uN8f SG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBTbJUdqRAUtJmV WRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YXWEYVgTxoi4uD D216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30iY9OpoPzOnpDf RBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHze Pa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB/wQEAwIBBjAS BgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8EUTBPME2gS6BJ hkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50 aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUHMAKGMWh0dHA6 Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQwJQYIKwYBBQUH MAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAIXWvnhX VW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjfy/tCPKElPgp1 1tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T4ENyG+2P/WA5 IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrUyTo8H+2b/5tJ M75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lEuJB+ytF5OOu0 M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggSdMIIDhaADAgECAhA0Pekr rCc0/4/LNJT7zHBUMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtB ZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAg BgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMDUwNjA3MDgwOTEwWhcNMjAw NTMwMTA0ODM4WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExho dHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfH TrSDZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4 vKJvq1lepS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i 5khhxkzzabGoLhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDre CqS6A3ezZcj9HtN0YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOB9DCB 8TAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73gJMtUGjAdBgNVHQ4EFgQUiYJnfcSdJnAA S7RQSHzePa4Ebn0wDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAow CDAGBgRVHSAAMEQGA1UdHwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9B ZGRUcnVzdEV4dGVybmFsQ0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGG GWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAAG8nONjKLDz MQHC33vdYqABnSMxD5ySc1NR6h9M+tafxMovZ354Mw90FrmRh5H1iib6ZHAA2B75CwRiUIeT gdTa9SPbNLuFVrRwNG54gzcehRzFERWSX4cXvaxq/fHC0cyJX7F88D5R8jXzfOxgmGs6K+Dv 37N9huu1G/Vb7KJ8mBPXAFC50S1z3gN4dOEFhTFey5q5nZTGuZQ3dXLcRPtn6PD6JR5Sp9ol 6UfgoMc8oE6xCjb7d0if75eK+7T+45QUqIO8XC0/0mBxYO7CcYIM6Yg249ogtKOgbKqWS7iA jnXKSQf2OxS639wF2Z/b4LLmTaB4JufnLW5/X8YeiBUxggKEMIICgAIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQdJA+PaBYSJojNUzZmA0n/zAJ BgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEyMDgyODIyMzQxM1owIwYJKoZIhvcNAQkEMRYEFPnSJ8vq2Uj5QDCBPFi/w95Hry8tMFIG CSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAIIvndLgyWZu Ps+tAIdvHL9x3KTOdXhnGFsw5XlgQ+ZuklnvLnaha+rmEBTptXH1j6P/0IUETuP2QYIJKRXn qNArvFR94kC44HW13zm6CTqzFF1y7OMnNU9gGXXQe8PkYKTUiaf3OjO5hTWyO/lwAmpIsYFA rWhQIsu/YVGMLCkTK/4ehHIr8OQpeeFSy+7Q3yUemil4uTuVVHQnPTv244U92Uf8iAHTWiyL vF3eTFbiI5GjIG2UWc5pwMkaCORcVS/e7FwxjCRoPIfv9urJIDW+NsSvA6gcxX91pZwGKhbZ N5rFrSAv8ktm1062QNRFBTGSbxlYyN3Mm1b8f2R2Q2k= --BwCQnh7xodEAoBMC-- From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 23:28:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DAE0106567A for ; Tue, 28 Aug 2012 23:28:23 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 471628FC0A for ; Tue, 28 Aug 2012 23:28:22 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id q7SNSFTB082000; Tue, 28 Aug 2012 17:28:15 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id q7SNSFVk081997; Tue, 28 Aug 2012 17:28:15 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Tue, 28 Aug 2012 17:28:15 -0600 (MDT) From: Warren Block To: Jamie Paul Griffin In-Reply-To: <20120828223413.GB78518@kontrol.kode5.net> Message-ID: References: <20120828203130.GB78051@kontrol.kode5.net> <20120828223413.GB78518@kontrol.kode5.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: Content-Disposition: INLINE X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 28 Aug 2012 17:28:15 -0600 (MDT) Cc: freebsd-stable@freebsd.org Subject: Re: Question About Tracking the Stable Branch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 23:28:23 -0000 On Tue, 28 Aug 2012, Jamie Paul Griffin wrote: > I've always updated my -RELEASE systems using the traditional method > so it seems it's no different other than perhaps updating more > frequently and deciding whether or not both kernel code and userland > code needs to be rebuilt together. > > It certainly seems a bad idea for me as someone with a lot to learn, > to patch specific parts of the source tree and rebuild those parts as > something is bound to go wrong at some point for me. In addition to what others have suggested, the devel/ccache port can seriously reduce world and kernel compilation time by caching results. Stuff that hasn't changed comes out of cache rather than from a recompile. A buildworld every few days usually takes only about a fourth of the time it would take without ccache. Unfortunately, so far it only has this extreme an effect with gcc, not so much with clang. I usually use 4G of cache space; haven't tested to see how much is actually needed. Setting CCACHE_COMPRESS=yes fits more files in the cache. In my tests, there was no speed penalty. From owner-freebsd-stable@FreeBSD.ORG Tue Aug 28 23:39:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EBF1106566B for ; Tue, 28 Aug 2012 23:39:13 +0000 (UTC) (envelope-from jamie@kode5.net) Received: from kontrol.kode5.net (kontrol.kode5.net [80.229.5.32]) by mx1.freebsd.org (Postfix) with ESMTP id B148A8FC18 for ; Tue, 28 Aug 2012 23:39:11 +0000 (UTC) Received: from kontrol.kode5.net (localhost [127.0.0.1]) by kontrol.kode5.net (8.14.5/8.14.5) with ESMTP id q7SNdAf5079338; Wed, 29 Aug 2012 00:39:10 +0100 (BST) (envelope-from jamie@kode5.net) Received: (from jamie@localhost) by kontrol.kode5.net (8.14.5/8.14.5/Submit) id q7SNd9J8079337; Wed, 29 Aug 2012 00:39:09 +0100 (BST) (envelope-from jamie@kode5.net) X-Authentication-Warning: kontrol.kode5.net: jamie set sender to jamie@kode5.net using -f Date: Wed, 29 Aug 2012 00:39:09 +0100 From: Jamie Paul Griffin To: Warren Block Message-ID: <20120828233909.GE78518@kontrol.kode5.net> References: <20120828203130.GB78051@kontrol.kode5.net> <20120828223413.GB78518@kontrol.kode5.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: x-operating-system: FreeBSD 9.1-PRERELEASE amd64 x-pgp-fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38 x-pgp-key: 1D31DC38 User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.5 at kontrol.kode5.net X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: Question About Tracking the Stable Branch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 23:39:13 -0000 [ Warren Block wrote on Tue 28.Aug'12 at 17:28:15 -0600 ] > On Tue, 28 Aug 2012, Jamie Paul Griffin wrote: > > > I've always updated my -RELEASE systems using the traditional method > > so it seems it's no different other than perhaps updating more > > frequently and deciding whether or not both kernel code and userland > > code needs to be rebuilt together. > > > > It certainly seems a bad idea for me as someone with a lot to learn, > > to patch specific parts of the source tree and rebuild those parts as > > something is bound to go wrong at some point for me. > > In addition to what others have suggested, the devel/ccache port can > seriously reduce world and kernel compilation time by caching results. > Stuff that hasn't changed comes out of cache rather than from a > recompile. A buildworld every few days usually takes only about a > fourth of the time it would take without ccache. Unfortunately, so far > it only has this extreme an effect with gcc, not so much with clang. > > I usually use 4G of cache space; haven't tested to see how much is > actually needed. Setting CCACHE_COMPRESS=yes fits more files in the > cache. In my tests, there was no speed penalty. Great suggestion, I'll look into that. Although, I am planning a rebuild using clang in the next few days but from what you say it could still be a useful addition. Jamie From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 07:35:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21B8A106566B; Wed, 29 Aug 2012 07:35:55 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5728FC15; Wed, 29 Aug 2012 07:35:54 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q7T7Zk8N016916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2012 09:35:46 +0200 Received: from portgus.lan (51.Red-79-159-211.staticIP.rima-tde.net [79.159.211.51]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q7T7ZhTq007574 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 09:35:45 +0200 Message-ID: <503DC61B.20101@entel.upc.edu> Date: Wed, 29 Aug 2012 09:34:51 +0200 From: =?ISO-8859-1?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120806 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-emulation@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Wed, 29 Aug 2012 09:35:46 +0200 (CEST) Cc: Subject: Problem adding more than 8 network adapters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 07:35:55 -0000 Hi, I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm facing is that I can't use more than 8 network adapters plugged to the virtual machine. Recent VirtualBox releases (since the 4.2RC1) allow, with the ICH9 chipset, to plug more than 8 network adapters. It doesn't matter what type of network adapter I use, FreeBSD seems not to see more than 8. I tried the same configuration (virtual machine with ICH9 chipset and ten network adapters) with a Linux distribution (ubuntu). Linux seems to see all the network adapters. Thus I would say it is not an emulation@ problem, but maybe anyone in the list knows about this problem. I don't know if it's a net@ problem (already send it there too, I'm waiting for some answers) or maybe it is a problem with the emulated PCI-bridge and then stable@ should be contacted. Also, I'm not sure if a real machine would support more than 8 network adapters or not. Any hints would be appreciated. Best, Gustau -- --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 08:12:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE2A0106566B; Wed, 29 Aug 2012 08:12:07 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 71CB28FC14; Wed, 29 Aug 2012 08:12:06 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q7T8CVgR044816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 10:12:32 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <503DCEA4.5070305@omnilan.de> Date: Wed, 29 Aug 2012 10:11:16 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Pete French References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC9EB048CDD20BADFA44B3D8A" Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 08:12:08 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC9EB048CDD20BADFA44B3D8A Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable schrieb Pete French am 28.08.2012 11:48 (localtime): >> No answer, so it seems that link aggregation doesn't really work in fr= eebsd, >> this may help others with the same problem... > I used to use LCAP a lot - this was a few years ago, but the critical > point was that it only worked if all the cables went to the same > logcial switch. Using a pair of switches for redundancy works fine, as > long as they are of the type which stacvk and look like a single physic= al > switch software-wise. Link aggregation can never work with two separate switches! LACP and static trunking require both sides to bundle the same trunk. which is impossible for two separate switches. For redundancy, there is the SpanningTreeProtocol, which FreeBSD supports in bridge (4) (more preferrably RSTP). > Saying "it doesnt really work in freebsd" is, to be honest, not so > far off the mark (if somewhat harshly phrased) - but it can be made to > behave if you do it in a certain way, and when it does it runs very nic= ely. In that case, it's nothing to do with FreeBSD! -Harry --------------enigC9EB048CDD20BADFA44B3D8A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlA9ztAACgkQLDqVQ9VXb8hyUQCeOhhyP5SrY/smTLa8t9+IkzLs D60An25gzXOFipcOL6wMS9wP9AKtjqtt =wKtp -----END PGP SIGNATURE----- --------------enigC9EB048CDD20BADFA44B3D8A-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 09:36:51 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78302106566B for ; Wed, 29 Aug 2012 09:36:51 +0000 (UTC) (envelope-from citrin@citrin.ru) Received: from mail-chaos.rambler.ru (mail-chaos.rambler.ru [81.19.68.130]) by mx1.freebsd.org (Postfix) with ESMTP id 2EFB98FC14 for ; Wed, 29 Aug 2012 09:36:50 +0000 (UTC) Received: from citrin.office.vega.ru (office-nat.spylog.net [193.169.234.6]) (Authenticated sender: citrin@citrin.ru) by mail-chaos.rambler.ru (Postfix) with ESMTPSA id 4CC7617038 for ; Wed, 29 Aug 2012 13:36:44 +0400 (MSD) Message-ID: <503DE2AB.6030702@citrin.ru> Date: Wed, 29 Aug 2012 13:36:43 +0400 From: Anton Yuzhaninov User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:6.0.2) Gecko/20110922 Thunderbird/6.0.2 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Problem with IPMI KCS driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 09:36:51 -0000 We use servers witch motherboard Supermicro X8DTT-H and meet with such problem: when watchdogd started, server is rebooted by IPMI watchdog several times per week. After some debugging I've found, that sometimes IPMI driver entered endless loop, and watchdogd have no chances to reset watchdog timer. In such situation top show: PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND ... 113 root -16 - 0K 16K CPU4 4 17:18 99.17% ipmi0: kcs Endless loop located in file /sys/dev/ipmi/ipmi_kcs.c and function kcs_wait_for_obf(): int status, start = ticks; status = INB(sc, KCS_CTL_STS); if (state == 0) { /* WAIT FOR OBF = 0 */ while (ticks - start < MAX_TIMEOUT && status & KCS_STATUS_OBF) { DELAY(100); status = INB(sc, KCS_CTL_STS); } } else { /* WAIT FOR OBF = 1 */ while (ticks - start < MAX_TIMEOUT && !(status & KCS_STATUS_OBF)) { DELAY(100); status = INB(sc, KCS_CTL_STS); } } It seems to be, that this loop intended to run no more than MAX_TIMEOUT ticks. but by some reason this timeout does not works and loop runs until reboot. Questions: 1. Is it correct to check ticks to implement timeout here? 2. how to fix this timeout? -- Anton Yuzhaninov From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 09:38:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B2F8106566C; Wed, 29 Aug 2012 09:38:30 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id ADAC08FC1E; Wed, 29 Aug 2012 09:38:29 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1T6eiz-0006ZK-UY; Wed, 29 Aug 2012 10:38:14 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T6eiz-000FgC-TV; Wed, 29 Aug 2012 10:38:13 +0100 To: h.schmalzbauer@omnilan.de, petefrench@ingresso.co.uk In-Reply-To: <503DCEA4.5070305@omnilan.de> Message-Id: From: Pete French Date: Wed, 29 Aug 2012 10:38:13 +0100 Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 09:38:30 -0000 > Link aggregation can never work with two separate switches! LACP and > static trunking require both sides to bundle the same trunk. which is > impossible for two separate switches. These switches had a port where you could connect them together and then configure each to know about the other switch, and to do LACP across the pair of them. Or at least thats what it looked like it was capable of doing, and it appeared to be doing LACP when configured that way and connected to Windows machines, just not FreeBSD ones. But I'm not a Cisco person by any stretch of the imagination, so if that config is actually not possible then that would kind of explain why it didn't work ;-) Sorry for the misinformation! -pete. [feeling a bit foolish now] From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 10:12:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01C63106564A; Wed, 29 Aug 2012 10:12:23 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 125A58FC12; Wed, 29 Aug 2012 10:12:21 +0000 (UTC) Received: from server.rulingia.com (c220-239-249-137.belrs5.nsw.optusnet.com.au [220.239.249.137]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q7TACAo5069551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Aug 2012 20:12:10 +1000 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id q7TAC3Lc075957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 20:12:03 +1000 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id q7TAC2Bi075956; Wed, 29 Aug 2012 20:12:02 +1000 (EST) (envelope-from peter) Date: Wed, 29 Aug 2012 20:12:02 +1000 From: Peter Jeremy To: Gustau =?iso-8859-1?Q?P=E9rez?= i Querol , John Baldwin Message-ID: <20120829101202.GA74970@server.rulingia.com> References: <503C930C.3010405@entel.upc.edu> <20120829090205.GA75022@server.rulingia.com> <503DE1BC.4050907@entel.upc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <503DE1BC.4050907@entel.upc.edu> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org Subject: Re: Problem adding more than 8 network adapters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 10:12:23 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Moving to -stable and adding jhb@ for his input] On 2012-Aug-29 11:32:44 +0200, Gustau P=E9rez i Querol wrote: >Al 29/08/2012 11:02, En/na Peter Jeremy ha escrit: >> On 2012-Aug-28 11:44:44 +0200, Gustau P=E9rez i Querol wrote: >>> I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm >>> facing is that I can't use more than 8 network adapters plugged to the >>> virtual machine. >> ... >>> I don't know if it's a net@ problem or maybe it is a problem with >>> the emulated PCI-bridge and then stable@ should be contacted. Also, I'm >>> not sure if a real machine would support more than 8 network adapters or >>> not. Any hints would be appreciated. >> I don't think I've ever used more than 6 physical NICs in a host but don= 't >> know of any reason for >8 to not work. > >> Can you please post a "pciconf -lv" from FreeBSD and the equivalent >> "lspci" from Linux. A FreeBSD verbose boot log might also help. > > Sure. I'm attaching them to this mail. I hope the mailing list=20 >doesn't eat them. If it does, I will post them online and send the URL=20 >to the mailing list. Ah.. lspci shows the 9th LANCE at 02:00.0. The verbose boot shows FreeBSD finds pcib2 (at pci0 device 25.0) but doesn't see anything on that bus. ISTR jhb@ will recognize that problem. >Table 'FACP' at 0x3fff0110 >Table 'APIC' at 0x3fff0280 >APIC: Found table at 0x3fff0280 >APIC: Using the MADT enumerator. >MADT: Found CPU APIC ID 0 ACPI ID 0: enabled >SMP: Added CPU 0 (AP) >Copyright (c) 1992-2012 The FreeBSD Project. >Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. >FreeBSD is a registered trademark of The FreeBSD Foundation. >FreeBSD 9.0-STABLE #0 r232547: Mon Mar 5 17:46:14 UTC 2012 > root@hast1:/usr/obj/usr/src/sys/GENERIC amd64 >Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff8168e000. >Preloaded elf obj module "/boot/kernel/zfs.ko" at 0xffffffff8168e180. >Preloaded elf obj module "/boot/kernel/opensolaris.ko" at 0xffffffff8168e8= 28. >Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff8168e= e58. >Preloaded elf obj module "/boot/modules/virtio.ko" at 0xffffffff8168eeb8. >Preloaded elf obj module "/boot/modules/virtio_pci.ko" at 0xffffffff8168f4= 20. >Preloaded elf obj module "/boot/modules/virtio_blk.ko" at 0xffffffff8168f9= 50. >Preloaded elf obj module "/boot/modules/if_vtnet.ko" at 0xffffffff8168fec0. >Calibrating TSC clock ... TSC clock: 2390626999 Hz >CPU: Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz (2390.63-MHz K8-class= CPU) > Origin =3D "GenuineIntel" Id =3D 0x20655 Family =3D 6 Model =3D 25 S= tepping =3D 5 > Features=3D0x783fbff > Features2=3D0x209 > AMD Features=3D0x28100800 > AMD Features2=3D0x1 >real memory =3D 1073676288 (1023 MB) >Physical memory chunk(s): >0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) >0x0000000000100000 - 0x00000000001fffff, 1048576 bytes (256 pages) >0x00000000016bf000 - 0x000000003e18ffff, 1017974784 bytes (248529 pages) >avail memory =3D 1008267264 (961 MB) >Event timer "LAPIC" quality 400 >ACPI APIC Table: >APIC: CPU 0 has ACPI ID 0 >x86bios: IVT 0x000000-0x0004ff at 0xfffffe0000000000 >x86bios: SSEG 0x001000-0x001fff at 0xffffff8000203000 >x86bios: EBDA 0x09f000-0x09ffff at 0xfffffe000009f000 >x86bios: ROM 0x0a0000-0x0fefff at 0xfffffe00000a0000 >ULE: setup cpu 0 >ACPI: RSDP 0xe0000 00024 (v02 VBOX ) >ACPI: XSDT 0x3fff0040 0004C (v01 VBOX VBOXXSDT 00000001 ASL 00000061) >ACPI: FACP 0x3fff0110 000F4 (v04 VBOX VBOXFACP 00000001 ASL 00000061) >ACPI: DSDT 0x3fff0530 01B96 (v01 VBOX VBOXBIOS 00000002 INTL 20120816) >ACPI: FACS 0x3fff0240 00040 >ACPI: APIC 0x3fff0280 00054 (v02 VBOX VBOXAPIC 00000001 ASL 00000061) >ACPI: HPET 0x3fff02e0 00038 (v01 VBOX VBOXHPET 00000001 ASL 00000061) >ACPI: MCFG 0x3fff0320 0003C (v01 VBOX VBOXMCFG 00000001 ASL 00000061) >ACPI: SSDT 0x3fff0360 001CC (v01 VBOX VBOXCPUT 00000002 INTL 20120816) >MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 >ioapic0: Routing external 8259A's -> intpin 0 >MADT: Interrupt override: source 0, irq 2 >ioapic0: Routing IRQ 0 -> intpin 2 >MADT: Interrupt override: source 9, irq 9 >ioapic0: intpin 9 trigger: level >ioapic0 irqs 0-23 on motherboard >cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x000000f0 pmc: 0x00010400 >wlan: <802.11 Link Layer> >snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [1= 024] >feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 feeder_r= ate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 >kbd: new array size 4 >kbd1 at kbdmux0 >nfslock: pseudo-device >mem: >CPU supports MTRRs but not enabled >io: >null: >random: >hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 >acpi0: on motherboard >PCIe: Memory Mapped configuration base @ 0xdc000000 >ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 >ACPI: Executed 1 blocks of module-level executable AML code >acpi0: Power Button (fixed) >acpi0: Sleep Button (fixed) >hpet0: vendor 0x8086, rev 0x1, 14318180Hz 64bit, 4 timers, legacy route >hpet0: t0: irqs 0xffffffff (0), 64bit, periodic >hpet0: t1: irqs 0xffffffff (0) >hpet0: t2: irqs 0xffffffff (0) >hpet0: t3: irqs 0x00000000 (0) >Timecounter "HPET" frequency 14318180 Hz quality 950 >cpu0: on acpi0 >cpu0: switching to generic Cx mode >attimer0: port 0x40-0x43,0x50-0x53 on acpi0 >Timecounter "i8254" frequency 1193182 Hz quality 0 >ioapic0: routing intpin 2 (ISA IRQ 0) to lapic 0 vector 49 >Event timer "i8254" frequency 1193182 Hz quality 100 >atrtc0: port 0x70-0x71 on acpi0 >atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustmen= t 0.500000000s) >ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 50 >Event timer "RTC" frequency 32768 Hz quality 0 >ACPI timer: 1/5 1/367 1/37 1/1 1/36 1/7 1/309 1/87 1/32 1/44 -> 10 >Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 >acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 >pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 5 9 10 11 > Validation 0 11 N 0 5 9 10 11 > After Disable 0 255 N 0 5 9 10 11 >pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 9 N 0 5 9 10 11 > Validation 0 9 N 0 5 9 10 11 > After Disable 0 255 N 0 5 9 10 11 >pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 5 9 10 11 > Validation 0 11 N 0 5 9 10 11 > After Disable 0 255 N 0 5 9 10 11 >pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 5 9 10 11 > Validation 0 11 N 0 5 9 10 11 > After Disable 0 255 N 0 5 9 10 11 >pcib0: port 0xcf8-0xcff on acpi0 >pcib0: decoding 4 range 0-0xcf7 >pcib0: decoding 4 range 0xd00-0xffff >pcib0: decoding 3 range 0xa0000-0xbffff >pcib0: decoding 3 range 0x40000000-0xffdfffff >pci0: on pcib0 >pci0: domain=3D0, physical bus=3D0 >found-> vendor=3D0x80ee, dev=3D0xbeef, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D2, func=3D0 > class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0000, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D10 > map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 23, en= abled >pcib0: allocated type 3 (0xe0000000-0xe07fffff) for rid 10 of pci0:0:2:0 >pcib0: matched entry for 0.2.INTA >pcib0: slot 2 INTA hardwired to IRQ 18 >found-> vendor=3D0x1022, dev=3D0x2000, revid=3D0x10 > domain=3D0, bus=3D0, slot=3D3, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x06 (1500 ns), maxlat=3D0xff (63750 ns) > intpin=3Da, irq=3D9 > map[10]: type I/O Port, range 32, base 0xd000, size 5, enabled >pcib0: allocated type 4 (0xd000-0xd01f) for rid 10 of pci0:0:3:0 > map[14]: type Memory, range 32, base 0xf0000000, size 12, enabled >pcib0: allocated type 3 (0xf0000000-0xf0000fff) for rid 14 of pci0:0:3:0 > map[18]: type Memory, range 32, base 0xf0080000, size 19, enabled >pcib0: allocated type 3 (0xf0080000-0xf00fffff) for rid 18 of pci0:0:3:0 >pcib0: matched entry for 0.3.INTA >pcib0: slot 3 INTA hardwired to IRQ 19 >found-> vendor=3D0x80ee, dev=3D0xcafe, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D4, func=3D0 > class=3D08-80-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0000, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D5 > map[10]: type I/O Port, range 32, base 0xd020, size 5, enabled >pcib0: allocated type 4 (0xd020-0xd03f) for rid 10 of pci0:0:4:0 > map[14]: type Memory, range 32, base 0xf0400000, size 22, enabled >pcib0: allocated type 3 (0xf0400000-0xf07fffff) for rid 14 of pci0:0:4:0 > map[18]: type Prefetchable Memory, range 32, base 0xf0800000, size 14, en= abled >pcib0: allocated type 3 (0xf0800000-0xf0803fff) for rid 18 of pci0:0:4:0 >pcib0: matched entry for 0.4.INTA >pcib0: slot 4 INTA hardwired to IRQ 20 >found-> vendor=3D0x8086, dev=3D0x7113, revid=3D0x08 > domain=3D0, bus=3D0, slot=3D7, func=3D0 > class=3D06-80-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D9 >pcib0: matched entry for 0.7.INTA >pcib0: slot 7 INTA hardwired to IRQ 23 >found-> vendor=3D0x1022, dev=3D0x2000, revid=3D0x10 > domain=3D0, bus=3D0, slot=3D8, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x06 (1500 ns), maxlat=3D0xff (63750 ns) > intpin=3Da, irq=3D5 > map[10]: type I/O Port, range 32, base 0xd040, size 5, enabled >pcib0: allocated type 4 (0xd040-0xd05f) for rid 10 of pci0:0:8:0 > map[14]: type Memory, range 32, base 0xf0804000, size 12, enabled >pcib0: allocated type 3 (0xf0804000-0xf0804fff) for rid 14 of pci0:0:8:0 > map[18]: type Memory, range 32, base 0xf0880000, size 19, enabled >pcib0: allocated type 3 (0xf0880000-0xf08fffff) for rid 18 of pci0:0:8:0 >pcib0: matched entry for 0.8.INTA >pcib0: slot 8 INTA hardwired to IRQ 16 >found-> vendor=3D0x1022, dev=3D0x2000, revid=3D0x10 > domain=3D0, bus=3D0, slot=3D9, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x06 (1500 ns), maxlat=3D0xff (63750 ns) > intpin=3Da, irq=3D11 > map[10]: type I/O Port, range 32, base 0xd060, size 5, enabled >pcib0: allocated type 4 (0xd060-0xd07f) for rid 10 of pci0:0:9:0 > map[14]: type Memory, range 32, base 0xf0900000, size 12, enabled >pcib0: allocated type 3 (0xf0900000-0xf0900fff) for rid 14 of pci0:0:9:0 > map[18]: type Memory, range 32, base 0xf0980000, size 19, enabled >pcib0: allocated type 3 (0xf0980000-0xf09fffff) for rid 18 of pci0:0:9:0 >pcib0: matched entry for 0.9.INTA >pcib0: slot 9 INTA hardwired to IRQ 17 >found-> vendor=3D0x1022, dev=3D0x2000, revid=3D0x10 > domain=3D0, bus=3D0, slot=3D10, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x06 (1500 ns), maxlat=3D0xff (63750 ns) > intpin=3Da, irq=3D10 > map[10]: type I/O Port, range 32, base 0xd080, size 5, enabled >pcib0: allocated type 4 (0xd080-0xd09f) for rid 10 of pci0:0:10:0 > map[14]: type Memory, range 32, base 0xf0a00000, size 12, enabled >pcib0: allocated type 3 (0xf0a00000-0xf0a00fff) for rid 14 of pci0:0:10:0 > map[18]: type Memory, range 32, base 0xf0a80000, size 19, enabled >pcib0: allocated type 3 (0xf0a80000-0xf0afffff) for rid 18 of pci0:0:10:0 >pcib0: matched entry for 0.10.INTA >pcib0: slot 10 INTA hardwired to IRQ 18 >found-> vendor=3D0x1022, dev=3D0x2000, revid=3D0x10 > domain=3D0, bus=3D0, slot=3D16, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x06 (1500 ns), maxlat=3D0xff (63750 ns) > intpin=3Da, irq=3D5 > map[10]: type I/O Port, range 32, base 0xd0a0, size 5, enabled >pcib0: allocated type 4 (0xd0a0-0xd0bf) for rid 10 of pci0:0:16:0 > map[14]: type Memory, range 32, base 0xf0b00000, size 12, enabled >pcib0: allocated type 3 (0xf0b00000-0xf0b00fff) for rid 14 of pci0:0:16:0 > map[18]: type Memory, range 32, base 0xf0b80000, size 19, enabled >pcib0: allocated type 3 (0xf0b80000-0xf0bfffff) for rid 18 of pci0:0:16:0 >pcib0: matched entry for 0.16.INTA >pcib0: slot 16 INTA hardwired to IRQ 16 >found-> vendor=3D0x1022, dev=3D0x2000, revid=3D0x10 > domain=3D0, bus=3D0, slot=3D17, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x06 (1500 ns), maxlat=3D0xff (63750 ns) > intpin=3Da, irq=3D11 > map[10]: type I/O Port, range 32, base 0xd0c0, size 5, enabled >pcib0: allocated type 4 (0xd0c0-0xd0df) for rid 10 of pci0:0:17:0 > map[14]: type Memory, range 32, base 0xf0c00000, size 12, enabled >pcib0: allocated type 3 (0xf0c00000-0xf0c00fff) for rid 14 of pci0:0:17:0 > map[18]: type Memory, range 32, base 0xf0c80000, size 19, enabled >pcib0: allocated type 3 (0xf0c80000-0xf0cfffff) for rid 18 of pci0:0:17:0 >pcib0: matched entry for 0.17.INTA >pcib0: slot 17 INTA hardwired to IRQ 17 >found-> vendor=3D0x1022, dev=3D0x2000, revid=3D0x10 > domain=3D0, bus=3D0, slot=3D18, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x06 (1500 ns), maxlat=3D0xff (63750 ns) > intpin=3Da, irq=3D10 > map[10]: type I/O Port, range 32, base 0xd0e0, size 5, enabled >pcib0: allocated type 4 (0xd0e0-0xd0ff) for rid 10 of pci0:0:18:0 > map[14]: type Memory, range 32, base 0xf0d00000, size 12, enabled >pcib0: allocated type 3 (0xf0d00000-0xf0d00fff) for rid 14 of pci0:0:18:0 > map[18]: type Memory, range 32, base 0xf0d80000, size 19, enabled >pcib0: allocated type 3 (0xf0d80000-0xf0dfffff) for rid 18 of pci0:0:18:0 >pcib0: matched entry for 0.18.INTA >pcib0: slot 18 INTA hardwired to IRQ 18 >found-> vendor=3D0x1022, dev=3D0x2000, revid=3D0x10 > domain=3D0, bus=3D0, slot=3D19, func=3D0 > class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0280, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x06 (1500 ns), maxlat=3D0xff (63750 ns) > intpin=3Da, irq=3D9 > map[10]: type I/O Port, range 32, base 0xd100, size 5, enabled >pcib0: allocated type 4 (0xd100-0xd11f) for rid 10 of pci0:0:19:0 > map[14]: type Memory, range 32, base 0xf0e00000, size 12, enabled >pcib0: allocated type 3 (0xf0e00000-0xf0e00fff) for rid 14 of pci0:0:19:0 > map[18]: type Memory, range 32, base 0xf0e80000, size 19, enabled >pcib0: allocated type 3 (0xf0e80000-0xf0efffff) for rid 18 of pci0:0:19:0 >pcib0: matched entry for 0.19.INTA >pcib0: slot 19 INTA hardwired to IRQ 19 >found-> vendor=3D0x1000, dev=3D0x0054, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D22, func=3D0 > class=3D01-00-00, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0157, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D10 > MSI supports 1 message, vector masks > map[10]: type I/O Port, range 32, base 0xd200, size 8, enabled >pcib0: allocated type 4 (0xd200-0xd2ff) for rid 10 of pci0:0:22:0 > map[14]: type Memory, range 32, base 0xf0f00000, size 17, enabled >pcib0: allocated type 3 (0xf0f00000-0xf0f1ffff) for rid 14 of pci0:0:22:0 > map[18]: type Memory, range 32, base 0xf0f20000, size 17, enabled >pcib0: allocated type 3 (0xf0f20000-0xf0f3ffff) for rid 18 of pci0:0:22:0 >pcib0: matched entry for 0.22.INTA >pcib0: slot 22 INTA hardwired to IRQ 22 >found-> vendor=3D0x8086, dev=3D0x2448, revid=3D0xf2 > domain=3D0, bus=3D0, slot=3D24, func=3D0 > class=3D06-04-01, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0020, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) >found-> vendor=3D0x8086, dev=3D0x2448, revid=3D0xf2 > domain=3D0, bus=3D0, slot=3D25, func=3D0 > class=3D06-04-01, hdrtype=3D0x01, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0020, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) >found-> vendor=3D0x8086, dev=3D0x27b9, revid=3D0x02 > domain=3D0, bus=3D0, slot=3D31, func=3D0 > class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0200, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) >found-> vendor=3D0x8086, dev=3D0x2829, revid=3D0x02 > domain=3D0, bus=3D0, slot=3D31, func=3D2 > class=3D01-06-01, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D9 > powerspec 3 supports D0 D3 current D0 > MSI supports 1 message, vector masks > map[10]: type I/O Port, range 32, base 0xe000, size 3, enabled >pcib0: allocated type 4 (0xe000-0xe007) for rid 10 of pci0:0:31:2 > map[14]: type I/O Port, range 32, base 0xe008, size 2, enabled >pcib0: allocated type 4 (0xe008-0xe00b) for rid 14 of pci0:0:31:2 > map[18]: type I/O Port, range 32, base 0xe010, size 3, enabled >pcib0: allocated type 4 (0xe010-0xe017) for rid 18 of pci0:0:31:2 > map[1c]: type I/O Port, range 32, base 0xe018, size 2, enabled >pcib0: allocated type 4 (0xe018-0xe01b) for rid 1c of pci0:0:31:2 > map[20]: type I/O Port, range 32, base 0xe020, size 4, enabled >pcib0: allocated type 4 (0xe020-0xe02f) for rid 20 of pci0:0:31:2 > map[24]: type Memory, range 32, base 0xf1000000, size 13, enabled >pcib0: allocated type 3 (0xf1000000-0xf1001fff) for rid 24 of pci0:0:31:2 >pcib0: matched entry for 0.31.INTA >pcib0: slot 31 INTA hardwired to IRQ 23 >found-> vendor=3D0x106b, dev=3D0x003f, revid=3D0x00 > domain=3D0, bus=3D0, slot=3D31, func=3D4 > class=3D0c-03-10, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0010, cachelnsz=3D0 (dwords) > lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D9 > MSI supports 1 message, vector masks > map[10]: type Memory, range 32, base 0xf1002000, size 12, enabled >pcib0: allocated type 3 (0xf1002000-0xf1002fff) for rid 10 of pci0:0:31:4 >pcib0: matched entry for 0.31.INTA >pcib0: slot 31 INTA hardwired to IRQ 23 >vgapci0: mem 0xe0000000-0xe07fffff irq 18 at devi= ce 2.0 on pci0 >le0: port 0xd000-0xd01f mem 0xf0000000-0xf0000fff,0xf00800= 00-0xf00fffff irq 19 at device 3.0 on pci0 >le0: 16 receive buffers, 4 transmit buffers >le0: bpf attached >le0: Ethernet address: 08:00:27:07:fe:dc >ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 51 >pci0: at device 4.0 (no driver attached) >pci0: at device 7.0 (no driver attached) >le1: port 0xd040-0xd05f mem 0xf0804000-0xf0804fff,0xf08800= 00-0xf08fffff irq 16 at device 8.0 on pci0 >le1: 16 receive buffers, 4 transmit buffers >le1: bpf attached >le1: Ethernet address: 08:00:27:28:ae:ca >ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 52 >le2: port 0xd060-0xd07f mem 0xf0900000-0xf0900fff,0xf09800= 00-0xf09fffff irq 17 at device 9.0 on pci0 >le2: 16 receive buffers, 4 transmit buffers >le2: bpf attached >le2: Ethernet address: 08:00:27:5a:0e:64 >ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 53 >le3: port 0xd080-0xd09f mem 0xf0a00000-0xf0a00fff,0xf0a800= 00-0xf0afffff irq 18 at device 10.0 on pci0 >le3: 16 receive buffers, 4 transmit buffers >le3: bpf attached >le3: Ethernet address: 08:00:27:8f:1a:d7 >ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 54 >le4: port 0xd0a0-0xd0bf mem 0xf0b00000-0xf0b00fff,0xf0b800= 00-0xf0bfffff irq 16 at device 16.0 on pci0 >le4: 16 receive buffers, 4 transmit buffers >le4: bpf attached >le4: Ethernet address: 08:00:27:59:77:ec >le5: port 0xd0c0-0xd0df mem 0xf0c00000-0xf0c00fff,0xf0c800= 00-0xf0cfffff irq 17 at device 17.0 on pci0 >le5: 16 receive buffers, 4 transmit buffers >le5: bpf attached >le5: Ethernet address: 08:00:27:02:9d:41 >le6: port 0xd0e0-0xd0ff mem 0xf0d00000-0xf0d00fff,0xf0d800= 00-0xf0dfffff irq 18 at device 18.0 on pci0 >le6: 16 receive buffers, 4 transmit buffers >le6: bpf attached >le6: Ethernet address: 08:00:27:22:bb:c7 >le7: port 0xd100-0xd11f mem 0xf0e00000-0xf0e00fff,0xf0e800= 00-0xf0efffff irq 19 at device 19.0 on pci0 >le7: 16 receive buffers, 4 transmit buffers >le7: bpf attached >le7: Ethernet address: 08:00:27:9a:0a:4e >mpt0: port 0xd200-0xd2ff mem 0xf0f00000-0xf0f1= ffff,0xf0f20000-0xf0f3ffff irq 22 at device 22.0 on pci0 >ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 55 >mpt0: MPI Version=3D1.5.0.0 >mpt0: chain depth limited to 3 (from 510) >mpt0: Maximum Segment Count: 123, Maximum CAM Segment Count: 33 >mpt0: MsgLength=3D15 IOCNumber =3D 0 >mpt0: IOCFACTS: GlobalCredits=3D256 BlockSize=3D12 bytes Request Frame Siz= e 512 bytes Max Chain Depth 3 >mpt0: IOCFACTS: Num Ports 8, FWImageSize 0, Flags=3D0 >mpt0: PORTFACTS[1]: Type 30 PFlags 9 IID 8 MaxDev 8 >mpt0: PORTFACTS[2]: Type 30 PFlags 9 IID 8 MaxDev 8 >mpt0: PORTFACTS[3]: Type 30 PFlags 9 IID 8 MaxDev 8 >mpt0: PORTFACTS[4]: Type 30 PFlags 9 IID 8 MaxDev 8 >mpt0: PORTFACTS[5]: Type 30 PFlags 9 IID 8 MaxDev 8 >mpt0: PORTFACTS[6]: Type 30 PFlags 9 IID 8 MaxDev 8 >mpt0: PORTFACTS[7]: Type 30 PFlags 9 IID 8 MaxDev 8 >mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required= ). >mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required= ). >pcib1: at device 24.0 on pci0 >pcib1: domain 0 >pcib1: secondary bus 1 >pcib1: subordinate bus 2 >pcib1: no prefetched decode >pcib1: Subtractively decoded bridge. >pci1: on pcib1 >pci1: domain=3D0, physical bus=3D1 >pcib2: at device 25.0 on pci0 >pcib2: domain 0 >pcib2: secondary bus 2 >pcib2: subordinate bus 3 >pcib2: no prefetched decode >pcib2: Subtractively decoded bridge. >pci2: on pcib2 >pci2: domain=3D0, physical bus=3D2 >isab0: at device 31.0 on pci0 >isa0: on isab0 >ahci0: port 0xe000-0xe007,0xe008-0xe00b= ,0xe010-0xe017,0xe018-0xe01b,0xe020-0xe02f mem 0xf1000000-0xf1001fff irq 23= at device 31.2 on pci0 >ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 56 >ahci0: AHCI v1.10 with 1 3Gbps ports, Port Multiplier not supported >ahci0: Caps: 64bit NCQ SS 3Gbps 32cmd CCC 1ports >ahci0: Caps2: >ahcich0: at channel 0 on ahci0 >ahcich0: Caps: >ohci0: mem 0xf1002000-0xf1002fff irq 23 at= device 31.4 on pci0 >usbus0: on ohci0 >usbus0: bpf attached >ohci0: usbpf: Attached >battery0: on acpi0 >acpi_acad0: on acpi0 >atkbdc0: port 0x60,0x64 irq 1 on acpi0 >atkbd0: irq 1 on atkbdc0 >atkbd: the current kbd controller command byte 0045 >atkbd: keyboard ID 0x41ab (2) >kbd0 at atkbd0 >kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 >ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 57 >atkbd0: [GIANT-LOCKED] >psm0: unable to allocate IRQ >psmcpnp0: irq 12 on acpi0 >psm0: current command byte:0045 >psm0: irq 12 on atkbdc0 >ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 58 >psm0: [GIANT-LOCKED] >psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons >psm0: config:00000000, flags:00000008, packet size:4 >psm0: syncmask:08, syncbits:00 >ppc0: using extended I/O port range >acpi0: wakeup code va 0xffffff8049ede000 pa 0x4000 >ex_isa_identify() >ahc_isa_probe 0: ioport 0xc00 alloc failed >ahc_isa_probe 1: ioport 0x1c00 alloc failed >ahc_isa_probe 2: ioport 0x2c00 alloc failed >ahc_isa_probe 3: ioport 0x3c00 alloc failed >ahc_isa_probe 4: ioport 0x4c00 alloc failed >ahc_isa_probe 5: ioport 0x5c00 alloc failed >ahc_isa_probe 6: ioport 0x6c00 alloc failed >ahc_isa_probe 7: ioport 0x7c00 alloc failed >ahc_isa_probe 8: ioport 0x8c00 alloc failed >ahc_isa_probe 9: ioport 0x9c00 alloc failed >ahc_isa_probe 10: ioport 0xac00 alloc failed >ahc_isa_probe 11: ioport 0xbc00 alloc failed >ahc_isa_probe 12: ioport 0xcc00 alloc failed >ahc_isa_probe 13: ioport 0xdc00 alloc failed >ahc_isa_probe 14: ioport 0xec00 alloc failed >pcib0: allocated type 3 (0xa0000-0xa07ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa0800-0xa0fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa1000-0xa17ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa1800-0xa1fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa2000-0xa27ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa2800-0xa2fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa3000-0xa37ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa3800-0xa3fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa4000-0xa47ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa4800-0xa4fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa5000-0xa57ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa5800-0xa5fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa6000-0xa67ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa6800-0xa6fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa7000-0xa77ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa7800-0xa7fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa8000-0xa87ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa8800-0xa8fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa9000-0xa97ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xa9800-0xa9fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xaa000-0xaa7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xaa800-0xaafff) for rid 0 of orm0 >pcib0: allocated type 3 (0xab000-0xab7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xab800-0xabfff) for rid 0 of orm0 >pcib0: allocated type 3 (0xac000-0xac7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xac800-0xacfff) for rid 0 of orm0 >pcib0: allocated type 3 (0xad000-0xad7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xad800-0xadfff) for rid 0 of orm0 >pcib0: allocated type 3 (0xae000-0xae7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xae800-0xaefff) for rid 0 of orm0 >pcib0: allocated type 3 (0xaf000-0xaf7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xaf800-0xaffff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb0000-0xb07ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb0800-0xb0fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb1000-0xb17ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb1800-0xb1fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb2000-0xb27ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb2800-0xb2fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb3000-0xb37ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb3800-0xb3fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb4000-0xb47ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb4800-0xb4fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb5000-0xb57ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb5800-0xb5fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb6000-0xb67ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb6800-0xb6fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb7000-0xb77ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb7800-0xb7fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb8000-0xb87ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb8800-0xb8fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb9000-0xb97ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xb9800-0xb9fff) for rid 0 of orm0 >pcib0: allocated type 3 (0xba000-0xba7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xba800-0xbafff) for rid 0 of orm0 >pcib0: allocated type 3 (0xbb000-0xbb7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xbb800-0xbbfff) for rid 0 of orm0 >pcib0: allocated type 3 (0xbc000-0xbc7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xbc800-0xbcfff) for rid 0 of orm0 >pcib0: allocated type 3 (0xbd000-0xbd7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xbd800-0xbdfff) for rid 0 of orm0 >pcib0: allocated type 3 (0xbe000-0xbe7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xbe800-0xbefff) for rid 0 of orm0 >pcib0: allocated type 3 (0xbf000-0xbf7ff) for rid 0 of orm0 >pcib0: allocated type 3 (0xbf800-0xbffff) for rid 0 of orm0 >isa_probe_children: disabling PnP devices >atkbdc: atkbdc0 already exists; skipping it >atrtc: atrtc0 already exists; skipping it >attimer: attimer0 already exists; skipping it >sc: sc0 already exists; skipping it >isa_probe_children: probing non-PnP devices >orm0: at iomem 0xc0000-0xc7fff,0xe2000-0xe6fff on isa0 >sc0: at flags 0x100 on isa0 >sc0: VGA <16 virtual consoles, flags=3D0x300> >sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) >vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >pcib0: allocated type 4 (0x3c0-0x3df) for rid 0 of vga0 >pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 >pcib0: allocated type 4 (0x3f0-0x3f5) for rid 0 of fdc0 >pcib0: allocated type 4 (0x3f7-0x3f7) for rid 1 of fdc0 >fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 >ppc0: cannot reserve I/O port range >ppc0: failed to probe at irq 7 on isa0 >pcib0: allocated type 4 (0x3f8-0x3ff) for rid 0 of uart0 >uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 >pcib0: allocated type 4 (0x2f8-0x2ff) for rid 0 of uart1 >uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 >isa_probe_children: probing PnP devices >ctl: CAM Target Layer loaded >Device configuration finished. >procfs registered >ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is pre= sent; > to enable, add "vfs.zfs.prefetch_disable=3D0" to /boot/loader.= conf. >ZFS filesystem version 5 >ZFS storage pool version 28 >lapic: Divisor 2, Frequency 500009333 Hz >Timecounters tick every 10.000 msec >vlan: initialized, using hash tables with chaining >lo0: bpf attached >hptrr: no controller detected. >usbus0: 12Mbps Full Speed USB v1.0 >ahcich0: AHCI reset... >ahcich0: SATA connect time=3D0us status=3D00000123 >ahcich0: AHCI reset: device found >ahcich0: AHCI reset: device ready after 0ms >ugen0.1: at usbus0 >uhub0: on usbus0 >(aprobe0:ahcich0:0:0:0): SIGNATURE: eb14 >battery0: battery initialization start >battery0: battery initialization done, tried 1 times >acpi_acad0: acline initialization start >system power profile changed to 'economy' >acpi_acad0: Off Line >acpi_acad0: acline initialization done, tried 1 times >uhub0: 8 ports with 8 removable, self powered >(probe8:ctl2cam0:0:1:0): Error 6, Unretryable error >pass0 at mpt0 bus 0 scbus0 target 0 lun 0 >pass0: Fixed Direct Access SCSI-5 device=20 >pass0: 300.000MB/s transfers >pass0: Command Queueing enabled >pass1 at ahcich0 bus 0 scbus1 target 0 lun 0 >pass1: Removable CD-ROM SCSI-0 device=20 >pass1: Serial Number VB0-1a2b3c4d >pass1: 300.000MB/s transfers (SATA 2.x, UDMA6, ATAPI 12bytes, PIO 8192byte= s) >pass1: Command Queueing enabled >da0 at mpt0 bus 0 scbus0 target 0 lun 0 >da0: Fixed Direct Access SCSI-5 device=20 >da0: 300.000MB/s transfers >da0: Command Queueing enabled >da0: 10240MB (20971520 512 byte sectors: 255H 63S/T 1305C) >GEOM: new disk da0 >cd0 at ahcich0 bus 0 scbus1 target 0 lun 0 >cd0: Removable CD-ROM SCSI-0 device=20 >cd0: Serial Number VB0-1a2b3c4d >cd0: 300.000MB/s transfers (SATA 2.x, UDMA6, ATAPI 12bytes, PIO 8192bytes) >cd0: Command Queueing enabled >cd0: cd present [82272 x 2048 byte records] >Timecounter "TSC" frequency 2390626999 Hz quality 800 >GEOM: new disk cd0 >Trying to mount root from zfs:sistema []... >start_init: trying /sbin/init >vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x00000000 chip=3D0xbeef80ee r= ev=3D0x00 hdr=3D0x00 > vendor =3D 'InnoTek Systemberatung GmbH' > device =3D 'VirtualBox Graphics Adapter' > class =3D display > subclass =3D VGA >le0@pci0:0:3:0: class=3D0x020000 card=3D0x20001022 chip=3D0x20001022 rev= =3D0x10 hdr=3D0x00 > vendor =3D 'Advanced Micro Devices [AMD]' > device =3D '79c970 [PCnet32 LANCE]' > class =3D network > subclass =3D ethernet >none0@pci0:0:4:0: class=3D0x088000 card=3D0x00000000 chip=3D0xcafe80ee rev= =3D0x00 hdr=3D0x00 > vendor =3D 'InnoTek Systemberatung GmbH' > device =3D 'VirtualBox Guest Service' > class =3D base peripheral >none1@pci0:0:7:0: class=3D0x068000 card=3D0x00000000 chip=3D0x71138086 rev= =3D0x08 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82371AB/EB/MB PIIX4 ACPI' > class =3D bridge >le1@pci0:0:8:0: class=3D0x020000 card=3D0x20001022 chip=3D0x20001022 rev= =3D0x10 hdr=3D0x00 > vendor =3D 'Advanced Micro Devices [AMD]' > device =3D '79c970 [PCnet32 LANCE]' > class =3D network > subclass =3D ethernet >le2@pci0:0:9:0: class=3D0x020000 card=3D0x20001022 chip=3D0x20001022 rev= =3D0x10 hdr=3D0x00 > vendor =3D 'Advanced Micro Devices [AMD]' > device =3D '79c970 [PCnet32 LANCE]' > class =3D network > subclass =3D ethernet >le3@pci0:0:10:0: class=3D0x020000 card=3D0x20001022 chip=3D0x20001022 rev= =3D0x10 hdr=3D0x00 > vendor =3D 'Advanced Micro Devices [AMD]' > device =3D '79c970 [PCnet32 LANCE]' > class =3D network > subclass =3D ethernet >le4@pci0:0:16:0: class=3D0x020000 card=3D0x20001022 chip=3D0x20001022 rev= =3D0x10 hdr=3D0x00 > vendor =3D 'Advanced Micro Devices [AMD]' > device =3D '79c970 [PCnet32 LANCE]' > class =3D network > subclass =3D ethernet >le5@pci0:0:17:0: class=3D0x020000 card=3D0x20001022 chip=3D0x20001022 rev= =3D0x10 hdr=3D0x00 > vendor =3D 'Advanced Micro Devices [AMD]' > device =3D '79c970 [PCnet32 LANCE]' > class =3D network > subclass =3D ethernet >le6@pci0:0:18:0: class=3D0x020000 card=3D0x20001022 chip=3D0x20001022 rev= =3D0x10 hdr=3D0x00 > vendor =3D 'Advanced Micro Devices [AMD]' > device =3D '79c970 [PCnet32 LANCE]' > class =3D network > subclass =3D ethernet >le7@pci0:0:19:0: class=3D0x020000 card=3D0x20001022 chip=3D0x20001022 rev= =3D0x10 hdr=3D0x00 > vendor =3D 'Advanced Micro Devices [AMD]' > device =3D '79c970 [PCnet32 LANCE]' > class =3D network > subclass =3D ethernet >mpt0@pci0:0:22:0: class=3D0x010000 card=3D0x80001000 chip=3D0x00541000 rev= =3D0x00 hdr=3D0x00 > vendor =3D 'LSI Logic / Symbios Logic' > device =3D 'SAS1068 PCI-X Fusion-MPT SAS' > class =3D mass storage > subclass =3D SCSI >pcib1@pci0:0:24:0: class=3D0x060401 card=3D0x00000000 chip=3D0x24488086 re= v=3D0xf2 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801 Mobile PCI Bridge' > class =3D bridge > subclass =3D PCI-PCI >pcib2@pci0:0:25:0: class=3D0x060401 card=3D0x00000000 chip=3D0x24488086 re= v=3D0xf2 hdr=3D0x01 > vendor =3D 'Intel Corporation' > device =3D '82801 Mobile PCI Bridge' > class =3D bridge > subclass =3D PCI-PCI >isab0@pci0:0:31:0: class=3D0x060100 card=3D0x72708086 chip=3D0x27b98086 re= v=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801GBM (ICH7-M) LPC Interface Bridge' > class =3D bridge > subclass =3D PCI-ISA >ahci0@pci0:0:31:2: class=3D0x010601 card=3D0x00000000 chip=3D0x28298086 re= v=3D0x02 hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D '82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller' > class =3D mass storage > subclass =3D SATA >ohci0@pci0:0:31:4: class=3D0x0c0310 card=3D0x00000000 chip=3D0x003f106b re= v=3D0x00 hdr=3D0x00 > vendor =3D 'Apple Computer Inc.' > device =3D 'KeyLargo/Intrepid USB' > class =3D serial bus > subclass =3D USB >00:02.0 VGA compatible controller: InnoTek Systemberatung GmbH VirtualBox = Graphics Adapter (prog-if 00 [VGA controller]) > Flags: bus master, fast devsel, latency 0, IRQ 10 > Memory at e0000000 (32-bit, prefetchable) [size=3D8M] > Expansion ROM at [disabled] > >00:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 = LANCE] (rev 10) > Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 > Flags: bus master, medium devsel, latency 64, IRQ 19 > I/O ports at d000 [size=3D32] > Memory at f0000000 (32-bit, non-prefetchable) [size=3D4K] > Memory at f0080000 (32-bit, non-prefetchable) [size=3D512K] > Kernel driver in use: pcnet32 > Kernel modules: pcnet32 > >00:04.0 System peripheral: InnoTek Systemberatung GmbH VirtualBox Guest Se= rvice > Flags: bus master, fast devsel, latency 0, IRQ 5 > I/O ports at d020 [size=3D32] > Memory at f0400000 (32-bit, non-prefetchable) [size=3D4M] > Memory at f0800000 (32-bit, prefetchable) [size=3D16K] > >00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08) > Flags: bus master, medium devsel, latency 0, IRQ 9 > Kernel modules: i2c-piix4 > >00:08.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 = LANCE] (rev 10) > Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 > Flags: bus master, medium devsel, latency 64, IRQ 16 > I/O ports at d040 [size=3D32] > Memory at f0804000 (32-bit, non-prefetchable) [size=3D4K] > Memory at f0880000 (32-bit, non-prefetchable) [size=3D512K] > Kernel driver in use: pcnet32 > Kernel modules: pcnet32 > >00:09.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 = LANCE] (rev 10) > Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 > Flags: bus master, medium devsel, latency 64, IRQ 17 > I/O ports at d060 [size=3D32] > Memory at f0900000 (32-bit, non-prefetchable) [size=3D4K] > Memory at f0980000 (32-bit, non-prefetchable) [size=3D512K] > Kernel driver in use: pcnet32 > Kernel modules: pcnet32 > >00:0a.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 = LANCE] (rev 10) > Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 > Flags: bus master, medium devsel, latency 64, IRQ 18 > I/O ports at d080 [size=3D32] > Memory at f0a00000 (32-bit, non-prefetchable) [size=3D4K] > Memory at f0a80000 (32-bit, non-prefetchable) [size=3D512K] > Kernel driver in use: pcnet32 > Kernel modules: pcnet32 > >00:10.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 = LANCE] (rev 10) > Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 > Flags: bus master, medium devsel, latency 64, IRQ 16 > I/O ports at d0a0 [size=3D32] > Memory at f0b00000 (32-bit, non-prefetchable) [size=3D4K] > Memory at f0b80000 (32-bit, non-prefetchable) [size=3D512K] > Kernel driver in use: pcnet32 > Kernel modules: pcnet32 > >00:11.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 = LANCE] (rev 10) > Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 > Flags: bus master, medium devsel, latency 64, IRQ 17 > I/O ports at d0c0 [size=3D32] > Memory at f0c00000 (32-bit, non-prefetchable) [size=3D4K] > Memory at f0c80000 (32-bit, non-prefetchable) [size=3D512K] > Kernel driver in use: pcnet32 > Kernel modules: pcnet32 > >00:12.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 = LANCE] (rev 10) > Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 > Flags: bus master, medium devsel, latency 64, IRQ 18 > I/O ports at d0e0 [size=3D32] > Memory at f0d00000 (32-bit, non-prefetchable) [size=3D4K] > Memory at f0d80000 (32-bit, non-prefetchable) [size=3D512K] > Kernel driver in use: pcnet32 > Kernel modules: pcnet32 > >00:13.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 = LANCE] (rev 10) > Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 > Flags: bus master, medium devsel, latency 64, IRQ 19 > I/O ports at d100 [size=3D32] > Memory at f0e00000 (32-bit, non-prefetchable) [size=3D4K] > Memory at f0e80000 (32-bit, non-prefetchable) [size=3D512K] > Kernel driver in use: pcnet32 > Kernel modules: pcnet32 > >00:16.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X F= usion-MPT SAS > Subsystem: LSI Logic / Symbios Logic Device 8000 > Flags: bus master, fast devsel, latency 64, IRQ 22 > I/O ports at d200 [disabled] [size=3D256] > Memory at f0f00000 (32-bit, non-prefetchable) [size=3D128K] > Memory at f0f20000 (32-bit, non-prefetchable) [size=3D128K] > Capabilities: > Kernel driver in use: mptsas > Kernel modules: mptsas > >00:18.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (pr= og-if 01 [Subtractive decode]) > Flags: bus master, 66MHz, fast devsel, latency 64 > Bus: primary=3D00, secondary=3D01, subordinate=3D01, sec-latency=3D0 > >00:19.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (pr= og-if 01 [Subtractive decode]) > Flags: bus master, 66MHz, fast devsel, latency 64 > Bus: primary=3D00, secondary=3D02, subordinate=3D02, sec-latency=3D0 > I/O behind bridge: 00001000-00001fff > Memory behind bridge: 40000000-400fffff > >00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Brid= ge (rev 02) > Subsystem: Intel Corporation Device 7270 > Flags: bus master, medium devsel, latency 0 > Kernel modules: leds-ss4200, iTCO_wdt, intel-rng > >00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SAT= A Controller [AHCI mode] (rev 02) (prog-if 01 [AHCI 1.0]) > Flags: bus master, fast devsel, latency 64, IRQ 40 > I/O ports at e000 [size=3D8] > I/O ports at e008 [size=3D4] > I/O ports at e010 [size=3D8] > I/O ports at e018 [size=3D4] > I/O ports at e020 [size=3D16] > Memory at f1000000 (32-bit, non-prefetchable) [size=3D8K] > Capabilities: > Kernel driver in use: ahci > >00:1f.4 USB controller: Apple Inc. KeyLargo/Intrepid USB (prog-if 10 [OHCI= ]) > Flags: bus master, fast devsel, latency 64, IRQ 23 > Memory at f1002000 (32-bit, non-prefetchable) [size=3D4K] > Capabilities: > Kernel driver in use: ohci_hcd > >02:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 = LANCE] (rev 10) > Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 > Flags: bus master, medium devsel, latency 64, IRQ 17 > I/O ports at 1000 [size=3D32] > Memory at 40080000 (32-bit, non-prefetchable) [size=3D4K] > Memory at 40000000 (32-bit, non-prefetchable) [size=3D512K] > Kernel driver in use: pcnet32 > Kernel modules: pcnet32 > >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" --=20 Peter Jeremy --T4sUOijqQbZv57TR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA96vIACgkQ/opHv/APuIdNIACfQoiIyX/+NjzGxH9yz7Yua137 2aYAn2q5LVDcoL3nUjKSM3knTBUv9hD0 =6t9k -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 10:18:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3B05106564A; Wed, 29 Aug 2012 10:18:02 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 536B68FC0A; Wed, 29 Aug 2012 10:18:01 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q7TAIW0v046920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 12:18:32 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <503DEC58.1050609@omnilan.de> Date: Wed, 29 Aug 2012 12:18:00 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Pete French References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB2100205CAE4CC6704DAFA3F" Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 10:18:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB2100205CAE4CC6704DAFA3F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable schrieb Pete French am 29.08.2012 11:38 (localtime): >> Link aggregation can never work with two separate switches! LACP and >> static trunking require both sides to bundle the same trunk. which is >> impossible for two separate switches. > These switches had a port where you could connect them together and > then configure each to know about the other switch, and to do LACP > across the pair of them. Or at least thats what it looked like it > was capable of doing, and it appeared to be doing LACP when configured > that way and connected to Windows machines, just not FreeBSD ones. But = I'm What you desciribe is well known as =E2=80=9Estacking=E2=80=9C (not to mi= x with =E2=80=9Evirtual stacking=E2=80=9C) and sorry that I haven't made clear that in such a cas= e LACP (also static trunking of course) works well and is a fantastic way to gain redundancy. When you create a physical switch stack, the individual switches are no separate switches anymore, but act like one big switch. With the advantage, that in case of a failure, and a trunk configured over two different units of the stack, the link remains active. But like mentioned, these switches are then not considered to be separate (=E2=80=9Evirtual stacking=E2=80=9C only combine them in managem= ent regards, _not_ physically, so be carefull when you look for switches with =E2=80=9Estacking=E2=80=9C capabilities!). The disadvantage of the real hardware stackable switch is the price. The cheapest way I've found is two DGS-3120 (~700$ each plus 200$ stacking cable). Ciscos and Junipers and the bigger HPs are all much above afaik. -Harry --------------enigB2100205CAE4CC6704DAFA3F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlA97FgACgkQLDqVQ9VXb8gG1wCgqn3xBuUpgGMdH2p3Zyx3ALWJ UG4Ani2Uxayyzbu4NHRo+NXWEujmT22G =4o6x -----END PGP SIGNATURE----- --------------enigB2100205CAE4CC6704DAFA3F-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 10:24:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 651491065673; Wed, 29 Aug 2012 10:24:52 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (s1.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id E3BDD8FC22; Wed, 29 Aug 2012 10:24:50 +0000 (UTC) Received: from titan.inop.wdn.omnilan.net (titan.inop.wdn.omnilan.net [172.21.3.1]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id q7TAPLIK047058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 12:25:21 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <503DEDF1.2020406@omnilan.de> Date: Wed, 29 Aug 2012 12:24:49 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Pete French References: <503DEC58.1050609@omnilan.de> In-Reply-To: <503DEC58.1050609@omnilan.de> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF43D9C6B09CD2D4AB4838903" Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 10:24:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF43D9C6B09CD2D4AB4838903 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable schrieb Harald Schmalzbauer am 29.08.2012 12:18 (localtime): > schrieb Pete French am 29.08.2012 11:38 (localtime): >>> Link aggregation can never work with two separate switches! LACP and >>> static trunking require both sides to bundle the same trunk. which is= >>> impossible for two separate switches. >> These switches had a port where you could connect them together and >> then configure each to know about the other switch, and to do LACP >> across the pair of them. Or at least thats what it looked like it >> was capable of doing, and it appeared to be doing LACP when configured= >> that way and connected to Windows machines, just not FreeBSD ones. But= I'm Have you checked that Windows really did LACP in your case? Sounds like it was no real hardware stack, so probably Windos just activated RSTP. FreeBSD doesn't detect any LACP/RSTP configuration features, but windows does with some NIC verndor's drivers. -Harry P.S.: Sorry for that additional answer, just forgot it in my last email. --------------enigF43D9C6B09CD2D4AB4838903 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlA97fEACgkQLDqVQ9VXb8gMgACgzrjGi0TNwuxFSZaAp07dGDhA EgEAmwYtrpmvKeSb9EMzoDDLvZK8LjTF =5bB2 -----END PGP SIGNATURE----- --------------enigF43D9C6B09CD2D4AB4838903-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 10:37:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CD2E106564A for ; Wed, 29 Aug 2012 10:37:23 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0263A8FC12 for ; Wed, 29 Aug 2012 10:37:22 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T6fe7-0001XU-5h for freebsd-stable@freebsd.org; Wed, 29 Aug 2012 12:37:15 +0200 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 ; Wed, 29 Aug 2012 12:37:15 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Aug 2012 12:37:15 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Wed, 29 Aug 2012 12:36:53 +0200 Lines: 44 Message-ID: References: <503CE60F.8040007@yahoo.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCF341A4A7614C1EAB312449F" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: <503CE60F.8040007@yahoo.de> X-Enigmail-Version: 1.3.5 Subject: Re: IPv4 vs. IPv6 Ethernet Performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 10:37:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCF341A4A7614C1EAB312449F Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 28/08/2012 17:38, Norbert Aschendorff wrote: > Configuration v6 v4 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Linux -> Linux 925 935 # <=3D This could be v6's 40B header > # vs. v4's 20B > Linux -> FreeBSD 450 700 > FreeBSD -> Linux 455 920 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The FreeBSD->Linux value shows that the ethernet chip on the FreeBSD > machine (it's Intel stuff on both sides, using the em(4) driver on > FreeBSD) is able to send at full 1G speed. But why is IPv6 so slow? There are some more numbers, FreeBSD-FreeBSD here: http://people.freebsd.org/~bz/bench/ Apparently, the software stack is capable enough so it may be a driver problem in your case. --------------enigCF341A4A7614C1EAB312449F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA98NAACgkQ/QjVBj3/HSxNtgCeLnPHgg65U9F73IWXPotoyK1P UtMAoJxfgYbbgxQzhKPtvgCjmypkhm18 =OcLw -----END PGP SIGNATURE----- --------------enigCF341A4A7614C1EAB312449F-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 10:44:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E1C0106564A; Wed, 29 Aug 2012 10:44:33 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) by mx1.freebsd.org (Postfix) with ESMTP id DECF28FC14; Wed, 29 Aug 2012 10:44:32 +0000 (UTC) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1T6fku-0007nX-5S; Wed, 29 Aug 2012 11:44:16 +0100 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T6fku-000FAI-4J; Wed, 29 Aug 2012 11:44:16 +0100 To: h.schmalzbauer@omnilan.de, petefrench@ingresso.co.uk In-Reply-To: <503DEDF1.2020406@omnilan.de> Message-Id: From: Pete French Date: Wed, 29 Aug 2012 11:44:16 +0100 Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 10:44:33 -0000 > Have you checked that Windows really did LACP in your case? Sounds like > it was no real hardware stack, so probably Windos just activated RSTP. > FreeBSD doesn't detect any LACP/RSTP configuration features, but windows > does with some NIC verndor's drivers. That is quite possible - I didnt set any of that side up, so am just trying to remember what the networking people said was going on. We may well have had some kind of magic drivers on the Windows side of things - indeed recall that there was some HP specific thing to manage the ethernet cards on those severs (DL360s). Actually I went and looked out my old emails - Cisco 3750 switches worked as a pair with LACP, Cisco 3560 ones didn't. Whatever the difference is between those two, thats the difference between working and not working :) Is that real stacking vs virtual stacking by any chance ? -pete. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 10:57:45 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47FBA1065674 for ; Wed, 29 Aug 2012 10:57:45 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward3h.mail.yandex.net (forward3h.mail.yandex.net [IPv6:2a02:6b8:0:f05::3]) by mx1.freebsd.org (Postfix) with ESMTP id BCF348FC1D for ; Wed, 29 Aug 2012 10:57:44 +0000 (UTC) Received: from smtp2h.mail.yandex.net (smtp2h.mail.yandex.net [84.201.187.145]) by forward3h.mail.yandex.net (Yandex) with ESMTP id 76A071361E07 for ; Wed, 29 Aug 2012 14:57:43 +0400 (MSK) Received: from smtp2h.mail.yandex.net (localhost [127.0.0.1]) by smtp2h.mail.yandex.net (Yandex) with ESMTP id 586B4170014D for ; Wed, 29 Aug 2012 14:57:43 +0400 (MSK) Received: from 87.249.28.59.tel.ru (87.249.28.59.tel.ru [87.249.28.59]) by smtp2h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id vgV0HSeT-vgVCLNYv; Wed, 29 Aug 2012 14:57:42 +0400 Message-ID: <503DF5A6.6030902@passap.ru> Date: Wed, 29 Aug 2012 14:57:42 +0400 From: =?UTF-8?B?0JHQvtGA0LjRgSDQodCw0LzQvtGA0L7QtNC+0LI=?= User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: [9.1-PRERELEASE r239793] rpcbind does not hornor -h flag X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 10:57:45 -0000 Hi List, Seems that rpcbind bind to all UDP interfaces (mind "udp4 *:940" at the last command): ----- % uname -a FreeBSD uni.wart.ru 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #7 r239793: Wed Aug 29 04:07:03 SAMT 2012 bsam@uni.wart.ru:/usr/obj/usr/src/sys/UNI i386 % sockstat -4l | grep rpc % grep rpcbind /etc/rc.conf.local rpcbind_flags="-h 192.168.119.252" % sudo /etc/rc.d/rpcbind onestart Starting rpcbind. % sockstat -4l | grep rpc root rpcbind 7713 9 udp4 127.0.0.1:111 *:* root rpcbind 7713 10 udp4 192.168.119.252:111 *:* root rpcbind 7713 11 udp4 *:940 *:* root rpcbind 7713 12 tcp4 127.0.0.1:111 *:* root rpcbind 7713 13 tcp4 192.168.119.252:111 *:* ----- -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 11:42:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13F9A106566B for ; Wed, 29 Aug 2012 11:42:25 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id C17EA8FC1B for ; Wed, 29 Aug 2012 11:42:24 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T6gfB-0007AX-29 for freebsd-stable@freebsd.org; Wed, 29 Aug 2012 13:42:25 +0200 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Aug 2012 13:42:25 +0200 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Aug 2012 13:42:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Date: Wed, 29 Aug 2012 11:42:13 +0000 (UTC) Lines: 24 Message-ID: References: <503CE60F.8040007@yahoo.de> 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: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20100101 Firefox/14.0.1) Subject: Re: IPv4 vs. IPv6 Ethernet Performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 11:42:25 -0000 Norbert Aschendorff yahoo.de> writes: > ... > Little table (values in Mbit/s): > > Configuration v6 v4 > ======================================= > Linux -> Linux 925 935 # <= This could be v6's 40B header > # vs. v4's 20B > Linux -> FreeBSD 450 700 > FreeBSD -> Linux 455 920 > ======================================= > > The FreeBSD->Linux value shows that the ethernet chip on the FreeBSD > machine (it's Intel stuff on both sides, using the em(4) driver on > FreeBSD) is able to send at full 1G speed. But why is IPv6 so slow? Norbert, may I ask you to provide one more stats item for this table, if you can ? FreeBSD -> FreeBSD ??? ??? Thanks, jb From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 12:25:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 156A71065675 for ; Wed, 29 Aug 2012 12:25:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id DE17D8FC1D for ; Wed, 29 Aug 2012 12:25:47 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 39DA4B972; Wed, 29 Aug 2012 08:25:47 -0400 (EDT) From: John Baldwin To: Peter Jeremy Date: Wed, 29 Aug 2012 08:13:55 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <503C930C.3010405@entel.upc.edu> <503DE1BC.4050907@entel.upc.edu> <20120829101202.GA74970@server.rulingia.com> In-Reply-To: <20120829101202.GA74970@server.rulingia.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201208290813.55855.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 29 Aug 2012 08:25:47 -0400 (EDT) Cc: Gustau =?iso-8859-15?q?P=E9rez_i_Querol?= , freebsd-stable@freebsd.org Subject: Re: Problem adding more than 8 network adapters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 12:25:48 -0000 On Wednesday, August 29, 2012 6:12:02 am Peter Jeremy wrote: > [Moving to -stable and adding jhb@ for his input] >=20 > On 2012-Aug-29 11:32:44 +0200, Gustau P=E9rez i Querol wrote: > >Al 29/08/2012 11:02, En/na Peter Jeremy ha escrit: > >> On 2012-Aug-28 11:44:44 +0200, Gustau P=E9rez i Querol wrote: > >>> I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm > >>> facing is that I can't use more than 8 network adapters plugged to the > >>> virtual machine. > >> ... > >>> I don't know if it's a net@ problem or maybe it is a problem with > >>> the emulated PCI-bridge and then stable@ should be contacted. Also, I= 'm > >>> not sure if a real machine would support more than 8 network adapters= or > >>> not. Any hints would be appreciated. > >> I don't think I've ever used more than 6 physical NICs in a host but d= on't > >> know of any reason for >8 to not work. > > > >> Can you please post a "pciconf -lv" from FreeBSD and the equivalent > >> "lspci" from Linux. A FreeBSD verbose boot log might also help. > > > > Sure. I'm attaching them to this mail. I hope the mailing list=20 > >doesn't eat them. If it does, I will post them online and send the URL=20 > >to the mailing list. >=20 > Ah.. lspci shows the 9th LANCE at 02:00.0. The verbose boot shows > FreeBSD finds pcib2 (at pci0 device 25.0) but doesn't see anything > on that bus. ISTR jhb@ will recognize that problem. Silly firmware, VM, whatever it is. :) It's buggy. > >pcib1: at device 24.0 on pci0 > >pcib1: domain 0 > >pcib1: secondary bus 1 > >pcib1: subordinate bus 2 > >pcib1: no prefetched decode > >pcib1: Subtractively decoded bridge. > >pci1: on pcib1 > >pci1: domain=3D0, physical bus=3D1 > >pcib2: at device 25.0 on pci0 > >pcib2: domain 0 > >pcib2: secondary bus 2 > >pcib2: subordinate bus 3 > >pcib2: no prefetched decode > >pcib2: Subtractively decoded bridge. > >pci2: on pcib2 > >pci2: domain=3D0, physical bus=3D2 This is indeed the problem. PCI bus 2 is "claimed" by both pcib1 and pcib2 since the VM author programmed the bridges incorrectly. In this case, the subordinate bus should be "1" and "2", not "2" and "3". You could add a ha= ck to pci_pci.c to fix the subordinate bus on these bridges which should proba= bly fix this. > >00:18.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (= prog-if 01 [Subtractive decode]) > > Flags: bus master, 66MHz, fast devsel, latency 64 > > Bus: primary=3D00, secondary=3D01, subordinate=3D01, sec-latency=3D0 > > > >00:19.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (= prog-if 01 [Subtractive decode]) > > Flags: bus master, 66MHz, fast devsel, latency 64 > > Bus: primary=3D00, secondary=3D02, subordinate=3D02, sec-latency=3D0 > > I/O behind bridge: 00001000-00001fff > > Memory behind bridge: 40000000-400fffff Note here in this output (presumably from lspci under Linux?), the subordinate bus register =3D=3D secondary bus register for each bridge. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 12:25:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55553106566B for ; Wed, 29 Aug 2012 12:25:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA5E8FC1E for ; Wed, 29 Aug 2012 12:25:49 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6AB10B97C; Wed, 29 Aug 2012 08:25:48 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 29 Aug 2012 08:25:44 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <503DE2AB.6030702@citrin.ru> In-Reply-To: <503DE2AB.6030702@citrin.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208290825.44198.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 29 Aug 2012 08:25:48 -0400 (EDT) Cc: Anton Yuzhaninov Subject: Re: Problem with IPMI KCS driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 12:25:49 -0000 On Wednesday, August 29, 2012 5:36:43 am Anton Yuzhaninov wrote: > We use servers witch motherboard Supermicro X8DTT-H and meet with such problem: > when watchdogd started, server is rebooted by IPMI watchdog several times per week. > > After some debugging I've found, that sometimes IPMI driver entered endless > loop, and watchdogd have no chances to reset watchdog timer. > In such situation top show: > > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND > ... > 113 root -16 - 0K 16K CPU4 4 17:18 99.17% ipmi0: kcs > > Endless loop located in file /sys/dev/ipmi/ipmi_kcs.c and function > kcs_wait_for_obf(): > > int status, start = ticks; > > status = INB(sc, KCS_CTL_STS); > if (state == 0) { > /* WAIT FOR OBF = 0 */ > while (ticks - start < MAX_TIMEOUT && status & KCS_STATUS_OBF) { > DELAY(100); > status = INB(sc, KCS_CTL_STS); > } > } else { > /* WAIT FOR OBF = 1 */ > while (ticks - start < MAX_TIMEOUT && > !(status & KCS_STATUS_OBF)) { > DELAY(100); > status = INB(sc, KCS_CTL_STS); > } > } > > It seems to be, that this loop intended to run no more than MAX_TIMEOUT ticks. > but by some reason this timeout does not works and loop runs until reboot. > > Questions: > 1. Is it correct to check ticks to implement timeout here? > 2. how to fix this timeout? Hmm. Can you try this: Index: kern/kern_clock.c =================================================================== --- kern/kern_clock.c (revision 239819) +++ kern/kern_clock.c (working copy) @@ -382,7 +382,7 @@ int stathz; int profhz; int profprocs; -int ticks; +volatile int ticks; int psratio; static DPCPU_DEFINE(int, pcputicks); /* Per-CPU version of ticks. */ @@ -469,7 +469,7 @@ hardclock(int usermode, uintfptr_t pc) { - atomic_add_int((volatile int *)&ticks, 1); + atomic_add_int(&ticks, 1); hardclock_cpu(usermode); tc_ticktock(1); cpu_tick_calibration(); Index: sys/kernel.h =================================================================== --- sys/kernel.h (revision 239819) +++ sys/kernel.h (working copy) @@ -63,7 +63,7 @@ extern int stathz; /* statistics clock's frequency */ extern int profhz; /* profiling clock's frequency */ extern int profprocs; /* number of process's profiling */ -extern int ticks; +extern volatile int ticks; #endif /* _KERNEL */ -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 12:33:01 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9C8106564A; Wed, 29 Aug 2012 12:33:01 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id DCC728FC20; Wed, 29 Aug 2012 12:33:00 +0000 (UTC) Received: by wicr5 with SMTP id r5so4683756wic.13 for ; Wed, 29 Aug 2012 05:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+N5KdQJPdBUachnjArYmyRVUm3nXLTqUbRqiqAmzkuw=; b=MnmhlV1MkSGmIXrEp/m/Oh0wxij8HFXIvYfRI1ui6Wdk5X1kEbrBhk0iiD4vs/YC/Q PBDif8eU0cIPlrTDZZeRQ3I1oEfMWfjsF6CnVQZqpLD5yih87KxqZO8kRCpnkE2S4DRp j2h4UVuiLp9dw0R9PVpx9wA7wGKRJHtowkZTwA35q2fpF0KxePp/Rn+cG7QIdI0OBzHa QzBXJkVDJRudgh/QTxX5b57N58L46Xaj2hIw1CXYM0yrCfk7PiRMmOeOz7R5QhFzKhQJ T8EfqsiZLBHP31bBKZy68nhTpNMizTOiTwfyJY98S2ielzbzv3Trh32x6on35bHp5x5H D6KA== Received: by 10.217.2.133 with SMTP id p5mr878653wes.143.1346243579421; Wed, 29 Aug 2012 05:32:59 -0700 (PDT) Received: from [10.129.32.13] (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id cl8sm10057353wib.10.2012.08.29.05.32.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Aug 2012 05:32:55 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) Content-Type: text/plain; charset=windows-1252 From: Nikolay Denev In-Reply-To: <503DEC58.1050609@omnilan.de> Date: Wed, 29 Aug 2012 15:31:34 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6F4AAF36-46D6-439A-8122-DD305B77CBB9@gmail.com> References: <503DEC58.1050609@omnilan.de> To: Harald Schmalzbauer X-Mailer: Apple Mail (2.1486) Cc: freebsd-net@freebsd.org, auryn@zirakzigil.org, freebsd-stable@freebsd.org, Pete French Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 12:33:01 -0000 On Aug 29, 2012, at 1:18 PM, Harald Schmalzbauer = wrote: > schrieb Pete French am 29.08.2012 11:38 (localtime): >>> Link aggregation can never work with two separate switches! LACP and >>> static trunking require both sides to bundle the same trunk. which = is >>> impossible for two separate switches. >> These switches had a port where you could connect them together and >> then configure each to know about the other switch, and to do LACP >> across the pair of them. Or at least thats what it looked like it >> was capable of doing, and it appeared to be doing LACP when = configured >> that way and connected to Windows machines, just not FreeBSD ones. = But I'm >=20 > What you desciribe is well known as =84stacking=93 (not to mix with = =84virtual > stacking=93) and sorry that I haven't made clear that in such a case = LACP > (also static trunking of course) works well and is a fantastic way to > gain redundancy. > When you create a physical switch stack, the individual switches are = no > separate switches anymore, but act like one big switch. > With the advantage, that in case of a failure, and a trunk configured > over two different units of the stack, the link remains active. > But like mentioned, these switches are then not considered to be > separate (=84virtual stacking=93 only combine them in management = regards, > _not_ physically, so be carefull when you look for switches with > =84stacking=93 capabilities!). > The disadvantage of the real hardware stackable switch is the price. = The > cheapest way I've found is two DGS-3120 (~700$ each plus 200$ stacking > cable). Ciscos and Junipers and the bigger HPs are all much above = afaik. >=20 > -Harry >=20 Not always. For example Extreme Networks's MLAG allows link aggregation = between two switches, that are not stacked. You just have to create a special vlan between them and = configure them for MLAG. But of course this is proprietary protocol. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 13:01:21 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4728C1065676 for ; Wed, 29 Aug 2012 13:01:21 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail2.icritical.com (mail2.icritical.com [212.57.248.50]) by mx1.freebsd.org (Postfix) with SMTP id 90EA78FC08 for ; Wed, 29 Aug 2012 13:01:19 +0000 (UTC) Received: (qmail 6567 invoked from network); 29 Aug 2012 13:01:19 -0000 Received: from localhost (127.0.0.1) by mail2.icritical.com with SMTP; 29 Aug 2012 13:01:19 -0000 Received: (qmail 6559 invoked by uid 599); 29 Aug 2012 13:01:19 -0000 Received: from unknown (HELO PDC002.icritical.int) (212.57.254.146) by mail2.icritical.com (qpsmtpd/0.28) with ESMTP; Wed, 29 Aug 2012 14:01:19 +0100 Message-ID: <503E129B.7070607@icritical.com> Date: Wed, 29 Aug 2012 14:01:15 +0100 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-TLS-Incoming: YES X-Virus-Scanned: by iCritical at mail2.icritical.com Subject: Userland dtrace broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 13:01:21 -0000 Following http://wiki.freebsd.org/DTrace/userland on 9.1-RC1, the example fails to work as demonstrated: # dtrace -s pid.d -c test dtrace: script 'pid.d' matched 2 probes CPU ID FUNCTION:NAME 1 59284 main:entry dtrace: pid 25479 exited with status 1 # Also, I get hangs when trying to do pretty much anything with the pid:::entry # dtrace -n 'pid$target::malloc:entry' -c 'echo x' dtrace: description 'pid$target::malloc:entry' matched 2 probes xCPU ID FUNCTION:NAME 1 59311 malloc:entry load: 0.43 cmd: dtrace 63737 [running] 8.93r 1.60u 4.19s 35% 25072k load: 0.88 cmd: echo 63738 [running] 45.10r 2.27u 18.75s 47% 1452k load: 1.19 cmd: dtrace 63737 [running] 70.32r 12.14u 33.27s 64% 25072k # procstat -k 63737 63738 PID TID COMM TDNAME KSTACK 63737 101505 dtrace - mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep do_wait __umtx_op_wait_uint_private amd64_syscall Xfast_syscall 63737 111024 dtrace - 63738 101657 echo - mi_switch thread_suspend_switch ptracestop cursig ast doreti_ast I have previously tried using dtrace on 9.0R, but it was insta-panic. Is there anything I may have missed here? make.conf: STRIP= CFLAGS+=-fno-omit-frame-pointer WITH_CTF=1 kernel config: include GENERIC ident DTRACE makeoptions DEBUG="-g" makeoptions WITH_CTF=1 options KDTRACE_FRAME options KDTRACE_HOOKS options DDB_CTF options DDB -- The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 13:13:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB426106566C; Wed, 29 Aug 2012 13:13:08 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 284428FC1B; Wed, 29 Aug 2012 13:13:07 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q7TDD5AX005011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2012 15:13:06 +0200 Received: from portgus.lan (51.Red-79-159-211.staticIP.rima-tde.net [79.159.211.51]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q7TDD2IE017107 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 15:13:04 +0200 Message-ID: <503E152A.30404@entel.upc.edu> Date: Wed, 29 Aug 2012 15:12:10 +0200 From: =?ISO-8859-15?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120806 Thunderbird/14.0 MIME-Version: 1.0 To: John Baldwin References: <503C930C.3010405@entel.upc.edu> <503DE1BC.4050907@entel.upc.edu> <20120829101202.GA74970@server.rulingia.com> <201208290813.55855.jhb@freebsd.org> In-Reply-To: <201208290813.55855.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Wed, 29 Aug 2012 15:13:06 +0200 (CEST) Cc: freebsd-stable@freebsd.org, Peter Jeremy Subject: Re: Problem adding more than 8 network adapters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 13:13:08 -0000 Al 29/08/2012 14:13, En/na John Baldwin ha escrit: > On Wednesday, August 29, 2012 6:12:02 am Peter Jeremy wrote: >> [Moving to -stable and adding jhb@ for his input] >> >> On 2012-Aug-29 11:32:44 +0200, Gustau Pérez i Querol wrote: >>> Al 29/08/2012 11:02, En/na Peter Jeremy ha escrit: >>>> On 2012-Aug-28 11:44:44 +0200, Gustau Pérez i Querol wrote: >>>>> I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm >>>>> facing is that I can't use more than 8 network adapters plugged to the >>>>> virtual machine. >>>> ... >>>>> I don't know if it's a net@ problem or maybe it is a problem with >>>>> the emulated PCI-bridge and then stable@ should be contacted. Also, I'm >>>>> not sure if a real machine would support more than 8 network adapters or >>>>> not. Any hints would be appreciated. >>>> I don't think I've ever used more than 6 physical NICs in a host but don't >>>> know of any reason for >8 to not work. >>>> Can you please post a "pciconf -lv" from FreeBSD and the equivalent >>>> "lspci" from Linux. A FreeBSD verbose boot log might also help. >>> Sure. I'm attaching them to this mail. I hope the mailing list >>> doesn't eat them. If it does, I will post them online and send the URL >>> to the mailing list. >> Ah.. lspci shows the 9th LANCE at 02:00.0. The verbose boot shows >> FreeBSD finds pcib2 (at pci0 device 25.0) but doesn't see anything >> on that bus. ISTR jhb@ will recognize that problem. > Silly firmware, VM, whatever it is. :) It's buggy. > >>> pcib1: at device 24.0 on pci0 >>> pcib1: domain 0 >>> pcib1: secondary bus 1 >>> pcib1: subordinate bus 2 >>> pcib1: no prefetched decode >>> pcib1: Subtractively decoded bridge. >>> pci1: on pcib1 >>> pci1: domain=0, physical bus=1 >>> pcib2: at device 25.0 on pci0 >>> pcib2: domain 0 >>> pcib2: secondary bus 2 >>> pcib2: subordinate bus 3 >>> pcib2: no prefetched decode >>> pcib2: Subtractively decoded bridge. >>> pci2: on pcib2 >>> pci2: domain=0, physical bus=2 > This is indeed the problem. PCI bus 2 is "claimed" by both pcib1 and pcib2 > since the VM author programmed the bridges incorrectly. In this case, the > subordinate bus should be "1" and "2", not "2" and "3". You could add a hack > to pci_pci.c to fix the subordinate bus on these bridges which should probably > fix this. I guess a quirk should be added to pci_pci.c:572? I guess it would be enough to check the chipid and then set the secbus and subbus according to the supbus, am I right? That quirk should be also added to head. But this would be a temporary hack, fortunately this hardware can be fixed (because it's virtual); so I guess the VBox team should be notified about this one. -- --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 13:30:13 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58E1E106564A; Wed, 29 Aug 2012 13:30:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 78F328FC12; Wed, 29 Aug 2012 13:30:12 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA07191; Wed, 29 Aug 2012 16:30:10 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <503E1961.80402@FreeBSD.org> Date: Wed, 29 Aug 2012 16:30:09 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120730 Thunderbird/14.0 MIME-Version: 1.0 To: John Baldwin , gperez@entel.upc.edu References: <503C930C.3010405@entel.upc.edu> <503DE1BC.4050907@entel.upc.edu> <20120829101202.GA74970@server.rulingia.com> <201208290813.55855.jhb@freebsd.org> In-Reply-To: <201208290813.55855.jhb@freebsd.org> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org Subject: Re: Problem adding more than 8 network adapters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 13:30:13 -0000 on 29/08/2012 15:13 John Baldwin said the following: > On Wednesday, August 29, 2012 6:12:02 am Peter Jeremy wrote: >> [Moving to -stable and adding jhb@ for his input] >> >> On 2012-Aug-29 11:32:44 +0200, Gustau Pérez i Querol wrote: [snip] >> Ah.. lspci shows the 9th LANCE at 02:00.0. The verbose boot shows >> FreeBSD finds pcib2 (at pci0 device 25.0) but doesn't see anything >> on that bus. ISTR jhb@ will recognize that problem. > > Silly firmware, VM, whatever it is. :) It's buggy. > >>> pcib1: at device 24.0 on pci0 >>> pcib1: domain 0 >>> pcib1: secondary bus 1 >>> pcib1: subordinate bus 2 >>> pcib1: no prefetched decode >>> pcib1: Subtractively decoded bridge. >>> pci1: on pcib1 >>> pci1: domain=0, physical bus=1 >>> pcib2: at device 25.0 on pci0 >>> pcib2: domain 0 >>> pcib2: secondary bus 2 >>> pcib2: subordinate bus 3 >>> pcib2: no prefetched decode >>> pcib2: Subtractively decoded bridge. >>> pci2: on pcib2 >>> pci2: domain=0, physical bus=2 > > This is indeed the problem. PCI bus 2 is "claimed" by both pcib1 and pcib2 > since the VM author programmed the bridges incorrectly. In this case, the > subordinate bus should be "1" and "2", not "2" and "3". You could add a hack > to pci_pci.c to fix the subordinate bus on these bridges which should probably > fix this. > >>> 00:18.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) >>> Flags: bus master, 66MHz, fast devsel, latency 64 >>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 >>> >>> 00:19.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) >>> Flags: bus master, 66MHz, fast devsel, latency 64 >>> Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 >>> I/O behind bridge: 00001000-00001fff >>> Memory behind bridge: 40000000-400fffff > > Note here in this output (presumably from lspci under Linux?), the > subordinate bus register == secondary bus register for each bridge. > I wonder where the discrepancy could come from. Why would VirtualBox emulate the bridge differently for different OSes? And I do not see any quirks related to bus numbers for this PCI ID in either Linux, FreeBSD or lspci code... I think that output of lspci on FreeBSD could be interesting too (it's available via sysutils/pciutils port). -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 13:55:06 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8526E106564A; Wed, 29 Aug 2012 13:55:06 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id D12A28FC08; Wed, 29 Aug 2012 13:55:05 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q7TDt4JS010062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2012 15:55:04 +0200 Received: from portgus.lan (51.Red-79-159-211.staticIP.rima-tde.net [79.159.211.51]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q7TDt2Cb022974 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 15:55:03 +0200 Message-ID: <503E1F02.6050505@entel.upc.edu> Date: Wed, 29 Aug 2012 15:54:10 +0200 From: =?ISO-8859-15?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120806 Thunderbird/14.0 MIME-Version: 1.0 To: Andriy Gapon References: <503C930C.3010405@entel.upc.edu> <503DE1BC.4050907@entel.upc.edu> <20120829101202.GA74970@server.rulingia.com> <201208290813.55855.jhb@freebsd.org> <503E1961.80402@FreeBSD.org> In-Reply-To: <503E1961.80402@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------070808000009070404080705" X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Wed, 29 Aug 2012 15:55:04 +0200 (CEST) Cc: freebsd-stable@freebsd.org, John Baldwin Subject: Re: Problem adding more than 8 network adapters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 13:55:06 -0000 This is a multi-part message in MIME format. --------------070808000009070404080705 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Al 29/08/2012 15:30, En/na Andriy Gapon ha escrit: > on 29/08/2012 15:13 John Baldwin said the following: >> On Wednesday, August 29, 2012 6:12:02 am Peter Jeremy wrote: >>> [Moving to -stable and adding jhb@ for his input] >>> >>> On 2012-Aug-29 11:32:44 +0200, Gustau Pérez i Querol wrote: > [snip] >>> Ah.. lspci shows the 9th LANCE at 02:00.0. The verbose boot shows >>> FreeBSD finds pcib2 (at pci0 device 25.0) but doesn't see anything >>> on that bus. ISTR jhb@ will recognize that problem. >> Silly firmware, VM, whatever it is. :) It's buggy. >> >>>> pcib1: at device 24.0 on pci0 >>>> pcib1: domain 0 >>>> pcib1: secondary bus 1 >>>> pcib1: subordinate bus 2 >>>> pcib1: no prefetched decode >>>> pcib1: Subtractively decoded bridge. >>>> pci1: on pcib1 >>>> pci1: domain=0, physical bus=1 >>>> pcib2: at device 25.0 on pci0 >>>> pcib2: domain 0 >>>> pcib2: secondary bus 2 >>>> pcib2: subordinate bus 3 >>>> pcib2: no prefetched decode >>>> pcib2: Subtractively decoded bridge. >>>> pci2: on pcib2 >>>> pci2: domain=0, physical bus=2 >> This is indeed the problem. PCI bus 2 is "claimed" by both pcib1 and pcib2 >> since the VM author programmed the bridges incorrectly. In this case, the >> subordinate bus should be "1" and "2", not "2" and "3". You could add a hack >> to pci_pci.c to fix the subordinate bus on these bridges which should probably >> fix this. >> >>>> 00:18.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) >>>> Flags: bus master, 66MHz, fast devsel, latency 64 >>>> Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 >>>> >>>> 00:19.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) >>>> Flags: bus master, 66MHz, fast devsel, latency 64 >>>> Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 >>>> I/O behind bridge: 00001000-00001fff >>>> Memory behind bridge: 40000000-400fffff >> Note here in this output (presumably from lspci under Linux?), the >> subordinate bus register == secondary bus register for each bridge. >> > I wonder where the discrepancy could come from. > Why would VirtualBox emulate the bridge differently for different OSes? > And I do not see any quirks related to bus numbers for this PCI ID in either > Linux, FreeBSD or lspci code... > > I think that output of lspci on FreeBSD could be interesting too (it's available > via sysutils/pciutils port). > The output of lspci gives the same info as pciconf. I'm attaching it however. -- --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona --------------070808000009070404080705 Content-Type: text/plain; charset=UTF-8; name="lspci.freebsd" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="lspci.freebsd" 00:02.0 VGA compatible controller: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter (prog-if 00 [VGA controller]) Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at e0000000 (32-bit, prefetchable) 00:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at d000 Memory at f0000000 (32-bit, non-prefetchable) Memory at f0080000 (32-bit, non-prefetchable) 00:04.0 System peripheral: InnoTek Systemberatung GmbH VirtualBox Guest Service Flags: bus master, fast devsel, latency 0, IRQ 20 I/O ports at d020 Memory at f0400000 (32-bit, non-prefetchable) Memory at f0800000 (32-bit, prefetchable) 00:07.0 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 08) Flags: bus master, medium devsel, latency 0, IRQ 9 00:08.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at d040 Memory at f0804000 (32-bit, non-prefetchable) Memory at f0880000 (32-bit, non-prefetchable) 00:09.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at d060 Memory at f0900000 (32-bit, non-prefetchable) Memory at f0980000 (32-bit, non-prefetchable) 00:0a.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 0, IRQ 18 I/O ports at d080 Memory at f0a00000 (32-bit, non-prefetchable) Memory at f0a80000 (32-bit, non-prefetchable) 00:10.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 0, IRQ 16 I/O ports at d0a0 Memory at f0b00000 (32-bit, non-prefetchable) Memory at f0b80000 (32-bit, non-prefetchable) 00:11.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 0, IRQ 17 I/O ports at d0c0 Memory at f0c00000 (32-bit, non-prefetchable) Memory at f0c80000 (32-bit, non-prefetchable) 00:12.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 0, IRQ 18 I/O ports at d0e0 Memory at f0d00000 (32-bit, non-prefetchable) Memory at f0d80000 (32-bit, non-prefetchable) 00:13.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 10) Subsystem: Advanced Micro Devices [AMD] PCnet - Fast 79C971 Flags: bus master, medium devsel, latency 0, IRQ 19 I/O ports at d100 Memory at f0e00000 (32-bit, non-prefetchable) Memory at f0e80000 (32-bit, non-prefetchable) 00:16.0 SCSI storage controller: LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS Subsystem: LSI Logic / Symbios Logic Device 8000 Flags: bus master, fast devsel, latency 0, IRQ 22 I/O ports at d200 [disabled] Memory at f0f00000 (32-bit, non-prefetchable) Memory at f0f20000 (32-bit, non-prefetchable) Capabilities: [80] MSI: Enable- Count=1/1 Maskable+ 64bit- 00:18.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=01, secondary=01, subordinate=02, sec-latency=0 !!! Unknown I/O range types e0/df !!! Unknown memory range types f100/f0ff 00:19.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) Flags: bus master, 66MHz, fast devsel, latency 0 Bus: primary=02, secondary=02, subordinate=03, sec-latency=0 !!! Unknown I/O range types e0/df !!! Unknown memory range types f100/f0ff 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) Subsystem: Intel Corporation Device 7270 Flags: bus master, medium devsel, latency 0, IRQ 255 00:1f.2 SATA controller: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] (rev 02) (prog-if 01 [AHCI 1.0]) Flags: bus master, fast devsel, latency 0, IRQ 23 I/O ports at e000 I/O ports at e008 I/O ports at e010 I/O ports at e018 I/O ports at e020 Memory at f1000000 (32-bit, non-prefetchable) Capabilities: [80] MSI: Enable- Count=1/1 Maskable+ 64bit- Capabilities: [70] Power Management version 3 Capabilities: [a8] SATA HBA v1.0 00:1f.4 USB controller: Apple Computer Inc. KeyLargo/Intrepid USB (prog-if 10 [OHCI]) Flags: bus master, fast devsel, latency 0, IRQ 23 Memory at f1002000 (32-bit, non-prefetchable) Capabilities: [80] MSI: Enable- Count=1/1 Maskable+ 64bit- --------------070808000009070404080705-- From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 14:16:57 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 68753106566C; Wed, 29 Aug 2012 14:16:57 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 788BC8FC12; Wed, 29 Aug 2012 14:16:56 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA07594; Wed, 29 Aug 2012 17:16:51 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <503E2453.9040407@FreeBSD.org> Date: Wed, 29 Aug 2012 17:16:51 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120730 Thunderbird/14.0 MIME-Version: 1.0 To: =?UTF-8?B?R3VzdGF1IFDDqXJleiBpIFF1ZXJvbA==?= , John Baldwin References: <503C930C.3010405@entel.upc.edu> <503DE1BC.4050907@entel.upc.edu> <20120829101202.GA74970@server.rulingia.com> <201208290813.55855.jhb@freebsd.org> <503E1961.80402@FreeBSD.org> <503E1F02.6050505@entel.upc.edu> In-Reply-To: <503E1F02.6050505@entel.upc.edu> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-stable@FreeBSD.org Subject: Re: Problem adding more than 8 network adapters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 14:16:57 -0000 on 29/08/2012 16:54 Gustau Pérez i Querol said the following: > Al 29/08/2012 15:30, En/na Andriy Gapon ha escrit: >> I wonder where the discrepancy could come from. >> Why would VirtualBox emulate the bridge differently for different OSes? >> And I do not see any quirks related to bus numbers for this PCI ID in either >> Linux, FreeBSD or lspci code... >> >> I think that output of lspci on FreeBSD could be interesting too (it's available >> via sysutils/pciutils port). >> > > The output of lspci gives the same info as pciconf. I'm attaching it however. [snip] > 00:18.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) > Flags: bus master, 66MHz, fast devsel, latency 0 > Bus: primary=01, secondary=01, subordinate=02, sec-latency=0 > !!! Unknown I/O range types e0/df > !!! Unknown memory range types f100/f0ff > > 00:19.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) > Flags: bus master, 66MHz, fast devsel, latency 0 > Bus: primary=02, secondary=02, subordinate=03, sec-latency=0 > !!! Unknown I/O range types e0/df > !!! Unknown memory range types f100/f0ff I think that I was wrong with regard to Linux. I see that it does extensive bridge reconfiguring if it notices any insanity. And I'd say that VirtualBix does create an insane config here. I believe that primary should be 0, secondary should be 1 and 2 respectively (as they are) and subordinate should be equal to secondary. So primary bus numbers and subordinate bus numbers are insane here. I am not sure how much the incorrect bus numbers actually affect FreeBSD PCI-PCI driver as it does not seem to use primary and subordinate numbers for anything important. Memory and I/O misconfiguration are most likely much more important here. In any case, here is a link to the broken VirtualBox code: http://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/Bus/DevPciIch9.cpp See function ich9pciInitBridgeTopology, which sets primary bus and secondary bus to X and subordinate bus to X+1. And here a link to Linux code that re-configures those bus numbers: http://lxr.linux.no/#linux+v3.5.3/drivers/pci/probe.c#L663 I bet that was "bus configuration invalid, reconfiguring" message during Linux boot. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 15:14:08 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97301106566B for ; Wed, 29 Aug 2012 15:14:08 +0000 (UTC) (envelope-from norbert.aschendorff@yahoo.de) Received: from nm38-vm5.bullet.mail.bf1.yahoo.com (nm38-vm5.bullet.mail.bf1.yahoo.com [72.30.239.21]) by mx1.freebsd.org (Postfix) with SMTP id 290C88FC20 for ; Wed, 29 Aug 2012 15:14:07 +0000 (UTC) Received: from [98.139.214.32] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 15:14:01 -0000 Received: from [98.139.213.11] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 15:14:01 -0000 Received: from [127.0.0.1] by smtp111.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 15:14:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1346253241; bh=4JiVXTmyUXNm3aCvjdpeQ6RhlQ9ZHTgT6dRNDoURZwk=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xYLNQrllp23j1Ag2a34uexlLFpeIIFx93+/vewLuEXSt56B6d+K4nz7waVPvPoc6oX+JC1luNpivl/ZmwX8KHEq8X33iEJE6XtQe7UVjnk3ptU2u0sXbI0rHQ4c625hsvcY9o/NAJ1XD85xRu3JIcenCFZca6kF5hm9M8/6I28o= X-Yahoo-Newman-Id: 729643.194.bm@smtp111.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 0fNKkewVM1nIOeWj67oqnE8UuICU6F2fuWSuhWgOgB1KNTL ZreDA4uCpDY3Zo4ah6qoEpLh4KdLJ8URiZkswXp8ldFowOtYUqZy_23tfDJc 5k3nVReXTyMiXqYkPOQlmH2P_Yk5Un83ErgcX.tQ9tsMUYd66mMciclswCa2 ISXaajbqNMgexqdOTiObxj432kgsvU2P7VI7QsKkxn_EOwd8p1oHLfVGOFnW bdflbhRmkbfuS1ohSAC3m9VzYiLegH0G4XMYAar8_DXBfC3pbtlrzubaLWzE LvMCl0mCknXyoOy714g9TQkHo0bny.B7quSeWtFkNJgkMcCp6Zzp0Z7nHFbr kiTqkZ3J72.GWB3wfiPEbGlnnwO2nlbQxgDi1IFNvG3nIfS0uBIHB5z7133W 8EFZYEpu4QI8C4cSSkmfOtsb0jdvCCFRpOXNWPYqmLpJuOwXX X-Yahoo-SMTP: d20YFqmswBAWc4wd23BcX3DKFU.SSFWadKORXj_BQPQ- Received: from vostro-linux.goebo.site (norbert.aschendorff@85.216.84.153 with plain) by smtp111.mail.bf1.yahoo.com with SMTP; 29 Aug 2012 08:14:01 -0700 PDT Message-ID: <503E31B7.2090401@yahoo.de> Date: Wed, 29 Aug 2012 17:13:59 +0200 From: Norbert Aschendorff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120418 Icedove/11.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <503CE60F.8040007@yahoo.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: IPv4 vs. IPv6 Ethernet Performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:14:08 -0000 That's a bit difficult because I own only one FreeBSD machine - to provide a result FreeBSD->FreeBSD I'd have to set up a completely new system. On the other side, I could try it using the Live system. I'll try it and tell you when I have results. Norbert From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 15:21:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08528106566B; Wed, 29 Aug 2012 15:21:27 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 796098FC17; Wed, 29 Aug 2012 15:21:25 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q7TFLOUO021152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2012 17:21:24 +0200 Received: from portgus.lan (51.Red-79-159-211.staticIP.rima-tde.net [79.159.211.51]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q7TFLMw8003510 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 17:21:23 +0200 Message-ID: <503E333E.4090703@entel.upc.edu> Date: Wed, 29 Aug 2012 17:20:30 +0200 From: =?ISO-8859-15?Q?Gustau_P=E9rez_i_Querol?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120806 Thunderbird/14.0 MIME-Version: 1.0 To: John Baldwin References: <503C930C.3010405@entel.upc.edu> <503DE1BC.4050907@entel.upc.edu> <20120829101202.GA74970@server.rulingia.com> <201208290813.55855.jhb@freebsd.org> In-Reply-To: <201208290813.55855.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Wed, 29 Aug 2012 17:21:24 +0200 (CEST) Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: Problem adding more than 8 network adapters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:21:27 -0000 Al 29/08/2012 14:13, En/na John Baldwin ha escrit: > On Wednesday, August 29, 2012 6:12:02 am Peter Jeremy wrote: >> [Moving to -stable and adding jhb@ for his input] >> >> On 2012-Aug-29 11:32:44 +0200, Gustau Pérez i Querol wrote: >>> Al 29/08/2012 11:02, En/na Peter Jeremy ha escrit: >>>> On 2012-Aug-28 11:44:44 +0200, Gustau Pérez i Querol wrote: >>>>> I'm running FreeBSD 9.1 RC1/AMD64 with VirtualBox. The problem I'm >>>>> facing is that I can't use more than 8 network adapters plugged to the >>>>> virtual machine. >>>> ... >>>>> I don't know if it's a net@ problem or maybe it is a problem with >>>>> the emulated PCI-bridge and then stable@ should be contacted. Also, I'm >>>>> not sure if a real machine would support more than 8 network adapters or >>>>> not. Any hints would be appreciated. >>>> I don't think I've ever used more than 6 physical NICs in a host but don't >>>> know of any reason for >8 to not work. >>>> Can you please post a "pciconf -lv" from FreeBSD and the equivalent >>>> "lspci" from Linux. A FreeBSD verbose boot log might also help. >>> Sure. I'm attaching them to this mail. I hope the mailing list >>> doesn't eat them. If it does, I will post them online and send the URL >>> to the mailing list. >> Ah.. lspci shows the 9th LANCE at 02:00.0. The verbose boot shows >> FreeBSD finds pcib2 (at pci0 device 25.0) but doesn't see anything >> on that bus. ISTR jhb@ will recognize that problem. > Silly firmware, VM, whatever it is. :) It's buggy. > >>> pcib1: at device 24.0 on pci0 >>> pcib1: domain 0 >>> pcib1: secondary bus 1 >>> pcib1: subordinate bus 2 >>> pcib1: no prefetched decode >>> pcib1: Subtractively decoded bridge. >>> pci1: on pcib1 >>> pci1: domain=0, physical bus=1 >>> pcib2: at device 25.0 on pci0 >>> pcib2: domain 0 >>> pcib2: secondary bus 2 >>> pcib2: subordinate bus 3 >>> pcib2: no prefetched decode >>> pcib2: Subtractively decoded bridge. >>> pci2: on pcib2 >>> pci2: domain=0, physical bus=2 > This is indeed the problem. PCI bus 2 is "claimed" by both pcib1 and pcib2 > since the VM author programmed the bridges incorrectly. In this case, the > subordinate bus should be "1" and "2", not "2" and "3". You could add a hack > to pci_pci.c to fix the subordinate bus on these bridges which should probably > fix this. > Reading the spec and according to the output of dmesg.verbose I do agree with your diagnosis. Both PCI-Bridges are attached to upstream PCI bus 0. And this the subordinate bus can't be bigger than the downstream bus those bridges connect to. So the subordinate buses have to be "1" and "2". I'll try to hack vbox (thanks to Andriy) code to map the subordinate bridges as they should. Thanks for the hint! Gustau -- --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 16:37:13 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0A58106564A; Wed, 29 Aug 2012 16:37:13 +0000 (UTC) (envelope-from gperez@entel.upc.edu) Received: from violet.upc.es (violet.upc.es [147.83.2.51]) by mx1.freebsd.org (Postfix) with ESMTP id 528EB8FC21; Wed, 29 Aug 2012 16:37:12 +0000 (UTC) Received: from ackerman2.upc.es (ackerman2.upc.es [147.83.2.244]) by violet.upc.es (8.14.1/8.13.1) with ESMTP id q7TGbBhL030278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Aug 2012 18:37:11 +0200 Received: from portgus.lan (51.Red-79-159-211.staticIP.rima-tde.net [79.159.211.51]) (authenticated bits=0) by ackerman2.upc.es (8.14.4/8.14.4) with ESMTP id q7TGb9Pd017416 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 29 Aug 2012 18:37:10 +0200 Message-ID: <503E4501.6070607@entel.upc.edu> Date: Wed, 29 Aug 2012 18:36:17 +0200 From: =?UTF-8?B?R3VzdGF1IFDDqXJleiBpIFF1ZXJvbA==?= User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120806 Thunderbird/14.0 MIME-Version: 1.0 To: Andriy Gapon References: <503C930C.3010405@entel.upc.edu> <503DE1BC.4050907@entel.upc.edu> <20120829101202.GA74970@server.rulingia.com> <201208290813.55855.jhb@freebsd.org> <503E1961.80402@FreeBSD.org> <503E1F02.6050505@entel.upc.edu> <503E2453.9040407@FreeBSD.org> In-Reply-To: <503E2453.9040407@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.70 on 147.83.2.244 X-Mail-Scanned: Criba 2.0 + Clamd X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (violet.upc.es [147.83.2.51]); Wed, 29 Aug 2012 18:37:11 +0200 (CEST) Cc: freebsd-stable@freebsd.org Subject: Re: Problem adding more than 8 network adapters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 16:37:14 -0000 Al 29/08/2012 16:16, En/na Andriy Gapon ha escrit: > on 29/08/2012 16:54 Gustau Pérez i Querol said the following: >> Al 29/08/2012 15:30, En/na Andriy Gapon ha escrit: >>> I wonder where the discrepancy could come from. >>> Why would VirtualBox emulate the bridge differently for different OSes? >>> And I do not see any quirks related to bus numbers for this PCI ID in either >>> Linux, FreeBSD or lspci code... >>> >>> I think that output of lspci on FreeBSD could be interesting too (it's available >>> via sysutils/pciutils port). >>> >> The output of lspci gives the same info as pciconf. I'm attaching it however. > [snip] >> 00:18.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) >> Flags: bus master, 66MHz, fast devsel, latency 0 >> Bus: primary=01, secondary=01, subordinate=02, sec-latency=0 >> !!! Unknown I/O range types e0/df >> !!! Unknown memory range types f100/f0ff >> >> 00:19.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) (prog-if 01 [Subtractive decode]) >> Flags: bus master, 66MHz, fast devsel, latency 0 >> Bus: primary=02, secondary=02, subordinate=03, sec-latency=0 >> !!! Unknown I/O range types e0/df >> !!! Unknown memory range types f100/f0ff > I think that I was wrong with regard to Linux. I see that it does extensive > bridge reconfiguring if it notices any insanity. And I'd say that VirtualBix does > create an insane config here. > I believe that primary should be 0, secondary should be 1 and 2 respectively (as > they are) and subordinate should be equal to secondary. So primary bus numbers > and subordinate bus numbers are insane here. > I am not sure how much the incorrect bus numbers actually affect FreeBSD PCI-PCI > driver as it does not seem to use primary and subordinate numbers for anything > important. > > Memory and I/O misconfiguration are most likely much more important here. > > In any case, here is a link to the broken VirtualBox code: > http://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/Bus/DevPciIch9.cpp > See function ich9pciInitBridgeTopology, which sets primary bus and secondary bus > to X and subordinate bus to X+1. > > And here a link to Linux code that re-configures those bus numbers: > http://lxr.linux.no/#linux+v3.5.3/drivers/pci/probe.c#L663 > > I bet that was "bus configuration invalid, reconfiguring" message during Linux boot. I did not see that message. Anyhow I found how to fix VBox to work as it should. I think I'm closing this thread and move it to @emulation. Gustau -- --------------------------------------------------------------------------- Prou top-posting : http://ca.wikipedia.org/wiki/Top-posting Stop top-posting : http://en.wikipedia.org/wiki/Posting_style O O O Gustau Pérez i Querol O O O Departament d'Enginyeria Telemàtica O O O Universitat Politècnica de Catalunya Edifici C3 - Despatx S101-B UPC Campus Nord UPC C/ Jordi Girona, 1-3 08034 - Barcelona From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 17:02:40 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 67677106564A for ; Wed, 29 Aug 2012 17:02:40 +0000 (UTC) (envelope-from matt@xtaz.co.uk) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) by mx1.freebsd.org (Postfix) with ESMTP id 161278FC1C for ; Wed, 29 Aug 2012 17:02:40 +0000 (UTC) Received: from mail.xtaz.co.uk (tao.xtaz.co.uk [IPv6:2a01:348:294::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.xtaz.co.uk (Postfix) with ESMTPS id DF509FFF2AC; Wed, 29 Aug 2012 18:02:37 +0100 (BST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 29 Aug 2012 18:02:37 +0100 From: Matt Smith To: Warren Block In-Reply-To: <50385abc5b84946693ca34bced9d0537@xtaz.co.uk> References: <2d4dfcb2637f4d0e9671899538b603d9@xtaz.co.uk> <67DFAA78-A9A2-49F9-9C29-CA5653ECE3C0@lassitu.de> <20120827172650.7e6a7685@AMD620.ovitrap.com> <78f8335e54e04f158609f0382afb8d4d@xtaz.co.uk> <79cd5f15b21566846e5ef3579f67668b@xtaz.co.uk> <50385abc5b84946693ca34bced9d0537@xtaz.co.uk> Message-ID: <7240a406195cec3b7bf5008feda90ad1@xtaz.co.uk> X-Sender: matt@xtaz.co.uk User-Agent: Roundcube Webmail/0.8.1 Cc: Erich Dollansky , freebsd-stable@freebsd.org, Stefan Bethke Subject: Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 17:02:40 -0000 On 2012-08-28 22:51, Matt Smith wrote: > On 2012-08-27 21:35, Warren Block wrote: >> On Mon, 27 Aug 2012, Matt Smith wrote: >>> Thank you for your help anyway, and your wonkity site, which I also >>> once used for converting my procmail to maildrop. And thanks also to >>> Erich and Stefan for your help. When I get some spare time I'll redo >>> the filesystem and hope that it works. >> >> Please post a followup after that. > > Here is the followup! I have just rebuilt the server from scratch > using a 9.1-RC1 amd64 memstick image. Used the GPT labels directly in > the fstab and ignored glabel. And guess what? It works fine as you > probably expected. So it was definitely user error and the glabel > broke it. At least I've learnt a lot more about partitioning and > filesystems than I knew before anyway! > > So once again, thank you for all your help. There is an open PR for > this that I raised which is amd64/170646 , I don't think there is any > way for me to close this myself is there? If somebody reads this who > has the rights to do so then please close it with "user is an idiot" > :) > > Matt. Hi again. Seems it was not actually that simple after all. Yesterday I had tested rebooting the server after just the base O/S had been installed and it was working fine so I assumed that was it. Today I have reinstalled all my ports and then decided to do one last reboot to make sure everything came up properly. And guess what? The same error happened again! I then tracked it down. It seems to happen when the mail/postgrey port is started. If I comment that out of rc.conf and reboot and let it mark the filesystem clean then I can happily reboot with no issues again. If I remove the comment and start it up then I get the same issue on the next reboot. So there is something strange happening between the mail/postgrey port and 9.1-RC1 amd64. As greylisting isn't completely important I can leave this disabled for now but I would like to still resolve this issue so that I can use it again, unless there is alternative greylisting software that I could use with postfix. From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 18:14:48 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3399106566B for ; Wed, 29 Aug 2012 18:14:48 +0000 (UTC) (envelope-from norbert.aschendorff@yahoo.de) Received: from nm13-vm0.bullet.mail.bf1.yahoo.com (nm13-vm0.bullet.mail.bf1.yahoo.com [98.139.213.79]) by mx1.freebsd.org (Postfix) with SMTP id 2A8E58FC1C for ; Wed, 29 Aug 2012 18:14:47 +0000 (UTC) Received: from [98.139.215.140] by nm13.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 18:14:47 -0000 Received: from [98.139.211.162] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 18:14:47 -0000 Received: from [127.0.0.1] by smtp219.mail.bf1.yahoo.com with NNFMP; 29 Aug 2012 18:14:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1346264087; bh=wcFZy5gseTJBR4ha7mp7kizpMr0IHVFnPtYfECgGaqI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=3HaY1nLnEGC+1rroATqzaz8D0N5VamIGFeGcX9rDjqMqs21Po9mCaW2ObD6bwkopcjYu2MoLjnVTs++By7C1ucLZF/wUJZLKj2g0aPwq0pvhcEgD/f4L9/esJotCJXIQLyYCOHNNuyz8gf8xfPJOcCkQkUZ0o1+2NhS4El03OIA= X-Yahoo-Newman-Id: 177603.30163.bm@smtp219.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: D0hitRYVM1kSbY00xl_IfGZSNGPV_qUp0N6Oil..q5BN13e xVCCTdpCpmXgUqaVifKrdq8fmmdPlghBKAmyvIYu9pGo.bF3ex5xHGAp2lHS 3qLY7LiiSSCN.Yhn8uy2i5tGNmRClvUe_1WJ2Q4paQMYrMTx4fHbKDvJIZK. qHWtM35_6VRAlnrVRb_KlmBJwBqOkZARtm70T_w.B9U9jqgWRLHw8kEW3YTF tm9lnA5sycbqzozJd0b6xUolcn_08SgDzJo8z3QBh0nDRRZc4udmVV1qvXfO fl2KgYTcDxH7h2MKHyvrP.5nHX7ql64GA3fXB8qLbCc1K3N0F8_.6sWDr9pT 92A6XYPHL6FwJA8Oyvge1ssFRHctc.enKHQAMQ0ujNw_f8q72Lkqn.KrwA_A a7lI7iBMk6LCKzh4R5wtRBjavxUp7wbPD94EOktlra38tOu8- X-Yahoo-SMTP: d20YFqmswBAWc4wd23BcX3DKFU.SSFWadKORXj_BQPQ- Received: from vostro-linux.goebo.site (norbert.aschendorff@85.216.84.153 with plain) by smtp219.mail.bf1.yahoo.com with SMTP; 29 Aug 2012 11:14:47 -0700 PDT Message-ID: <503E5C14.9090001@yahoo.de> Date: Wed, 29 Aug 2012 20:14:44 +0200 From: Norbert Aschendorff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120418 Icedove/11.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <503CE60F.8040007@yahoo.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: IPv4 vs. IPv6 Ethernet Performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 18:14:48 -0000 So, I got the results using the Live system. Machine [1] is an older Thinkpad T61 (running the Live system), Machine [2] the well-known "FreeBSD" machine from the previous benchmark. Both machines run FreeBSD 9.1-RC1 GENERIC. {Values in MBit/s} Configuration IPv6 IPv4 --------------------------------------- [1] -> [2] 450 600 [2] -> [1] 401 855 This confirms the FreeBSD IPv6 receive rate measured with Linux as sender (iperf client). Norbert From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 19:01:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8266D106564A for ; Wed, 29 Aug 2012 19:01:25 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 3AD3E8FC08 for ; Wed, 29 Aug 2012 19:01:25 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T6nW1-00041h-PI for freebsd-stable@freebsd.org; Wed, 29 Aug 2012 21:01:26 +0200 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Aug 2012 21:01:25 +0200 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Aug 2012 21:01:25 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Date: Wed, 29 Aug 2012 19:01:13 +0000 (UTC) Lines: 17 Message-ID: References: <503CE60F.8040007@yahoo.de> <503E5C14.9090001@yahoo.de> 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: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20100101 Firefox/14.0.1) Subject: Re: IPv4 vs. IPv6 Ethernet Performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 19:01:25 -0000 Norbert Aschendorff yahoo.de> writes: > ... > {Values in MBit/s} > > Configuration IPv6 IPv4 > --------------------------------------- > [1] -> [2] 450 600 > [2] -> [1] 401 855 > ... Well done. Thanks. jb From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 19:31:26 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5931B1065676 for ; Wed, 29 Aug 2012 19:31:26 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 2BFC08FC08 for ; Wed, 29 Aug 2012 19:31:25 +0000 (UTC) Received: from www.dweimer.net (webmail.dweimer.net [192.168.5.1]) by webmail.dweimer.net (8.14.5/8.14.5) with ESMTP id q7TJVIZR071888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Aug 2012 14:31:19 -0500 (CDT) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 29 Aug 2012 14:31:18 -0500 From: dweimer To: Kevin Oberman Organization: dweimer.net Mail-Reply-To: In-Reply-To: References: <9fa99b69aab3afdd72f5776406eb1b65@dweimer.net> Message-ID: X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/0.8.0 Cc: FreeBSD Stable Subject: Re: cdrtools port installation failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dweimer@dweimer.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 19:31:26 -0000 On 2012-08-28 15:38, Kevin Oberman wrote: > On Tue, Aug 28, 2012 at 8:46 AM, dweimer wrote: >> Anyone else not able to get cdrtools to install on a Stable System? >> >> I have just recently synced my source and rebuilt world, and kernel, >> then >> installed. Now while trying to install the livecd port, the >> cdrtools >> dependency is failing to install. >> >> The port compiles fine (at least it doesn't stop reporting an >> error), but >> dies on the installation portion reporting a missing file. >> >> install: >> >> /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav: >> No such file or directory *** [do-install] Error code 71 >> >> There is a cdda2wav.d and cdda2wav.o file in the directory its >> searching, >> however when I run this on my FreeBSD 9.0-RELEASE-p4 system, there >> is also a >> cdda2wav file with no extension. >> >> ls >> >> /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/ >> Dnull >> Inull >> aifc.d >> aifc.o >> aiff.d >> aiff.o >> base64.d >> base64.o >> cd_misc.d >> cd_misc.o >> cdda2wav.d >> cdda2wav.o >> config.cache >> config.log >> config.status >> interface.d >> interface.o >> ioctl.d >> ioctl.o >> lconfig.h >> local.cnf >> parse.d >> parse.o >> raw.d >> raw.o >> resample.d >> resample.o >> ringbuff.d >> ringbuff.o >> scsi_cdr.d >> scsi_cdr.o >> scsi_cmds.d >> scsi_cmds.o >> scsi_scan.d >> scsi_scan.o >> semshm.d >> semshm.o >> setuid.d >> setuid.o >> sndconfig.d >> sndconfig.o >> sun.d >> sun.o >> toc.d >> toc.o >> wav.d >> wav.o >> >> >> -- >> Thanks, >> Dean E. Weimer >> http://www.dweimer.net/ > > How odd! I can't replicate this at all. > > I just made cdrtools-3.00_2 and I have: > cc -o OBJ/amd64-freebsd-cc/cdda2wav OBJ/amd64-freebsd-cc/cdda2wav.o > OBJ/amd64-freebsd-cc/interface.o OBJ/amd64-freebsd-cc/semshm.o > OBJ/amd64-freebsd-cc/resample.o OBJ/amd64-freebsd-cc/scsi_scan.o > OBJ/amd64-freebsd-cc/toc.o OBJ/amd64-freebsd-cc/wav.o > OBJ/amd64-freebsd-cc/sun.o OBJ/amd64-freebsd-cc/raw.o > OBJ/amd64-freebsd-cc/setuid.o OBJ/amd64-freebsd-cc/ringbuff.o > OBJ/amd64-freebsd-cc/sndconfig.o OBJ/amd64-freebsd-cc/scsi_cmds.o > OBJ/amd64-freebsd-cc/aiff.o OBJ/amd64-freebsd-cc/aifc.o > OBJ/amd64-freebsd-cc/scsi_cdr.o OBJ/amd64-freebsd-cc/cd_misc.o > OBJ/amd64-freebsd-cc/ioctl.o OBJ/amd64-freebsd-cc/base64.o > OBJ/amd64-freebsd-cc/parse.o -L../libs/amd64-freebsd-cc > -L../libs/amd64-freebsd-cc -L/usr/local/lib -L/usr/local/lib > -lscgcmd -lrscg -lscg -lparanoia -lcdrdeflt -ldeflt -lmdigest > -lschily -lcam > > And, as I expected, I find it: > # find work/cdrtools-3.00/ -name cdda2wav > work/cdrtools-3.00/cdda2wav > work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav > > Look trough the log of your make and see if anything "odd" happened > in > that step. It should be at the end of the section : > ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc/Inull" > ==> CONFIGURING LOCAL RULES "OBJ/amd64-freebsd-cc/local.cnf" > and just before: > ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdrecord" > > This was on a stable system updated on Aug. 16. Finally had a chance to get back to this today, I haven't updated the ports tree or source since the last run. Built again same problem, After looking, I did have everything set to build with clang, and changed it to use gcc, then bingo it installed. However the FreeBSD 9.0-RELEASE-p4 system did successfully use clang, both systems have world and kernel built with clang. Will run it again with clang and capture the output of the make operation. Contents of /etc/make.conf, includes using gcc for cdrtools: # Use OpenSSL from ports instead of base WITH_OPENSSL_PORT=yes # Avoid Building Ports Against X WITHOUT_X11=yes # Performance related options CFLAGS?= -O CLFAGS+= -pipe # Ignore Warnings NO_WERROR= WERROR= # ports which will only build with the base system GNU compiler (4.2) # the "make index" target also needs this .if target(index) | \ ${.CURDIR:M*/lang/gcc*} | \ ${.CURDIR:M*/lang/ruby*} | \ ${.CURDIR:M*/devel/binutils*} | \ ${.CURDIR:M*/sysutils/cdrtools*} | \ ${.CURDIR:M*/www/squid*} USE_GCC?=4.2 .endif # use clang unless gcc is explicitly required .if !defined(USE_GCC) .if !defined(CC) || ${CC} == "cc" CC=clang .endif .if !defined(CXX) || ${CXX} == "c++" CXX=clang++ .endif .if !defined(CPP) || ${CPP} == "cpp" CPP=clang-cpp .endif .endif # added by use.perl 2012-08-28 04:04:28 PERL_VERSION=5.16.0 -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 19:40:32 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A28A81065675; Wed, 29 Aug 2012 19:40:32 +0000 (UTC) (envelope-from ayuzhaninov@openstat.ru) Received: from mail.openstat.ru (mail.openstat.ru [193.169.234.252]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1208FC0A; Wed, 29 Aug 2012 19:40:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=openstat.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=eC7WIO5ozJ9aWy1FAKwbmIxZXNb4Qqy9nVZv1tFFw/k=; b=ilhfQ/XWSMtKq/u81UK/ZVlUCE0ABcywIRPt3YPBEokFNP+pjKtDJDhLwTKNaHyqxo5biiyj+PuGo4eINVNAR1mkLQ+0ofavWHz3qpOM2PeN5AnoIKAhaZ3zETiRB6uMPZDoGQ8l8cHO6/Y3Jz0YAfDIq/XacWBobxEd/DYIav0=; Received: from [178.214.34.160] (helo=[192.168.1.100]) by mail.openstat.ru with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80 (FreeBSD)) (envelope-from ) id 1T6o0I-000MzZ-0k; Wed, 29 Aug 2012 23:32:42 +0400 Message-ID: <503E6E59.2000600@openstat.ru> Date: Wed, 29 Aug 2012 23:32:41 +0400 From: Anton Yuzhanionov User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: John Baldwin References: <503DE2AB.6030702@citrin.ru> <201208290825.44198.jhb@freebsd.org> In-Reply-To: <201208290825.44198.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: ayuzhaninov X-Rspam-Status: skip_authenticated Cc: freebsd-stable@freebsd.org Subject: Re: Problem with IPMI KCS driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 19:40:32 -0000 On 29.08.2012 16:25, John Baldwin wrote: > Hmm. Can you try this: > > Index: kern/kern_clock.c > =================================================================== > --- kern/kern_clock.c (revision 239819) > +++ kern/kern_clock.c (working copy) > @@ -382,7 +382,7 @@ > int stathz; > int profhz; > int profprocs; > -int ticks; > +volatile int ticks; > int psratio; > With this patch if_cdce.c can't be compiled: /usr/src/sys/modules/usb/cdce/../../../dev/usb/net/if_cdce.c: In function 'cdce_attach': /usr/src/sys/modules/usb/cdce/../../../dev/usb/net/if_cdce.c:616: warning: passing argument 2 of 'memcpy' discards qualifiers from pointer target type *** Error code 1 memcpy(&sc->sc_ue.ue_eaddr[1], &ticks, sizeof(uint32_t)); As I understand, memcpy() don't accept pointers to volatile objects. May be some other source can be used for generated MAC address. I have installed patched kernel (without cdce) and need some time to check if the problem with IPMI KCS is reproduced. -- Anton Yuzhaninov From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 20:17:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 312A41065674 for ; Wed, 29 Aug 2012 20:17:44 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id B3D878FC0A for ; Wed, 29 Aug 2012 20:17:43 +0000 (UTC) Received: by wicr5 with SMTP id r5so5194586wic.13 for ; Wed, 29 Aug 2012 13:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=S7rOW0ZFrBZVP+OkFqjsOZPONeh6NPOR/FqkLoUU7d0=; b=HSYomnjVwH0lldbVxbcXJQqkYfGnbk2rKx7SX3zd0KtC+neWLCEgOxtfMHHjEO9/TS lpUZW79Ekj07bq3C9rex99VBq6FMgG//IbSIsjNDTzy3FD5SwSyJdIolGL0fwRnI2q6B zQHryJ3hPukIrR659dr2HsulryLVfHCZIKrWzg9rOQhejFEWgfZdn8B/9qCy/0+hmAzB 52pug3Pw4OeklVHncijiuyUBZ0ghxXpmRIVjxJFTCRxg2cS0E6HojCAzyautDrU627CC PWVXaWZChYnneFPBQaw8rQMQzspsPtxFNCez4e0dyvazZkPvXvEW1l0RvcEd91aERKRF 1d2Q== Received: by 10.180.106.97 with SMTP id gt1mr42672501wib.5.1346271457481; Wed, 29 Aug 2012 13:17:37 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.223.153.200 with HTTP; Wed, 29 Aug 2012 13:17:17 -0700 (PDT) In-Reply-To: <503E5C14.9090001@yahoo.de> References: <503CE60F.8040007@yahoo.de> <503E5C14.9090001@yahoo.de> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Wed, 29 Aug 2012 22:17:17 +0200 X-Google-Sender-Auth: dhi_wOXDV1_BoRIvc-m984FRdps Message-ID: To: Norbert Aschendorff Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: IPv4 vs. IPv6 Ethernet Performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 20:17:44 -0000 On Wed, Aug 29, 2012 at 8:14 PM, Norbert Aschendorff wrote: > This confirms the FreeBSD IPv6 receive rate measured with Linux as > sender (iperf client). > Hi, Last time I've played with IPerf and IPV6 between my FreeBSD machines, he didn't take care of the IPv6 Ethernet MTU (1480 and not 1500), neither the IPv6 size header and send 1470 bytes datagrams in place of 1430 bytes datagrams: All my IPerf generated IPv6 packets were fragmented, and this fragmentation reduce a lot's the throughput in IPv6 mode. Can you check if this problem was fixed ? Regards, Olivier From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 20:22:59 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA4B41065673; Wed, 29 Aug 2012 20:22:59 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.giulioferro.ch (mx1.giulioferro.ch [217.150.252.208]) by mx1.freebsd.org (Postfix) with ESMTP id 36D208FC18; Wed, 29 Aug 2012 20:22:59 +0000 (UTC) Received: from mailscan.giulioferro.ch (unknown [192.168.115.2]) by mx1.giulioferro.ch (Postfix) with ESMTP id 1F817733E4; Wed, 29 Aug 2012 22:22:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at example.com Received: from mx1.giulioferro.ch ([192.168.114.4]) by mailscan.giulioferro.ch (mailscan.giulioferro.ch [192.168.115.2]) (amavisd-new, port 10024) with ESMTP id m109XxCBAXxQ; Wed, 29 Aug 2012 22:22:49 +0200 (CEST) Received: from mail.zirakzigil.org (net-93-70-48-129.cust.dsl.vodafone.it [93.70.48.129]) by mx1.giulioferro.ch (Postfix) with ESMTP id 646DC733CE; Wed, 29 Aug 2012 22:22:49 +0200 (CEST) Received: from ext.zirakzigil.org (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id AA6B319B890; Wed, 29 Aug 2012 10:37:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by ext.zirakzigil.org (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id jjIuchcbDYlO; Wed, 29 Aug 2012 10:37:27 +0200 (CEST) Received: from [192.168.231.11] (ext [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 9609519B88A; Wed, 29 Aug 2012 10:37:26 +0200 (CEST) Message-ID: <503E7A16.6030600@zirakzigil.org> Date: Wed, 29 Aug 2012 22:22:46 +0200 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Damien Fleuriot References: <5033FB17.7020600@zirakzigil.org> <503884A0.50708@zirakzigil.org> <503BC8F5.3040208@zirakzigil.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "freebsd-stable@freebsd.org" Subject: Re: Problem with link aggregation + sshd X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 20:23:00 -0000 On 08/28/2012 11:12 AM, Damien Fleuriot wrote: > Hi Giulio, > > > > Just to clear things up: > igb0: 192.168.9.60/24 > lagg0: 192.168.12.21/24 > Yes. Actually I notice now that the lagg0 address is different from what I wrote below in my rc.conf (192.168.12.7). I've just made many test with different configuration, but no matter, it just doesn't work... > > What's the IP of the host you're trying ssh connections from ? I'm just trying to connect to and from management interface igb0 (192.168.9.60). From external pc I do : ssh myuser@192.168.9.60 From that server I do : ssh myuser@pcaddress Just to be more precise, the consequences are: 1) daemon sshd on the server gets stuck and becomes unkillable 2) the first connection may work, but then the program ssh on the server becomes unresponsive and unkillable If I don't create a lagg0 interface and just connect (say) igb1 to the data switch, I've no problem and everything works. Just to answer others' question, I connect igb1, igb2 and igb3 to the same data switch in ports configured for aggregation. I connect igb0 to another management switch (of course not configured for aggregation) > > Also, just in case, did you enable any firewall ? (PF, ipfw) As I already said, no. Nothing is working/active on this server, just sshd. Thank you. > > > > On 27 August 2012 21:22, Giulio Ferro wrote: >> Hi, thanks for the answer >> >> Here is what you asked for: >> >> # ifconfig igb0 >> igb0: flags=8843 metric 0 mtu 1500 >> >> options=4401bb >> ether ... >> inet 192.168.9.60 netmask 0xffffff00 broadcast 192.168.9.255 >> inet6 .... prefixlen 64 scopeid 0x1 >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> >> >> # netstat -rn >> Routing tables >> >> Internet: >> Destination Gateway Flags Refs Use Netif Expire >> default 192.168.9.1 UGS 0 0 igb0 >> 127.0.0.1 link#12 UH 0 0 lo0 >> 192.168.9.0/24 link#1 U 0 14 igb0 >> 192.168.9.60 link#1 UHS 0 0 lo0 >> 192.168.12.0/24 link#13 U 0 109 lagg0 >> 192.168.12.21 link#13 UHS 0 0 lo0 >> >> Internet6: >> Destination Gateway Flags >> Netif Expire >> ::/96 ::1 UGRS lo0 >> ::1 link#12 UH lo0 >> ::ffff:0.0.0.0/96 ::1 UGRS lo0 >> fe80::/10 ::1 UGRS lo0 >> fe80::%igb0/64 link#1 U igb0 >> fe80::ea39:35ff:feb6:a0d4%igb0 link#1 UHS lo0 >> fe80::%igb1/64 link#2 U igb1 >> fe80::ea39:35ff:feb6:a0d5%igb1 link#2 UHS lo0 >> fe80::%igb2/64 link#3 U igb2 >> fe80::ea39:35ff:feb6:a0d6%igb2 link#3 UHS lo0 >> fe80::%igb3/64 link#4 U igb3 >> fe80::ea39:35ff:feb6:a0d7%igb3 link#4 UHS lo0 >> fe80::%lo0/64 link#12 U lo0 >> fe80::1%lo0 link#12 UHS lo0 >> fe80::%lagg0/64 link#13 U lagg0 >> fe80::ea39:35ff:feb6:a0d5%lagg0 link#13 UHS lo0 >> ff01::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 >> ff01::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 >> ff01::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 >> ff01::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 >> ff01::%lo0/32 ::1 U lo0 >> ff01::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U >> lagg0 >> ff02::/16 ::1 UGRS lo0 >> ff02::%igb0/32 fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 >> ff02::%igb1/32 fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 >> ff02::%igb2/32 fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 >> ff02::%igb3/32 fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 >> ff02::%lo0/32 ::1 U lo0 >> ff02::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U >> lagg0 >> >> >> >> # netstat -aln | grep 22 >> tcp4 0 0 *.22 *.* LISTEN >> tcp6 0 0 *.22 *.* LISTEN >> >> Note that I already tried to only listen on igb0 interface (192.168.9.60) in >> sshd_config, but the results are exactly >> the same described below. >> >> >> >> >> >> >> >> On 08/25/2012 01:22 PM, Damien Fleuriot wrote: >>> >>> In the meantime kindly post: >>> >>> >>> Ifconfig for your igb0 >>> Netstat -rn >>> Netstat -aln | grep 22 >>> >>> >>> >>> On 25 Aug 2012, at 13:18, Damien Fleuriot wrote: >>> >>>> I'll get back to you regarding link aggregation when I'm done with >>>> groceries. >>>> >>>> We use it here in production and it works flawlessly. >>>> >>>> >>>> >>>> On 25 Aug 2012, at 09:54, Giulio Ferro wrote: >>>> >>>>> No answer, so it seems that link aggregation doesn't really work in >>>>> freebsd, >>>>> this may help others with the same problem... >>>>> >>>>> I reverted back to one link for management and one for service, and ssh >>>>> works as it should... >>>>> >>>>> >>>>> On 08/21/2012 11:18 PM, Giulio Ferro wrote: >>>>>> >>>>>> Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic >>>>>> (igb) >>>>>> >>>>>> 1 nic is connected standalone to the management switch, the 3 other >>>>>> nics >>>>>> are connected to a switch configured for aggregation. >>>>>> >>>>>> If I configure the first nic (igb0) there is no problem, I can operate >>>>>> as I normally do and sshd functions normally. >>>>>> >>>>>> The problems start when I configure the 3 other nics for aggregation: >>>>>> >>>>>> in /etc/rc.conf >>>>>> ... >>>>>> ifconfig_igb1="up" >>>>>> ifconfig_igb2="up" >>>>>> ifconfig_igb3="up" >>>>>> >>>>>> cloned_interfaces=lagg0 >>>>>> ifconfig_lagg0="laggproto lacp laggport igb1 laggport igb2 laggport >>>>>> igb3 192.168.12.7/24" >>>>>> ... >>>>>> >>>>>> I restart the server and the aggregation seems to work correctly, in >>>>>> fact ifconfig returns the correct lagg0 interface with the aggregated >>>>>> links, the correct protocol (lacp) and the correct ip address and the >>>>>> status is active. I can ping other IPs on the aggregated link. >>>>>> >>>>>> Also the other (standalone) link seems to work correctly. I can ping >>>>>> that address from other machines, and I can ping other IPs from that >>>>>> server. >>>>>> >>>>>> DNS lookups work ok too I can also use telnet to connect to pop3 >>>>>> servers so there seems to be no problem on the network stack. >>>>>> >>>>>> But if I try to connect to the sshd service on that server, it hangs >>>>>> indefinitely. On the server I find two sshd processes: >>>>>> /usr/sbin/sshd >>>>>> /usr/sbin/sshd -R >>>>>> >>>>>> There is no message in the logs. >>>>>> >>>>>> If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays >>>>>> there >>>>>> forever waiting for the pid to die (it never does) >>>>>> >>>>>> Even ssh client doesn't seem to work. In fact, if I try to connect to >>>>>> another server, the ssh client may start to work correctly, then soon >>>>>> or later it just hangs there forever, and I can't kill it with ctrl-c. >>>>>> >>>>>> No firewall is configured, there is nothing else working on this >>>>>> server. >>>>>> >>>>>> Thanks for any suggestions... >>>>>> _______________________________________________ >>>>>> freebsd-stable@freebsd.org mailing list >>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>>> To unsubscribe, send any mail to >>>>>> "freebsd-stable-unsubscribe@freebsd.org" >>>>> >>>>> >>>>> _______________________________________________ >>>>> freebsd-stable@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>>> To unsubscribe, send any mail to >>>>> "freebsd-stable-unsubscribe@freebsd.org" >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 20:59:02 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6A027106566B for ; Wed, 29 Aug 2012 20:59:02 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 1FE6C8FC14 for ; Wed, 29 Aug 2012 20:59:01 +0000 (UTC) Received: from www.dweimer.net (webmail.dweimer.net [192.168.5.1]) by webmail.dweimer.net (8.14.5/8.14.5) with ESMTP id q7TKx0jp075564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 29 Aug 2012 15:59:01 -0500 (CDT) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 29 Aug 2012 15:59:00 -0500 From: dweimer To: Organization: dweimer.net Mail-Reply-To: In-Reply-To: References: <9fa99b69aab3afdd72f5776406eb1b65@dweimer.net> Message-ID: <76d6a3d12030d89690a3b6d28c85f48b@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/0.8.0 Subject: Re: cdrtools port installation failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dweimer@dweimer.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 20:59:02 -0000 On 2012-08-29 14:31, dweimer wrote: > On 2012-08-28 15:38, Kevin Oberman wrote: >> On Tue, Aug 28, 2012 at 8:46 AM, dweimer >> wrote: >>> Anyone else not able to get cdrtools to install on a Stable System? >>> >>> I have just recently synced my source and rebuilt world, and >>> kernel, then >>> installed. Now while trying to install the livecd port, the >>> cdrtools >>> dependency is failing to install. >>> >>> The port compiles fine (at least it doesn't stop reporting an >>> error), but >>> dies on the installation portion reporting a missing file. >>> >>> install: >>> >>> /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav: >>> No such file or directory *** [do-install] Error code 71 >>> >>> There is a cdda2wav.d and cdda2wav.o file in the directory its >>> searching, >>> however when I run this on my FreeBSD 9.0-RELEASE-p4 system, there >>> is also a >>> cdda2wav file with no extension. >>> >>> ls >>> >>> /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/ >>> Dnull >>> Inull >>> aifc.d >>> aifc.o >>> aiff.d >>> aiff.o >>> base64.d >>> base64.o >>> cd_misc.d >>> cd_misc.o >>> cdda2wav.d >>> cdda2wav.o >>> config.cache >>> config.log >>> config.status >>> interface.d >>> interface.o >>> ioctl.d >>> ioctl.o >>> lconfig.h >>> local.cnf >>> parse.d >>> parse.o >>> raw.d >>> raw.o >>> resample.d >>> resample.o >>> ringbuff.d >>> ringbuff.o >>> scsi_cdr.d >>> scsi_cdr.o >>> scsi_cmds.d >>> scsi_cmds.o >>> scsi_scan.d >>> scsi_scan.o >>> semshm.d >>> semshm.o >>> setuid.d >>> setuid.o >>> sndconfig.d >>> sndconfig.o >>> sun.d >>> sun.o >>> toc.d >>> toc.o >>> wav.d >>> wav.o >>> >>> >>> -- >>> Thanks, >>> Dean E. Weimer >>> http://www.dweimer.net/ >> >> How odd! I can't replicate this at all. >> >> I just made cdrtools-3.00_2 and I have: >> cc -o OBJ/amd64-freebsd-cc/cdda2wav OBJ/amd64-freebsd-cc/cdda2wav.o >> OBJ/amd64-freebsd-cc/interface.o OBJ/amd64-freebsd-cc/semshm.o >> OBJ/amd64-freebsd-cc/resample.o OBJ/amd64-freebsd-cc/scsi_scan.o >> OBJ/amd64-freebsd-cc/toc.o OBJ/amd64-freebsd-cc/wav.o >> OBJ/amd64-freebsd-cc/sun.o OBJ/amd64-freebsd-cc/raw.o >> OBJ/amd64-freebsd-cc/setuid.o OBJ/amd64-freebsd-cc/ringbuff.o >> OBJ/amd64-freebsd-cc/sndconfig.o OBJ/amd64-freebsd-cc/scsi_cmds.o >> OBJ/amd64-freebsd-cc/aiff.o OBJ/amd64-freebsd-cc/aifc.o >> OBJ/amd64-freebsd-cc/scsi_cdr.o OBJ/amd64-freebsd-cc/cd_misc.o >> OBJ/amd64-freebsd-cc/ioctl.o OBJ/amd64-freebsd-cc/base64.o >> OBJ/amd64-freebsd-cc/parse.o -L../libs/amd64-freebsd-cc >> -L../libs/amd64-freebsd-cc -L/usr/local/lib -L/usr/local/lib >> -lscgcmd -lrscg -lscg -lparanoia -lcdrdeflt -ldeflt -lmdigest >> -lschily -lcam >> >> And, as I expected, I find it: >> # find work/cdrtools-3.00/ -name cdda2wav >> work/cdrtools-3.00/cdda2wav >> work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav >> >> Look trough the log of your make and see if anything "odd" happened >> in >> that step. It should be at the end of the section : >> ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc/Inull" >> ==> CONFIGURING LOCAL RULES "OBJ/amd64-freebsd-cc/local.cnf" >> and just before: >> ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdrecord" >> >> This was on a stable system updated on Aug. 16. > > Finally had a chance to get back to this today, I haven't updated the > ports tree or source since the last run. Built again same problem, > After looking, I did have everything set to build with clang, and > changed it to use gcc, then bingo it installed. > > However the FreeBSD 9.0-RELEASE-p4 system did successfully use clang, > both systems have world and kernel built with clang. > > Will run it again with clang and capture the output of the make > operation. > > Contents of /etc/make.conf, includes using gcc for cdrtools: > > # Use OpenSSL from ports instead of base > WITH_OPENSSL_PORT=yes > > # Avoid Building Ports Against X > WITHOUT_X11=yes > > # Performance related options > CFLAGS?= -O > CLFAGS+= -pipe > > # Ignore Warnings > NO_WERROR= > WERROR= > > # ports which will only build with the base system GNU compiler (4.2) > # the "make index" target also needs this > .if target(index) | \ > ${.CURDIR:M*/lang/gcc*} | \ > ${.CURDIR:M*/lang/ruby*} | \ > ${.CURDIR:M*/devel/binutils*} | \ > ${.CURDIR:M*/sysutils/cdrtools*} | \ > ${.CURDIR:M*/www/squid*} > USE_GCC?=4.2 > .endif > > # use clang unless gcc is explicitly required > .if !defined(USE_GCC) > .if !defined(CC) || ${CC} == "cc" > CC=clang > .endif > .if !defined(CXX) || ${CXX} == "c++" > CXX=clang++ > .endif > .if !defined(CPP) || ${CPP} == "cpp" > CPP=clang-cpp > .endif > .endif > > # added by use.perl 2012-08-28 04:04:28 > PERL_VERSION=5.16.0 This might, be the source of the problem, full output of make install available here : ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdda2wav" gmake[1]: Entering directory `/usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav' ./RULES/local.cnf:43: OBJ/amd64-freebsd-cc/Inull: No such file or directory ./RULES/local.cnf:44: OBJ/amd64-freebsd-cc/local.cnf: No such file or directory ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc" clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT parse.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/parse.d clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT base64.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/base64.d In file included from base64.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT ioctl.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/ioctl.d In file included from ioctl.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. ==> MAKING SYMLINKS in . ln: ./config.guess: File exists ln: ./config.sub: File exists clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT cd_misc.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/cd_misc.d clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT scsi_cdr.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/scsi_cdr.d clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT aifc.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/aifc.d In file included from aifc.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT aiff.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/aiff.d In file included from aiff.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT scsi_cmds.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/scsi_cmds.d In file included from scsi_cmds.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT sndconfig.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/sndconfig.d In file included from sndconfig.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT ringbuff.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/ringbuff.d In file included from ringbuff.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT setuid.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/setuid.d In file included from setuid.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT raw.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/raw.d In file included from raw.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT sun.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/sun.d In file included from sun.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT wav.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/wav.d In file included from wav.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT toc.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/toc.d In file included from toc.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT scsi_scan.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/scsi_scan.d clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT resample.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/resample.d In file included from resample.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT semshm.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/semshm.d In file included from semshm.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT interface.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/interface.d In file included from interface.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT cdda2wav.c \ | sed -e 's;^\(.*\)\.o[ ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/cdda2wav.d In file included from cdda2wav.c:2: ./config.h:34:10: fatal error: 'lconfig.h' file not found #include "lconfig.h" ^ 1 error generated. ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc/Inull" ==> CONFIGURING LOCAL RULES "OBJ/amd64-freebsd-cc/local.cnf" creating cache ./config.cache checking host system type... amd64-unknown-freebsd9.1 -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 21:12:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FF3D10656D7; Wed, 29 Aug 2012 21:12:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 24D448FC19; Wed, 29 Aug 2012 21:12:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 747FAB987; Wed, 29 Aug 2012 17:12:32 -0400 (EDT) From: John Baldwin To: Andriy Gapon Date: Wed, 29 Aug 2012 13:32:35 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <503C930C.3010405@entel.upc.edu> <503E1F02.6050505@entel.upc.edu> <503E2453.9040407@FreeBSD.org> In-Reply-To: <503E2453.9040407@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201208291332.35888.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 29 Aug 2012 17:12:32 -0400 (EDT) Cc: Gustau =?utf-8?q?P=C3=A9rez_i_Querol?= , freebsd-stable@freebsd.org Subject: Re: Problem adding more than 8 network adapters X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:12:33 -0000 On Wednesday, August 29, 2012 10:16:51 am Andriy Gapon wrote: > on 29/08/2012 16:54 Gustau P=C3=A9rez i Querol said the following: > > Al 29/08/2012 15:30, En/na Andriy Gapon ha escrit: > >> I wonder where the discrepancy could come from. > >> Why would VirtualBox emulate the bridge differently for different OSes? > >> And I do not see any quirks related to bus numbers for this PCI ID in = either > >> Linux, FreeBSD or lspci code... > >> > >> I think that output of lspci on FreeBSD could be interesting too (it's= available > >> via sysutils/pciutils port). > >> > >=20 > > The output of lspci gives the same info as pciconf. I'm attaching it= however. > [snip] > > 00:18.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) = (prog-if 01 [Subtractive decode]) > > Flags: bus master, 66MHz, fast devsel, latency 0 > > Bus: primary=3D01, secondary=3D01, subordinate=3D02, sec-latency=3D0 > > !!! Unknown I/O range types e0/df > > !!! Unknown memory range types f100/f0ff > >=20 > > 00:19.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f2) = (prog-if 01 [Subtractive decode]) > > Flags: bus master, 66MHz, fast devsel, latency 0 > > Bus: primary=3D02, secondary=3D02, subordinate=3D03, sec-latency=3D0 > > !!! Unknown I/O range types e0/df > > !!! Unknown memory range types f100/f0ff >=20 > I think that I was wrong with regard to Linux. I see that it does extens= ive > bridge reconfiguring if it notices any insanity. And I'd say that Virtua= lBix does > create an insane config here. > I believe that primary should be 0, secondary should be 1 and 2 respectiv= ely (as > they are) and subordinate should be equal to secondary. So primary bus n= umbers > and subordinate bus numbers are insane here. > I am not sure how much the incorrect bus numbers actually affect FreeBSD = PCI-PCI > driver as it does not seem to use primary and subordinate numbers for any= thing > important. The problem is that it affects the routing of PCI config requests, so it ne= eds to be correct. Fixing our PCI code to properly renumber buses as needed is= a WIP I have, but it's not ready for testing yet to see if it would help with= this case. =2D-=20 John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 21:12:33 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5294106564A for ; Wed, 29 Aug 2012 21:12:33 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id AB5478FC1D for ; Wed, 29 Aug 2012 21:12:33 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 0D21DB98C; Wed, 29 Aug 2012 17:12:33 -0400 (EDT) From: John Baldwin To: Anton Yuzhanionov Date: Wed, 29 Aug 2012 16:40:01 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: <503DE2AB.6030702@citrin.ru> <201208290825.44198.jhb@freebsd.org> <503E6E59.2000600@openstat.ru> In-Reply-To: <503E6E59.2000600@openstat.ru> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201208291640.01448.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 29 Aug 2012 17:12:33 -0400 (EDT) Cc: freebsd-stable@freebsd.org Subject: Re: Problem with IPMI KCS driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:12:33 -0000 On Wednesday, August 29, 2012 3:32:41 pm Anton Yuzhanionov wrote: > On 29.08.2012 16:25, John Baldwin wrote: > > Hmm. Can you try this: > > > > Index: kern/kern_clock.c > > =================================================================== > > --- kern/kern_clock.c (revision 239819) > > +++ kern/kern_clock.c (working copy) > > @@ -382,7 +382,7 @@ > > int stathz; > > int profhz; > > int profprocs; > > -int ticks; > > +volatile int ticks; > > int psratio; > > > > With this patch if_cdce.c can't be compiled: > > /usr/src/sys/modules/usb/cdce/../../../dev/usb/net/if_cdce.c: In > function 'cdce_attach': > /usr/src/sys/modules/usb/cdce/../../../dev/usb/net/if_cdce.c:616: > warning: passing argument 2 of 'memcpy' discards qualifiers from pointer > target type > *** Error code 1 > > memcpy(&sc->sc_ue.ue_eaddr[1], &ticks, sizeof(uint32_t)); That can just be fixed with a cast. It just wants 4 bytes of some sort. > I have installed patched kernel (without cdce) and need some time to > check if the problem with IPMI KCS is reproduced. Ok. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 21:14:01 2012 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B11BA106568E; Wed, 29 Aug 2012 21:14:01 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 896D08FC29; Wed, 29 Aug 2012 21:14:00 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id AAA10796; Thu, 30 Aug 2012 00:13:36 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1T6pZw-000Pde-9P; Thu, 30 Aug 2012 00:13:36 +0300 Message-ID: <503E85FE.4050300@FreeBSD.org> Date: Thu, 30 Aug 2012 00:13:34 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Anton Yuzhanionov References: <503DE2AB.6030702@citrin.ru> <201208290825.44198.jhb@freebsd.org> <503E6E59.2000600@openstat.ru> In-Reply-To: <503E6E59.2000600@openstat.ru> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org, John Baldwin Subject: Re: Problem with IPMI KCS driver X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:14:01 -0000 on 29/08/2012 22:32 Anton Yuzhanionov said the following: > On 29.08.2012 16:25, John Baldwin wrote: >> Hmm. Can you try this: >> >> Index: kern/kern_clock.c >> =================================================================== >> --- kern/kern_clock.c (revision 239819) >> +++ kern/kern_clock.c (working copy) >> @@ -382,7 +382,7 @@ >> int stathz; >> int profhz; >> int profprocs; >> -int ticks; >> +volatile int ticks; >> int psratio; >> > > With this patch if_cdce.c can't be compiled: > > /usr/src/sys/modules/usb/cdce/../../../dev/usb/net/if_cdce.c: In function > 'cdce_attach': > /usr/src/sys/modules/usb/cdce/../../../dev/usb/net/if_cdce.c:616: warning: > passing argument 2 of 'memcpy' discards qualifiers from pointer target type > *** Error code 1 > > memcpy(&sc->sc_ue.ue_eaddr[1], &ticks, sizeof(uint32_t)); > > As I understand, memcpy() don't accept pointers to volatile objects. > May be some other source can be used for generated MAC address. int x = ticks; memcpy(..., &x, ...); should work > I have installed patched kernel (without cdce) and need some time to check if > the problem with IPMI KCS is reproduced. > -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Aug 29 22:23:38 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB3CD106566B for ; Wed, 29 Aug 2012 22:23:38 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4C8038FC17 for ; Wed, 29 Aug 2012 22:23:38 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so830963wgb.31 for ; Wed, 29 Aug 2012 15:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PhYxpkQbg7n47ohzE8+1Q8kDz7jq39QsJNbuZiHa6rA=; b=C04XOQnSWPv/AE3gVlBAdSPeyqJfhEMu5crBZO+0yUFxbo7V+J4sw1iMFmRDJcIFgk 1JhwcfbANpKtmUNMkJ/UeLIXx2URMAp7EMUE6rLSCUqXOow5gj1lW+X0GIePKDXqpZWF FtVA8pt0L4s5jy7reffnLH9BZoyLvyerCRBd4XFOe5jUKCYTM/+46PoJ1O9sRX9kOMvP CQLtkYAc04SBx4RdCG7ghmAdistxMU67rQXR8ySbWAly/XVvgz2qExgxHzHRPZ5VxkpS lifbFMDPLel+9Dvd28nBwpY0Wz4CrfNaweYusuENwOVpXij9x/P+jshimUuzPPCyjMh3 S5zg== MIME-Version: 1.0 Received: by 10.180.107.103 with SMTP id hb7mr6712588wib.3.1346279017098; Wed, 29 Aug 2012 15:23:37 -0700 (PDT) Received: by 10.223.63.76 with HTTP; Wed, 29 Aug 2012 15:23:37 -0700 (PDT) In-Reply-To: <76d6a3d12030d89690a3b6d28c85f48b@dweimer.net> References: <9fa99b69aab3afdd72f5776406eb1b65@dweimer.net> <76d6a3d12030d89690a3b6d28c85f48b@dweimer.net> Date: Wed, 29 Aug 2012 15:23:37 -0700 Message-ID: From: Kevin Oberman To: dweimer@dweimer.net Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: cdrtools port installation failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 22:23:38 -0000 On Wed, Aug 29, 2012 at 1:59 PM, dweimer wrote: > On 2012-08-29 14:31, dweimer wrote: >> >> On 2012-08-28 15:38, Kevin Oberman wrote: >>> >>> On Tue, Aug 28, 2012 at 8:46 AM, dweimer wrote: >>>> >>>> Anyone else not able to get cdrtools to install on a Stable System? >>>> >>>> I have just recently synced my source and rebuilt world, and kernel, >>>> then >>>> installed. Now while trying to install the livecd port, the cdrtools >>>> dependency is failing to install. >>>> >>>> The port compiles fine (at least it doesn't stop reporting an error), >>>> but >>>> dies on the installation portion reporting a missing file. >>>> >>>> install: >>>> >>>> >>>> /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav: >>>> No such file or directory *** [do-install] Error code 71 >>>> >>>> There is a cdda2wav.d and cdda2wav.o file in the directory its >>>> searching, >>>> however when I run this on my FreeBSD 9.0-RELEASE-p4 system, there is >>>> also a >>>> cdda2wav file with no extension. >>>> >>>> ls >>>> >>>> >>>> /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/ >>>> Dnull >>>> Inull >>>> aifc.d >>>> aifc.o >>>> aiff.d >>>> aiff.o >>>> base64.d >>>> base64.o >>>> cd_misc.d >>>> cd_misc.o >>>> cdda2wav.d >>>> cdda2wav.o >>>> config.cache >>>> config.log >>>> config.status >>>> interface.d >>>> interface.o >>>> ioctl.d >>>> ioctl.o >>>> lconfig.h >>>> local.cnf >>>> parse.d >>>> parse.o >>>> raw.d >>>> raw.o >>>> resample.d >>>> resample.o >>>> ringbuff.d >>>> ringbuff.o >>>> scsi_cdr.d >>>> scsi_cdr.o >>>> scsi_cmds.d >>>> scsi_cmds.o >>>> scsi_scan.d >>>> scsi_scan.o >>>> semshm.d >>>> semshm.o >>>> setuid.d >>>> setuid.o >>>> sndconfig.d >>>> sndconfig.o >>>> sun.d >>>> sun.o >>>> toc.d >>>> toc.o >>>> wav.d >>>> wav.o >>>> >>>> >>>> -- >>>> Thanks, >>>> Dean E. Weimer >>>> http://www.dweimer.net/ >>> >>> >>> How odd! I can't replicate this at all. >>> >>> I just made cdrtools-3.00_2 and I have: >>> cc -o OBJ/amd64-freebsd-cc/cdda2wav OBJ/amd64-freebsd-cc/cdda2wav.o >>> OBJ/amd64-freebsd-cc/interface.o OBJ/amd64-freebsd-cc/semshm.o >>> OBJ/amd64-freebsd-cc/resample.o OBJ/amd64-freebsd-cc/scsi_scan.o >>> OBJ/amd64-freebsd-cc/toc.o OBJ/amd64-freebsd-cc/wav.o >>> OBJ/amd64-freebsd-cc/sun.o OBJ/amd64-freebsd-cc/raw.o >>> OBJ/amd64-freebsd-cc/setuid.o OBJ/amd64-freebsd-cc/ringbuff.o >>> OBJ/amd64-freebsd-cc/sndconfig.o OBJ/amd64-freebsd-cc/scsi_cmds.o >>> OBJ/amd64-freebsd-cc/aiff.o OBJ/amd64-freebsd-cc/aifc.o >>> OBJ/amd64-freebsd-cc/scsi_cdr.o OBJ/amd64-freebsd-cc/cd_misc.o >>> OBJ/amd64-freebsd-cc/ioctl.o OBJ/amd64-freebsd-cc/base64.o >>> OBJ/amd64-freebsd-cc/parse.o -L../libs/amd64-freebsd-cc >>> -L../libs/amd64-freebsd-cc -L/usr/local/lib -L/usr/local/lib >>> -lscgcmd -lrscg -lscg -lparanoia -lcdrdeflt -ldeflt -lmdigest >>> -lschily -lcam >>> >>> And, as I expected, I find it: >>> # find work/cdrtools-3.00/ -name cdda2wav >>> work/cdrtools-3.00/cdda2wav >>> work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav >>> >>> Look trough the log of your make and see if anything "odd" happened in >>> that step. It should be at the end of the section : >>> ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc/Inull" >>> ==> CONFIGURING LOCAL RULES "OBJ/amd64-freebsd-cc/local.cnf" >>> and just before: >>> ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdrecord" >>> >>> This was on a stable system updated on Aug. 16. >> >> >> Finally had a chance to get back to this today, I haven't updated the >> ports tree or source since the last run. Built again same problem, >> After looking, I did have everything set to build with clang, and >> changed it to use gcc, then bingo it installed. >> >> However the FreeBSD 9.0-RELEASE-p4 system did successfully use clang, >> both systems have world and kernel built with clang. >> >> Will run it again with clang and capture the output of the make operation. >> >> Contents of /etc/make.conf, includes using gcc for cdrtools: >> >> # Use OpenSSL from ports instead of base >> WITH_OPENSSL_PORT=yes >> >> # Avoid Building Ports Against X >> WITHOUT_X11=yes >> >> # Performance related options >> CFLAGS?= -O >> CLFAGS+= -pipe >> >> # Ignore Warnings >> NO_WERROR= >> WERROR= >> >> # ports which will only build with the base system GNU compiler (4.2) >> # the "make index" target also needs this >> .if target(index) | \ >> ${.CURDIR:M*/lang/gcc*} | \ >> ${.CURDIR:M*/lang/ruby*} | \ >> ${.CURDIR:M*/devel/binutils*} | \ >> ${.CURDIR:M*/sysutils/cdrtools*} | \ >> ${.CURDIR:M*/www/squid*} >> USE_GCC?=4.2 >> .endif >> >> # use clang unless gcc is explicitly required >> .if !defined(USE_GCC) >> .if !defined(CC) || ${CC} == "cc" >> CC=clang >> .endif >> .if !defined(CXX) || ${CXX} == "c++" >> CXX=clang++ >> .endif >> .if !defined(CPP) || ${CPP} == "cpp" >> CPP=clang-cpp >> .endif >> .endif >> >> # added by use.perl 2012-08-28 04:04:28 >> PERL_VERSION=5.16.0 > > > This might, be the source of the problem, full output of make install > available here : > > ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdda2wav" > gmake[1]: Entering directory > `/usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav' > ./RULES/local.cnf:43: OBJ/amd64-freebsd-cc/Inull: No such file or directory > ./RULES/local.cnf:44: OBJ/amd64-freebsd-cc/local.cnf: No such file or > directory > ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc" > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT parse.c > \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/parse.d > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT base64.c > \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/base64.d > In file included from base64.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT ioctl.c > \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/ioctl.d > In file included from ioctl.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > ==> MAKING SYMLINKS in . > ln: ./config.guess: File exists > ln: ./config.sub: File exists > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT > cd_misc.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/cd_misc.d > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT > scsi_cdr.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/scsi_cdr.d > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT aifc.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/aifc.d > In file included from aifc.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT aiff.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/aiff.d > In file included from aiff.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT > scsi_cmds.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/scsi_cmds.d > In file included from scsi_cmds.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT > sndconfig.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/sndconfig.d > In file included from sndconfig.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT > ringbuff.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/ringbuff.d > In file included from ringbuff.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT setuid.c > \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/setuid.d > In file included from setuid.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT raw.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/raw.d > In file included from raw.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT sun.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/sun.d > In file included from sun.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT wav.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/wav.d > In file included from wav.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT toc.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/toc.d > In file included from toc.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT > scsi_scan.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/scsi_scan.d > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT > resample.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/resample.d > In file included from resample.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT semshm.c > \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/semshm.d > In file included from semshm.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT > interface.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/interface.d > In file included from interface.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc > -I../include -I/usr/local/include -I/usr/local/include -I../libcdrdeflt > -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT > cdda2wav.c \ > | sed -e 's;^\(.*\)\.o[ > ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/cdda2wav.d > In file included from cdda2wav.c:2: > ./config.h:34:10: fatal error: 'lconfig.h' file not found > #include "lconfig.h" > ^ > 1 error generated. > > ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc/Inull" > ==> CONFIGURING LOCAL RULES "OBJ/amd64-freebsd-cc/local.cnf" > creating cache ./config.cache > checking host system type... amd64-unknown-freebsd9.1 Hmm. Color me confused: >> .if target(index) | \ >> ${.CURDIR:M*/lang/gcc*} | \ >> ${.CURDIR:M*/lang/ruby*} | \ >> ${.CURDIR:M*/devel/binutils*} | \ >> ${.CURDIR:M*/sysutils/cdrtools*} | \ >> ${.CURDIR:M*/www/squid*} >> USE_GCC?=4.2 >> .endif This seems to imply that base gcc4.2 will be used to build sysutils/cdrtools, but the build log clearly shows clang being used. All of my ports are built with gcc-4.2 by default, though some have Makefiles that force either gcc-4.6 or clang. The "./config.h:34:10: fatal error: 'lconfig.h' file not found" error is also reported by gcc. But you cut off the log a bit short. cdda2wav is not built in that stage. It is built in the following MAKING DIRECTORY "OBJ/amd64-freebsd-cc/Inull" section, and at the very end of that stage. It is the very last executable built in the lnull stage. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Thu Aug 30 00:26:44 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E16A106567A for ; Thu, 30 Aug 2012 00:26:44 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 33C8F8FC19 for ; Thu, 30 Aug 2012 00:26:43 +0000 (UTC) Received: from www.dweimer.net (webmail.dweimer.net [192.168.5.1]) by webmail.dweimer.net (8.14.5/8.14.5) with ESMTP id q7U0QgAg084004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 29 Aug 2012 19:26:42 -0500 (CDT) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 29 Aug 2012 19:26:42 -0500 From: dweimer To: Kevin Oberman Organization: dweimer.net Mail-Reply-To: In-Reply-To: References: <9fa99b69aab3afdd72f5776406eb1b65@dweimer.net> <76d6a3d12030d89690a3b6d28c85f48b@dweimer.net> Message-ID: X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/0.8.0 Cc: freebsd-stable@freebsd.org Subject: Re: cdrtools port installation failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dweimer@dweimer.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 00:26:44 -0000 On 2012-08-29 17:23, Kevin Oberman wrote: > On Wed, Aug 29, 2012 at 1:59 PM, dweimer wrote: >> On 2012-08-29 14:31, dweimer wrote: >>> >>> On 2012-08-28 15:38, Kevin Oberman wrote: >>>> >>>> On Tue, Aug 28, 2012 at 8:46 AM, dweimer >>>> wrote: >>>>> >>>>> Anyone else not able to get cdrtools to install on a Stable >>>>> System? >>>>> >>>>> I have just recently synced my source and rebuilt world, and >>>>> kernel, >>>>> then >>>>> installed. Now while trying to install the livecd port, the >>>>> cdrtools >>>>> dependency is failing to install. >>>>> >>>>> The port compiles fine (at least it doesn't stop reporting an >>>>> error), >>>>> but >>>>> dies on the installation portion reporting a missing file. >>>>> >>>>> install: >>>>> >>>>> >>>>> >>>>> /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav: >>>>> No such file or directory *** [do-install] Error code 71 >>>>> >>>>> There is a cdda2wav.d and cdda2wav.o file in the directory its >>>>> searching, >>>>> however when I run this on my FreeBSD 9.0-RELEASE-p4 system, >>>>> there is >>>>> also a >>>>> cdda2wav file with no extension. >>>>> >>>>> ls >>>>> >>>>> >>>>> >>>>> /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/ >>>>> Dnull >>>>> Inull >>>>> aifc.d >>>>> aifc.o >>>>> aiff.d >>>>> aiff.o >>>>> base64.d >>>>> base64.o >>>>> cd_misc.d >>>>> cd_misc.o >>>>> cdda2wav.d >>>>> cdda2wav.o >>>>> config.cache >>>>> config.log >>>>> config.status >>>>> interface.d >>>>> interface.o >>>>> ioctl.d >>>>> ioctl.o >>>>> lconfig.h >>>>> local.cnf >>>>> parse.d >>>>> parse.o >>>>> raw.d >>>>> raw.o >>>>> resample.d >>>>> resample.o >>>>> ringbuff.d >>>>> ringbuff.o >>>>> scsi_cdr.d >>>>> scsi_cdr.o >>>>> scsi_cmds.d >>>>> scsi_cmds.o >>>>> scsi_scan.d >>>>> scsi_scan.o >>>>> semshm.d >>>>> semshm.o >>>>> setuid.d >>>>> setuid.o >>>>> sndconfig.d >>>>> sndconfig.o >>>>> sun.d >>>>> sun.o >>>>> toc.d >>>>> toc.o >>>>> wav.d >>>>> wav.o >>>>> >>>>> >>>>> -- >>>>> Thanks, >>>>> Dean E. Weimer >>>>> http://www.dweimer.net/ >>>> >>>> >>>> How odd! I can't replicate this at all. >>>> >>>> I just made cdrtools-3.00_2 and I have: >>>> cc -o OBJ/amd64-freebsd-cc/cdda2wav >>>> OBJ/amd64-freebsd-cc/cdda2wav.o >>>> OBJ/amd64-freebsd-cc/interface.o OBJ/amd64-freebsd-cc/semshm.o >>>> OBJ/amd64-freebsd-cc/resample.o OBJ/amd64-freebsd-cc/scsi_scan.o >>>> OBJ/amd64-freebsd-cc/toc.o OBJ/amd64-freebsd-cc/wav.o >>>> OBJ/amd64-freebsd-cc/sun.o OBJ/amd64-freebsd-cc/raw.o >>>> OBJ/amd64-freebsd-cc/setuid.o OBJ/amd64-freebsd-cc/ringbuff.o >>>> OBJ/amd64-freebsd-cc/sndconfig.o OBJ/amd64-freebsd-cc/scsi_cmds.o >>>> OBJ/amd64-freebsd-cc/aiff.o OBJ/amd64-freebsd-cc/aifc.o >>>> OBJ/amd64-freebsd-cc/scsi_cdr.o OBJ/amd64-freebsd-cc/cd_misc.o >>>> OBJ/amd64-freebsd-cc/ioctl.o OBJ/amd64-freebsd-cc/base64.o >>>> OBJ/amd64-freebsd-cc/parse.o -L../libs/amd64-freebsd-cc >>>> -L../libs/amd64-freebsd-cc -L/usr/local/lib -L/usr/local/lib >>>> -lscgcmd -lrscg -lscg -lparanoia -lcdrdeflt -ldeflt -lmdigest >>>> -lschily -lcam >>>> >>>> And, as I expected, I find it: >>>> # find work/cdrtools-3.00/ -name cdda2wav >>>> work/cdrtools-3.00/cdda2wav >>>> work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav >>>> >>>> Look trough the log of your make and see if anything "odd" >>>> happened in >>>> that step. It should be at the end of the section : >>>> ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc/Inull" >>>> ==> CONFIGURING LOCAL RULES >>>> "OBJ/amd64-freebsd-cc/local.cnf" >>>> and just before: >>>> ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdrecord" >>>> >>>> This was on a stable system updated on Aug. 16. >>> >>> >>> Finally had a chance to get back to this today, I haven't updated >>> the >>> ports tree or source since the last run. Built again same problem, >>> After looking, I did have everything set to build with clang, and >>> changed it to use gcc, then bingo it installed. >>> >>> However the FreeBSD 9.0-RELEASE-p4 system did successfully use >>> clang, >>> both systems have world and kernel built with clang. >>> >>> Will run it again with clang and capture the output of the make >>> operation. >>> >>> Contents of /etc/make.conf, includes using gcc for cdrtools: >>> >>> # Use OpenSSL from ports instead of base >>> WITH_OPENSSL_PORT=yes >>> >>> # Avoid Building Ports Against X >>> WITHOUT_X11=yes >>> >>> # Performance related options >>> CFLAGS?= -O >>> CLFAGS+= -pipe >>> >>> # Ignore Warnings >>> NO_WERROR= >>> WERROR= >>> >>> # ports which will only build with the base system GNU compiler >>> (4.2) >>> # the "make index" target also needs this >>> .if target(index) | \ >>> ${.CURDIR:M*/lang/gcc*} | \ >>> ${.CURDIR:M*/lang/ruby*} | \ >>> ${.CURDIR:M*/devel/binutils*} | \ >>> ${.CURDIR:M*/sysutils/cdrtools*} | \ >>> ${.CURDIR:M*/www/squid*} >>> USE_GCC?=4.2 >>> .endif >>> >>> # use clang unless gcc is explicitly required >>> .if !defined(USE_GCC) >>> .if !defined(CC) || ${CC} == "cc" >>> CC=clang >>> .endif >>> .if !defined(CXX) || ${CXX} == "c++" >>> CXX=clang++ >>> .endif >>> .if !defined(CPP) || ${CPP} == "cpp" >>> CPP=clang-cpp >>> .endif >>> .endif >>> >>> # added by use.perl 2012-08-28 04:04:28 >>> PERL_VERSION=5.16.0 >> >> >> This might, be the source of the problem, full output of make >> install >> available here : >> >> ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdda2wav" >> gmake[1]: Entering directory >> `/usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav' >> ./RULES/local.cnf:43: OBJ/amd64-freebsd-cc/Inull: No such file or >> directory >> ./RULES/local.cnf:44: OBJ/amd64-freebsd-cc/local.cnf: No such file >> or >> directory >> ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc" >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> parse.c >> \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/parse.d >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> base64.c >> \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/base64.d >> In file included from base64.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> ioctl.c >> \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/ioctl.d >> In file included from ioctl.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> ==> MAKING SYMLINKS in . >> ln: ./config.guess: File exists >> ln: ./config.sub: File exists >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> cd_misc.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/cd_misc.d >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> scsi_cdr.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/scsi_cdr.d >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> aifc.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/aifc.d >> In file included from aifc.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> aiff.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/aiff.d >> In file included from aiff.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> scsi_cmds.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/scsi_cmds.d >> In file included from scsi_cmds.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> sndconfig.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/sndconfig.d >> In file included from sndconfig.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> ringbuff.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/ringbuff.d >> In file included from ringbuff.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> setuid.c >> \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/setuid.d >> In file included from setuid.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> raw.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/raw.d >> In file included from raw.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> sun.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/sun.d >> In file included from sun.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> wav.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/wav.d >> In file included from wav.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> toc.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/toc.d >> In file included from toc.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> scsi_scan.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/scsi_scan.d >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> resample.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/resample.d >> In file included from resample.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> semshm.c >> \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/semshm.d >> In file included from semshm.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> interface.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/interface.d >> In file included from interface.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc >> -I../incs/amd64-freebsd-cc >> -I../include -I/usr/local/include -I/usr/local/include >> -I../libcdrdeflt >> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >> cdda2wav.c \ >> | sed -e 's;^\(.*\)\.o[ >> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > >> OBJ/amd64-freebsd-cc/cdda2wav.d >> In file included from cdda2wav.c:2: >> ./config.h:34:10: fatal error: 'lconfig.h' file not found >> #include "lconfig.h" >> ^ >> 1 error generated. >> >> ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc/Inull" >> ==> CONFIGURING LOCAL RULES "OBJ/amd64-freebsd-cc/local.cnf" >> creating cache ./config.cache >> checking host system type... amd64-unknown-freebsd9.1 > > Hmm. Color me confused: >>> .if target(index) | \ >>> ${.CURDIR:M*/lang/gcc*} | \ >>> ${.CURDIR:M*/lang/ruby*} | \ >>> ${.CURDIR:M*/devel/binutils*} | \ >>> ${.CURDIR:M*/sysutils/cdrtools*} | \ >>> ${.CURDIR:M*/www/squid*} >>> USE_GCC?=4.2 >>> .endif > > This seems to imply that base gcc4.2 will be used to build > sysutils/cdrtools, but the build log clearly shows clang being used. > > All of my ports are built with gcc-4.2 by default, though some have > Makefiles that force either gcc-4.6 or clang. > > The "./config.h:34:10: fatal error: 'lconfig.h' file not found" error > is also reported by gcc. > > But you cut off the log a bit short. cdda2wav is not built in that > stage. It is built in the following MAKING DIRECTORY > "OBJ/amd64-freebsd-cc/Inull" section, and at the very end of that > stage. It is the very last executable built in the lnull stage. Yes I made that copy of the /etc/make.conf when I had it excluded from using clang, works with that setup, when removed from the exclude list it fails. The full output is at the url: it was an awful lot to post in the email. Every listing of INULL is followed by directory not found, that section was the only spot I saw errors, and not just warnings. -- Thanks, Dean E. Weimer http://www.dweimer.net/ From owner-freebsd-stable@FreeBSD.ORG Thu Aug 30 06:43:52 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9B2B5106564A for ; Thu, 30 Aug 2012 06:43:52 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail2.icritical.com (mail2.icritical.com [212.57.248.50]) by mx1.freebsd.org (Postfix) with SMTP id E43D18FC15 for ; Thu, 30 Aug 2012 06:43:51 +0000 (UTC) Received: (qmail 12845 invoked from network); 30 Aug 2012 06:43:49 -0000 Received: from localhost (127.0.0.1) by mail2.icritical.com with SMTP; 30 Aug 2012 06:43:49 -0000 Received: (qmail 12836 invoked by uid 599); 30 Aug 2012 06:43:49 -0000 Received: from unknown (HELO PDC002.icritical.int) (212.57.254.146) by mail2.icritical.com (qpsmtpd/0.28) with ESMTP; Thu, 30 Aug 2012 07:43:49 +0100 Message-ID: <503F0BA2.6060107@icritical.com> Date: Thu, 30 Aug 2012 07:43:46 +0100 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-TLS-Incoming: YES X-Virus-Scanned: by iCritical at mail2.icritical.com Subject: Killing processes from DDB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 06:43:52 -0000 Is it possible to forcibly kill process from DDB which are unkillable from userland? My understanding is the 'kill' command is effectively the same as the userland version, so perhaps a process could be terminated by invoking an OOM handler or something? I just had a VirtualBox instance crash and hog 100% CPU on my desktop: mattb 36939 100.0 13.6 2577328 2276108 ?? I 6:13AM 2:28.44 /usr/local/lib/virtualbox/VirtualBox I kill -9 it mattb 36939 100.0 13.6 2577328 2275804 ?? T 6:13AM 3:10.89 /usr/local/lib/virtualbox/VirtualBox Note it's moved to 'stop' state for some reason, yet is still eating 100% cpu time # procstat -k 36939 PID TID COMM TDNAME KSTACK 36939 227509 VirtualBox - 36939 227836 VirtualBox - mi_switch thread_suspend_switch thread_single exit1 sigexit postsig ast doreti_ast Could this be the trigger - 9.0 binary (from pkgng) against 9.1? $ procstat -b 1 36939 PID COMM OSREL PATH 1 init 901000 /sbin/init 36939 VirtualBox 900044 /usr/local/lib/virtualbox/VirtualBox I couldn't even kill it with "dtrace -n 'pid$target:::' -p 36939 -l" - which so far has proven reliable in killing anything: # dtrace -n 'pid$target:::' -p 2021 -l <--- unimportant proc Bus error: 10 (core dumped) # dtrace -n 'pid$target:::' -p 2044 -l <--- unimportant proc Bus error: 10 (core dumped) # dtrace -n 'pid$target:::' -p 36939 -l <--- virtualbox hangs dtrace ^C I couldn't truss the process or use gcore to get a dump, so my only option was a reboot. Does anyone have any suggestions on a course of action in case this happens again? I can't get a kernel dump since the machine doesn't have enough swap (small SSDs) Thanks -- The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com From owner-freebsd-stable@FreeBSD.ORG Thu Aug 30 08:12:28 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A865106566C for ; Thu, 30 Aug 2012 08:12:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C2A258FC19 for ; Thu, 30 Aug 2012 08:12:27 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q7U8CW1p048669; Thu, 30 Aug 2012 11:12:32 +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.5/8.14.5) with ESMTP id q7U8CKTX080965; Thu, 30 Aug 2012 11:12:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q7U8CK5r080964; Thu, 30 Aug 2012 11:12:20 +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: Thu, 30 Aug 2012 11:12:20 +0300 From: Konstantin Belousov To: Matt Burke Message-ID: <20120830081220.GJ33100@deviant.kiev.zoral.com.ua> References: <503F0BA2.6060107@icritical.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m35yhtyYP/lVCYkX" Content-Disposition: inline In-Reply-To: <503F0BA2.6060107@icritical.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 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 Cc: freebsd-stable@freebsd.org Subject: Re: Killing processes from DDB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 08:12:28 -0000 --m35yhtyYP/lVCYkX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 30, 2012 at 07:43:46AM +0100, Matt Burke wrote: > Is it possible to forcibly kill process from DDB which are unkillable from > userland? My understanding is the 'kill' command is effectively the same = as > the userland version, so perhaps a process could be terminated by invoking > an OOM handler or something? Processes can only be terminated at the safe points, where kernel code explicitely checks for termination conditions and which are known to not hold kernel resources. Yes, kill command from ddb just kills the process, i.e. it sends a signal to it, handling of which is subject of the normal signal delivering. >=20 >=20 > I just had a VirtualBox instance crash and hog 100% CPU on my desktop: >=20 > mattb 36939 100.0 13.6 2577328 2276108 ?? I 6:13AM 2:28.44 > /usr/local/lib/virtualbox/VirtualBox >=20 > I kill -9 it >=20 > mattb 36939 100.0 13.6 2577328 2275804 ?? T 6:13AM 3:10.89 > /usr/local/lib/virtualbox/VirtualBox >=20 > Note it's moved to 'stop' state for some reason, yet is still eating 100% > cpu time >=20 > # procstat -k 36939 > PID TID COMM TDNAME KSTACK > 36939 227509 VirtualBox - > 36939 227836 VirtualBox - mi_switch > thread_suspend_switch thread_single exit1 sigexit postsig ast doreti_ast Stop state indicates that the process is stopped or being stopped. The later is your case. The process has one thread executing exit1() kernel function, which terminates the process. In the course of work, the function notifies all other threads of the exiting process that they shall terminate ASAP at the next safe point. According to the procstat output, there is other thread in the process which seems to execute in kernel. My guess is that it loops somewhere, not reachi= ng any check-points for termination. >=20 >=20 > Could this be the trigger - 9.0 binary (from pkgng) against 9.1? >=20 > $ procstat -b 1 36939 > PID COMM OSREL PATH > 1 init 901000 /sbin/init > 36939 VirtualBox 900044 /usr/local/lib/virtualbox/VirtualBox >=20 >=20 > I couldn't even kill it with "dtrace -n 'pid$target:::' -p 36939 -l" - > which so far has proven reliable in killing anything: >=20 > # dtrace -n 'pid$target:::' -p 2021 -l <--- unimportant proc > Bus error: 10 (core dumped) > # dtrace -n 'pid$target:::' -p 2044 -l <--- unimportant proc > Bus error: 10 (core dumped) > # dtrace -n 'pid$target:::' -p 36939 -l <--- virtualbox hangs dtrace > ^C >=20 > I couldn't truss the process or use gcore to get a dump, so my only option > was a reboot. Does anyone have any suggestions on a course of action in > case this happens again? I can't get a kernel dump since the machine > doesn't have enough swap (small SSDs) The way to debug the issue is to break into ddb on console and get a backtrace for the spinning thread, then continue, then break again and get another backtrace. Do it several times, to see where the code spins. It is impossible to even start guessing what is wrong, without seeing the backtrace. Still, recompiling VB could be good idea, since VB kernel module uses non-stable KPI and KBI, thus what you see might be just build issue. --m35yhtyYP/lVCYkX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlA/IGQACgkQC3+MBN1Mb4it1gCcC9NjEamsIfxTmgPw/FEpe6nO uukAoOGdVt+anyTUE3CSeyQ+bMszPgXE =AnUq -----END PGP SIGNATURE----- --m35yhtyYP/lVCYkX-- From owner-freebsd-stable@FreeBSD.ORG Thu Aug 30 10:12:50 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 65A851065761 for ; Thu, 30 Aug 2012 10:12:49 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [93.95.13.41]) by mx1.freebsd.org (Postfix) with SMTP id 0E9998FC21 for ; Thu, 30 Aug 2012 10:12:48 +0000 (UTC) Received: (qmail 2376 invoked from network); 30 Aug 2012 10:06:06 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 30 Aug 2012 10:06:06 -0000 Received: (qmail 2361 invoked by uid 599); 30 Aug 2012 10:06:06 -0000 Received: from unknown (HELO PDC002.icritical.int) (212.57.254.146) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Thu, 30 Aug 2012 11:06:06 +0100 Message-ID: <503F3B09.9040905@icritical.com> Date: Thu, 30 Aug 2012 11:06:01 +0100 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 MIME-Version: 1.0 To: Konstantin Belousov References: <503F0BA2.6060107@icritical.com> <20120830081220.GJ33100@deviant.kiev.zoral.com.ua> In-Reply-To: <20120830081220.GJ33100@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-TLS-Incoming: YES X-Virus-Scanned: by iCritical at mail1.icritical.com Cc: freebsd-stable@freebsd.org Subject: Re: Killing processes from DDB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 10:12:50 -0000 On 08/30/12 09:12, Konstantin Belousov wrote: > Stop state indicates that the process is stopped or being stopped. The later > is your case. The process has one thread executing exit1() kernel function, > which terminates the process. In the course of work, the function notifies > all other threads of the exiting process that they shall terminate ASAP at > the next safe point. Thanks for the explanation - I thought stop state was just a mechanism for processes to pause (as in ^Z from the shell) by being skipped by the scheduler or something... Looking in /sys/kern I think I need to do a lot of reading to correct what appear to be some bad assumptions I've picked up over the years. > The way to debug the issue is to break into ddb on console and get > a backtrace for the spinning thread, then continue, then break again > and get another backtrace. Do it several times, to see where the code > spins. Understood. > It is impossible to even start guessing what is wrong, without seeing > the backtrace. > > Still, recompiling VB could be good idea, since VB kernel module uses > non-stable KPI and KBI, thus what you see might be just build issue. Indeed, however I find Bad Things happening are a great excuse to learn more about the system's innards ;) -- The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. iCritical is a trading name of Critical Software Ltd. Registered in England: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. www.icritical.com From owner-freebsd-stable@FreeBSD.ORG Thu Aug 30 14:18:23 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FE19106564A for ; Thu, 30 Aug 2012 14:18:23 +0000 (UTC) (envelope-from legolas@legolasweb.nl) Received: from smtpq1.tb.mail.iss.as9143.net (smtpq1.tb.mail.iss.as9143.net [212.54.42.164]) by mx1.freebsd.org (Postfix) with ESMTP id 33B548FC1F for ; Thu, 30 Aug 2012 14:18:22 +0000 (UTC) Received: from [212.54.42.133] (helo=smtp2.tb.mail.iss.as9143.net) by smtpq1.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1T75Ap-0007cU-4J for freebsd-stable@freebsd.org; Thu, 30 Aug 2012 15:52:43 +0200 Received: from 5357e32a.cm-6-8d.dynamic.ziggo.nl ([83.87.227.42] helo=homey.local) by smtp2.tb.mail.iss.as9143.net with esmtp (Exim 4.71) (envelope-from ) id 1T75Ao-000509-MC for freebsd-stable@freebsd.org; Thu, 30 Aug 2012 15:52:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 30 Aug 2012 15:53:39 +0200 From: Stas Verberkt To: In-Reply-To: <50384172.3090706@pingle.org> References: <1345697446.84337.11.camel@neo.cse.buffalo.edu> <20120823225855.U33776@sola.nimnet.asn.au> <1345729674.52121.4.camel@bauer.cse.buffalo.edu> <5036497F.7020501@icarz.com> <1345736581.27688.403.camel@revolution.hippie.lan> <50384172.3090706@pingle.org> Message-ID: X-Sender: legolas@legolasweb.nl User-Agent: Roundcube Webmail/0.8.1 X-Ziggo-spambar: --- X-Ziggo-spamscore: -3.1 X-Ziggo-spamreport: ALL_TRUSTED=-1, BAYES_00=-1.9, PROLO_TRUST_RDNS=-3, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.2, TW_SV=0.077, URIBL_AH_DNSBL=1.5 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No Subject: Re: FreeBSD 9.1-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 14:18:23 -0000 Jim Pingle schreef op : > On 8/23/2012 11:43 AM, Ian Lepore wrote: >> On Thu, 2012-08-23 at 11:17 -0400, Ken Menzel wrote: >>> >>> I found two good primers: >>> >>> http://mebsd.com/configure-freebsd-servers/update-freebsd-source-tree-using-subversion-svn.html >>> >>> http://www.freebsd.org/doc/en/articles/committers-guide/article.html#SUBVERSION-PRIMER >>> >>> The second primer in the committer handbook seems to indicate that >>> it >>> is difficult to run an SVN mirror. This appears to me to be the >>> biggest drawback. I have been using CVS and perforce for years, >>> but >>> subversion is new to me. >> >> It may be difficult to run an svn mirror that allows you to commit >> locally and get those changes back to the project, but running a >> read-only mirror is trivial. The script I run nightly from cron to >> sync >> my local mirror is: >> >> #!/bin/sh >> # >> # svnsync to pull in changes from FreeBSD to my local >> mirror. >> # >> svnsync sync file:///local/vc/svn/base >> >> I can't remember how I initially created and populated the mirror, >> but >> it's likely I grabbed a snapshot of the mirror at work and brought >> it >> home on a thumb drive (just to avoid initial network DL time). > > I spent a little time today setting up an SVN mirror after reading > this > thread and wrote up a how-to for those looking to do the same. > > http://www.pingle.org/2012/08/24/freebsd-svn-mirror > > Comments/Flames/Corrections welcome... > Just wondering: do you really need DAV if you are not going to allow writing? I serve my read-only GIT repositories using HTTP without WebDAV. From owner-freebsd-stable@FreeBSD.ORG Thu Aug 30 14:34:27 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19916106566B for ; Thu, 30 Aug 2012 14:34:27 +0000 (UTC) (envelope-from jl.dupont@outlook.com) Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by mx1.freebsd.org (Postfix) with ESMTP id D4EBC8FC0A for ; Thu, 30 Aug 2012 14:34:26 +0000 (UTC) Received: from BLU002-W180 ([65.55.111.71]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Aug 2012 07:33:20 -0700 Message-ID: X-Originating-IP: [194.145.144.230] From: Jean-Luc Dupont To: "freebsd-stable@freebsd.org" Date: Thu, 30 Aug 2012 14:33:20 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 30 Aug 2012 14:33:20.0826 (UTC) FILETIME=[674681A0:01CD86BC] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Kernel Panic on 9.0 and 9.1 with carp on BCE network interface X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 14:34:27 -0000 Hello=2C We are using Freebsd 9.0 on dell poweredge servers with broadcom (bce) in= tegrated interfaces and intel pci-x cards. This server is used as gateway/firewall (IPFW) with several VLANs and each = interface and carp for redundancy with another identical server. We encounter a kernel panic and reboot when some users connect to an extern= al FTP (just after=20 accepting the password). We upgraded to 9.1-prerelease and 9.1-stable=2C without any change=2C still= same systematic panic. Here is the backtrace : cpuid =3D 3 KDB: stack backtrace: #0 0xffffffff808342b6 at kdb_backtrace+0x66 #1 0xffffffff807fe40d at panic+0x1cd #2 0xffffffff80a21c6f at ufs_dirbad+0x4f #3 0xffffffff80a2334a at ufs_lookup_ino+0x68a #4 0xffffffff8088077f at vfs_cache_lookup+0xff #5 0xffffffff80b3b380 at VOP_LOOKUP_APV+0x40 #6 0xffffffff80887e94 at lookup+0x464 #7 0xffffffff80888fa9 at namei+0x4e9 #8 0xffffffff808a307b at vn_open_cred+0x3bb #9 0xffffffff808a2117 at kern_openat+0x1e7 #10 0xffffffff80ad1fa6 at amd64_syscall+0x546 #11 0xffffffff80abd967 at Xfast_syscall+0xf7 Uptime: 6m4s (kgdb) #0 doadump (textdump=3DVariable "textdump" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:271 #1 0xffffffff807fdf02 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xffffffff807fe3e3 in panic (fmt=3D0x104
) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xffffffff80a21c6f in ufs_dirbad (ip=3DVariable "ip" is not available. ) at /usr/src/sys/ufs/ufs/ufs_lookup.c:773 #4 0xffffffff80a2334a in ufs_lookup_ino (vdp=3D0xfffffe00b0aee5a0=2C=20 vpp=3D0xffffff834bb30a10=2C cnp=3D0xffffff834bb30a38=2C dd_ino=3D0x0) at /usr/src/sys/ufs/ufs/ufs_lookup.c:393 #5 0xffffffff8088077f in vfs_cache_lookup (ap=3DVariable "ap" is not avail= able. ) at vnode_if.h:80 #6 0xffffffff80b3b380 in VOP_LOOKUP_APV (vop=3D0xffffffff8104e960=2C=20 a=3D0xffffff834bb306f0) at vnode_if.c:123 #7 0xffffffff80887e94 in lookup (ndp=3D0xffffff834bb309d0) at vnode_if.h:5= 4 #8 0xffffffff80888fa9 in namei (ndp=3D0xffffff834bb309d0) at /usr/src/sys/kern/vfs_lookup.c:297 #9 0xffffffff808a307b in vn_open_cred (ndp=3D0xffffff834bb309d0=2C=20 flagp=3D0xffffff834bb309cc=2C cmode=3D0=2C vn_open_flags=3DVariable "vn= _open_flags" is not available. ) at /usr/src/sys/kern/vfs_vnops.c:195 #10 0xffffffff808a2117 in kern_openat (td=3D0xfffffe000ff75470=2C fd=3D-100= =2C=20 path=3D0x809ff80c0
=2C=20 pathseg=3DUIO_USERSPACE=2C flags=3D1=2C mode=3DVariable "mode" is not a= vailable. ) at /usr/src/sys/kern/vfs_syscalls.c:1132 #11 0xffffffff80ad1fa6 in amd64_syscall (td=3D0xfffffe000ff75470=2C traced= =3D0) at subr_syscall.c:135 #12 0xffffffff80abd967 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:387 #13 0x0000000801e5366c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb)=20 We have the coredump and the kernel.debug=2C if there is anything we can do= to help you identifying the origin of this issue. Thank you very much = From owner-freebsd-stable@FreeBSD.ORG Thu Aug 30 14:38:37 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34FAD106566B for ; Thu, 30 Aug 2012 14:38:37 +0000 (UTC) (envelope-from lists@pingle.org) Received: from chloe.pingle.org (unknown [IPv6:2605:8000:d:1:40::1]) by mx1.freebsd.org (Postfix) with ESMTP id E7EEA8FC1A for ; Thu, 30 Aug 2012 14:38:36 +0000 (UTC) Received: from chloe.pingle.org (unknown [127.0.0.1]) by chloe.pingle.org (Postfix) with ESMTP id C6DCB450A3 for ; Thu, 30 Aug 2012 10:38:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at pingle.org Received: from chloe.pingle.org ([127.0.0.1]) by chloe.pingle.org (chloe.pingle.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyOn_NwCE8Pz for ; Thu, 30 Aug 2012 10:38:13 -0400 (EDT) Received: from [IPv6:2001:470:1f11:e1c:5c20:5e11:5128:bebc] (unknown [IPv6:2001:470:1f11:e1c:5c20:5e11:5128:bebc]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jim) by chloe.pingle.org (Postfix) with ESMTPSA id 1311B450A2 for ; Thu, 30 Aug 2012 10:38:13 -0400 (EDT) Message-ID: <503F7ACE.9090703@pingle.org> Date: Thu, 30 Aug 2012 10:38:06 -0400 From: Jim Pingle User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: FreeBSD References: <1345697446.84337.11.camel@neo.cse.buffalo.edu> <20120823225855.U33776@sola.nimnet.asn.au> <1345729674.52121.4.camel@bauer.cse.buffalo.edu> <5036497F.7020501@icarz.com> <1345736581.27688.403.camel@revolution.hippie.lan> <50384172.3090706@pingle.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD 9.1-RC1 Available... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 14:38:37 -0000 On 8/30/2012 9:53 AM, Stas Verberkt wrote: >> I spent a little time today setting up an SVN mirror after reading this >> thread and wrote up a how-to for those looking to do the same. >> >> http://www.pingle.org/2012/08/24/freebsd-svn-mirror >> >> Comments/Flames/Corrections welcome... >> > Just wondering: do you really need DAV if you are not going to allow > writing? > I serve my read-only GIT repositories using HTTP without WebDAV. I'm not 100% sure on that part - previously I had setup a read+write SVN repo over HTTPS (at $oldjob) so I went with the directions I had for that, just adjusted for read-only. Some Googling suggests that DAV is required. The official Subversion book lists DAV as a requirement[1]. Wikipedia seems to suggest it's required as well "Apache HTTP Server as network server, WebDAV/Delta-V for protocol. There is also an independent server process called svnserve that uses a custom protocol over TCP/IP." If someone knows a trick to serve it up over HTTP without DAV that would be good to know. Jim P.S. Realized I sent this directly, resending to the list, with an edit. [1] http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html From owner-freebsd-stable@FreeBSD.ORG Thu Aug 30 14:40:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 704941065673 for ; Thu, 30 Aug 2012 14:40:18 +0000 (UTC) (envelope-from jl.dupont@outlook.com) Received: from blu0-omc2-s32.blu0.hotmail.com (blu0-omc2-s32.blu0.hotmail.com [65.55.111.107]) by mx1.freebsd.org (Postfix) with ESMTP id 29A3B8FC23 for ; Thu, 30 Aug 2012 14:40:17 +0000 (UTC) Received: from BLU002-W136 ([65.55.111.71]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Aug 2012 07:39:10 -0700 Message-ID: X-Originating-IP: [194.145.144.230] From: Jean-Luc Dupont To: "freebsd-stable@freebsd.org" Date: Thu, 30 Aug 2012 14:39:10 +0000 Importance: Normal In-Reply-To: References: MIME-Version: 1.0 X-OriginalArrivalTime: 30 Aug 2012 14:39:10.0780 (UTC) FILETIME=[37DD3FC0:01CD86BD] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: RE: Kernel Panic on 9.0 and 9.1 with carp on BCE network interface X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 14:40:18 -0000 Sorry=2C it seems that I didn't put the right backtrace : #0 doadump (textdump=3DVariable "textdump" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:271 271 dumpsys(&dumper)=3B (kgdb) #0 doadump (textdump=3DVariable "textdump" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:271 #1 0xffffffff807fdf02 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xffffffff807fe3e3 in panic (fmt=3D0x104
) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xffffffff80ad2700 in trap_fatal (frame=3D0xc=2C eva=3DVariable "eva" i= s not available. ) at /usr/src/sys/amd64/amd64/trap.c:857 #4 0xffffffff80ad2a3d in trap_pfault (frame=3D0xffffff82e97a3500=2C usermo= de=3D0) at /usr/src/sys/amd64/amd64/trap.c:773 #5 0xffffffff80ad305e in trap (frame=3D0xffffff82e97a3500) at /usr/src/sys/amd64/amd64/trap.c:456 #6 0xffffffff80abd67f in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0xffffffff8085f597 in m_copym (m=3D0x0=2C off0=3D1500=2C len=3D1480=2C = wait=3D1) at /usr/src/sys/kern/uipc_mbuf.c:542 #8 0xffffffff8092f2c8 in ip_fragment (ip=3D0xfffffe00970e0580=2C=20 m_frag=3D0xffffff82e97a3728=2C mtu=3DVariable "mtu" is not available. ) at /usr/src/sys/netinet/ip_output.c:822 #9 0xffffffff8092fc17 in ip_output (m=3D0xfffffe00970e0500=2C opt=3DVariab= le "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:653 #10 0xffffffff80928713 in ip_forward (m=3D0xfffffe00970e0500=2C srcrt=3DVar= iable "srcrt" is not available. ) at /usr/src/sys/netinet/ip_input.c:1494 #11 0xffffffff80929dc8 in ip_input (m=3D0xfffffe00970e0500) at /usr/src/sys/netinet/ip_input.c:702 #12 0xffffffff808bfe17 in netisr_dispatch_src (proto=3D56=2C source=3DVaria= ble "source" is not available. ) at /usr/src/sys/net/netisr.c:1013 #13 0xffffffff808b6d8c in ether_demux (ifp=3D0xfffffe0011056000=2C=20 m=3D0xfffffe00970e0500) at /usr/src/sys/net/if_ethersubr.c:940 #14 0xffffffff808b7054 in ether_nh_input (m=3DVariable "m" is not available= . ) at /usr/src/sys/net/if_ethersubr.c:759 #15 0xffffffff808bfe17 in netisr_dispatch_src (proto=3D504=2C source=3DVari= able "source" is not available. ) at /usr/src/sys/net/netisr.c:1013 #16 0xffffffff808b6caf in ether_demux (ifp=3D0xfffffe0003b54000=2C=20 m=3D0xfffffe00970e0500) at /usr/src/sys/net/if_ethersubr.c:849 #17 0xffffffff808b7054 in ether_nh_input (m=3DVariable "m" is not available= . ) at /usr/src/sys/net/if_ethersubr.c:759 #18 0xffffffff808bfe17 in netisr_dispatch_src (proto=3D504=2C source=3DVari= able "source" is not available. ) at /usr/src/sys/net/netisr.c:1013 #19 0xffffffff8040048a in bce_intr (xsc=3DVariable "xsc" is not available. ) at /usr/src/sys/dev/bce/if_bce.c:6578 #20 0xffffffff807d39e4 in intr_event_execute_handlers (p=3DVariable "p" is = not available. ) at /usr/src/sys/kern/kern_intr.c:1260 #21 0xffffffff807d5176 in ithread_loop (arg=3D0xfffffe0003e50000) at /usr/src/sys/kern/kern_intr.c:1273 #22 0xffffffff807d0b0f in fork_exit ( callout=3D0xffffffff807d50d0 =2C arg=3D0xfffffe0003e50000= =2C=20 frame=3D0xffffff82e97a3c40) at /usr/src/sys/kern/kern_fork.c:992 #23 0xffffffff80abdbae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:602 > From: jl.dupont@outlook.com > To: freebsd-stable@freebsd.org > Date: Thu=2C 30 Aug 2012 14:33:20 +0000 > Subject: Kernel Panic on 9.0 and 9.1 with carp on BCE network interface >=20 > Hello=2C >=20 > We are using Freebsd 9.0 on dell poweredge servers with broadcom (bce) = integrated interfaces and intel pci-x cards. >=20 > This server is used as gateway/firewall (IPFW) with several VLANs and eac= h interface and carp for redundancy with another identical server. >=20 > We encounter a kernel panic and reboot when some users connect to an exte= rnal FTP (just after=20 > accepting the password). >=20 > We upgraded to 9.1-prerelease and 9.1-stable=2C without any change=2C sti= ll same systematic panic. >=20 > Here is the backtrace : >=20 > cpuid =3D 3 > KDB: stack backtrace: > #0 0xffffffff808342b6 at kdb_backtrace+0x66 > #1 0xffffffff807fe40d at panic+0x1cd > #2 0xffffffff80a21c6f at ufs_dirbad+0x4f > #3 0xffffffff80a2334a at ufs_lookup_ino+0x68a > #4 0xffffffff8088077f at vfs_cache_lookup+0xff > #5 0xffffffff80b3b380 at VOP_LOOKUP_APV+0x40 > #6 0xffffffff80887e94 at lookup+0x464 > #7 0xffffffff80888fa9 at namei+0x4e9 > #8 0xffffffff808a307b at vn_open_cred+0x3bb > #9 0xffffffff808a2117 at kern_openat+0x1e7 > #10 0xffffffff80ad1fa6 at amd64_syscall+0x546 > #11 0xffffffff80abd967 at Xfast_syscall+0xf7 > Uptime: 6m4s >=20 > (kgdb) #0 doadump (textdump=3DVariable "textdump" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:271 > #1 0xffffffff807fdf02 in kern_reboot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:448 > #2 0xffffffff807fe3e3 in panic (fmt=3D0x104
) > at /usr/src/sys/kern/kern_shutdown.c:636 > #3 0xffffffff80a21c6f in ufs_dirbad (ip=3DVariable "ip" is not available= . > ) > at /usr/src/sys/ufs/ufs/ufs_lookup.c:773 > #4 0xffffffff80a2334a in ufs_lookup_ino (vdp=3D0xfffffe00b0aee5a0=2C=20 > vpp=3D0xffffff834bb30a10=2C cnp=3D0xffffff834bb30a38=2C dd_ino=3D0x0) > at /usr/src/sys/ufs/ufs/ufs_lookup.c:393 > #5 0xffffffff8088077f in vfs_cache_lookup (ap=3DVariable "ap" is not ava= ilable. > ) at vnode_if.h:80 > #6 0xffffffff80b3b380 in VOP_LOOKUP_APV (vop=3D0xffffffff8104e960=2C=20 > a=3D0xffffff834bb306f0) at vnode_if.c:123 > #7 0xffffffff80887e94 in lookup (ndp=3D0xffffff834bb309d0) at vnode_if.h= :54 > #8 0xffffffff80888fa9 in namei (ndp=3D0xffffff834bb309d0) > at /usr/src/sys/kern/vfs_lookup.c:297 > #9 0xffffffff808a307b in vn_open_cred (ndp=3D0xffffff834bb309d0=2C=20 > flagp=3D0xffffff834bb309cc=2C cmode=3D0=2C vn_open_flags=3DVariable "= vn_open_flags" is not available. > ) > at /usr/src/sys/kern/vfs_vnops.c:195 > #10 0xffffffff808a2117 in kern_openat (td=3D0xfffffe000ff75470=2C fd=3D-1= 00=2C=20 > path=3D0x809ff80c0
=2C=20 > pathseg=3DUIO_USERSPACE=2C flags=3D1=2C mode=3DVariable "mode" is not= available. > ) > at /usr/src/sys/kern/vfs_syscalls.c:1132 > #11 0xffffffff80ad1fa6 in amd64_syscall (td=3D0xfffffe000ff75470=2C trace= d=3D0) > at subr_syscall.c:135 > #12 0xffffffff80abd967 in Xfast_syscall () > at /usr/src/sys/amd64/amd64/exception.S:387 > #13 0x0000000801e5366c in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb)=20 >=20 >=20 > We have the coredump and the kernel.debug=2C if there is anything we can = do to help you identifying the origin of this issue. >=20 > Thank you very much >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe=2C send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" = From owner-freebsd-stable@FreeBSD.ORG Thu Aug 30 15:09:31 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 13037106566B for ; Thu, 30 Aug 2012 15:09:31 +0000 (UTC) (envelope-from norbert.aschendorff@yahoo.de) Received: from nm29-vm3.bullet.mail.gq1.yahoo.com (nm29-vm3.bullet.mail.gq1.yahoo.com [98.136.216.178]) by mx1.freebsd.org (Postfix) with SMTP id C945F8FC16 for ; Thu, 30 Aug 2012 15:09:30 +0000 (UTC) Received: from [98.137.12.60] by nm29.bullet.mail.gq1.yahoo.com with NNFMP; 30 Aug 2012 15:06:48 -0000 Received: from [208.71.42.207] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 30 Aug 2012 15:06:48 -0000 Received: from [127.0.0.1] by smtp218.mail.gq1.yahoo.com with NNFMP; 30 Aug 2012 15:06:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1346339208; bh=ub8231eEOQDZqiyhrRk6hKLk719PvNfrCukGjfuleAU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UMFJrRN/88SztoSsbCW0sSklwZHCepsaCW2ISCB0IdqwyuKdFdrHdPLs740nvX/YS3/A6Fpv+mpkgc4aGEj8oadfgXW5F7QyvrOU1FvV6H+/Elq257tv995r26R4nV6QzYTZtWikAU88Dpauh3FRs9fvfg8E+ujUSTavBlvYCE4= X-Yahoo-Newman-Id: 353660.52367.bm@smtp218.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: gCQCDu8VM1l4wkncYVnQhm8ViC.7jYe0HopnlbkDtoljhnO BcG8GJCfMg5jvd05OrNYDLScbbCSUugPKhtszGoHSGjPU_up4OdThEb19Ti0 kF_TAg1WJiBkbsfGHyCPcSt44g_5rf0y7a5wN_3nGBVDs_ROg2mZIEl1xM8K cloEdsv7mkIjMxhQg3B5STFSR4JyxqdvYO_VdKOgoJ_KwsvkxO592HixbFZF C_Pu7Et7HBaOvA2oGS80ecYHOfRQyL5PyZYAcuPyzmhCx1hE2vpUKVMEZaoN If1Y4hp1gxwi7vMk0CHYGwn5XkIjMqZE.YfsfZe4B184QG.YKBYp3y4tUesk ZbBaqyOVQ_mFqmVOEWrbQp2sRHXsE1_zDnr5mSpTjFYLX0gIyeIzRkO1Ncq_ Q9rlNRPN4eW3rUUFYUbPYxq97pzSotdFko36k4AOzOKf5D.r4qorkLTc5Sbt ZrhcQqcNOZ7ofx92VgRqlTKiYCQsIlOBNb_omLcIRwAI- X-Yahoo-SMTP: d20YFqmswBAWc4wd23BcX3DKFU.SSFWadKORXj_BQPQ- Received: from vostro-linux.goebo.site (norbert.aschendorff@85.216.84.153 with plain) by smtp218.mail.gq1.yahoo.com with SMTP; 30 Aug 2012 08:06:48 -0700 PDT Message-ID: <503F8186.4070906@yahoo.de> Date: Thu, 30 Aug 2012 17:06:46 +0200 From: Norbert Aschendorff User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120418 Icedove/11.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <503CE60F.8040007@yahoo.de> <503E5C14.9090001@yahoo.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: IPv4 vs. IPv6 Ethernet Performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 15:09:31 -0000 I tested it using tcpdump: http://nopaste.info/9394068f54_nl.html The length field says for each packet 1408 bytes, so that should be OK. The Wireshark instance on the iperf server says something like "16732 bytes on wire" for the most packets (not always with 16732 bytes, but most packets over 10,000) - could that be reassembled somehow? Norbert From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 03:27:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3E7B7106564A for ; Fri, 31 Aug 2012 03:27:46 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by mx1.freebsd.org (Postfix) with ESMTP id B6A4F8FC14 for ; Fri, 31 Aug 2012 03:27:45 +0000 (UTC) Received: by wibhr14 with SMTP id hr14so820613wib.13 for ; Thu, 30 Aug 2012 20:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=K6rQjexKJpTWiXNOGncECKwKgyhbxps4HI3wdoq06TY=; b=0BXat+KygbBLGrWrfo5zIEnBmNGvzwuY6ZzMUIHDZ5lxwwcqjDtNAsFSGMjo8Zw+/k hebZj7FAoJ1IIjaBmLKcccDIutdqOon2OIM0I13tFtlqFzoRQC8Lq4FXvXmtMM4n1mp8 DU/vveBFji+JjDdAGCTesr0/580TWABMqaCHry1Xm51ppCKTokfAGLWq+kZYE3wBUzHl 3jK6MQt8L7tUW+I/YJ6ArURlsgRlSIFHsuxQpBUbiFMPxahrpg7sOpg3wLsBfSrSROzE UiwGotqmvwZCnOE8OObgTLv97adt6kcOexwUcTX7DTzMhbtqv8x2gA25gyUf4j5j+s0B cYXA== MIME-Version: 1.0 Received: by 10.180.106.97 with SMTP id gt1mr1457451wib.5.1346383659348; Thu, 30 Aug 2012 20:27:39 -0700 (PDT) Received: by 10.223.63.76 with HTTP; Thu, 30 Aug 2012 20:27:39 -0700 (PDT) In-Reply-To: References: <9fa99b69aab3afdd72f5776406eb1b65@dweimer.net> <76d6a3d12030d89690a3b6d28c85f48b@dweimer.net> Date: Thu, 30 Aug 2012 20:27:39 -0700 Message-ID: From: Kevin Oberman To: dweimer@dweimer.net Content-Type: text/plain; charset=UTF-8 Cc: freebsd-stable@freebsd.org Subject: Re: cdrtools port installation failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 03:27:46 -0000 On Wed, Aug 29, 2012 at 5:26 PM, dweimer wrote: > On 2012-08-29 17:23, Kevin Oberman wrote: >> >> On Wed, Aug 29, 2012 at 1:59 PM, dweimer wrote: >>> >>> On 2012-08-29 14:31, dweimer wrote: >>>> >>>> >>>> On 2012-08-28 15:38, Kevin Oberman wrote: >>>>> >>>>> >>>>> On Tue, Aug 28, 2012 at 8:46 AM, dweimer wrote: >>>>>> >>>>>> >>>>>> Anyone else not able to get cdrtools to install on a Stable System? >>>>>> >>>>>> I have just recently synced my source and rebuilt world, and kernel, >>>>>> then >>>>>> installed. Now while trying to install the livecd port, the cdrtools >>>>>> dependency is failing to install. >>>>>> >>>>>> The port compiles fine (at least it doesn't stop reporting an error), >>>>>> but >>>>>> dies on the installation portion reporting a missing file. >>>>>> >>>>>> install: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav: >>>>>> No such file or directory *** [do-install] Error code 71 >>>>>> >>>>>> There is a cdda2wav.d and cdda2wav.o file in the directory its >>>>>> searching, >>>>>> however when I run this on my FreeBSD 9.0-RELEASE-p4 system, there is >>>>>> also a >>>>>> cdda2wav file with no extension. >>>>>> >>>>>> ls >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> /usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/ >>>>>> Dnull >>>>>> Inull >>>>>> aifc.d >>>>>> aifc.o >>>>>> aiff.d >>>>>> aiff.o >>>>>> base64.d >>>>>> base64.o >>>>>> cd_misc.d >>>>>> cd_misc.o >>>>>> cdda2wav.d >>>>>> cdda2wav.o >>>>>> config.cache >>>>>> config.log >>>>>> config.status >>>>>> interface.d >>>>>> interface.o >>>>>> ioctl.d >>>>>> ioctl.o >>>>>> lconfig.h >>>>>> local.cnf >>>>>> parse.d >>>>>> parse.o >>>>>> raw.d >>>>>> raw.o >>>>>> resample.d >>>>>> resample.o >>>>>> ringbuff.d >>>>>> ringbuff.o >>>>>> scsi_cdr.d >>>>>> scsi_cdr.o >>>>>> scsi_cmds.d >>>>>> scsi_cmds.o >>>>>> scsi_scan.d >>>>>> scsi_scan.o >>>>>> semshm.d >>>>>> semshm.o >>>>>> setuid.d >>>>>> setuid.o >>>>>> sndconfig.d >>>>>> sndconfig.o >>>>>> sun.d >>>>>> sun.o >>>>>> toc.d >>>>>> toc.o >>>>>> wav.d >>>>>> wav.o >>>>>> >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Dean E. Weimer >>>>>> http://www.dweimer.net/ >>>>> >>>>> >>>>> >>>>> How odd! I can't replicate this at all. >>>>> >>>>> I just made cdrtools-3.00_2 and I have: >>>>> cc -o OBJ/amd64-freebsd-cc/cdda2wav OBJ/amd64-freebsd-cc/cdda2wav.o >>>>> OBJ/amd64-freebsd-cc/interface.o OBJ/amd64-freebsd-cc/semshm.o >>>>> OBJ/amd64-freebsd-cc/resample.o OBJ/amd64-freebsd-cc/scsi_scan.o >>>>> OBJ/amd64-freebsd-cc/toc.o OBJ/amd64-freebsd-cc/wav.o >>>>> OBJ/amd64-freebsd-cc/sun.o OBJ/amd64-freebsd-cc/raw.o >>>>> OBJ/amd64-freebsd-cc/setuid.o OBJ/amd64-freebsd-cc/ringbuff.o >>>>> OBJ/amd64-freebsd-cc/sndconfig.o OBJ/amd64-freebsd-cc/scsi_cmds.o >>>>> OBJ/amd64-freebsd-cc/aiff.o OBJ/amd64-freebsd-cc/aifc.o >>>>> OBJ/amd64-freebsd-cc/scsi_cdr.o OBJ/amd64-freebsd-cc/cd_misc.o >>>>> OBJ/amd64-freebsd-cc/ioctl.o OBJ/amd64-freebsd-cc/base64.o >>>>> OBJ/amd64-freebsd-cc/parse.o -L../libs/amd64-freebsd-cc >>>>> -L../libs/amd64-freebsd-cc -L/usr/local/lib -L/usr/local/lib >>>>> -lscgcmd -lrscg -lscg -lparanoia -lcdrdeflt -ldeflt -lmdigest >>>>> -lschily -lcam >>>>> >>>>> And, as I expected, I find it: >>>>> # find work/cdrtools-3.00/ -name cdda2wav >>>>> work/cdrtools-3.00/cdda2wav >>>>> work/cdrtools-3.00/cdda2wav/OBJ/amd64-freebsd-cc/cdda2wav >>>>> >>>>> Look trough the log of your make and see if anything "odd" happened in >>>>> that step. It should be at the end of the section : >>>>> ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc/Inull" >>>>> ==> CONFIGURING LOCAL RULES "OBJ/amd64-freebsd-cc/local.cnf" >>>>> and just before: >>>>> ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdrecord" >>>>> >>>>> This was on a stable system updated on Aug. 16. >>>> >>>> >>>> >>>> Finally had a chance to get back to this today, I haven't updated the >>>> ports tree or source since the last run. Built again same problem, >>>> After looking, I did have everything set to build with clang, and >>>> changed it to use gcc, then bingo it installed. >>>> >>>> However the FreeBSD 9.0-RELEASE-p4 system did successfully use clang, >>>> both systems have world and kernel built with clang. >>>> >>>> Will run it again with clang and capture the output of the make >>>> operation. >>>> >>>> Contents of /etc/make.conf, includes using gcc for cdrtools: >>>> >>>> # Use OpenSSL from ports instead of base >>>> WITH_OPENSSL_PORT=yes >>>> >>>> # Avoid Building Ports Against X >>>> WITHOUT_X11=yes >>>> >>>> # Performance related options >>>> CFLAGS?= -O >>>> CLFAGS+= -pipe >>>> >>>> # Ignore Warnings >>>> NO_WERROR= >>>> WERROR= >>>> >>>> # ports which will only build with the base system GNU compiler (4.2) >>>> # the "make index" target also needs this >>>> .if target(index) | \ >>>> ${.CURDIR:M*/lang/gcc*} | \ >>>> ${.CURDIR:M*/lang/ruby*} | \ >>>> ${.CURDIR:M*/devel/binutils*} | \ >>>> ${.CURDIR:M*/sysutils/cdrtools*} | \ >>>> ${.CURDIR:M*/www/squid*} >>>> USE_GCC?=4.2 >>>> .endif >>>> >>>> # use clang unless gcc is explicitly required >>>> .if !defined(USE_GCC) >>>> .if !defined(CC) || ${CC} == "cc" >>>> CC=clang >>>> .endif >>>> .if !defined(CXX) || ${CXX} == "c++" >>>> CXX=clang++ >>>> .endif >>>> .if !defined(CPP) || ${CPP} == "cpp" >>>> CPP=clang-cpp >>>> .endif >>>> .endif >>>> >>>> # added by use.perl 2012-08-28 04:04:28 >>>> PERL_VERSION=5.16.0 >>> >>> >>> >>> This might, be the source of the problem, full output of make install >>> available here : >>> >>> ==> MAKING "all" ON SUBDIRECTORY "SRCROOT/cdda2wav" >>> gmake[1]: Entering directory >>> `/usr/ports/sysutils/cdrtools/work/cdrtools-3.00/cdda2wav' >>> ./RULES/local.cnf:43: OBJ/amd64-freebsd-cc/Inull: No such file or >>> directory >>> ./RULES/local.cnf:44: OBJ/amd64-freebsd-cc/local.cnf: No such file or >>> directory >>> ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc" >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> parse.c >>> \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/parse.d >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> base64.c >>> \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/base64.d >>> In file included from base64.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> ioctl.c >>> \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/ioctl.d >>> In file included from ioctl.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> ==> MAKING SYMLINKS in . >>> ln: ./config.guess: File exists >>> ln: ./config.sub: File exists >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> cd_misc.c \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/cd_misc.d >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> scsi_cdr.c \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/scsi_cdr.d >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> aifc.c \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/aifc.d >>> In file included from aifc.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> aiff.c \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/aiff.d >>> In file included from aiff.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> scsi_cmds.c \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/scsi_cmds.d >>> In file included from scsi_cmds.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> sndconfig.c \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/sndconfig.d >>> In file included from sndconfig.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> ringbuff.c \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/ringbuff.d >>> In file included from ringbuff.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> setuid.c >>> \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/setuid.d >>> In file included from setuid.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT raw.c >>> \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/raw.d >>> In file included from raw.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT sun.c >>> \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/sun.d >>> In file included from sun.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT wav.c >>> \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/wav.d >>> In file included from wav.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT toc.c >>> \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/toc.d >>> In file included from toc.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> scsi_scan.c \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/scsi_scan.d >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> resample.c \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/resample.d >>> In file included from resample.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> semshm.c >>> \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/semshm.d >>> In file included from semshm.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> interface.c \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/interface.d >>> In file included from interface.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> clang -M -DSCHILY_BUILD -IOBJ/amd64-freebsd-cc -I../incs/amd64-freebsd-cc >>> -I../include -I/usr/local/include -I/usr/local/include >>> -I../libcdrdeflt >>> -DFIFO -I../libscg -I../libparanoia -I../cdrecord -DSCHILY_PRINT >>> cdda2wav.c \ >>> | sed -e 's;^\(.*\)\.o[ >>> ]*:;OBJ/amd64-freebsd-cc/\1.o \1.d:;' > OBJ/amd64-freebsd-cc/cdda2wav.d >>> In file included from cdda2wav.c:2: >>> ./config.h:34:10: fatal error: 'lconfig.h' file not found >>> #include "lconfig.h" >>> ^ >>> 1 error generated. >>> >>> ==> MAKING DIRECTORY "OBJ/amd64-freebsd-cc/Inull" >>> ==> CONFIGURING LOCAL RULES "OBJ/amd64-freebsd-cc/local.cnf" >>> creating cache ./config.cache >>> checking host system type... amd64-unknown-freebsd9.1 >> >> >> Hmm. Color me confused: >>>> >>>> .if target(index) | \ >>>> ${.CURDIR:M*/lang/gcc*} | \ >>>> ${.CURDIR:M*/lang/ruby*} | \ >>>> ${.CURDIR:M*/devel/binutils*} | \ >>>> ${.CURDIR:M*/sysutils/cdrtools*} | \ >>>> ${.CURDIR:M*/www/squid*} >>>> USE_GCC?=4.2 >>>> .endif >> >> >> This seems to imply that base gcc4.2 will be used to build >> sysutils/cdrtools, but the build log clearly shows clang being used. >> >> All of my ports are built with gcc-4.2 by default, though some have >> Makefiles that force either gcc-4.6 or clang. >> >> The "./config.h:34:10: fatal error: 'lconfig.h' file not found" error >> is also reported by gcc. >> >> But you cut off the log a bit short. cdda2wav is not built in that >> stage. It is built in the following MAKING DIRECTORY >> "OBJ/amd64-freebsd-cc/Inull" section, and at the very end of that >> stage. It is the very last executable built in the lnull stage. > > > Yes I made that copy of the /etc/make.conf when I had it excluded from using > clang, works with that setup, when removed from the exclude list it fails. > The full output is at the url: > it was an awful lot to post in the email. Every listing of INULL is > followed by directory not found, that section was the only spot I saw > errors, and not just warnings. Sorry, but I think I have reached my level of incompetence. You will need to try to get the attention of someone who knows more about compilers in general and clang in specific. I suspect clang may need an added option, that is really just a guess. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 03:59:49 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49400106564A; Fri, 31 Aug 2012 03:59:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 829B78FC14; Fri, 31 Aug 2012 03:59:48 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V3xl3B041968; Fri, 31 Aug 2012 03:59:47 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q7V3xl4x041937; Fri, 31 Aug 2012 03:59:47 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 03:59:47 GMT Message-Id: <201208310359.q7V3xl4x041937@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 03:59:49 -0000 TB --- 2012-08-31 02:33:33 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-08-31 02:33:33 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-08-31 02:33:33 - starting RELENG_9 tinderbox run for ia64/ia64 TB --- 2012-08-31 02:33:33 - cleaning the object tree TB --- 2012-08-31 02:33:33 - cvsupping the source tree TB --- 2012-08-31 02:33:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/ia64/ia64/supfile TB --- 2012-08-31 02:34:47 - building world TB --- 2012-08-31 02:34:47 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 02:34:47 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 02:34:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 02:34:47 - SRCCONF=/dev/null TB --- 2012-08-31 02:34:47 - TARGET=ia64 TB --- 2012-08-31 02:34:47 - TARGET_ARCH=ia64 TB --- 2012-08-31 02:34:47 - TZ=UTC TB --- 2012-08-31 02:34:47 - __MAKE_CONF=/dev/null TB --- 2012-08-31 02:34:47 - cd /src TB --- 2012-08-31 02:34:47 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 02:34:48 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/ia64.ia64/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Update': sha512.c:(.text+0x4380): multiple definition of `SHA512_Update' /obj/ia64.ia64/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0x3bb0): first defined here /obj/ia64.ia64/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Final': sha512.c:(.text+0x4680): multiple definition of `SHA512_Final' /obj/ia64.ia64/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0x3d10): first defined here nc.lo: In function `_$$hide$$ nc.lo main': (.text+0x4502): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/ia64.ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 03:59:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 03:59:47 - ERROR: failed to build world TB --- 2012-08-31 03:59:47 - 3256.86 user 544.46 system 5173.99 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 04:47:52 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB1C4106564A; Fri, 31 Aug 2012 04:47:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 935BD8FC14; Fri, 31 Aug 2012 04:47:52 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V4lq36044863; Fri, 31 Aug 2012 04:47:52 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q7V4lprS044832; Fri, 31 Aug 2012 04:47:51 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 04:47:51 GMT Message-Id: <201208310447.q7V4lprS044832@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on mips/mips X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 04:47:53 -0000 TB --- 2012-08-31 03:44:17 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-08-31 03:44:17 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-08-31 03:44:17 - starting RELENG_9 tinderbox run for mips/mips TB --- 2012-08-31 03:44:17 - cleaning the object tree TB --- 2012-08-31 03:44:17 - cvsupping the source tree TB --- 2012-08-31 03:44:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/mips/mips/supfile TB --- 2012-08-31 03:45:20 - building world TB --- 2012-08-31 03:45:20 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 03:45:20 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 03:45:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 03:45:20 - SRCCONF=/dev/null TB --- 2012-08-31 03:45:20 - TARGET=mips TB --- 2012-08-31 03:45:20 - TARGET_ARCH=mips TB --- 2012-08-31 03:45:20 - TZ=UTC TB --- 2012-08-31 03:45:20 - __MAKE_CONF=/dev/null TB --- 2012-08-31 03:45:20 - cd /src TB --- 2012-08-31 03:45:20 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 03:45:23 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/mips.mipsel/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Update': sha512.c:(.text+0x5178): multiple definition of `SHA512_Update' /obj/mips.mipsel/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0xab9c): first defined here /obj/mips.mipsel/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Final': sha512.c:(.text+0x5408): multiple definition of `SHA512_Final' /obj/mips.mipsel/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0xadb0): first defined here nc.lo: In function `_$$hide$$ nc.lo main': (.text+0x2290): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/mips.mipsel/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 04:47:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 04:47:51 - ERROR: failed to build world TB --- 2012-08-31 04:47:51 - 2214.20 user 499.62 system 3814.45 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-mips-mips.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 05:32:06 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 923BD1065670; Fri, 31 Aug 2012 05:32:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 5232F8FC17; Fri, 31 Aug 2012 05:32:06 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V5W5P5076632; Fri, 31 Aug 2012 05:32:05 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q7V5W5hT076622; Fri, 31 Aug 2012 05:32:05 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 05:32:05 GMT Message-Id: <201208310532.q7V5W5hT076622@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 05:32:06 -0000 TB --- 2012-08-31 04:52:43 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-08-31 04:52:43 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-08-31 04:52:43 - starting RELENG_8 tinderbox run for amd64/amd64 TB --- 2012-08-31 04:52:43 - cleaning the object tree TB --- 2012-08-31 04:52:43 - cvsupping the source tree TB --- 2012-08-31 04:52:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/amd64/amd64/supfile TB --- 2012-08-31 04:52:56 - building world TB --- 2012-08-31 04:52:56 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 04:52:56 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 04:52:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 04:52:56 - SRCCONF=/dev/null TB --- 2012-08-31 04:52:56 - TARGET=amd64 TB --- 2012-08-31 04:52:56 - TARGET_ARCH=amd64 TB --- 2012-08-31 04:52:56 - TZ=UTC TB --- 2012-08-31 04:52:56 - __MAKE_CONF=/dev/null TB --- 2012-08-31 04:52:56 - cd /src TB --- 2012-08-31 04:52:56 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 04:52:57 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/amd64/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x2f70): first defined here /obj/amd64/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Update' changed from 244 in /obj/amd64/src/tmp/usr/lib/libmd.a(sha512c.o) to 278 in /obj/amd64/src/tmp/usr/lib/libmd.a(sha512c.o) /obj/amd64/src/tmp/usr/lib/libcrypto.a(sha512.o)(.text+0x15f0): In function `SHA512_Final': : multiple definition of `SHA512_Final' /obj/amd64/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x3070): first defined here /obj/amd64/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Final' changed from 191 in /obj/amd64/src/tmp/usr/lib/libmd.a(sha512c.o) to 542 in /obj/amd64/src/tmp/usr/lib/libmd.a(sha512c.o) nc.lo(.text+0x1d26): In function `_$$hide$$ nc.lo main': : warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/amd64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 05:32:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 05:32:05 - ERROR: failed to build world TB --- 2012-08-31 05:32:05 - 1823.63 user 338.70 system 2361.95 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-amd64-amd64.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 05:53:54 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5F0E2106566B; Fri, 31 Aug 2012 05:53:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 1FB188FC12; Fri, 31 Aug 2012 05:53:54 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V5rrbQ093712; Fri, 31 Aug 2012 05:53:53 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q7V5rrSV093695; Fri, 31 Aug 2012 05:53:53 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 05:53:53 GMT Message-Id: <201208310553.q7V5rrSV093695@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on arm/arm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 05:53:54 -0000 TB --- 2012-08-31 05:22:37 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-08-31 05:22:37 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-08-31 05:22:37 - starting RELENG_8 tinderbox run for arm/arm TB --- 2012-08-31 05:22:37 - cleaning the object tree TB --- 2012-08-31 05:22:37 - cvsupping the source tree TB --- 2012-08-31 05:22:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/arm/arm/supfile TB --- 2012-08-31 05:22:54 - building world TB --- 2012-08-31 05:22:54 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 05:22:54 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 05:22:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 05:22:54 - SRCCONF=/dev/null TB --- 2012-08-31 05:22:54 - TARGET=arm TB --- 2012-08-31 05:22:54 - TARGET_ARCH=arm TB --- 2012-08-31 05:22:54 - TZ=UTC TB --- 2012-08-31 05:22:54 - __MAKE_CONF=/dev/null TB --- 2012-08-31 05:22:54 - cd /src TB --- 2012-08-31 05:22:54 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 05:22:55 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] : multiple definition of `SHA512_Update' /obj/arm/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0xb0d4): first defined here /obj/arm/src/tmp/usr/lib/libcrypto.a(sha512.o)(.text+0x55d8): In function `SHA512_Final': : multiple definition of `SHA512_Final' /obj/arm/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0xb244): first defined here /obj/arm/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Final' changed from 228 in /obj/arm/src/tmp/usr/lib/libmd.a(sha512c.o) to 536 in /obj/arm/src/tmp/usr/lib/libmd.a(sha512c.o) nc.lo(.text+0x18e0): In function `$a': : warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/arm/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 05:53:53 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 05:53:53 - ERROR: failed to build world TB --- 2012-08-31 05:53:53 - 1418.01 user 325.89 system 1876.52 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 06:10:46 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 584A9106566B; Fri, 31 Aug 2012 06:10:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id F00198FC12; Fri, 31 Aug 2012 06:10:45 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V6Aj3U033754; Fri, 31 Aug 2012 06:10:45 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q7V6AjaO033750; Fri, 31 Aug 2012 06:10:45 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 06:10:45 GMT Message-Id: <201208310610.q7V6AjaO033750@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 06:10:46 -0000 TB --- 2012-08-31 05:32:05 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-08-31 05:32:05 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-08-31 05:32:05 - starting RELENG_8 tinderbox run for i386/i386 TB --- 2012-08-31 05:32:05 - cleaning the object tree TB --- 2012-08-31 05:32:05 - cvsupping the source tree TB --- 2012-08-31 05:32:05 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/i386/supfile TB --- 2012-08-31 05:32:19 - building world TB --- 2012-08-31 05:32:19 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 05:32:19 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 05:32:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 05:32:19 - SRCCONF=/dev/null TB --- 2012-08-31 05:32:19 - TARGET=i386 TB --- 2012-08-31 05:32:19 - TARGET_ARCH=i386 TB --- 2012-08-31 05:32:19 - TZ=UTC TB --- 2012-08-31 05:32:19 - __MAKE_CONF=/dev/null TB --- 2012-08-31 05:32:19 - cd /src TB --- 2012-08-31 05:32:19 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 05:32:19 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/i386/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x83a0): first defined here /obj/i386/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Update' changed from 296 in /obj/i386/src/tmp/usr/lib/libmd.a(sha512c.o) to 304 in /obj/i386/src/tmp/usr/lib/libmd.a(sha512c.o) /obj/i386/src/tmp/usr/lib/libcrypto.a(sha512.o)(.text+0x3d40): In function `SHA512_Final': : multiple definition of `SHA512_Final' /obj/i386/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x84d0): first defined here /obj/i386/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Final' changed from 206 in /obj/i386/src/tmp/usr/lib/libmd.a(sha512c.o) to 695 in /obj/i386/src/tmp/usr/lib/libmd.a(sha512c.o) nc.lo(.text+0x2086): In function `main': : warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/i386/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 06:10:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 06:10:45 - ERROR: failed to build world TB --- 2012-08-31 06:10:45 - 1800.41 user 332.57 system 2319.75 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 06:20:01 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1E070106564A; Fri, 31 Aug 2012 06:20:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id CF9C88FC0A; Fri, 31 Aug 2012 06:20:00 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V6K0hT078486; Fri, 31 Aug 2012 06:20:00 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q7V6K05N078479; Fri, 31 Aug 2012 06:20:00 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 06:20:00 GMT Message-Id: <201208310620.q7V6K05N078479@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 06:20:01 -0000 TB --- 2012-08-31 05:41:37 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-08-31 05:41:37 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-08-31 05:41:37 - starting RELENG_8 tinderbox run for i386/pc98 TB --- 2012-08-31 05:41:37 - cleaning the object tree TB --- 2012-08-31 05:41:37 - cvsupping the source tree TB --- 2012-08-31 05:41:37 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/i386/pc98/supfile TB --- 2012-08-31 05:41:50 - building world TB --- 2012-08-31 05:41:50 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 05:41:50 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 05:41:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 05:41:50 - SRCCONF=/dev/null TB --- 2012-08-31 05:41:50 - TARGET=pc98 TB --- 2012-08-31 05:41:50 - TARGET_ARCH=i386 TB --- 2012-08-31 05:41:50 - TZ=UTC TB --- 2012-08-31 05:41:50 - __MAKE_CONF=/dev/null TB --- 2012-08-31 05:41:50 - cd /src TB --- 2012-08-31 05:41:50 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 05:41:51 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/pc98/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x83a0): first defined here /obj/pc98/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Update' changed from 296 in /obj/pc98/src/tmp/usr/lib/libmd.a(sha512c.o) to 304 in /obj/pc98/src/tmp/usr/lib/libmd.a(sha512c.o) /obj/pc98/src/tmp/usr/lib/libcrypto.a(sha512.o)(.text+0x3d40): In function `SHA512_Final': : multiple definition of `SHA512_Final' /obj/pc98/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x84d0): first defined here /obj/pc98/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Final' changed from 206 in /obj/pc98/src/tmp/usr/lib/libmd.a(sha512c.o) to 695 in /obj/pc98/src/tmp/usr/lib/libmd.a(sha512c.o) nc.lo(.text+0x2086): In function `main': : warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/pc98/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 06:20:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 06:20:00 - ERROR: failed to build world TB --- 2012-08-31 06:20:00 - 1794.81 user 340.38 system 2302.96 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 06:24:46 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E3A71065670; Fri, 31 Aug 2012 06:24:46 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 613338FC15; Fri, 31 Aug 2012 06:24:46 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V6OjAB027210; Fri, 31 Aug 2012 06:24:45 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q7V6OjDR027189; Fri, 31 Aug 2012 06:24:45 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 06:24:45 GMT Message-Id: <201208310624.q7V6OjDR027189@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 06:24:46 -0000 TB --- 2012-08-31 03:59:47 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-08-31 03:59:47 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-08-31 03:59:47 - starting RELENG_9 tinderbox run for powerpc/powerpc TB --- 2012-08-31 03:59:47 - cleaning the object tree TB --- 2012-08-31 03:59:47 - cvsupping the source tree TB --- 2012-08-31 03:59:47 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/powerpc/powerpc/supfile TB --- 2012-08-31 04:00:26 - building world TB --- 2012-08-31 04:00:26 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 04:00:26 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 04:00:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 04:00:26 - SRCCONF=/dev/null TB --- 2012-08-31 04:00:26 - TARGET=powerpc TB --- 2012-08-31 04:00:26 - TARGET_ARCH=powerpc TB --- 2012-08-31 04:00:26 - TZ=UTC TB --- 2012-08-31 04:00:26 - __MAKE_CONF=/dev/null TB --- 2012-08-31 04:00:26 - cd /src TB --- 2012-08-31 04:00:26 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 04:00:28 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/powerpc.powerpc/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Update': sha512.c:(.text+0x5114): multiple definition of `SHA512_Update' /obj/powerpc.powerpc/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0x986c): first defined here /obj/powerpc.powerpc/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Final': sha512.c:(.text+0x52f8): multiple definition of `SHA512_Final' /obj/powerpc.powerpc/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0x9a48): first defined here nc.lo: In function `_$$hide$$ nc.lo main': (.text+0x21d0): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/powerpc.powerpc/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 06:24:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 06:24:45 - ERROR: failed to build world TB --- 2012-08-31 06:24:45 - 5937.84 user 817.49 system 8697.67 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 06:29:41 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19C6F106566B; Fri, 31 Aug 2012 06:29:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id B66A68FC17; Fri, 31 Aug 2012 06:29:40 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V6TeLQ087026; Fri, 31 Aug 2012 06:29:40 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q7V6Tehh087022; Fri, 31 Aug 2012 06:29:40 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 06:29:40 GMT Message-Id: <201208310629.q7V6Tehh087022@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 06:29:41 -0000 TB --- 2012-08-31 05:45:28 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-08-31 05:45:28 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-08-31 05:45:28 - starting RELENG_8 tinderbox run for ia64/ia64 TB --- 2012-08-31 05:45:28 - cleaning the object tree TB --- 2012-08-31 05:45:28 - cvsupping the source tree TB --- 2012-08-31 05:45:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/ia64/ia64/supfile TB --- 2012-08-31 05:45:45 - building world TB --- 2012-08-31 05:45:45 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 05:45:45 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 05:45:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 05:45:45 - SRCCONF=/dev/null TB --- 2012-08-31 05:45:45 - TARGET=ia64 TB --- 2012-08-31 05:45:45 - TARGET_ARCH=ia64 TB --- 2012-08-31 05:45:45 - TZ=UTC TB --- 2012-08-31 05:45:45 - __MAKE_CONF=/dev/null TB --- 2012-08-31 05:45:45 - cd /src TB --- 2012-08-31 05:45:45 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 05:45:45 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/ia64/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x3bb0): first defined here /obj/ia64/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Update' changed from 352 in /obj/ia64/src/tmp/usr/lib/libmd.a(sha512c.o) to 736 in /obj/ia64/src/tmp/usr/lib/libmd.a(sha512c.o) /obj/ia64/src/tmp/usr/lib/libcrypto.a(sha512.o)(.text+0x4680): In function `SHA512_Final': : multiple definition of `SHA512_Final' /obj/ia64/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x3d10): first defined here /obj/ia64/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Final' changed from 256 in /obj/ia64/src/tmp/usr/lib/libmd.a(sha512c.o) to 1152 in /obj/ia64/src/tmp/usr/lib/libmd.a(sha512c.o) nc.lo(.text+0x4502): In function `main': : warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/ia64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 06:29:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 06:29:40 - ERROR: failed to build world TB --- 2012-08-31 06:29:40 - 2195.48 user 354.92 system 2651.43 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-ia64-ia64.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 06:37:38 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7F4D01065673; Fri, 31 Aug 2012 06:37:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 4172C8FC12; Fri, 31 Aug 2012 06:37:38 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V6bbk1037628; Fri, 31 Aug 2012 06:37:37 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q7V6bbSg037621; Fri, 31 Aug 2012 06:37:37 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 06:37:37 GMT Message-Id: <201208310637.q7V6bbSg037621@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 06:37:38 -0000 TB --- 2012-08-31 06:04:40 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-08-31 06:04:40 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-08-31 06:04:40 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2012-08-31 06:04:40 - cleaning the object tree TB --- 2012-08-31 06:04:40 - cvsupping the source tree TB --- 2012-08-31 06:04:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2012-08-31 06:04:59 - building world TB --- 2012-08-31 06:04:59 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 06:04:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 06:04:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 06:04:59 - SRCCONF=/dev/null TB --- 2012-08-31 06:04:59 - TARGET=sparc64 TB --- 2012-08-31 06:04:59 - TARGET_ARCH=sparc64 TB --- 2012-08-31 06:04:59 - TZ=UTC TB --- 2012-08-31 06:04:59 - __MAKE_CONF=/dev/null TB --- 2012-08-31 06:04:59 - cd /src TB --- 2012-08-31 06:04:59 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 06:04:59 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/sparc64/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x37e0): first defined here /obj/sparc64/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Update' changed from 220 in /obj/sparc64/src/tmp/usr/lib/libmd.a(sha512c.o) to 344 in /obj/sparc64/src/tmp/usr/lib/libmd.a(sha512c.o) /obj/sparc64/src/tmp/usr/lib/libcrypto.a(sha512.o)(.text+0x2400): In function `SHA512_Final': : multiple definition of `SHA512_Final' /obj/sparc64/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x38c0): first defined here /obj/sparc64/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Final' changed from 184 in /obj/sparc64/src/tmp/usr/lib/libmd.a(sha512c.o) to 476 in /obj/sparc64/src/tmp/usr/lib/libmd.a(sha512c.o) nc.lo(.text+0x218c): In function `main': : warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 06:37:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 06:37:37 - ERROR: failed to build world TB --- 2012-08-31 06:37:37 - 1633.18 user 304.99 system 1976.73 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 06:39:29 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8182B1065676; Fri, 31 Aug 2012 06:39:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-legacy2.sentex.ca (freebsd-legacy2.sentex.ca [IPv6:2607:f3e0:0:3::6502:9c]) by mx1.freebsd.org (Postfix) with ESMTP id 29AD18FC20; Fri, 31 Aug 2012 06:39:29 +0000 (UTC) Received: from freebsd-legacy2.sentex.ca (localhost [127.0.0.1]) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V6dSv0047035; Fri, 31 Aug 2012 06:39:28 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-legacy2.sentex.ca (8.14.5/8.14.5/Submit) id q7V6dSFG047034; Fri, 31 Aug 2012 06:39:28 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 06:39:28 GMT Message-Id: <201208310639.q7V6dSFG047034@freebsd-legacy2.sentex.ca> X-Authentication-Warning: freebsd-legacy2.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 06:39:29 -0000 TB --- 2012-08-31 06:03:50 - tinderbox 2.9 running on freebsd-legacy2.sentex.ca TB --- 2012-08-31 06:03:50 - FreeBSD freebsd-legacy2.sentex.ca 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-08-31 06:03:50 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2012-08-31 06:03:50 - cleaning the object tree TB --- 2012-08-31 06:03:50 - cvsupping the source tree TB --- 2012-08-31 06:03:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2012-08-31 06:04:59 - building world TB --- 2012-08-31 06:04:59 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 06:04:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 06:04:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 06:04:59 - SRCCONF=/dev/null TB --- 2012-08-31 06:04:59 - TARGET=powerpc TB --- 2012-08-31 06:04:59 - TARGET_ARCH=powerpc TB --- 2012-08-31 06:04:59 - TZ=UTC TB --- 2012-08-31 06:04:59 - __MAKE_CONF=/dev/null TB --- 2012-08-31 06:04:59 - cd /src TB --- 2012-08-31 06:04:59 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 06:04:59 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/powerpc/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x986c): first defined here /obj/powerpc/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Update' changed from 476 in /obj/powerpc/src/tmp/usr/lib/libmd.a(sha512c.o) to 472 in /obj/powerpc/src/tmp/usr/lib/libmd.a(sha512c.o) /obj/powerpc/src/tmp/usr/lib/libcrypto.a(sha512.o)(.text+0x52f8): In function `SHA512_Final': : multiple definition of `SHA512_Final' /obj/powerpc/src/tmp/usr/lib/libmd.a(sha512c.o)(.text+0x9a48): first defined here /obj/powerpc/src/tmp/usr/bin/ld: Warning: size of symbol `SHA512_Final' changed from 280 in /obj/powerpc/src/tmp/usr/lib/libmd.a(sha512c.o) to 800 in /obj/powerpc/src/tmp/usr/lib/libmd.a(sha512c.o) nc.lo(.text+0x21d0): In function `main': : warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/powerpc/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 06:39:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 06:39:28 - ERROR: failed to build world TB --- 2012-08-31 06:39:28 - 1739.22 user 314.34 system 2138.70 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 07:15:23 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7FDDF1065670; Fri, 31 Aug 2012 07:15:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 4079D8FC0A; Fri, 31 Aug 2012 07:15:23 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V7FMfF011627; Fri, 31 Aug 2012 07:15:22 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q7V7FMiv011602; Fri, 31 Aug 2012 07:15:22 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 07:15:22 GMT Message-Id: <201208310715.q7V7FMiv011602@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on powerpc64/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 07:15:23 -0000 TB --- 2012-08-31 04:47:52 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-08-31 04:47:52 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-08-31 04:47:52 - starting RELENG_9 tinderbox run for powerpc64/powerpc TB --- 2012-08-31 04:47:52 - cleaning the object tree TB --- 2012-08-31 04:47:52 - cvsupping the source tree TB --- 2012-08-31 04:47:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/powerpc64/powerpc/supfile TB --- 2012-08-31 04:48:37 - building world TB --- 2012-08-31 04:48:37 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 04:48:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 04:48:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 04:48:37 - SRCCONF=/dev/null TB --- 2012-08-31 04:48:37 - TARGET=powerpc TB --- 2012-08-31 04:48:37 - TARGET_ARCH=powerpc64 TB --- 2012-08-31 04:48:37 - TZ=UTC TB --- 2012-08-31 04:48:37 - __MAKE_CONF=/dev/null TB --- 2012-08-31 04:48:37 - cd /src TB --- 2012-08-31 04:48:37 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 04:48:39 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/powerpc.powerpc64/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.opd+0x0): first defined here /obj/powerpc.powerpc64/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Update': sha512.c:(.opd+0x60): multiple definition of `SHA512_Update' /obj/powerpc.powerpc64/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.opd+0x30): first defined here /obj/powerpc.powerpc64/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Final': sha512.c:(.opd+0x90): multiple definition of `SHA512_Final' /obj/powerpc.powerpc64/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.opd+0x48): first defined here nc.lo:(.text+0x22bc): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/powerpc.powerpc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 07:15:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 07:15:22 - ERROR: failed to build world TB --- 2012-08-31 07:15:22 - 5980.55 user 826.02 system 8850.17 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-powerpc64-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 07:31:34 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 405F5106564A; Fri, 31 Aug 2012 07:31:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 0286E8FC1A; Fri, 31 Aug 2012 07:31:33 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V7VXf5080269; Fri, 31 Aug 2012 07:31:33 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q7V7VXxT080268; Fri, 31 Aug 2012 07:31:33 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 07:31:33 GMT Message-Id: <201208310731.q7V7VXxT080268@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 07:31:34 -0000 TB --- 2012-08-31 06:24:46 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-08-31 06:24:46 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-08-31 06:24:46 - starting RELENG_9 tinderbox run for sparc64/sparc64 TB --- 2012-08-31 06:24:46 - cleaning the object tree TB --- 2012-08-31 06:24:46 - cvsupping the source tree TB --- 2012-08-31 06:24:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/sparc64/sparc64/supfile TB --- 2012-08-31 06:25:23 - building world TB --- 2012-08-31 06:25:23 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 06:25:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 06:25:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 06:25:23 - SRCCONF=/dev/null TB --- 2012-08-31 06:25:23 - TARGET=sparc64 TB --- 2012-08-31 06:25:23 - TARGET_ARCH=sparc64 TB --- 2012-08-31 06:25:23 - TZ=UTC TB --- 2012-08-31 06:25:23 - __MAKE_CONF=/dev/null TB --- 2012-08-31 06:25:23 - cd /src TB --- 2012-08-31 06:25:23 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 06:25:24 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/sparc64.sparc64/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Update': sha512.c:(.text+0x2280): multiple definition of `SHA512_Update' /obj/sparc64.sparc64/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0x37e0): first defined here /obj/sparc64.sparc64/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Final': sha512.c:(.text+0x2400): multiple definition of `SHA512_Final' /obj/sparc64.sparc64/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0x38c0): first defined here nc.lo: In function `_$$hide$$ nc.lo main': (.text+0x218c): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/sparc64.sparc64/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 07:31:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 07:31:33 - ERROR: failed to build world TB --- 2012-08-31 07:31:33 - 2487.90 user 455.41 system 4007.39 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 08:45:33 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C5881065673; Fri, 31 Aug 2012 08:45:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 5D9798FC15; Fri, 31 Aug 2012 08:45:33 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q7V8jW9M065082; Fri, 31 Aug 2012 08:45:32 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q7V8jWgD065081; Fri, 31 Aug 2012 08:45:32 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 08:45:32 GMT Message-Id: <201208310845.q7V8jWgD065081@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on arm/arm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 08:45:33 -0000 TB --- 2012-08-31 07:45:00 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-08-31 07:45:00 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-08-31 07:45:00 - starting RELENG_9 tinderbox run for arm/arm TB --- 2012-08-31 07:45:00 - cleaning the object tree TB --- 2012-08-31 07:45:00 - cvsupping the source tree TB --- 2012-08-31 07:45:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/arm/arm/supfile TB --- 2012-08-31 07:46:21 - building world TB --- 2012-08-31 07:46:21 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 07:46:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 07:46:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 07:46:21 - SRCCONF=/dev/null TB --- 2012-08-31 07:46:21 - TARGET=arm TB --- 2012-08-31 07:46:21 - TARGET_ARCH=arm TB --- 2012-08-31 07:46:21 - TZ=UTC TB --- 2012-08-31 07:46:21 - __MAKE_CONF=/dev/null TB --- 2012-08-31 07:46:21 - cd /src TB --- 2012-08-31 07:46:21 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 07:46:22 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/arm.arm/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Update': sha512.c:(.text+0x5454): multiple definition of `SHA512_Update' /obj/arm.arm/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0xb0b4): first defined here /obj/arm.arm/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Final': sha512.c:(.text+0x55d8): multiple definition of `SHA512_Final' /obj/arm.arm/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0xb224): first defined here nc.lo: In function `_$$hide$$ nc.lo $a': _$$hide$$ nc.lo socks.c:(.text+0x18e0): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/arm.arm/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 08:45:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 08:45:32 - ERROR: failed to build world TB --- 2012-08-31 08:45:32 - 2100.91 user 497.43 system 3632.34 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-arm-arm.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 10:22:58 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 169BE1065673; Fri, 31 Aug 2012 10:22:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id CBE7F8FC0C; Fri, 31 Aug 2012 10:22:57 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q7VAMvcH040217; Fri, 31 Aug 2012 10:22:57 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q7VAMvUD040180; Fri, 31 Aug 2012 10:22:57 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 10:22:57 GMT Message-Id: <201208311022.q7VAMvUD040180@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on i386/i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 10:22:58 -0000 TB --- 2012-08-31 07:45:00 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-08-31 07:45:00 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-08-31 07:45:00 - starting RELENG_9 tinderbox run for i386/i386 TB --- 2012-08-31 07:45:00 - cleaning the object tree TB --- 2012-08-31 07:45:00 - cvsupping the source tree TB --- 2012-08-31 07:45:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/i386/i386/supfile TB --- 2012-08-31 07:46:23 - building world TB --- 2012-08-31 07:46:23 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 07:46:23 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 07:46:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 07:46:23 - SRCCONF=/dev/null TB --- 2012-08-31 07:46:23 - TARGET=i386 TB --- 2012-08-31 07:46:23 - TARGET_ARCH=i386 TB --- 2012-08-31 07:46:23 - TZ=UTC TB --- 2012-08-31 07:46:23 - __MAKE_CONF=/dev/null TB --- 2012-08-31 07:46:23 - cd /src TB --- 2012-08-31 07:46:23 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 07:46:23 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/i386.i386/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Update': sha512.c:(.text+0x3c00): multiple definition of `SHA512_Update' /obj/i386.i386/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0x83a0): first defined here /obj/i386.i386/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Final': sha512.c:(.text+0x3d40): multiple definition of `SHA512_Final' /obj/i386.i386/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0x84d0): first defined here nc.lo: In function `_$$hide$$ nc.lo main': (.text+0x2086): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/i386.i386/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 10:22:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 10:22:56 - ERROR: failed to build world TB --- 2012-08-31 10:22:56 - 6445.29 user 812.02 system 9476.73 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 10:24:05 2012 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C97F9106566B; Fri, 31 Aug 2012 10:24:05 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-stable.sentex.ca (freebsd-stable.sentex.ca [IPv6:2607:f3e0:0:3::6502:9b]) by mx1.freebsd.org (Postfix) with ESMTP id 8A17C8FC0C; Fri, 31 Aug 2012 10:24:05 +0000 (UTC) Received: from freebsd-stable.sentex.ca (localhost [127.0.0.1]) by freebsd-stable.sentex.ca (8.14.5/8.14.5) with ESMTP id q7VAO52m044900; Fri, 31 Aug 2012 10:24:05 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id q7VAO56l044895; Fri, 31 Aug 2012 10:24:05 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 31 Aug 2012 10:24:05 GMT Message-Id: <201208311024.q7VAO56l044895@freebsd-stable.sentex.ca> X-Authentication-Warning: freebsd-stable.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_9 tinderbox] failure on i386/pc98 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 10:24:05 -0000 TB --- 2012-08-31 07:45:00 - tinderbox 2.9 running on freebsd-stable.sentex.ca TB --- 2012-08-31 07:45:00 - FreeBSD freebsd-stable.sentex.ca 8.2-STABLE FreeBSD 8.2-STABLE #4: Wed Sep 28 13:48:49 UTC 2011 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2012-08-31 07:45:00 - starting RELENG_9 tinderbox run for i386/pc98 TB --- 2012-08-31 07:45:00 - cleaning the object tree TB --- 2012-08-31 07:45:00 - cvsupping the source tree TB --- 2012-08-31 07:45:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_9/i386/pc98/supfile TB --- 2012-08-31 07:46:21 - building world TB --- 2012-08-31 07:46:21 - CROSS_BUILD_TESTING=YES TB --- 2012-08-31 07:46:21 - MAKEOBJDIRPREFIX=/obj TB --- 2012-08-31 07:46:21 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-08-31 07:46:21 - SRCCONF=/dev/null TB --- 2012-08-31 07:46:21 - TARGET=pc98 TB --- 2012-08-31 07:46:21 - TARGET_ARCH=i386 TB --- 2012-08-31 07:46:21 - TZ=UTC TB --- 2012-08-31 07:46:21 - __MAKE_CONF=/dev/null TB --- 2012-08-31 07:46:21 - cd /src TB --- 2012-08-31 07:46:21 - /usr/bin/make -B buildworld >>> World build started on Fri Aug 31 07:46:22 UTC 2012 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/pc98.i386/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Update': sha512.c:(.text+0x3c00): multiple definition of `SHA512_Update' /obj/pc98.i386/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0x83a0): first defined here /obj/pc98.i386/src/tmp/usr/lib/libcrypto.a(sha512.o): In function `SHA512_Final': sha512.c:(.text+0x3d40): multiple definition of `SHA512_Final' /obj/pc98.i386/src/tmp/usr/lib/libmd.a(sha512c.o):sha512c.c:(.text+0x84d0): first defined here nc.lo: In function `_$$hide$$ nc.lo main': (.text+0x2086): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() *** Error code 1 Stop in /obj/pc98.i386/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-08-31 10:24:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-08-31 10:24:05 - ERROR: failed to build world TB --- 2012-08-31 10:24:05 - 6451.30 user 826.87 system 9544.84 real http://tinderbox.freebsd.org/tinderbox-releng_9-RELENG_9-i386-pc98.full From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 11:08:30 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8473106564A; Fri, 31 Aug 2012 11:08:30 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [84.237.50.39]) by mx1.freebsd.org (Postfix) with ESMTP id 787BB8FC19; Fri, 31 Aug 2012 11:08:30 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1T7P50-0008VJ-89; Fri, 31 Aug 2012 18:08:02 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id q7VB9r4f015575; Fri, 31 Aug 2012 18:09:54 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id q7VB9Wnf015482; Fri, 31 Aug 2012 18:09:32 +0700 (NOVT) (envelope-from danfe) Date: Fri, 31 Aug 2012 18:09:31 +0700 From: Alexey Dokuchaev To: Konstantin Belousov Message-ID: <20120831110931.GA10786@regency.nsu.ru> References: <20120227152238.GA2940@regency.nsu.ru> <201203050710.22871.hselasky@c2i.net> <20120827125943.GA68575@regency.nsu.ru> <201208271734.54814.hselasky@c2i.net> <20120828020750.GA61543@regency.nsu.ru> <20120828085656.GI33100@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120828085656.GI33100@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org, freebsd-usb@freebsd.org, Jung-uk Kim Subject: Re: Resume broken in 8.3-PRERELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 11:08:30 -0000 On Tue, Aug 28, 2012 at 11:56:56AM +0300, Konstantin Belousov wrote: > On Tue, Aug 28, 2012 at 09:07:51AM +0700, Alexey Dokuchaev wrote: > > Before zzz'ing: > > > > db> show intrcnt > > irq1: atkbd0 168 > > irq9: acpi0 8300 > > irc12: psm0 2 > > irq14: ata0 6301 > > irq16: bge0 uhci3 13 > > irq23: uhci0 ehci0 2 > > cpu0: timer 7306385 > > irq256: hdac0 30 > > > > After (within a minute after botched resume) > > > > db> show intrcnt > > irq1: atkbd0 479 > > irq9: cdpi0 8379 > > Was the output pasted verbatim ? I am curious about the irq9 name mangling > in the second paste. Sorry, just rerun the test, no mangling, it was a typo on my behalf due to copying by hand. ./danfe From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 18:26:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6E59106566B; Fri, 31 Aug 2012 18:26:18 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (m209-73.dsl.rawbw.com [198.144.209.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3C18FC12; Fri, 31 Aug 2012 18:26:18 +0000 (UTC) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.5/8.14.5) with ESMTP id q7VIQHaS007657; Fri, 31 Aug 2012 11:26:17 -0700 (PDT) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.5/8.14.5/Submit) id q7VIQHL7007656; Fri, 31 Aug 2012 11:26:17 -0700 (PDT) (envelope-from david) Date: Fri, 31 Aug 2012 11:26:17 -0700 From: David Wolfskill To: freebsd-stable Message-ID: <20120831182617.GC2990@albert.catwhisker.org> References: <1345697446.84337.11.camel@neo.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yLVHuoLXiP9kZBkt" Content-Disposition: inline In-Reply-To: <1345697446.84337.11.camel@neo.cse.buffalo.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: 9.1-RC1 installer [was: FreeBSD 9.1-RC1 Available...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 18:26:18 -0000 --yLVHuoLXiP9kZBkt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I had occasion yesterday to install FreeBSD on a machine (an HP Compaq dx7200 Slim Tower) that had never (AFAIK) had FreeBSD installed on it. Since I don't often use the installer, I thought it might be good to try the 9.1-RC1 installer. While the exercise was ultimately successful, I needed to make use of additional hardware (including a second FreeBSD machine -- my laptop) to complete it. Had I been trying to install with just the target machine and the USB drive (memstick), as far as I can tell, I would have ended up with a brick. I like to set up machines with a minimum of 3 slices -- e.g.: albert(8.3-S)[2] df -ht ufs Filesystem Size Used Avail Capacity Mounted on /dev/ad4s1a 1.5G 363M 1G 27% / /dev/ad4s1d 3.4G 378M 2.8G 12% /usr /dev/ad4s3d 7.8G 3.9G 3.3G 54% /var /dev/ad4s3e 96G 45G 42G 52% /common albert(8.3-S)[3]=20 While that only shows 2 of the slices, slice 2 is set up like slice 1 is; an excerpt from fstab: albert(8.3-S)[3] grep ufs /etc/fstab /dev/ad4s1a / ufs rw 1 1 /dev/ad4s1d /usr ufs ro 2 2 /dev/ad4s2a /S2 ufs rw,noauto 2 2 /dev/ad4s2d /S2/usr ufs rw,noauto 2 2 /dev/ad4s3d /var ufs rw 2 2 /dev/ad4s3e /common ufs rw 2 2 albert(8.3-S)[4]=20 When I am about to upgrade such a machine -- albert, there, generally gets updated weekly -- I "clone" the / and /usr file systems from the currently-booted slice to the other one, reboot from the copy, and upgrade it in place. If I have a problem, I can boot from the slice that it had been booted from before I started the upgrade, lick my wounds, and figure out what to do next. (Granted, it's very rare that I need to do that -- but I very much like having the ability to do so.) Accordingly, when I was to install 9.1-RC1 on the HPaq, the first slient (to the above) thing I recall noticing was that the installer was referring to "partitions" (in the context of reserving space for "other Operating Systems") which confused me a great deal: I thought those were "slices". It was fairly obvious (even to me) that the "automatic" option wouldn't suit my purposes; after a false start, I managed to use the Manual approach & set up the 3 slices; here's what "gpart show" says about it (now that it works): =3D> 63 156249937 ada0 MBR (74G) 63 20971503 1 freebsd [active] (10G) 20971566 20971503 2 freebsd (10G) 41943069 113246154 3 freebsd (54G) 155189223 1060777 - free - (518M) =3D> 0 20971503 ada0s1 BSD (10G) 0 4194304 1 freebsd-ufs (2.0G) 4194304 16777198 2 freebsd-ufs (8G) 20971502 1 - free - (512B) =3D> 0 20971503 ada0s2 BSD (10G) 0 4194304 1 freebsd-ufs (2.0G) 4194304 16777198 2 freebsd-ufs (8G) 20971502 1 - free - (512B) =3D> 0 113246154 ada0s3 BSD (54G) 0 12582912 1 freebsd-swap (6.0G) 12582912 41943040 2 freebsd-ufs (20G) 54525952 58720201 4 freebsd-ufs (28G) 113246153 1 - free - (512B) The first fairly major problem occurred once the installation was complete: I rebooted the system... or tried to. It wouldn't boot, and I couldn't even get the machine to go into BIOS "setup" mode (still can't, for that matter). I pulled the disk drive, then connected it to my laptop via one of those UCB <=3D> SATA adaptors; "gpart show" showed that slice 3 (ada0s3) was marked "active". Oops. I don't recall a point during the install where I had a chance to actually mention which slice I might want active. And absent other clues, I would have expected the slice that contained the file system that was to be mounted on / to get that honor. So using my laptop, I set slice 1 (ada0s1) as "active", then replaced the drive and tried again. No go. It seems that the boot0 code wasn't written to the disk, either. So I re-attached the drive to my laptop & ran "boot0cfg" to set to boot code -- and, while I was there, told the MBR that slice 1 would be a good place from which to boot. That finally worked. I was, however, a bit surprised to find that my script to accomplish the "cloning" didn't work without some ... exercise: it uses a "dump | restore" pipeline to read the (mounted) / and /usr & restore them (after newfs, of course) on the target slice. Well, dump wants to make a snapshot if it's reading from a FS mounted read/write, and that's apparently not (currently?) compatible with SU+J, which is the default that the installer used. (I was subsequently able to manually disable the journaling, clone the slice, and re-enable the journaling. A subsequent test verified that I could then boot from either slice 1 or slice 2, and that I could control this by running a script before rebooting.) So I got there, though I did encounter a bit of turbulence. :-} Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --yLVHuoLXiP9kZBkt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBBAcgACgkQmprOCmdXAD0tKgCePvgN12PUXi4OG78K4PZyuGRK 8usAoIP3K+F13EF4M/ZYSPg2BhbuwyQf =aPA4 -----END PGP SIGNATURE----- --yLVHuoLXiP9kZBkt-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 19:10:29 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2EA71065680 for ; Fri, 31 Aug 2012 19:10:29 +0000 (UTC) (envelope-from allbery.b@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 8A7898FC1D for ; Fri, 31 Aug 2012 19:10:29 +0000 (UTC) Received: by qadc11 with SMTP id c11so1389954qad.13 for ; Fri, 31 Aug 2012 12:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WIzMamLnOr46VFB6wH+9dUPKX47t7kw6SYETvPb7Y3s=; b=TgZGY62FsNdFIYLPdAXKWQrx/tJo3+1c7dCNv+fJHNbce3FiGJpOlsz1EWemQEpPpI 9oCv/cidxpmQ794TQ/ncSAgf+mGI5zFpemQ4tgP5tIWkb3PrJFjJR6WdzVsBvjEXHq9k Wo+i9SVk0x2Eh6uc1v6MYwZ7v4N6X1jLCmds5VqsuU7hzKERsYWhufsMbtXKLzRKFWgI lFkCzuzJeSL1uyDyx4JmQjmqwOmetdAHphx/Kn/NatAPotSHGZl7gJYrJSztPKz2CQW9 vRdJWx0GgcIygByTqcjpywfAfJLs811JwzNzYzLRYG6J8wF9Jl1ltBhYVuQ2av7rOmtb M9/w== MIME-Version: 1.0 Received: by 10.224.189.83 with SMTP id dd19mr20173157qab.45.1346440223392; Fri, 31 Aug 2012 12:10:23 -0700 (PDT) Received: by 10.49.95.230 with HTTP; Fri, 31 Aug 2012 12:10:23 -0700 (PDT) In-Reply-To: <20120831182617.GC2990@albert.catwhisker.org> References: <1345697446.84337.11.camel@neo.cse.buffalo.edu> <20120831182617.GC2990@albert.catwhisker.org> Date: Fri, 31 Aug 2012 15:10:23 -0400 Message-ID: From: Brandon Allbery To: David Wolfskill Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable Subject: Re: 9.1-RC1 installer [was: FreeBSD 9.1-RC1 Available...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 19:10:30 -0000 On Fri, Aug 31, 2012 at 2:26 PM, David Wolfskill wrote: > While the exercise was ultimately successful, I needed to make use of > additional hardware (including a second FreeBSD machine -- my laptop) to > complete it. Had I been trying to install with just the target machine > and the USB drive (memstick), as far as I can tell, I would have ended > up with a brick. > I can confirm this, and I *did* end up with a brick (went back and did it again with the 9.0-R installer to get a working system). Worse, it managed to damage the EFI partition and I'm still getting fallout from that I think. -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 19:12:25 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D97A81065674 for ; Fri, 31 Aug 2012 19:12:25 +0000 (UTC) (envelope-from bplank@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with ESMTP id 6EFCE8FC19 for ; Fri, 31 Aug 2012 19:12:25 +0000 (UTC) Received: (qmail 51980 invoked from network); 31 Aug 2012 15:05:43 -0400 Received: from blinky.gta.com (HELO ?10.10.1.112?) (10.10.1.112) by gta.com with ESMTP; 31 Aug 2012 15:05:43 -0400 Message-ID: <50410ACC.4010901@gta.com> Date: Fri, 31 Aug 2012 15:04:44 -0400 From: Brad Plank Organization: Global Technology Associates, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090303030901080409020305" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: VLAN and ARP table X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 19:12:26 -0000 This is a cryptographically signed message in MIME format. --------------ms090303030901080409020305 Content-Type: multipart/mixed; boundary="------------020109010500090509050302" This is a multi-part message in MIME format. --------------020109010500090509050302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable VLAN interfaces no longer show up in "arp -an", in FreeBSD 9.x, however, the VLAN appears to be fully functional. Any ideas? # ifconfig em0: flags=3D8843 metric 0 mtu 15= 00 options=3D9b ether 08:00:27:b7:11:3b inet 10.20.13.104 netmask 0xffff0000 broadcast 10.20.255.255 inet6 fe80::a00:27ff:feb7:113b%em0 prefixlen 64 scopeid 0x1 inet6 2620:3f:8000:1:d::104 prefixlen 64 nd6 options=3D21 media: Ethernet autoselect (1000baseT ) status: active lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet 127.0.0.1 netmask 0xff000000 nd6 options=3D21 vlan0: flags=3D8843 metric 0 mtu = 1500 options=3D3 ether 08:00:27:b7:11:3b inet 172.16.200.104 netmask 0xffffff00 broadcast 172.16.200.255 nd6 options=3D29 media: Ethernet autoselect (1000baseT ) status: active vlan: 115 parent interface: em0 # arp -an ? (10.20.13.112) at c8:60:00:c3:24:19 on em0 expires in 1181 seconds=20 [ethernet] ? (10.20.13.9) at 00:12:3f:20:b9:4c on em0 expires in 908 seconds [ethern= et] ? (10.20.13.104) at 08:00:27:b7:11:3b on em0 permanent [ethernet] ? (10.20.13.110) at 00:90:fb:02:db:e8 on em0 expires in 448 seconds=20 [ethernet] ? (10.20.13.109) at 08:00:27:7c:19:d5 on em0 expires in 663 seconds=20 [ethernet] ? (10.20.254.254) at 00:00:5e:00:01:33 on em0 expires in 1063 seconds=20 [ethernet] Regards, Brad Plank --------------020109010500090509050302-- --------------ms090303030901080409020305-- From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 20:53:49 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85A551065670 for ; Fri, 31 Aug 2012 20:53:49 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3DF588FC1D for ; Fri, 31 Aug 2012 20:53:49 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 291D02842C; Fri, 31 Aug 2012 22:44:56 +0200 (CEST) Received: from [192.168.1.2] (static-84-242-120-26.net.upcbroadband.cz [84.242.120.26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 1441D28427; Fri, 31 Aug 2012 22:44:55 +0200 (CEST) Message-ID: <50412248.30107@quip.cz> Date: Fri, 31 Aug 2012 22:44:56 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Brandon Allbery References: <1345697446.84337.11.camel@neo.cse.buffalo.edu> <20120831182617.GC2990@albert.catwhisker.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable Subject: Re: 9.1-RC1 installer [was: FreeBSD 9.1-RC1 Available...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 20:53:49 -0000 Brandon Allbery wrote: > On Fri, Aug 31, 2012 at 2:26 PM, David Wolfskillwrote: > >> While the exercise was ultimately successful, I needed to make use of >> additional hardware (including a second FreeBSD machine -- my laptop) to >> complete it. Had I been trying to install with just the target machine >> and the USB drive (memstick), as far as I can tell, I would have ended >> up with a brick. >> > > I can confirm this, and I *did* end up with a brick (went back and did it > again with the 9.0-R installer to get a working system). Worse, it managed > to damage the EFI partition and I'm still getting fallout from that I think. Me too. I tried 9.1-RC1 installer last week to install FreeBSD on to 8GB USB flashdisk. Created two slices, add root partition on first slice (da1s1a). Installation went OK, but after reboot, the system did not came up. "error loading operating system" (it was BIOS message, so USB flashdisk did not contains any boot code, but da1s1 was marked as active) I did the installation again with the same result, so I tried FreeBSD 8.3 installer and everything was fine. Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Fri Aug 31 22:27:16 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D42DB106564A for ; Fri, 31 Aug 2012 22:27:16 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 63CD08FC15 for ; Fri, 31 Aug 2012 22:27:16 +0000 (UTC) Received: by wgbds11 with SMTP id ds11so2527443wgb.31 for ; Fri, 31 Aug 2012 15:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=HJEl9zxcwRnYGTroAf/SIZYiwc4Zhws703hFMot6dsE=; b=gwT3+b6qL37EQpgAyTJ69TUZ3e2a4Ensg+QCe2wAoAWxlO7MSj5XN5AB0bhk26gIKs 5fCmdevBfkBXT5nL3yzWVuVDDAKr1RXKEX4Qvy2oJhSN+p6/cYBSHtAXXJk5s0/K99Rc IfadSfLaAlpA3INZxsX3xSwg7mQjNhe1F1UwGAHr3Tzse8RiVh61+mPc/D5NGi/wmfEf BMRS4f6dkoe+HrtIxRVXjqQ7NInUmqS5UlKWbuJwgyJCaNa3jy2HFB6YByUtFZgQQFK9 oOwdFAH4NlDaCOqPt8BlhT+yzAj/B4wCsHtWuQnDjcrwgVCd3hqqyBgzAJxTtP+J5sa7 3C/w== Received: by 10.180.100.37 with SMTP id ev5mr7313759wib.5.1346452035196; Fri, 31 Aug 2012 15:27:15 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.223.153.200 with HTTP; Fri, 31 Aug 2012 15:26:55 -0700 (PDT) In-Reply-To: <503F8186.4070906@yahoo.de> References: <503CE60F.8040007@yahoo.de> <503E5C14.9090001@yahoo.de> <503F8186.4070906@yahoo.de> From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Sat, 1 Sep 2012 00:26:55 +0200 X-Google-Sender-Auth: XMgcJ6dSXpWtDVGyU-4g1joR0pY Message-ID: To: Norbert Aschendorff Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: IPv4 vs. IPv6 Ethernet Performance X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 22:27:16 -0000 On Thu, Aug 30, 2012 at 5:06 PM, Norbert Aschendorff wrote: > I tested it using tcpdump: http://nopaste.info/9394068f54_nl.html > The length field says for each packet 1408 bytes, so that should be OK. > TCP the packet size is OK (MSS negociated), it's in IPv6 UDP mode that iperf have a problem with the default packet size: "iperf -V -u -c desthost" "tcpdump host desthost" output (notice the frag and default length): 00:08:33.256304 IP6 (flowlabel 0x09036, hlim 64, next-header Fragment (44) payload length: 1440) 2001:db8::1 > 2001:db8::2: frag (0x3c8d768a:0|1432) 39065 > commplex-link: UDP, length 1470 00:08:33.256307 IP6 (flowlabel 0x09036, hlim 64, next-header Fragment (44) payload length: 54) 2001:db8::1 > 2001:db8::2: frag (0x3c8d768a:1432|46) 00:08:33.256317 IP6 (flowlabel 0x09036, hlim 64, next-header Fragment (44) payload length: 1440) 2001:db8::1 > 2001:db8::2: frag (0x6f6f083c:0|1432) 39065 > commplex-link: UDP, length 1470 00:08:33.256320 IP6 (flowlabel 0x09036, hlim 64, next-header Fragment (44) payload length: 54) 2001:db8::1 > 2001:db8::1: frag (0x6f6f083c:1432|46) Regards, olivier From owner-freebsd-stable@FreeBSD.ORG Sat Sep 1 08:03:18 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA097106564A for ; Sat, 1 Sep 2012 08:03:18 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2202D8FC08 for ; Sat, 1 Sep 2012 08:03:17 +0000 (UTC) Received: from [172.25.24.201] (rwpc15.mby.riverwillow.net.au [172.25.24.201]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.5/8.14.5) with ESMTP id q81837Zd072253 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Sat, 1 Sep 2012 18:03:09 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1346486589; bh=mBQU3xSfY8q73V+tORBBxHaavYdfFkFGFGmSDVqsGvs=; h=Date:From:To:Subject:References:In-Reply-To; b=vynThirvO+hLHXU0wD9swTIxvhc/aj86b7cQvhQXpF8PxE4swnPRboSMxAxi1uvi9 W4x8FQmRI4L+9XCsKgpSQ5MnKNAfONeFkkZaVwWYYLLxkl2VmxT3BiHrYqUpa05Tjq i7y2+NpVYX5UfR4d0mLaQiLH1KJ+H4Vy0I6H7KCo= Message-ID: <5041C131.90402@riverwillow.com.au> Date: Sat, 01 Sep 2012 18:02:57 +1000 From: John Marshall Organization: Riverwillow Pty Ltd User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:14.0) Gecko/20120812 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <1345697446.84337.11.camel@neo.cse.buffalo.edu> <20120831182617.GC2990@albert.catwhisker.org> <50412248.30107@quip.cz> In-Reply-To: <50412248.30107@quip.cz> X-Enigmail-Version: 1.4.3 OpenPGP: id=A29A84A2; url=http://pki.riverwillow.com.au/pgp/johnmarshall.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD3513EEEDA2FD71A7E5AE06E" Subject: Re: 9.1-RC1 installer [was: FreeBSD 9.1-RC1 Available...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 08:03:18 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD3513EEEDA2FD71A7E5AE06E Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've just installed an Intel server from a 9.1-RC1 CD. This was my first encounter with the new installer. I didn't like the look of what the Auto option showed me for drive partitioning, so I tried Manual and found that confusing. I ended up choosing the Shell option for drive partitioning and carved up the drive exactly as I wanted it, including setting the active partition [bootme], using gpart(8) and newfs(8). Upon entering the shell from the menu, a comprehensive message was printed explaining that, after I had finished creating the new filesystems, I would need to create an fstab file and then mount the newly-created filesystems. I followed those instructions and, when I exited the shell, watched the installation proceed flawlessly and then booted the new system. So, my installation had a happy ending. I didn't end up with a brick but I gave up on the menu-driven filesystem creation. --=20 John Marshall --------------enigD3513EEEDA2FD71A7E5AE06E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlBBwTsACgkQw/tAaKKahKJScgCfePkgDJbDIHRXEo2mAWWTu2UA ZNAAoMLC/7cSFTERdVu7BuaowsrzZBof =c74V -----END PGP SIGNATURE----- --------------enigD3513EEEDA2FD71A7E5AE06E-- From owner-freebsd-stable@FreeBSD.ORG Sat Sep 1 10:49:55 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DBCA1065673 for ; Sat, 1 Sep 2012 10:49:55 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0296A8FC18 for ; Sat, 1 Sep 2012 10:49:53 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1T7lGu-00040R-LZ for freebsd-stable@freebsd.org; Sat, 01 Sep 2012 12:49:48 +0200 Received: from 79-139-19-75.prenet.pl ([79.139.19.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Sep 2012 12:49:48 +0200 Received: from jb.1234abcd by 79-139-19-75.prenet.pl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 01 Sep 2012 12:49:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: jb Date: Sat, 1 Sep 2012 10:49:34 +0000 (UTC) Lines: 14 Message-ID: References: <1345697446.84337.11.camel@neo.cse.buffalo.edu> <20120831182617.GC2990@albert.catwhisker.org> <50412248.30107@quip.cz> <5041C131.90402@riverwillow.com.au> 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: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 79.139.19.75 (Mozilla/5.0 (X11; FreeBSD i386; rv:15.0) Gecko/20100101 Firefox/15.0) Subject: Re: 9.1-RC1 installer [was: FreeBSD 9.1-RC1 Available...] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 10:49:55 -0000 John Marshall riverwillow.com.au> writes: > > I've just installed an Intel server from a 9.1-RC1 CD. This was my first > encounter with the new installer. I didn't like the look of what the > Auto option showed me for drive partitioning, so I tried Manual and > found that confusing. > ... Fair enough. But what should it loook like ? How to make it less confusing ? Can you elaborate here or file a PR# with details ? jb From owner-freebsd-stable@FreeBSD.ORG Sat Sep 1 18:45:46 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEA32106564A for ; Sat, 1 Sep 2012 18:45:46 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C60E8FC16 for ; Sat, 1 Sep 2012 18:45:44 +0000 (UTC) Received: from [192.168.248.32] ([192.168.248.32]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id q81IjfJC058770 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 2 Sep 2012 00:45:42 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <504257C9.3080502@norma.perm.ru> Date: Sun, 02 Sep 2012 00:45:29 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <50410ACC.4010901@gta.com> In-Reply-To: <50410ACC.4010901@gta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Sun, 02 Sep 2012 00:45:42 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru Subject: Re: VLAN and ARP table X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 18:45:46 -0000 Hi. On 01.09.2012 1:04, Brad Plank wrote: > VLAN interfaces no longer show up in "arp -an", in FreeBSD 9.x, however, > the VLAN appears to be fully functional. Any ideas? > > They do. arp -an ? (86.109.196.1) at 00:21:1b:d1:14:1b on vlan818 expires in 1192 seconds [vlan] ? (89.250.213.121) at d4:ca:6d:2a:aa:11 on vlan104 expires in 906 seconds [vlan] ? (89.250.210.65) at d4:ca:6d:2a:aa:11 on vlan104 expires in 1198 seconds [vlan] ? (128.127.144.7) at 00:50:56:a3:48:59 on vlan23 expires in 1188 seconds [vlan] ? (128.127.144.5) at 00:00:5e:00:01:0b on vlan23 expires in 1194 seconds [vlan] ? (128.127.144.2) at 00:02:b3:e9:8d:0e on vlan23 expires in 380 seconds [vlan] ? (128.127.144.1) at 00:1a:64:21:8e:80 on vlan23 expires in 1199 seconds [vlan] ? (192.168.9.43) at b8:c7:5d:91:8e:30 on vlan21 expires in 1176 seconds [vlan] ? (192.168.9.16) at 94:3a:f0:9f:a1:0b on vlan21 expires in 1103 seconds [vlan] ? (192.168.9.19) at 90:c1:15:1b:c9:f3 on vlan21 expires in 1102 seconds [vlan] Eugene.