From owner-freebsd-stable@FreeBSD.ORG Sun Apr 14 00:03:03 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A5F6774D; Sun, 14 Apr 2013 00:03:03 +0000 (UTC) (envelope-from cforgeron@acsi.ca) Received: from AA-Edge2007.acsi.ca (unknown [IPv6:2001:0:4137:9e76:de:32a:71bb:44fd]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9081854; Sun, 14 Apr 2013 00:03:03 +0000 (UTC) Received: from AA-EX0.acsi.ca (192.168.9.11) by AA-Edge2007.acsi.ca (192.168.9.15) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 13 Apr 2013 21:02:58 -0300 Received: from AA-EX0.acsi.ca ([::1]) by AA-EX0.acsi.ca ([::1]) with mapi id 14.02.0298.004; Sat, 13 Apr 2013 21:02:59 -0300 From: Chris Forgeron To: Jeremy Chadwick Subject: RE: kern/165903: mbuf leak Thread-Topic: kern/165903: mbuf leak Thread-Index: Ac4biy6IuBBGvQzdTV+HyC/2Nu0hHwa1JruAAACBygAAjhhzIAAIKF2AAAYpjSA= Date: Sun, 14 Apr 2013 00:02:56 +0000 Message-ID: <46D80686C389884BB0C047851038EC456D8C0F52@AA-EX0.acsi.ca> References: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> <20130410235347.GA38492@icarus.home.lan> <20130411000818.GA38803@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0EF0@AA-EX0.acsi.ca> <20130413235031.GA8212@icarus.home.lan> In-Reply-To: <20130413235031.GA8212@icarus.home.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.9.108] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-stable@freebsd.org" , Jack Vogel , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 00:03:03 -0000 Interesting about the drivers - I will look into that tomorrow, I could be = on an older version. I started down that path a little while ago, but when = pkng wasn't quite ready, I just reverted to the old ways/ommands that seeme= d to work.=20 Here is the dump of the requested commands. I will point out the most inter= esting one first: dmsg It's flooded with: arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast arp: 43:05:43:05:00:00 is multicast Checking an older 9.0-STABLE from july, I see the same message flood in dme= sg, but these machines are not exhausting mbuf. Perhaps there is a leak in handling this condition? Please note: I will also have this problem with the vmware VMXNET3 driver u= sing vmware's official tools, so it's not just em at fault.=20 Here is the rest. I left pciconf verbose Thanks.=20 root@test:/usr/home/aatech # sysctl -a dev.em.0=20 dev.em.0.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.0.5 dev.em.0.%driver: em dev.em.0.%location: slot=3D0 function=3D0 handle=3D\_SB_.PCI0.P2P0.S1F0 dev.em.0.%pnpinfo: vendor=3D0x8086 device=3D0x100f subvendor=3D0x15ad subde= vice=3D0x0750 class=3D0x020000 dev.em.0.%parent: pci2 dev.em.0.nvm: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.flow_control: 3 dev.em.0.mbuf_alloc_fail: 0 dev.em.0.cluster_alloc_fail: 0 dev.em.0.dropped: 0 dev.em.0.tx_dma_fail: 0 dev.em.0.tx_desc_fail1: 0 dev.em.0.tx_desc_fail2: 0 dev.em.0.rx_overruns: 0 dev.em.0.watchdog_timeouts: 0 dev.em.0.device_control: 1086325321 dev.em.0.rx_control: 32770 dev.em.0.fc_high_water: 47104 dev.em.0.fc_low_water: 45604 dev.em.0.fifo_workaround: 0 dev.em.0.fifo_reset: 0 dev.em.0.txd_head: 23 dev.em.0.txd_tail: 24 dev.em.0.rxd_head: 138 dev.em.0.rxd_tail: 137 dev.em.0.mac_stats.excess_coll: 0 dev.em.0.mac_stats.single_coll: 0 dev.em.0.mac_stats.multiple_coll: 0 dev.em.0.mac_stats.late_coll: 0 dev.em.0.mac_stats.collision_count: 0 dev.em.0.mac_stats.symbol_errors: 0 dev.em.0.mac_stats.sequence_errors: 0 dev.em.0.mac_stats.defer_count: 0 dev.em.0.mac_stats.missed_packets: 0 dev.em.0.mac_stats.recv_no_buff: 0 dev.em.0.mac_stats.recv_undersize: 0 dev.em.0.mac_stats.recv_fragmented: 0 dev.em.0.mac_stats.recv_oversize: 0 dev.em.0.mac_stats.recv_jabber: 0 dev.em.0.mac_stats.recv_errs: 0 dev.em.0.mac_stats.crc_errs: 0 dev.em.0.mac_stats.alignment_errs: 0 dev.em.0.mac_stats.coll_ext_errs: 0 dev.em.0.mac_stats.xon_recvd: 0 dev.em.0.mac_stats.xon_txd: 0 dev.em.0.mac_stats.xoff_recvd: 0 dev.em.0.mac_stats.xoff_txd: 0 dev.em.0.mac_stats.total_pkts_recvd: 73008 dev.em.0.mac_stats.good_pkts_recvd: 49029 dev.em.0.mac_stats.bcast_pkts_recvd: 0 dev.em.0.mac_stats.mcast_pkts_recvd: 0 dev.em.0.mac_stats.rx_frames_64: 0 dev.em.0.mac_stats.rx_frames_65_127: 45990 dev.em.0.mac_stats.rx_frames_128_255: 2446 dev.em.0.mac_stats.rx_frames_256_511: 592 dev.em.0.mac_stats.rx_frames_512_1023: 1 dev.em.0.mac_stats.rx_frames_1024_1522: 0 dev.em.0.mac_stats.good_octets_recvd: 3809187 dev.em.0.mac_stats.good_octets_txd: 441363 dev.em.0.mac_stats.total_pkts_txd: 3497 dev.em.0.mac_stats.good_pkts_txd: 3497 dev.em.0.mac_stats.bcast_pkts_txd: 0 dev.em.0.mac_stats.mcast_pkts_txd: 0 dev.em.0.mac_stats.tx_frames_64: 418 dev.em.0.mac_stats.tx_frames_65_127: 2678 dev.em.0.mac_stats.tx_frames_128_255: 131 dev.em.0.mac_stats.tx_frames_256_511: 213 dev.em.0.mac_stats.tx_frames_512_1023: 49 dev.em.0.mac_stats.tx_frames_1024_1522: 8 dev.em.0.mac_stats.tso_txd: 0 dev.em.0.mac_stats.tso_ctx_fail: 0 dev.em.0.wake: 0 root@test:/usr/home/aatech # cat pciconf.txt hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x197615ad chip=3D0x7190808= 6 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '440BX/ZX/DX - 82443BX/ZX/DX Host bridge' class =3D bridge subclass =3D HOST-PCI pcib1@pci0:0:1:0: class=3D0x060400 card=3D0x00000000 chip=3D0x7191808= 6 rev=3D0x01 hdr=3D0x01 vendor =3D 'Intel Corporation' device =3D '440BX/ZX/DX - 82443BX/ZX/DX AGP bridge' class =3D bridge subclass =3D PCI-PCI isab0@pci0:0:7:0: class=3D0x060100 card=3D0x197615ad chip=3D0x7110808= 6 rev=3D0x08 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4 ISA' class =3D bridge subclass =3D PCI-ISA atapci0@pci0:0:7:1: class=3D0x01018a card=3D0x197615ad chip=3D0x7111808= 6 rev=3D0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4 IDE' class =3D mass storage subclass =3D ATA bar [20] =3D type I/O Port, range 32, base 0x10c0, size 16, enabled none0@pci0:0:7:3: class=3D0x068000 card=3D0x197615ad chip=3D0x7113808= 6 rev=3D0x08 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82371AB/EB/MB PIIX4 ACPI' class =3D bridge none1@pci0:0:7:7: class=3D0x088000 card=3D0x074015ad chip=3D0x074015a= d rev=3D0x10 hdr=3D0x00 vendor =3D 'VMware' device =3D 'Virtual Machine Communication Interface' class =3D base peripheral bar [10] =3D type I/O Port, range 32, base 0x1080, size 64, enabled bar [14] =3D type Memory, range 64, base 0xd0000000, size 8192, enabl= ed cap 05[40] =3D MSI supports 1 message, 64 bit=20 cap 11[58] =3D MSI-X supports 2 messages in map 0x14 vgapci0@pci0:0:15:0: class=3D0x030000 card=3D0x040515ad chip=3D0x040515a= d rev=3D0x00 hdr=3D0x00 vendor =3D 'VMware' device =3D 'SVGA II Adapter' class =3D display subclass =3D VGA bar [10] =3D type I/O Port, range 32, base 0x10d0, size 16, enabled bar [14] =3D type Prefetchable Memory, range 32, base 0xd8000000, siz= e 67108864, enabled bar [18] =3D type Memory, range 32, base 0xd0800000, size 8388608, en= abled cap 09[40] =3D vendor (length 0) mpt0@pci0:0:16:0: class=3D0x010000 card=3D0x197615ad chip=3D0x0030100= 0 rev=3D0x01 hdr=3D0x00 vendor =3D 'LSI Logic / Symbios Logic' device =3D '53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI' class =3D mass storage subclass =3D SCSI bar [10] =3D type I/O Port, range 32, base 0x1400, size 256, enabled bar [14] =3D type Memory, range 64, base 0xd0040000, size 131072, ena= bled bar [1c] =3D type Memory, range 64, base 0xd0020000, size 131072, ena= bled pcib2@pci0:0:17:0: class=3D0x060401 card=3D0x079015ad chip=3D0x079015a= d rev=3D0x02 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI bridge' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x079015ad pcib3@pci0:0:21:0: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib4@pci0:0:21:1: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib5@pci0:0:21:2: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib6@pci0:0:21:3: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib7@pci0:0:21:4: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib8@pci0:0:21:5: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib9@pci0:0:21:6: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib10@pci0:0:21:7: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib11@pci0:0:22:0: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib12@pci0:0:22:1: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib13@pci0:0:22:2: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib14@pci0:0:22:3: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib15@pci0:0:22:4: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib16@pci0:0:22:5: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib17@pci0:0:22:6: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib18@pci0:0:22:7: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib19@pci0:0:23:0: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib20@pci0:0:23:1: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib21@pci0:0:23:2: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib22@pci0:0:23:3: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib23@pci0:0:23:4: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib24@pci0:0:23:5: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib25@pci0:0:23:6: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib26@pci0:0:23:7: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib27@pci0:0:24:0: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib28@pci0:0:24:1: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib29@pci0:0:24:2: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib30@pci0:0:24:3: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib31@pci0:0:24:4: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib32@pci0:0:24:5: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib33@pci0:0:24:6: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 pcib34@pci0:0:24:7: class=3D0x060400 card=3D0x07a015ad chip=3D0x07a015a= d rev=3D0x01 hdr=3D0x01 vendor =3D 'VMware' device =3D 'PCI Express Root Port' class =3D bridge subclass =3D PCI-PCI cap 0d[40] =3D PCI Bridge card=3D0x07a015ad cap 01[48] =3D powerspec 3 supports D0 D3 current D0 cap 10[50] =3D PCI-Express 2 root port slot max data 128(128) link x32(= x32) speed 5.0(5.0) cap 05[8c] =3D MSI supports 1 message, 64 bit, vector masks=20 em0@pci0:2:0:0: class=3D0x020000 card=3D0x075015ad chip=3D0x100f8086 rev=3D= 0x01 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D '82545EM Gigabit Ethernet Controller (Copper)' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 64, base 0xd1020000, size 131072, ena= bled bar [18] =3D type Memory, range 64, base 0xd1000000, size 65536, enab= led bar [20] =3D type I/O Port, range 32, base 0x2000, size 64, enabled cap 01[dc] =3D powerspec 2 supports D0 D3 current D0 cap 07[e4] =3D PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split t= ransaction uhci0@pci0:2:2:0: class=3D0x0c0300 card=3D0x197615ad chip=3D0x077415a= d rev=3D0x00 hdr=3D0x00 vendor =3D 'VMware' device =3D 'USB1.1 UHCI Controller' class =3D serial bus subclass =3D USB bar [20] =3D type I/O Port, range 32, base 0x2040, size 32, enabled ehci0@pci0:2:3:0: class=3D0x0c0320 card=3D0x077015ad chip=3D0x077015a= d rev=3D0x00 hdr=3D0x00 vendor =3D 'VMware' device =3D 'USB2 EHCI Controller' class =3D serial bus subclass =3D USB bar [10] =3D type Memory, range 32, base 0xd1010000, size 4096, enabl= ed none2@pci0:3:0:0: class=3D0x020000 card=3D0x07b015ad chip=3D0x07b015a= d rev=3D0x01 hdr=3D0x00 vendor =3D 'VMware' device =3D 'VMXNET3 Ethernet Controller' class =3D network subclass =3D ethernet bar [10] =3D type Memory, range 32, base 0xd2404000, size 4096, enabl= ed bar [14] =3D type Memory, range 32, base 0xd2403000, size 4096, enabl= ed bar [18] =3D type Memory, range 32, base 0xd2400000, size 8192, enabl= ed bar [1c] =3D type I/O Port, range 32, base 0x4000, size 16, enabled cap 01[40] =3D powerspec 3 supports D0 D1 D2 D3 current D0 cap 10[48] =3D PCI-Express 2 endpoint max data 128(128) link x32(x32) speed 5.0(5.0) cap 05[84] =3D MSI supports 1 message, 64 bit=20 cap 11[9c] =3D MSI-X supports 25 messages in map 0x18 ecap 0003[100] =3D Serial 1 ff5650003a0d80fe From owner-freebsd-stable@FreeBSD.ORG Sun Apr 14 00:29:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A012AA0 for ; Sun, 14 Apr 2013 00:29:21 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:96]) by mx1.freebsd.org (Postfix) with ESMTP id 3C6FA18C7 for ; Sun, 14 Apr 2013 00:29:21 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta09.emeryville.ca.mail.comcast.net with comcast id PcTS1l0031Y3wxoA9cVLtK; Sun, 14 Apr 2013 00:29:20 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta15.emeryville.ca.mail.comcast.net with comcast id PcVL1l0051t3BNj8bcVLFW; Sun, 14 Apr 2013 00:29:20 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E70E673A33; Sat, 13 Apr 2013 17:29:19 -0700 (PDT) Date: Sat, 13 Apr 2013 17:29:19 -0700 From: Jeremy Chadwick To: Chris Forgeron Subject: Re: kern/165903: mbuf leak Message-ID: <20130414002919.GA9076@icarus.home.lan> References: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> <20130410235347.GA38492@icarus.home.lan> <20130411000818.GA38803@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0EF0@AA-EX0.acsi.ca> <20130413235031.GA8212@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0F52@AA-EX0.acsi.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D80686C389884BB0C047851038EC456D8C0F52@AA-EX0.acsi.ca> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1365899360; bh=pJUSMlnrDhNrxEUbgm1l5iUlvKxDmXxIxOZ7th5yFLo=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=FnybEd540QeXQxlU0OBSBJognR51Zu7fkCrglNsI6MKlq0beiUf6LvHVnwdHlGVOi 1P6z8fdWqTpZHjUBnJx9LZs3i/bkWJi6vXTwR+4AjcZsBVRTzIAwhfRlMnumyXBR4Z Yc4SNq2U7kqx4okeunadOu6LpQMQEbqbW0mVw31PVMxVHPokp9TYs29ZkcSO531IWL S/q4Z9PGFCOX8x9Md2JclfmNFoFg7DtdmYeEBCH0L5za0GfRLk4+Pma2yoHVU/nLtw On6kmwxjQA2Vlbe0umuvI8Pd5/dppndE7Nvt/rttJ9k8Lqc7rVp8KrjO6TPmCgVr33 Sdo8es6mxAgYw== Cc: Gleb Smirnoff , "freebsd-stable@freebsd.org" , Jack Vogel , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 00:29:21 -0000 On Sun, Apr 14, 2013 at 12:02:56AM +0000, Chris Forgeron wrote: > Interesting about the drivers - I will look into that tomorrow, I could be on an older version. I started down that path a little while ago, but when pkng wasn't quite ready, I just reverted to the old ways/ommands that seemed to work. > > Here is the dump of the requested commands. I will point out the most interesting one first: dmsg > > It's flooded with: > > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > arp: 43:05:43:05:00:00 is multicast > > Checking an older 9.0-STABLE from july, I see the same message flood in dmesg, but these machines are not exhausting mbuf. > > Perhaps there is a leak in handling this condition? > > Please note: I will also have this problem with the vmware VMXNET3 driver using vmware's official tools, so it's not just em at fault. > > Here is the rest. I left pciconf verbose > > Thanks. > > > root@test:/usr/home/aatech # sysctl -a dev.em.0 > dev.em.0.%desc: Intel(R) PRO/1000 Legacy Network Connection 1.0.5 > dev.em.0.%driver: em > dev.em.0.%location: slot=0 function=0 handle=\_SB_.PCI0.P2P0.S1F0 > dev.em.0.%pnpinfo: vendor=0x8086 device=0x100f subvendor=0x15ad subdevice=0x0750 class=0x020000 > dev.em.0.%parent: pci2 > dev.em.0.nvm: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > dev.em.0.flow_control: 3 > dev.em.0.mbuf_alloc_fail: 0 > dev.em.0.cluster_alloc_fail: 0 > dev.em.0.dropped: 0 > dev.em.0.tx_dma_fail: 0 > dev.em.0.tx_desc_fail1: 0 > dev.em.0.tx_desc_fail2: 0 > dev.em.0.rx_overruns: 0 > dev.em.0.watchdog_timeouts: 0 > dev.em.0.device_control: 1086325321 > dev.em.0.rx_control: 32770 > dev.em.0.fc_high_water: 47104 > dev.em.0.fc_low_water: 45604 > dev.em.0.fifo_workaround: 0 > dev.em.0.fifo_reset: 0 > dev.em.0.txd_head: 23 > dev.em.0.txd_tail: 24 > dev.em.0.rxd_head: 138 > dev.em.0.rxd_tail: 137 > dev.em.0.mac_stats.excess_coll: 0 > dev.em.0.mac_stats.single_coll: 0 > dev.em.0.mac_stats.multiple_coll: 0 > dev.em.0.mac_stats.late_coll: 0 > dev.em.0.mac_stats.collision_count: 0 > dev.em.0.mac_stats.symbol_errors: 0 > dev.em.0.mac_stats.sequence_errors: 0 > dev.em.0.mac_stats.defer_count: 0 > dev.em.0.mac_stats.missed_packets: 0 > dev.em.0.mac_stats.recv_no_buff: 0 > dev.em.0.mac_stats.recv_undersize: 0 > dev.em.0.mac_stats.recv_fragmented: 0 > dev.em.0.mac_stats.recv_oversize: 0 > dev.em.0.mac_stats.recv_jabber: 0 > dev.em.0.mac_stats.recv_errs: 0 > dev.em.0.mac_stats.crc_errs: 0 > dev.em.0.mac_stats.alignment_errs: 0 > dev.em.0.mac_stats.coll_ext_errs: 0 > dev.em.0.mac_stats.xon_recvd: 0 > dev.em.0.mac_stats.xon_txd: 0 > dev.em.0.mac_stats.xoff_recvd: 0 > dev.em.0.mac_stats.xoff_txd: 0 > dev.em.0.mac_stats.total_pkts_recvd: 73008 > dev.em.0.mac_stats.good_pkts_recvd: 49029 > dev.em.0.mac_stats.bcast_pkts_recvd: 0 > dev.em.0.mac_stats.mcast_pkts_recvd: 0 > dev.em.0.mac_stats.rx_frames_64: 0 > dev.em.0.mac_stats.rx_frames_65_127: 45990 > dev.em.0.mac_stats.rx_frames_128_255: 2446 > dev.em.0.mac_stats.rx_frames_256_511: 592 > dev.em.0.mac_stats.rx_frames_512_1023: 1 > dev.em.0.mac_stats.rx_frames_1024_1522: 0 > dev.em.0.mac_stats.good_octets_recvd: 3809187 > dev.em.0.mac_stats.good_octets_txd: 441363 > dev.em.0.mac_stats.total_pkts_txd: 3497 > dev.em.0.mac_stats.good_pkts_txd: 3497 > dev.em.0.mac_stats.bcast_pkts_txd: 0 > dev.em.0.mac_stats.mcast_pkts_txd: 0 > dev.em.0.mac_stats.tx_frames_64: 418 > dev.em.0.mac_stats.tx_frames_65_127: 2678 > dev.em.0.mac_stats.tx_frames_128_255: 131 > dev.em.0.mac_stats.tx_frames_256_511: 213 > dev.em.0.mac_stats.tx_frames_512_1023: 49 > dev.em.0.mac_stats.tx_frames_1024_1522: 8 > dev.em.0.mac_stats.tso_txd: 0 > dev.em.0.mac_stats.tso_ctx_fail: 0 > dev.em.0.wake: 0 > > > > root@test:/usr/home/aatech # cat pciconf.txt > hostb0@pci0:0:0:0: class=0x060000 card=0x197615ad chip=0x71908086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '440BX/ZX/DX - 82443BX/ZX/DX Host bridge' > class = bridge > subclass = HOST-PCI > pcib1@pci0:0:1:0: class=0x060400 card=0x00000000 chip=0x71918086 rev=0x01 hdr=0x01 > vendor = 'Intel Corporation' > device = '440BX/ZX/DX - 82443BX/ZX/DX AGP bridge' > class = bridge > subclass = PCI-PCI > isab0@pci0:0:7:0: class=0x060100 card=0x197615ad chip=0x71108086 rev=0x08 hdr=0x00 > vendor = 'Intel Corporation' > device = '82371AB/EB/MB PIIX4 ISA' > class = bridge > subclass = PCI-ISA > atapci0@pci0:0:7:1: class=0x01018a card=0x197615ad chip=0x71118086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82371AB/EB/MB PIIX4 IDE' > class = mass storage > subclass = ATA > bar [20] = type I/O Port, range 32, base 0x10c0, size 16, enabled > none0@pci0:0:7:3: class=0x068000 card=0x197615ad chip=0x71138086 rev=0x08 hdr=0x00 > vendor = 'Intel Corporation' > device = '82371AB/EB/MB PIIX4 ACPI' > class = bridge > none1@pci0:0:7:7: class=0x088000 card=0x074015ad chip=0x074015ad rev=0x10 hdr=0x00 > vendor = 'VMware' > device = 'Virtual Machine Communication Interface' > class = base peripheral > bar [10] = type I/O Port, range 32, base 0x1080, size 64, enabled > bar [14] = type Memory, range 64, base 0xd0000000, size 8192, enabled > cap 05[40] = MSI supports 1 message, 64 bit > cap 11[58] = MSI-X supports 2 messages in map 0x14 > vgapci0@pci0:0:15:0: class=0x030000 card=0x040515ad chip=0x040515ad rev=0x00 hdr=0x00 > vendor = 'VMware' > device = 'SVGA II Adapter' > class = display > subclass = VGA > bar [10] = type I/O Port, range 32, base 0x10d0, size 16, enabled > bar [14] = type Prefetchable Memory, range 32, base 0xd8000000, size 67108864, enabled > bar [18] = type Memory, range 32, base 0xd0800000, size 8388608, enabled > cap 09[40] = vendor (length 0) > mpt0@pci0:0:16:0: class=0x010000 card=0x197615ad chip=0x00301000 rev=0x01 hdr=0x00 > vendor = 'LSI Logic / Symbios Logic' > device = '53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI' > class = mass storage > subclass = SCSI > bar [10] = type I/O Port, range 32, base 0x1400, size 256, enabled > bar [14] = type Memory, range 64, base 0xd0040000, size 131072, enabled > bar [1c] = type Memory, range 64, base 0xd0020000, size 131072, enabled > pcib2@pci0:0:17:0: class=0x060401 card=0x079015ad chip=0x079015ad rev=0x02 hdr=0x01 > vendor = 'VMware' > device = 'PCI bridge' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x079015ad > pcib3@pci0:0:21:0: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib4@pci0:0:21:1: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib5@pci0:0:21:2: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib6@pci0:0:21:3: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib7@pci0:0:21:4: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib8@pci0:0:21:5: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib9@pci0:0:21:6: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib10@pci0:0:21:7: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib11@pci0:0:22:0: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib12@pci0:0:22:1: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib13@pci0:0:22:2: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib14@pci0:0:22:3: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib15@pci0:0:22:4: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib16@pci0:0:22:5: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib17@pci0:0:22:6: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib18@pci0:0:22:7: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib19@pci0:0:23:0: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib20@pci0:0:23:1: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib21@pci0:0:23:2: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib22@pci0:0:23:3: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib23@pci0:0:23:4: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib24@pci0:0:23:5: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib25@pci0:0:23:6: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib26@pci0:0:23:7: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib27@pci0:0:24:0: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib28@pci0:0:24:1: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib29@pci0:0:24:2: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib30@pci0:0:24:3: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib31@pci0:0:24:4: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib32@pci0:0:24:5: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib33@pci0:0:24:6: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > pcib34@pci0:0:24:7: class=0x060400 card=0x07a015ad chip=0x07a015ad rev=0x01 hdr=0x01 > vendor = 'VMware' > device = 'PCI Express Root Port' > class = bridge > subclass = PCI-PCI > cap 0d[40] = PCI Bridge card=0x07a015ad > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 10[50] = PCI-Express 2 root port slot max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[8c] = MSI supports 1 message, 64 bit, vector masks > em0@pci0:2:0:0: class=0x020000 card=0x075015ad chip=0x100f8086 rev=0x01 hdr=0x00 > vendor = 'Intel Corporation' > device = '82545EM Gigabit Ethernet Controller (Copper)' > class = network > subclass = ethernet > bar [10] = type Memory, range 64, base 0xd1020000, size 131072, enabled > bar [18] = type Memory, range 64, base 0xd1000000, size 65536, enabled > bar [20] = type I/O Port, range 32, base 0x2000, size 64, enabled > cap 01[dc] = powerspec 2 supports D0 D3 current D0 > cap 07[e4] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction > uhci0@pci0:2:2:0: class=0x0c0300 card=0x197615ad chip=0x077415ad rev=0x00 hdr=0x00 > vendor = 'VMware' > device = 'USB1.1 UHCI Controller' > class = serial bus > subclass = USB > bar [20] = type I/O Port, range 32, base 0x2040, size 32, enabled > ehci0@pci0:2:3:0: class=0x0c0320 card=0x077015ad chip=0x077015ad rev=0x00 hdr=0x00 > vendor = 'VMware' > device = 'USB2 EHCI Controller' > class = serial bus > subclass = USB > bar [10] = type Memory, range 32, base 0xd1010000, size 4096, enabled > none2@pci0:3:0:0: class=0x020000 card=0x07b015ad chip=0x07b015ad rev=0x01 hdr=0x00 > vendor = 'VMware' > device = 'VMXNET3 Ethernet Controller' > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xd2404000, size 4096, enabled > bar [14] = type Memory, range 32, base 0xd2403000, size 4096, enabled > bar [18] = type Memory, range 32, base 0xd2400000, size 8192, enabled > bar [1c] = type I/O Port, range 32, base 0x4000, size 16, enabled > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 10[48] = PCI-Express 2 endpoint max data 128(128) link x32(x32) > speed 5.0(5.0) > cap 05[84] = MSI supports 1 message, 64 bit > cap 11[9c] = MSI-X supports 25 messages in map 0x18 > ecap 0003[100] = Serial 1 ff5650003a0d80fe The multicast messages are coming from src/sys/netinet/if_ether.c. Reviewing that code: http://svnweb.freebsd.org/base/stable/9/sys/netinet/if_ether.c r241992 catches my eye, referring to the sysctl named net.link.ether.inet.allow_multicast, which defaults to 0. Note the commit message, however: Merge 240073 from head: Provide a sysctl switch that allows to install ARP entries with multicast bit set. FreeBSD refuses to install such entries since 9.0, and this broke installations running Microsoft NLB, which are violating standards. Tested by: Tarasov Oleg The relevant logging line code is: 549 if (allow_multicast == 0 && ETHER_IS_MULTICAST(ar_sha(ah))) { 550 log(LOG_NOTICE, "arp: %*D is multicast\n", 551 ifp->if_addrlen, (u_char *)ar_sha(ah), ":"); 552 return; 553 } Where allow_multicast correlates directly with the aforementioned sysctl, and ETHER_IS_MULTICAST is a macro in src/sys/net/ethernet.h 73 #define ETHER_IS_MULTICAST(addr) (*(addr) & 0x01) /* is address mcast/bcast? */ I'm not familiar with what ar_sha() does, but the macro checks to see if the dereferenced value has bit 0 set or not. I do not think setting net.link.ether.inet.allow_multicast=1 would alleviate the mbuf issue, based on the code I've looked at. I do see some code in src/sys/net/if_ethersubr.c that relates to mbufs and ETHER_IS_MULTICAST() conditions, however. I'm CC'ing the committer, Gleb Smirnoff, who might have some more insights on what's going on here, where in the kernel the leak may be, and/or how to track it down. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Apr 14 00:59:18 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C72791C9 for ; Sun, 14 Apr 2013 00:59:18 +0000 (UTC) (envelope-from tevans.uk@googlemail.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 545C51B04 for ; Sun, 14 Apr 2013 00:59:17 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id z13so3554247lbh.41 for ; Sat, 13 Apr 2013 17:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=vtNnHCjI4RaymUe3kGnWACGmnKOI3s8le4SjY0d3SmU=; b=fpGN2258xykb6zeceBY1QgMyMnPqAUrcHqJEonaq6b+sg4PA8ZPaZ8pHF9dqYVu+cl 9nYVSv8ymv717hcNzndYF+56MnmN6uszBpTpBBMFJEm7qhLCWlMpOSPFAituXLUyb2le 8p23lOmTZD0czoohZXlptk4K4BzqHuqYxfIZgEsYmDreA4s4aQiZrDnD22p+QzI5YSqh venPIIr8Bqo1Ef5XMAUM1ymaQcKOp9tWsG+ZoZBFw61TsAVuiTscqWOfVICOr9tzJ2MD 3xYorgnv3y6/4QjP7vG39gdLkZeRFsiNjwNcLjf+CaqGqKxcA4XlPGrIdsmKhtz2ee+N oS/Q== MIME-Version: 1.0 X-Received: by 10.112.128.231 with SMTP id nr7mr7837490lbb.26.1365901156764; Sat, 13 Apr 2013 17:59:16 -0700 (PDT) Received: by 10.112.198.201 with HTTP; Sat, 13 Apr 2013 17:59:16 -0700 (PDT) Date: Sun, 14 Apr 2013 01:59:16 +0100 Message-ID: Subject: auditdistd user preventing installkernel From: Tom Evans To: FreeBSD Stable Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 00:59:18 -0000 Hi all I was updating a newly installed FreeBSD 9.1 RELEASE box to 9-STABLE, and was preparing to install the kernel in order to reboot to test it. However I was immediately hit with this: > # make installkernel DESTDIR=/ROOT/9-STABLE-2013-04-13 ERROR: Required auditdistd user is missing, see /usr/src/UPDATING. *** [installcheck_UGID] Error code 1 I did see UPDATING... 20121218: With the addition of auditdistd(8), a new auditdistd user is now depended on during installworld. "mergemaster -p" can be used to add the user prior to installworld, as documented in the handbook. It instructed me to run "mergemaster -p" prior to installworld (this should always be done anyway, according to updating). But I'm not installing world yet, just the kernel. Should UPDATING be corrected? Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Sun Apr 14 15:02:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63352DB for ; Sun, 14 Apr 2013 15:02:13 +0000 (UTC) (envelope-from jcm@visi.com) Received: from g2host.com (mailback4.g2host.com [208.42.184.244]) by mx1.freebsd.org (Postfix) with ESMTP id 21637201 for ; Sun, 14 Apr 2013 15:02:12 +0000 (UTC) Received: from [208.42.90.57] (account jcm@visi.com) by mailback4.g2host.com (CommuniGate Pro WEBUSER 5.3.11) with HTTP id 12752490 for freebsd-stable@freebsd.org; Sun, 14 Apr 2013 10:02:06 -0500 From: "John Mehr" Subject: Re: svn - but smaller? To: X-Mailer: CommuniGate Pro WebUser v5.3.11 Date: Sun, 14 Apr 2013 10:02:06 -0500 Message-ID: In-Reply-To: <5169447A.6020904@gmail.com> References: <55f7d158-b02d-49f4-8181-8711be8d5647@googlegroups.com> <51691775.3000006@gmail.com> <5169447A.6020904@gmail.com> MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1; format="flowed" Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 15:02:13 -0000 On Sat, 13 Apr 2013 14:41:46 +0300  Markiyan Kushnir wrote: > On 13.04.2013 11:29, Markiyan Kushnir wrote: >> The only thing I would like to add -- tree lookup did >>make a good effect >> on CPU consumption. >> > John, > > I'm just curious, did you consider sys/tree.h for tree >implementation? I realize that it wouldn't be well >portable to Linux. Any way, did you have other >considerations to use your own tree implementation in >svnup? Hello, Actually, the thought of using sys/tree.h never crossed my mind.  I wrote my own tree implementation a couple of years ago in Objective-C for a different project and re-implementing it in pure C only took me an hour or so to complete. > > -- > Markiyan. > >> -- >> Markiyan. >> >> >> On 13.04.2013 10:38, mrboco@gmail.com wrote: >>>> In the previous version (0.61), the process of checking >>>> file names against the list of known files in the >>>> repository was inefficient and most likely accounts for >>>> the slow down you're seeing.  I've reimplemented it >>>>using >>>> a binary search tree and the lookup phase is no longer a >>>> bottleneck. >>> >>> I'm sorry but 0.62 still locks while fetching from a >>>local repository: >>> >>> last pid: 74701;  load averages:  2.24,  2.52, >>> 2.56                                           up >>>772+03:32:23 13:19:55 >>> 96 processes:  2 running, 94 sleeping >>> CPU: 14.8% user,  0.0% nice, 40.3% system,  0.7% >>>interrupt, 44.2% idle >>> Mem: 1191M Active, 436M Inact, 248M Wired, 76M Cache, >>>112M Buf, 50M Free >>> Swap: 1024M Total, 232M Used, 792M Free, 22% Inuse >>> >>>    PID USERNAME   THR PRI NICE   SIZE    RES STATE   C >>>  TIME   WCPU >>> COMMAND >>> 30193 root         1 117    0 56220K  9108K CPU1    1 >>> 99:16 96.39% svnup >>> >>> The send/receive queues are filled up and not changing >>>over time: >>> >>> root@alpha:~# netstat -an | fgrep -w 3690 >>> tcp4    8192  24576 81.30.199.66.3690 >>>     81.30.199.66.44473 >>> ESTABLISHED >>> tcp4   24576  16384 81.30.199.66.44473 >>>    81.30.199.66.3690 >>> ESTABLISHED >>> tcp4       0      0 *.3690                 *.* >>>                   LISTEN >>> >>> root@alpha:~# kdump | head -40 >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>>   30193 svnup    RET   write -1 errno 35 Resource >>>temporarily unavailable >>>   30193 svnup    CALL  write(0x3,0x8843a000,0xd91) >>> >>> I think you should either use blocking IO or catch IO >>>errors. And >>> please consider to set the socket options too. >>> >>> Thanks. >>> _______________________________________________ >>> 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 Sun Apr 14 16:47:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2561F2DF for ; Sun, 14 Apr 2013 16:47:04 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by mx1.freebsd.org (Postfix) with ESMTP id E7C008CA for ; Sun, 14 Apr 2013 16:47:03 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id eh20so3578552obb.31 for ; Sun, 14 Apr 2013 09:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5qbtGG8938XpmWyNZW2dWcW3h3Vxg2Vj8GVlZ/QjOG4=; b=gXJ139z3HluqGaak/qk0wspGQBvvj04Z1TyvIJMBEwEeBC5GlS/PtYriy0XdmSFqYQ m/XI4pFPR20QWbjLo1q56jkqO6cpTcZxoAk1qtiROTUofHitGzYJQnfwO5G9QBOCDAta oK21cjSNmvx/Me6+CyeIzCkhQA01tiDBb1xDpDJvC7Utg9YU5sq2cKrGamqkyB9vIpgJ C0bQRLjM3S6QnYrkCv+hAbvmvEXuoCybDrDH+anRwOz2JVFAowrRczxltDPxib/0M3RE Zwe54XA1tuIp7nFs6GlnHsKZZ4l2l/LNUTOCfKNkhto6LNuBqXps/qqwhpx/UV64cNWa ZPFg== MIME-Version: 1.0 X-Received: by 10.182.64.74 with SMTP id m10mr2376643obs.61.1365957533842; Sun, 14 Apr 2013 09:38:53 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.76.33.7 with HTTP; Sun, 14 Apr 2013 09:38:53 -0700 (PDT) In-Reply-To: References: Date: Sun, 14 Apr 2013 09:38:53 -0700 X-Google-Sender-Auth: A8Zl37l8dXPjijTkFAP13tvNBGU Message-ID: Subject: Re: auditdistd user preventing installkernel From: Kevin Oberman To: Tom Evans Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 14 Apr 2013 16:47:04 -0000 On Sat, Apr 13, 2013 at 5:59 PM, Tom Evans wrote: > Hi all > > I was updating a newly installed FreeBSD 9.1 RELEASE box to 9-STABLE, > and was preparing to install the kernel in order to reboot to test it. > > However I was immediately hit with this: > > > # make installkernel DESTDIR=/ROOT/9-STABLE-2013-04-13 > ERROR: Required auditdistd user is missing, see /usr/src/UPDATING. > *** [installcheck_UGID] Error code 1 > > I did see UPDATING... > > 20121218: > With the addition of auditdistd(8), a new auditdistd user is now > depended on during installworld. "mergemaster -p" can be used to add > the user prior to installworld, as documented in the handbook. > > > It instructed me to run "mergemaster -p" prior to installworld (this > should always be done anyway, according to updating). But I'm not > installing world yet, just the kernel. > > Should UPDATING be corrected? > > Cheers > > Tom > _______________________________________________ > 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" > This is, indeed, an error in UPDATING. 'mergemaster -p' must be run before installkernel. Actually, you are really supposed to run 'mergemaster -p' before buildworld: -p Pre-buildworld mode. Compares only files known to be essen- tial to the success of {build|install}world, including /etc/make.conf. Though, in reality, there has never been a case where it was actually needed that early. None the less, it can be run then and there might be such a case some day. In particular, make.conf could impact buildworld. -- R. Kevin Oberman, Network Engineer E-mail: rkoberman@gmail.com From owner-freebsd-stable@FreeBSD.ORG Mon Apr 15 03:32:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B846345A; Mon, 15 Apr 2013 03:32:15 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8FD36EBE; Mon, 15 Apr 2013 03:32:15 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-237-17.lns20.per1.internode.on.net [121.45.237.17]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r3F3WAmK013173 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 14 Apr 2013 20:32:12 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <516B74BC.3070903@freebsd.org> Date: Mon, 15 Apr 2013 11:32:12 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: EuroBSDcon 2013: Call for Proposals, Conference on September 28+29 2013 References: <51667FDC.7050807@freebsd.org> In-Reply-To: <51667FDC.7050807@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 03:32:15 -0000 On 4/11/13 5:18 PM, Andre Oppermann wrote: > Excuse me for being slightly spammy but I've received feedback that we > haven't spread this information widely enough outside the inner circles > and interested people missed the announcement. > > EuroBSDcon 2013: September 28-29 in Malta > ========================================= > > EuroBSDcon is the European technical conference for users and > developers > of BSD-based systems. The conference will take place Saturday and > Sunday > 28-29 September at the Hilton Conference Centre in St. Julian's, Malta > (tutorials and FreeBSD Developer Summit on preceding Thursday and > Friday, > talks on Saturday and Sunday). [Yes, very nice weather at that time of > year, about 26/19C sunny no rain, Social event on Saturday evening > is going > to be a sunset beach BBQ] The web page suggest I bring my wife AND my spouse.. what if they don't know about each other? From owner-freebsd-stable@FreeBSD.ORG Mon Apr 15 10:45:28 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EAC57854; Mon, 15 Apr 2013 10:45:28 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 751D8320; Mon, 15 Apr 2013 10:45:28 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r3FAgdkp097825; Mon, 15 Apr 2013 14:42:39 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r3FAgcxI097824; Mon, 15 Apr 2013 14:42:38 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 15 Apr 2013 14:42:38 +0400 From: Gleb Smirnoff To: Chris Forgeron Subject: Re: kern/165903: mbuf leak Message-ID: <20130415104238.GP76816@FreeBSD.org> References: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> <20130410235347.GA38492@icarus.home.lan> <20130411000818.GA38803@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0EF0@AA-EX0.acsi.ca> <20130413235031.GA8212@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0F52@AA-EX0.acsi.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="+OvhQd+MVTzxy63P" Content-Disposition: inline In-Reply-To: <46D80686C389884BB0C047851038EC456D8C0F52@AA-EX0.acsi.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jeremy Chadwick , "freebsd-stable@freebsd.org" , Jack Vogel , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 15 Apr 2013 10:45:29 -0000 --+OvhQd+MVTzxy63P Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Chris, can you please test attached patch? Jeremy, thanks for cc :) -- Totus tuus, Glebius. --+OvhQd+MVTzxy63P Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="if_ether.c.diff" Index: if_ether.c =================================================================== --- if_ether.c (revision 249327) +++ if_ether.c (working copy) @@ -558,13 +558,13 @@ in_arpinput(struct mbuf *m) if (ah->ar_pln != sizeof(struct in_addr)) { log(LOG_NOTICE, "in_arp: requested protocol length != %zu\n", sizeof(struct in_addr)); - return; + goto drop; } if (allow_multicast == 0 && ETHER_IS_MULTICAST(ar_sha(ah))) { log(LOG_NOTICE, "arp: %*D is multicast\n", ifp->if_addrlen, (u_char *)ar_sha(ah), ":"); - return; + goto drop; } op = ntohs(ah->ar_op); --+OvhQd+MVTzxy63P-- From owner-freebsd-stable@FreeBSD.ORG Tue Apr 16 02:41:42 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BB1D654B for ; Tue, 16 Apr 2013 02:41:42 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8BD637AC for ; Tue, 16 Apr 2013 02:41:42 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id l20so25755oag.41 for ; Mon, 15 Apr 2013 19:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VUQ6sVAfO0y0J90XeOPeL+dCG8qK4pkI+/QurHsjSKk=; b=EYKsXCy6duMFSZVShxvSFSHAx6lzZpz7PCwiTZdKBW1AXKEWcSv03XQe+gQqZc4U12 kPevxp5Cbk4vybiRRBoyNCasvJYCzpUsaL/IhoSU6DZiOKLaoGB66nc0RO2AVlka6740 Dtf9g8wBSFJd/OAapsx+TQ1YPV9eEru+GzB2PchLMbloxe+q0pbvdPjik6V4pyvb0H0D EsV2c+ZVAyTX9avNsYl5cqYaPlLLn0cArADMohawa8wYNSovRd2mYUzCdDifIcq+DSuF 4NM7wZQkg4b2TT1wv/C24Qn5y0Pq2+V/ASWOZaB+GZGD3uvvg7RFZ0/gHRZNU3NtAE/f WuCw== MIME-Version: 1.0 X-Received: by 10.182.39.201 with SMTP id r9mr152500obk.16.1366080096423; Mon, 15 Apr 2013 19:41:36 -0700 (PDT) Received: by 10.76.109.236 with HTTP; Mon, 15 Apr 2013 19:41:36 -0700 (PDT) In-Reply-To: <20130412142802.GA1657@regency.nsu.ru> References: <20130410052710.GA36137@regency.nsu.ru> <20130412101746.GA68687@regency.nsu.ru> <20130412142802.GA1657@regency.nsu.ru> Date: Mon, 15 Apr 2013 22:41:36 -0400 Message-ID: Subject: Re: fusefs-kmod does not work on 8-STABLE? From: Ryan Stone To: Alexey Dokuchaev Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 02:41:42 -0000 On Fri, Apr 12, 2013 at 10:28 AM, Alexey Dokuchaev wrote: > On Fri, Apr 12, 2013 at 05:17:46PM +0700, Alexey Dokuchaev wrote: > > On Wed, Apr 10, 2013 at 12:27:10PM +0700, Alexey Dokuchaev wrote: > > > I've got puzzled with the fact that fusefs-kmod apparently does not on > > > recent 8-STABLE: it builds and loads, but I don't see normal "fuse4bsd: > > > version 0.3.9-pre1, FUSE ABI 7.19" like I do on 9-STABLE (installed on > the > > > same laptop with almost identical kernel config). > > > > > > The result is that /dev/fuse0 never gets created, and any fuse mount > > > attempt results in this message: > > > > > > fuse: failed to open fuse device: No such file or directory > > > > I've traced the problem down a bit, it seems to be due to some weird > > brokenness of building modules outside the kernel: .ko file loads, but > > modevent() functions apparently does not execute at all. > > I've found the culprit: the problem is in this command of the build: > > ld -Bshareable -d -warn-common -o hello.ko.debug hello.kld > > I had put /usr/local/bin in my $PATH before /usr/bin for a reason I don't > currently recall, and have binutils-2.23.1 installed. As a result, ld(1) > in the quoted line above was called from /usr/local/bin/ld, which brought > in all the weird things I was observing: failure of fusefs-kmod, failure > of simple "hello world" KLD, "link_elf: symbol undefined" messages > when loading snd_hda(4) and nvidia(4) drivers. > > How, does anyone have a clue why new ld(1) plays so badly with our system > toolchain on 8.x (at least)? > > ./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" > Is this for i386? When compiling modules with newer versions of ld I had to add the following flags to the ld invocation to get the module to work: -u __start_set_sysinit_set -u __start_set_sysuninit_set \ -u __start_set_sysctl_set -u __start_set_modmetadata_set \ -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ -u __stop_set_sysctl_set -u __stop_set_modmetadata_set From owner-freebsd-stable@FreeBSD.ORG Tue Apr 16 04:09:45 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 47D68CD4; Tue, 16 Apr 2013 04:09:45 +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 DAD89AF4; Tue, 16 Apr 2013 04:09:44 +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 r3G49hdv094462; Tue, 16 Apr 2013 04:09:43 GMT (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-stable.sentex.ca (8.14.5/8.14.5/Submit) id r3G49hbL094448; Tue, 16 Apr 2013 04:09:43 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 16 Apr 2013 04:09:43 GMT Message-Id: <201304160409.r3G49hbL094448@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 , , Subject: [releng_9 tinderbox] failure on i386/i386 Precedence: bulk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 04:09:45 -0000 TB --- 2013-04-15 20:55:22 - tinderbox 2.10 running on freebsd-stable.sentex.ca TB --- 2013-04-15 20:55:22 - FreeBSD freebsd-stable.sentex.ca 8.3-STABLE FreeBSD 8.3-STABLE #0: Tue Oct 16 17:37:58 UTC 2012 mdtancsa@freebsd-stable.sentex.ca:/usr/obj/usr/src/sys/server amd64 TB --- 2013-04-15 20:55:22 - starting RELENG_9 tinderbox run for i386/i386 TB --- 2013-04-15 20:55:22 - cleaning the object tree TB --- 2013-04-15 20:55:22 - /usr/local/bin/svn stat /src TB --- 2013-04-15 20:55:27 - At svn revision 249526 TB --- 2013-04-15 20:55:28 - building world TB --- 2013-04-15 20:55:28 - CROSS_BUILD_TESTING=YES TB --- 2013-04-15 20:55:28 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-15 20:55:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-15 20:55:28 - SRCCONF=/dev/null TB --- 2013-04-15 20:55:28 - TARGET=i386 TB --- 2013-04-15 20:55:28 - TARGET_ARCH=i386 TB --- 2013-04-15 20:55:28 - TZ=UTC TB --- 2013-04-15 20:55:28 - __MAKE_CONF=/dev/null TB --- 2013-04-15 20:55:28 - cd /src TB --- 2013-04-15 20:55:28 - /usr/bin/make -B buildworld >>> World build started on Mon Apr 15 20:55:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Apr 15 23:49:22 UTC 2013 TB --- 2013-04-15 23:49:22 - generating LINT kernel config TB --- 2013-04-15 23:49:22 - cd /src/sys/i386/conf TB --- 2013-04-15 23:49:22 - /usr/bin/make -B LINT TB --- 2013-04-15 23:49:22 - cd /src/sys/i386/conf TB --- 2013-04-15 23:49:22 - /usr/sbin/config -m LINT TB --- 2013-04-15 23:49:22 - building LINT kernel TB --- 2013-04-15 23:49:22 - CROSS_BUILD_TESTING=YES TB --- 2013-04-15 23:49:22 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-15 23:49:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-15 23:49:22 - SRCCONF=/dev/null TB --- 2013-04-15 23:49:22 - TARGET=i386 TB --- 2013-04-15 23:49:22 - TARGET_ARCH=i386 TB --- 2013-04-15 23:49:22 - TZ=UTC TB --- 2013-04-15 23:49:22 - __MAKE_CONF=/dev/null TB --- 2013-04-15 23:49:22 - cd /src TB --- 2013-04-15 23:49:22 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Apr 15 23:49:22 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Apr 16 00:30:05 UTC 2013 TB --- 2013-04-16 00:30:05 - cd /src/sys/i386/conf TB --- 2013-04-16 00:30:05 - /usr/sbin/config -m LINT-NOINET TB --- 2013-04-16 00:30:05 - building LINT-NOINET kernel TB --- 2013-04-16 00:30:05 - CROSS_BUILD_TESTING=YES TB --- 2013-04-16 00:30:05 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-16 00:30:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-16 00:30:05 - SRCCONF=/dev/null TB --- 2013-04-16 00:30:05 - TARGET=i386 TB --- 2013-04-16 00:30:05 - TARGET_ARCH=i386 TB --- 2013-04-16 00:30:05 - TZ=UTC TB --- 2013-04-16 00:30:05 - __MAKE_CONF=/dev/null TB --- 2013-04-16 00:30:05 - cd /src TB --- 2013-04-16 00:30:05 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Tue Apr 16 00:30:05 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Tue Apr 16 01:09:49 UTC 2013 TB --- 2013-04-16 01:09:49 - cd /src/sys/i386/conf TB --- 2013-04-16 01:09:49 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-04-16 01:09:50 - building LINT-NOINET6 kernel TB --- 2013-04-16 01:09:50 - CROSS_BUILD_TESTING=YES TB --- 2013-04-16 01:09:50 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-16 01:09:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-16 01:09:50 - SRCCONF=/dev/null TB --- 2013-04-16 01:09:50 - TARGET=i386 TB --- 2013-04-16 01:09:50 - TARGET_ARCH=i386 TB --- 2013-04-16 01:09:50 - TZ=UTC TB --- 2013-04-16 01:09:50 - __MAKE_CONF=/dev/null TB --- 2013-04-16 01:09:50 - cd /src TB --- 2013-04-16 01:09:50 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Tue Apr 16 01:09:50 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Tue Apr 16 01:50:20 UTC 2013 TB --- 2013-04-16 01:50:20 - cd /src/sys/i386/conf TB --- 2013-04-16 01:50:20 - /usr/sbin/config -m LINT-NOIP TB --- 2013-04-16 01:50:20 - building LINT-NOIP kernel TB --- 2013-04-16 01:50:20 - CROSS_BUILD_TESTING=YES TB --- 2013-04-16 01:50:20 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-16 01:50:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-16 01:50:20 - SRCCONF=/dev/null TB --- 2013-04-16 01:50:20 - TARGET=i386 TB --- 2013-04-16 01:50:20 - TARGET_ARCH=i386 TB --- 2013-04-16 01:50:20 - TZ=UTC TB --- 2013-04-16 01:50:20 - __MAKE_CONF=/dev/null TB --- 2013-04-16 01:50:20 - cd /src TB --- 2013-04-16 01:50:20 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Tue Apr 16 01:50:20 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Tue Apr 16 02:27:52 UTC 2013 TB --- 2013-04-16 02:27:52 - cd /src/sys/i386/conf TB --- 2013-04-16 02:27:52 - /usr/sbin/config -m LINT-VIMAGE TB --- 2013-04-16 02:27:52 - building LINT-VIMAGE kernel TB --- 2013-04-16 02:27:52 - CROSS_BUILD_TESTING=YES TB --- 2013-04-16 02:27:52 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-16 02:27:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-16 02:27:52 - SRCCONF=/dev/null TB --- 2013-04-16 02:27:52 - TARGET=i386 TB --- 2013-04-16 02:27:52 - TARGET_ARCH=i386 TB --- 2013-04-16 02:27:52 - TZ=UTC TB --- 2013-04-16 02:27:52 - __MAKE_CONF=/dev/null TB --- 2013-04-16 02:27:52 - cd /src TB --- 2013-04-16 02:27:52 - /usr/bin/make -B buildkernel KERNCONF=LINT-VIMAGE >>> Kernel build for LINT-VIMAGE started on Tue Apr 16 02:27:53 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-VIMAGE completed on Tue Apr 16 03:10:40 UTC 2013 TB --- 2013-04-16 03:10:40 - cd /src/sys/i386/conf TB --- 2013-04-16 03:10:40 - /usr/sbin/config -m GENERIC TB --- 2013-04-16 03:10:40 - building GENERIC kernel TB --- 2013-04-16 03:10:40 - CROSS_BUILD_TESTING=YES TB --- 2013-04-16 03:10:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-16 03:10:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-16 03:10:40 - SRCCONF=/dev/null TB --- 2013-04-16 03:10:40 - TARGET=i386 TB --- 2013-04-16 03:10:40 - TARGET_ARCH=i386 TB --- 2013-04-16 03:10:40 - TZ=UTC TB --- 2013-04-16 03:10:40 - __MAKE_CONF=/dev/null TB --- 2013-04-16 03:10:40 - cd /src TB --- 2013-04-16 03:10:40 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Apr 16 03:10:40 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue Apr 16 03:44:15 UTC 2013 TB --- 2013-04-16 03:44:15 - cd /src/sys/i386/conf TB --- 2013-04-16 03:44:15 - /usr/sbin/config -m PAE TB --- 2013-04-16 03:44:15 - building PAE kernel TB --- 2013-04-16 03:44:15 - CROSS_BUILD_TESTING=YES TB --- 2013-04-16 03:44:15 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-16 03:44:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-16 03:44:15 - SRCCONF=/dev/null TB --- 2013-04-16 03:44:15 - TARGET=i386 TB --- 2013-04-16 03:44:15 - TARGET_ARCH=i386 TB --- 2013-04-16 03:44:15 - TZ=UTC TB --- 2013-04-16 03:44:15 - __MAKE_CONF=/dev/null TB --- 2013-04-16 03:44:15 - cd /src TB --- 2013-04-16 03:44:15 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Tue Apr 16 03:44:15 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Tue Apr 16 03:53:38 UTC 2013 TB --- 2013-04-16 03:53:38 - cd /src/sys/i386/conf TB --- 2013-04-16 03:53:38 - /usr/sbin/config -m XBOX TB --- 2013-04-16 03:53:38 - building XBOX kernel TB --- 2013-04-16 03:53:38 - CROSS_BUILD_TESTING=YES TB --- 2013-04-16 03:53:38 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-16 03:53:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-16 03:53:38 - SRCCONF=/dev/null TB --- 2013-04-16 03:53:38 - TARGET=i386 TB --- 2013-04-16 03:53:38 - TARGET_ARCH=i386 TB --- 2013-04-16 03:53:38 - TZ=UTC TB --- 2013-04-16 03:53:38 - __MAKE_CONF=/dev/null TB --- 2013-04-16 03:53:38 - cd /src TB --- 2013-04-16 03:53:38 - /usr/bin/make -B buildkernel KERNCONF=XBOX >>> Kernel build for XBOX started on Tue Apr 16 03:53:38 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for XBOX completed on Tue Apr 16 03:58:18 UTC 2013 TB --- 2013-04-16 03:58:18 - cd /src/sys/i386/conf TB --- 2013-04-16 03:58:18 - /usr/sbin/config -m XEN TB --- 2013-04-16 03:58:18 - building XEN kernel TB --- 2013-04-16 03:58:18 - CROSS_BUILD_TESTING=YES TB --- 2013-04-16 03:58:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-04-16 03:58:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-04-16 03:58:18 - SRCCONF=/dev/null TB --- 2013-04-16 03:58:18 - TARGET=i386 TB --- 2013-04-16 03:58:18 - TARGET_ARCH=i386 TB --- 2013-04-16 03:58:18 - TZ=UTC TB --- 2013-04-16 03:58:18 - __MAKE_CONF=/dev/null TB --- 2013-04-16 03:58:18 - cd /src TB --- 2013-04-16 03:58:18 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Tue Apr 16 03:58:18 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ctl/../../cam/ctl/ctl_backend_ramdisk.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ctl/../../cam/ctl/ctl_cmd_table.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ctl/../../cam/ctl/ctl_frontend.c cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386.i386/src/sys/XEN/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/i386.i386/src/sys/XEN -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-sse -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -c /src/sys/modules/ctl/../../cam/ctl/ctl_frontend_cam_sim.c cc1: warnings being treated as errors /src/sys/modules/ctl/../../cam/ctl/ctl_frontend_cam_sim.c: In function 'cfcs_datamove': /src/sys/modules/ctl/../../cam/ctl/ctl_frontend_cam_sim.c:433: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] /src/sys/modules/ctl/../../cam/ctl/ctl_frontend_cam_sim.c:459: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] *** Error code 1 Stop in /src/sys/modules/ctl. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386.i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-04-16 04:09:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-04-16 04:09:43 - ERROR: failed to build XEN kernel TB --- 2013-04-16 04:09:43 - 19706.46 user 2106.96 system 26061.00 real http://tinderbox.freebsd.org/tinderbox-freebsd9-build-RELENG_9-i386-i386.full From owner-freebsd-stable@FreeBSD.ORG Tue Apr 16 06:14:43 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 76FD8D83 for ; Tue, 16 Apr 2013 06:14: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 26822E9C for ; Tue, 16 Apr 2013 06:14:42 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1URz94-0001DA-6b; Tue, 16 Apr 2013 13:13:34 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id r3G6ESrF034620; Tue, 16 Apr 2013 13:14:28 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id r3G6E6gx034597; Tue, 16 Apr 2013 13:14:06 +0700 (NOVT) (envelope-from danfe) Date: Tue, 16 Apr 2013 13:14:06 +0700 From: Alexey Dokuchaev To: Ryan Stone Subject: Re: fusefs-kmod does not work on 8-STABLE? Message-ID: <20130416061406.GA31583@regency.nsu.ru> References: <20130410052710.GA36137@regency.nsu.ru> <20130412101746.GA68687@regency.nsu.ru> <20130412142802.GA1657@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 06:14:43 -0000 On Mon, Apr 15, 2013 at 10:41:36PM -0400, Ryan Stone wrote: > On Fri, Apr 12, 2013 at 10:28 AM, Alexey Dokuchaev wrote: > > I've found the culprit: the problem is in this command of the build: > > > > ld -Bshareable -d -warn-common -o hello.ko.debug hello.kld > > > > I had put /usr/local/bin in my $PATH before /usr/bin for a reason I don't > > currently recall, and have binutils-2.23.1 installed. As a result, ld(1) > > in the quoted line above was called from /usr/local/bin/ld, [...] > > Is this for i386? When compiling modules with newer versions of ld I had > to add the following flags to the ld invocation to get the module to work: Yes, this is for i386. > -u __start_set_sysinit_set -u __start_set_sysuninit_set \ > -u __start_set_sysctl_set -u __start_set_modmetadata_set \ > -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ > -u __stop_set_sysctl_set -u __stop_set_modmetadata_set Hmm. Adding these does help, indeed. How did you come up with this list? Is it documented anywhere, or just the result of careful readelf/objdump examination? Thanks! ./danfe From owner-freebsd-stable@FreeBSD.ORG Tue Apr 16 11:21:46 2013 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 89B001A8 for ; Tue, 16 Apr 2013 11:21:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4DECB2ED for ; Tue, 16 Apr 2013 11:21:45 +0000 (UTC) Received: from spaceball.andric.com (spaceball.andric.com [IPv6:2001:7b8:3a7:0:204:4bff:fe01:de8a]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 360D85C44; Tue, 16 Apr 2013 13:21:37 +0200 (CEST) Message-ID: <516D343C.2050707@FreeBSD.org> Date: Tue, 16 Apr 2013 13:21:32 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Thunderbird/21.0 MIME-Version: 1.0 To: Alexey Dokuchaev , Ryan Stone Subject: Re: fusefs-kmod does not work on 8-STABLE? References: <20130410052710.GA36137@regency.nsu.ru> <20130412101746.GA68687@regency.nsu.ru> <20130412142802.GA1657@regency.nsu.ru> <20130416061406.GA31583@regency.nsu.ru> In-Reply-To: <20130416061406.GA31583@regency.nsu.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 11:21:46 -0000 On 2013-04-16 08:14, Alexey Dokuchaev wrote: > On Mon, Apr 15, 2013 at 10:41:36PM -0400, Ryan Stone wrote: >> On Fri, Apr 12, 2013 at 10:28 AM, Alexey Dokuchaev wrote: >>> I've found the culprit: the problem is in this command of the build: >>> >>> ld -Bshareable -d -warn-common -o hello.ko.debug hello.kld >>> >>> I had put /usr/local/bin in my $PATH before /usr/bin for a reason I don't >>> currently recall, and have binutils-2.23.1 installed. As a result, ld(1) >>> in the quoted line above was called from /usr/local/bin/ld, [...] >> >> Is this for i386? When compiling modules with newer versions of ld I had >> to add the following flags to the ld invocation to get the module to work: > > Yes, this is for i386. > >> -u __start_set_sysinit_set -u __start_set_sysuninit_set \ >> -u __start_set_sysctl_set -u __start_set_modmetadata_set \ >> -u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ >> -u __stop_set_sysctl_set -u __stop_set_modmetadata_set > > Hmm. Adding these does help, indeed. How did you come up with this list? > Is it documented anywhere, or just the result of careful readelf/objdump > examination? Thanks! These are module start/stop symbols, which get optimized away by newer versions of binutils. We fixed it in head when binutils 2.17.50 was imported, here: http://svn.freebsd.org/changeset/base/215137 This fix could probably also be used for stable/8. It is most likely too late to get into 8.4, though. From owner-freebsd-stable@FreeBSD.ORG Tue Apr 16 12:10:48 2013 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4D0577C; Tue, 16 Apr 2013 12:10:48 +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 F168379A; Tue, 16 Apr 2013 12:10:47 +0000 (UTC) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.69) (envelope-from ) id 1US4ii-00036o-PD; Tue, 16 Apr 2013 19:10:44 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id r3GCBe59083795; Tue, 16 Apr 2013 19:11:40 +0700 (NOVT) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id r3GCBZXW083794; Tue, 16 Apr 2013 19:11:35 +0700 (NOVT) (envelope-from danfe) Date: Tue, 16 Apr 2013 19:11:35 +0700 From: Alexey Dokuchaev To: Dimitry Andric Subject: Re: fusefs-kmod does not work on 8-STABLE? Message-ID: <20130416121135.GA81519@regency.nsu.ru> References: <20130410052710.GA36137@regency.nsu.ru> <20130412101746.GA68687@regency.nsu.ru> <20130412142802.GA1657@regency.nsu.ru> <20130416061406.GA31583@regency.nsu.ru> <516D343C.2050707@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <516D343C.2050707@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: stable@FreeBSD.org, Ryan Stone X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 12:10:48 -0000 On Tue, Apr 16, 2013 at 01:21:32PM +0200, Dimitry Andric wrote: > On 2013-04-16 08:14, Alexey Dokuchaev wrote: > >>-u __start_set_sysinit_set -u __start_set_sysuninit_set \ > >>-u __start_set_sysctl_set -u __start_set_modmetadata_set \ > >>-u __stop_set_sysinit_set -u __stop_set_sysuninit_set \ > >>-u __stop_set_sysctl_set -u __stop_set_modmetadata_set > > These are module start/stop symbols, which get optimized away by newer > versions of binutils. We fixed it in head when binutils 2.17.50 was > imported, here: > > http://svn.freebsd.org/changeset/base/215137 > > This fix could probably also be used for stable/8. It is most likely > too late to get into 8.4, though. Personally I do not care for 8.4 (or any release), but would definitely appreciate if you could merge it to stable/8, thanks! ./danfe From owner-freebsd-stable@FreeBSD.ORG Tue Apr 16 15:00:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6AA3AA7C for ; Tue, 16 Apr 2013 15:00:00 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id D6B18FD9 for ; Tue, 16 Apr 2013 14:59:59 +0000 (UTC) Received: (qmail 23539 invoked from network); 16 Apr 2013 16:06:10 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Apr 2013 16:06:10 -0000 Message-ID: <516D676D.6020706@freebsd.org> Date: Tue, 16 Apr 2013 16:59:57 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Julian Elischer Subject: Re: EuroBSDcon 2013: Call for Proposals, Conference on September 28+29 2013 References: <51667FDC.7050807@freebsd.org> <516B74BC.3070903@freebsd.org> In-Reply-To: <516B74BC.3070903@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 15:00:00 -0000 On 15.04.2013 05:32, Julian Elischer wrote: > On 4/11/13 5:18 PM, Andre Oppermann wrote: >> Excuse me for being slightly spammy but I've received feedback that we >> haven't spread this information widely enough outside the inner circles >> and interested people missed the announcement. >> >> EuroBSDcon 2013: September 28-29 in Malta >> ========================================= >> >> EuroBSDcon is the European technical conference for users and developers >> of BSD-based systems. The conference will take place Saturday and Sunday >> 28-29 September at the Hilton Conference Centre in St. Julian's, Malta >> (tutorials and FreeBSD Developer Summit on preceding Thursday and Friday, >> talks on Saturday and Sunday). [Yes, very nice weather at that time of >> year, about 26/19C sunny no rain, Social event on Saturday evening is going >> to be a sunset beach BBQ] > > The web page suggest I bring my wife AND my spouse.. what if they don't > know about each other? Well, you have poorly managed your relationships then. ;) This web page is a place holder and will be updated with the all important details on venue/travel/hotels/schedule really soon now. -- Andre From owner-freebsd-stable@FreeBSD.ORG Tue Apr 16 16:18:17 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C6CA8726 for ; Tue, 16 Apr 2013 16:18:17 +0000 (UTC) (envelope-from patmcevoy@mac.com) Received: from st11p00mm-asmtp003.mac.com (st11p00mm-asmtpout003.mac.com [17.172.81.2]) by mx1.freebsd.org (Postfix) with ESMTP id A10276A8 for ; Tue, 16 Apr 2013 16:18:17 +0000 (UTC) Received: from 192.168.1.44 (pool-96-224-34-95.nycmny.east.verizon.net [96.224.34.95]) by st11p00mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-23.01(7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTPSA id <0MLC00KUCT543U10@st11p00mm-asmtp003.mac.com> for freebsd-stable@freebsd.org; Tue, 16 Apr 2013 15:17:32 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8626,1.0.431,0.0.0000 definitions=2013-04-16_06:2013-04-16,2013-04-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=4 phishscore=0 bulkscore=97 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1302030000 definitions=main-1304160118 Message-id: <516D6B87.6030601@mac.com> Date: Tue, 16 Apr 2013 11:17:27 -0400 From: Patrick McEvoy User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: EuroBSDcon 2013: Call for Proposals, Conference on September 28+29 2013 References: <51667FDC.7050807@freebsd.org> <516B74BC.3070903@freebsd.org> <516D676D.6020706@freebsd.org> In-reply-to: <516D676D.6020706@freebsd.org> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: patmcevoy@mac.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 16:18:17 -0000 On 4/16/13 10:59 AM, Andre Oppermann wrote: > On 15.04.2013 05:32, Julian Elischer wrote: >> On 4/11/13 5:18 PM, Andre Oppermann wrote: >>> Excuse me for being slightly spammy but I've received feedback that we >>> haven't spread this information widely enough outside the inner circles >>> and interested people missed the announcement. >>> >>> EuroBSDcon 2013: September 28-29 in Malta >>> ========================================= >>> >>> EuroBSDcon is the European technical conference for users and >>> developers >>> of BSD-based systems. The conference will take place Saturday and >>> Sunday >>> 28-29 September at the Hilton Conference Centre in St. Julian's, Malta >>> (tutorials and FreeBSD Developer Summit on preceding Thursday and >>> Friday, >>> talks on Saturday and Sunday). [Yes, very nice weather at that time of >>> year, about 26/19C sunny no rain, Social event on Saturday evening >>> is going >>> to be a sunset beach BBQ] >> >> The web page suggest I bring my wife AND my spouse.. what if they >> don't > > know about each other? > > Well, you have poorly managed your relationships then. ;) > > This web page is a place holder and will be updated with the all > important > details on venue/travel/hotels/schedule really soon now. > Tweeted: BSDTV: EuroBSDcon 2013: September 28-29 in Malta : 2013.eurobsdcon.org Your family will actually want to travel with you! #BSD P From owner-freebsd-stable@FreeBSD.ORG Tue Apr 16 16:46:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7518A522 for ; Tue, 16 Apr 2013 16:46:59 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by mx1.freebsd.org (Postfix) with ESMTP id 56C7A854 for ; Tue, 16 Apr 2013 16:46:59 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta02.emeryville.ca.mail.comcast.net with comcast id Qcls1l0021GXsucA2gmzTZ; Tue, 16 Apr 2013 16:46:59 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta07.emeryville.ca.mail.comcast.net with comcast id Qgmy1l00T1t3BNj8Ugmy3D; Tue, 16 Apr 2013 16:46:58 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 4A9B373A33; Tue, 16 Apr 2013 09:46:58 -0700 (PDT) Date: Tue, 16 Apr 2013 09:46:58 -0700 From: Jeremy Chadwick To: Chris Forgeron Subject: Re: kern/165903: mbuf leak Message-ID: <20130416164658.GA81268@icarus.home.lan> References: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> <20130410235347.GA38492@icarus.home.lan> <20130411000818.GA38803@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0EF0@AA-EX0.acsi.ca> <20130413235031.GA8212@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0F52@AA-EX0.acsi.ca> <20130415104238.GP76816@FreeBSD.org> <46D80686C389884BB0C047851038EC456D8C3001@AA-EX0.acsi.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D80686C389884BB0C047851038EC456D8C3001@AA-EX0.acsi.ca> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366130819; bh=MxouuO7MzW1H2fV3/ItG/Vn7RQbBq3uV9rTvuQiRR4c=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=olUaakjF0SQi+cAPshm6aCXtdNFeV/mxVgfaPr2+wywQA8FEqPa1KE5xbmPfKmbCJ CeHUZCxi0RgMYuA7nXXc/lP7TkgeQDUu7U8K4nBC9nxV1nc+aVav8de6b43P3QFllm Rz4Uumh4wBdVvW9FXXOVMkoJoqlAlgbgY38NFsdOhqxZxGUE1R94HzAiGbpyaXIUbt c4TKqe+58rUxkMyFTNYKlEHvaKF+opzK7hsc1g2WZogxNFjK0mS30MmJnhxyVDziI0 iZTWkOc9bbBcc/WZmpMPiEQ+Hd3OPJAgs/OheQvIDRkmIG6FFXA59zaXpJmESecyd6 Oe9Zf1SUQFN3Q== Cc: Gleb Smirnoff , "freebsd-stable@freebsd.org" , Jack Vogel , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 16:46:59 -0000 On Tue, Apr 16, 2013 at 04:43:49PM +0000, Chris Forgeron wrote: > Thanks, I've applied it, and am rebuilding now. I should know tonight/tomorrow > > I take it this proves that I don't have the latest source with cvsup, or is this work in progress? > > Thanks again. The patch Gleb provided is not committed anywhere (not even HEAD/current) -- it's a patch for you to test. :-) The sources you have via csup/cvsup seem to be recent enough (all I can go off of is your legacy em(4) driver version being 1.0.5). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Apr 16 17:55:22 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DCC9AB54 for ; Tue, 16 Apr 2013 17:55:22 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mx1.freebsd.org (Postfix) with ESMTP id 5D6A3C17 for ; Tue, 16 Apr 2013 17:55:21 +0000 (UTC) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id r3GHtKUh022936 for ; Tue, 16 Apr 2013 19:55:20 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.13.6/8.13.6) with ESMTP id r3GHtKw8017779 for ; Tue, 16 Apr 2013 19:55:20 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.6/8.14.6) id r3GHtKYO020121; Date: Tue, 16 Apr 2013 19:55:20 +0200 From: Andre Albsmeier To: freebsd-stable@freebsd.org Subject: Lost CDROM on 9.1 with ATA_CAM on Promise controller Message-ID: <20130416175520.GA9548@bali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 17:55:22 -0000 I have lost one of my CDROM drives (HL-DT-STDVD-RAM GH22LP20/2.00) after going from 7.4 to 9.1 when using ATA_CAM. It is attached to a Promise PDC20268 UDMA100 controller. A standard harddisk drive attached to this controller works well. Cables, controller and drive where replaced already. Kernel gives me: atapci1: port 0xb000-0xb007,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9800-0x980f mem 0xdf800000-0xdf803fff irq 11 at device 12.0 on pci0 ata2: at channel 0 on atapci1 ata3: at channel 1 on atapci1 ... ada0 at ata2 bus 0 scbus2 target 0 lun 0 ada0: ATA-7 device ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 286188MB (586114704 512 byte sectors: 16H 63S/T 16383C) ... (cd2:ata3:0:0:0): got CAM status 0x50 (cd2:ata3:0:0:0): fatal error, failed to attach to device (cd2:ata3:0:0:0): lost device, 4 refs (cd2:ata3:0:0:0): removing device entry ... Attaching the CDROM drive to the controller that is integrated on the mainboard (Intel PIIX4 UDMA33 controller) does not show this problem (but here I don't have UDMA66). It also works when not using ATA_CAM: ... acd0: DVDR at ata3-master UDMA66 ... So this semes to be a problem with the Promise controller and ATA_CAM. Any ideas? Or should I file PR? Thanks, -Andre From owner-freebsd-stable@FreeBSD.ORG Tue Apr 16 19:38:23 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BF1681C8 for ; Tue, 16 Apr 2013 19:38:23 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id A58B51266 for ; Tue, 16 Apr 2013 19:38:23 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta01.emeryville.ca.mail.comcast.net with comcast id Qdho1l0051smiN4A1jePnU; Tue, 16 Apr 2013 19:38:23 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id QjeN1l0091t3BNj8gjeNhY; Tue, 16 Apr 2013 19:38:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2621173A33; Tue, 16 Apr 2013 12:38:22 -0700 (PDT) Date: Tue, 16 Apr 2013 12:38:22 -0700 From: Jeremy Chadwick To: Andre Albsmeier Subject: Re: Lost CDROM on 9.1 with ATA_CAM on Promise controller Message-ID: <20130416193822.GA83620@icarus.home.lan> References: <20130416175520.GA9548@bali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130416175520.GA9548@bali> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366141103; bh=EUw7VUTJo6BsjiqzgZ/h7chfiH1+H3XXTwpnBxvBzfw=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=PNVVArT9R7GLCfG2DxOnTbDvpbGV9Q0BdgxU1tsqOGiIka9HkWoc5YWm0hdimBdo1 xppI5WvwrM5y/Uzq1d6YQ4FT/3zj0VxxlV6ybDOKAkJlCUvvioFf1zpaSq0kfiYxEd AXsTxhmc4iU3Hh8lxIzL6mtZnYlKVHUS0Iywxna57GfJ13GXGRdqaSqeg5l2LA5p8A ai7SE28p4iFOJwiLyQwsxTudunOBaB/V4cWjEbmELkuRPlNNCDbD1oDDM4GaVC3J54 1DxF0VKZL6UBx0okq1VJ0nAJhxOOI5iAw4Z5f1oVxpPybVQj+KLDlJ9wDqCWCvlL3o XEAlnOvDzL2Hw== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 16 Apr 2013 19:38:23 -0000 On Tue, Apr 16, 2013 at 07:55:20PM +0200, Andre Albsmeier wrote: > I have lost one of my CDROM drives (HL-DT-STDVD-RAM GH22LP20/2.00) > after going from 7.4 to 9.1 when using ATA_CAM. It is attached to > a Promise PDC20268 UDMA100 controller. A standard harddisk drive > attached to this controller works well. Cables, controller and drive > where replaced already. > > Kernel gives me: > > atapci1: port 0xb000-0xb007,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9800-0x980f mem 0xdf800000-0xdf803fff irq 11 at device 12.0 on pci0 > ata2: at channel 0 on atapci1 > ata3: at channel 1 on atapci1 > ... > ada0 at ata2 bus 0 scbus2 target 0 lun 0 > ada0: ATA-7 device > ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > ada0: 286188MB (586114704 512 byte sectors: 16H 63S/T 16383C) > ... > (cd2:ata3:0:0:0): got CAM status 0x50 > (cd2:ata3:0:0:0): fatal error, failed to attach to device > (cd2:ata3:0:0:0): lost device, 4 refs > (cd2:ata3:0:0:0): removing device entry > ... > > Attaching the CDROM drive to the controller that is integrated on > the mainboard (Intel PIIX4 UDMA33 controller) does not show this > problem (but here I don't have UDMA66). > > It also works when not using ATA_CAM: > > ... > acd0: DVDR at ata3-master UDMA66 > ... > > So this semes to be a problem with the Promise controller and ATA_CAM. > > Any ideas? Or should I file PR? The controller in question is a Promise Ultra100 TX2. The error message comes from sys/cam/scsi/scsi_cd.c, in function cddone(). The logic is a little hard for me to follow (I understand about 70% of it). Look at lines 1724 to 1877 for stable/9. 1. Can you provide full output from a verbose boot when the CD/DVD drive is attached to the Promise controller? 2. What firmware version the card is using? The PDC20268 had many, many firmware problems relating to ATAPI devices. 3. I wouldn't worry about ATA66 vs. ATA33; this drive can only support up to about 22MBytes/second so ATA66 isn't going to get you anything, so as a workaround, using the PIIX4 for it would not hurt you. 4. ONLY if this turns out to be a "controller thing": I'm not sure how much effort should be spent trying to make this work, as the PDC20268 is legacy/deprecated hardware (made/released 13 years ago). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 06:35:13 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 033E999C for ; Wed, 17 Apr 2013 06:35:13 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by mx1.freebsd.org (Postfix) with ESMTP id 31498E27 for ; Wed, 17 Apr 2013 06:35:11 +0000 (UTC) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id r3H6Q15w008379; Wed, 17 Apr 2013 08:26:01 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.13.6/8.13.6) with ESMTP id r3H6Q0kF026853; Wed, 17 Apr 2013 08:26:00 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.6/8.14.6) id r3H6Q0ql001304; Date: Wed, 17 Apr 2013 08:26:00 +0200 From: Andre Albsmeier To: Jeremy Chadwick Subject: Re: Lost CDROM on 9.1 with ATA_CAM on Promise controller Message-ID: <20130417062600.GA15613@bali> References: <20130416175520.GA9548@bali> <20130416193822.GA83620@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130416193822.GA83620@icarus.home.lan> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 06:35:13 -0000 On Tue, 16-Apr-2013 at 21:38:22 +0200, Jeremy Chadwick wrote: > On Tue, Apr 16, 2013 at 07:55:20PM +0200, Andre Albsmeier wrote: > > I have lost one of my CDROM drives (HL-DT-STDVD-RAM GH22LP20/2.00) > > after going from 7.4 to 9.1 when using ATA_CAM. It is attached to > > a Promise PDC20268 UDMA100 controller. A standard harddisk drive > > attached to this controller works well. Cables, controller and drive > > where replaced already. > > > > Kernel gives me: > > > > atapci1: port 0xb000-0xb007,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9800-0x980f mem 0xdf800000-0xdf803fff irq 11 at device 12.0 on pci0 > > ata2: at channel 0 on atapci1 > > ata3: at channel 1 on atapci1 > > ... > > ada0 at ata2 bus 0 scbus2 target 0 lun 0 > > ada0: ATA-7 device > > ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > > ada0: 286188MB (586114704 512 byte sectors: 16H 63S/T 16383C) > > ... > > (cd2:ata3:0:0:0): got CAM status 0x50 > > (cd2:ata3:0:0:0): fatal error, failed to attach to device > > (cd2:ata3:0:0:0): lost device, 4 refs > > (cd2:ata3:0:0:0): removing device entry > > ... > > > > Attaching the CDROM drive to the controller that is integrated on > > the mainboard (Intel PIIX4 UDMA33 controller) does not show this > > problem (but here I don't have UDMA66). > > > > It also works when not using ATA_CAM: > > > > ... > > acd0: DVDR at ata3-master UDMA66 > > ... > > > > So this semes to be a problem with the Promise controller and ATA_CAM. > > > > Any ideas? Or should I file PR? > > The controller in question is a Promise Ultra100 TX2. Right. Tried with an Ultra133, same effect. > > The error message comes from sys/cam/scsi/scsi_cd.c, in function > cddone(). The logic is a little hard for me to follow (I understand > about 70% of it). Look at lines 1724 to 1877 for stable/9. > > 1. Can you provide full output from a verbose boot when the CD/DVD drive > is attached to the Promise controller? Attached below. I have just filtered out some ahc cruft... Later I will try to boot a -current kernel -- just to see how this behaves... > > 2. What firmware version the card is using? The PDC20268 had many, many > firmware problems relating to ATAPI devices. It is the latest BIOS: 2.20.0.15. > > 3. I wouldn't worry about ATA66 vs. ATA33; this drive can only support > up to about 22MBytes/second so ATA66 isn't going to get you anything, > so as a workaround, using the PIIX4 for it would not hurt you. Probably. But I already had cdrecord complain when it came to the funky DMA speed test it is doing. It went away when using the UDMA66 port. And on the other hand I sometimes use the PIIX4 port for other stuff and I do not want to attach the cdrom to the slave port. > > 4. ONLY if this turns out to be a "controller thing": I'm not sure how > much effort should be spent trying to make this work, as the PDC20268 is > legacy/deprecated hardware (made/released 13 years ago). The whole box is more than 13 years old (good old Asus BX board) ;-) But since it worked in 7.4-STABLE I feel that this is some kind of regression. I do not want to waste anyone's resources in fixing it -- just if someone is curious and/or has an idea how to fix it... And here is the dmesg: Copyright (c) 1992-2013 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-STABLE #6: Wed Apr 17 07:56:57 CEST 2013 root@server.ofw.tld:/usr/obj/src/src-9/sys/bratfix i386 gcc version 4.2.1 20070831 patched [FreeBSD] Preloaded elf kernel "/boot/kernel/kernel" at 0xc097d000. Calibrating TSC clock ... TSC clock: 1405298309 Hz CPU: Intel(R) Celeron(TM) CPU 1400MHz (1405.30-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Family = 0x6 Model = 0xb Stepping = 1 Features=0x383f9ff Instruction TLB: 4 KB pages, 4-way set associative, 32 entries Instruction TLB: 4 MB pages, fully associative, 2 entries Data TLB: 4 KB pages, 4-way set associative, 64 entries 2nd-level cache: 256 KB, 8-way set associative, 32 byte line size 1st-level instruction cache: 16 KB, 4-way set associative, 32 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 16 KB, 4-way set associative, 32 byte line size real memory = 268435456 (256 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000000fb18fff, 250556416 bytes (61171 pages) avail memory = 253022208 (241 MB) bios32: Found BIOS32 Service Directory header at 0xc00f92a0 bios32: Entry = 0xf06c0 (c00f06c0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0x8c0 pnpbios: Found PnP BIOS data at 0xc00fc240 pnpbios: Entry = f0000:c270 Rev = 1.0 pnpbios: OEM ID cd041 Other BIOS signatures found: ULE: setup cpu 0 random: cpuctl: access to MSR registers/cpuid info. nfslock: pseudo-device io: mem: Pentium Pro MTRR support enabled null: ACPI: RSDP 0xf5a90 00014 (v00 ASUS ) ACPI: RSDT 0xffec000 0002C (v01 ASUS CUBX-L 30303031 MSFT 31313031) ACPI: FACP 0xffec080 00074 (v01 ASUS CUBX-L 30303031 MSFT 31313031) ACPI: DSDT 0xffec100 02626 (v01 ASUS CUBX-L 00001000 MSFT 0100000B) ACPI: FACS 0xffff000 00040 ACPI: BOOT 0xffec040 00028 (v01 ASUS CUBX-L 30303031 MSFT 31313031) acpi0: on motherboard acpi0: Power Button (fixed) acpi0: wakeup code va 0xc1f76000 pa 0x1000 atpic: Programming IRQ9 as level/low pci_open(1): mode 1 addr port (0x0cf8) is 0x8000005c pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, ff00000 (3) failed cpu0: on acpi0 cpu0: switching to generic Cx mode 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-0x73 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us, adjustment 0.500000000s) Event timer "RTC" frequency 32768 Hz quality 0 ACPI timer: 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 0/4 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 12 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 5 6 7 9 10 11 12 14 15 Validation 0 15 N 0 3 4 5 6 7 9 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 acpi_button0: on acpi0 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 0xc8000-0xdffff pcib0: decoding 3 range 0x10000000-0xffffffff ACPI: Found matching pin for 0.12.INTA at func 0: 11 ACPI: Found matching pin for 0.11.INTA at func 0: 10 ACPI: Found matching pin for 0.10.INTA at func 0: 12 ACPI: Found matching pin for 0.9.INTA at func 0: 15 ACPI: Found matching pin for 0.4.INTD at func 2: 255 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x7190, revid=0x03 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xe4000000, size 26, enabled pcib0: allocated type 3 (0xe4000000-0xe7ffffff) for rid 10 of pci0:0:0:0 found-> vendor=0x8086, dev=0x7191, revid=0x03 domain=0, bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0117, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x88 (34000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x02 domain=0, bus=0, slot=4, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7111, revid=0x01 domain=0, bus=0, slot=4, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib0: allocated type 4 (0x1f0-0x1f7) for rid 10 of pci0:0:4:1 pcib0: allocated type 4 (0x3f6-0x3f6) for rid 14 of pci0:0:4:1 pcib0: allocated type 4 (0x170-0x177) for rid 18 of pci0:0:4:1 pcib0: allocated type 4 (0x376-0x376) for rid 1c of pci0:0:4:1 map[20]: type I/O Port, range 32, base 0xd800, size 4, port disabled pcib0: allocated type 4 (0xd800-0xd80f) for rid 20 of pci0:0:4:1 found-> vendor=0x8086, dev=0x7112, revid=0x01 domain=0, bus=0, slot=4, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=255 map[20]: type I/O Port, range 32, base 0xd400, size 5, enabled pcib0: allocated type 4 (0xd400-0xd41f) for rid 20 of pci0:0:4:2 found-> vendor=0x8086, dev=0x7113, revid=0x02 domain=0, bus=0, slot=4, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[90]: type I/O Port, range 32, base 0xe800, size 4, enabled pcib0: allocated type 4 (0xe800-0xe80f) for rid 90 of pci0:0:4:3 found-> vendor=0x9004, dev=0x8178, revid=0x00 domain=0, bus=0, slot=9, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0280, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x08 (2000 ns) intpin=a, irq=15 map[10]: type I/O Port, range 32, base 0xd000, size 8, enabled pcib0: allocated type 4 (0xd000-0xd0ff) for rid 10 of pci0:0:9:0 map[14]: type Memory, range 32, base 0xe1000000, size 12, enabled pcib0: allocated type 3 (0xe1000000-0xe1000fff) for rid 14 of pci0:0:9:0 pcib0: matched entry for 0.9.INTA (src \134_SB_.LNKD:0) pcib0: slot 9 INTA routed to irq 15 via \134_SB_.LNKD found-> vendor=0x8086, dev=0x107c, revid=0x05 domain=0, bus=0, slot=10, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=12 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xe0800000, size 17, enabled pcib0: allocated type 3 (0xe0800000-0xe081ffff) for rid 10 of pci0:0:10:0 map[18]: type I/O Port, range 32, base 0xb800, size 6, enabled pcib0: allocated type 4 (0xb800-0xb83f) for rid 18 of pci0:0:10:0 pcib0: matched entry for 0.10.INTA (src \134_SB_.LNKC:0) pcib0: slot 10 INTA routed to irq 12 via \134_SB_.LNKC found-> vendor=0x9005, dev=0x0080, revid=0x02 domain=0, bus=0, slot=11, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x28 (10000 ns), maxlat=0x19 (6250 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xb400, size 8, enabled pcib0: allocated type 4 (0xb400-0xb4ff) for rid 10 of pci0:0:11:0 map[14]: type Memory, range 64, base 0xe0000000, size 12, enabled pcib0: allocated type 3 (0xe0000000-0xe0000fff) for rid 14 of pci0:0:11:0 pcib0: matched entry for 0.11.INTA (src \134_SB_.LNKB:0) pcib0: slot 11 INTA routed to irq 10 via \134_SB_.LNKB found-> vendor=0x105a, dev=0x4d68, revid=0x02 domain=0, bus=0, slot=12, func=0 class=01-80-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0430, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0x12 (4500 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D3 current D0 map[10]: type I/O Port, range 32, base 0xb000, size 3, enabled pcib0: allocated type 4 (0xb000-0xb007) for rid 10 of pci0:0:12:0 map[14]: type I/O Port, range 32, base 0xa800, size 2, enabled pcib0: allocated type 4 (0xa800-0xa803) for rid 14 of pci0:0:12:0 map[18]: type I/O Port, range 32, base 0xa400, size 3, enabled pcib0: allocated type 4 (0xa400-0xa407) for rid 18 of pci0:0:12:0 map[1c]: type I/O Port, range 32, base 0xa000, size 2, enabled pcib0: allocated type 4 (0xa000-0xa003) for rid 1c of pci0:0:12:0 map[20]: type I/O Port, range 32, base 0x9800, size 4, enabled pcib0: allocated type 4 (0x9800-0x980f) for rid 20 of pci0:0:12:0 map[24]: type Memory, range 32, base 0xdf800000, size 14, enabled pcib0: allocated type 3 (0xdf800000-0xdf803fff) for rid 24 of pci0:0:12:0 pcib0: matched entry for 0.12.INTA (src \134_SB_.LNKA:0) pcib0: slot 12 INTA routed to irq 11 via \134_SB_.LNKA eccmon0: RAM ECC Monitor v0.13 on i440BX/ZX (8086:7190), reporting tested eccmon0: Capabilities: ECC with hardware scrubber eccmon0: Current mode: ECC with hardware scrubber eccmon0: Bank Size Type ILV ECC eccmon0: 0 128M SDR N Y eccmon0: 2 128M SDR N Y eccmon0: Total RAM detected: 256M eccmon0: on hostb0 eccmon0: attached pcib1: at device 1.0 on pci0 pcib0: allocated type 3 (0xe1800000-0xe2dfffff) for rid 20 of pcib1 pcib0: allocated type 3 (0xe2f00000-0xe3ffffff) for rid 24 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: memory decode 0xe1800000-0xe2dfffff pcib1: prefetched decode 0xe2f00000-0xe3ffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x102b, dev=0x0521, revid=0x03 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x20 (8000 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe3000000, size 24, enabled pcib1: allocated prefetch range (0xe3000000-0xe3ffffff) for rid 10 of pci0:1:0:0 map[14]: type Memory, range 32, base 0xe2000000, size 14, enabled pcib1: allocated memory range (0xe2000000-0xe2003fff) for rid 14 of pci0:1:0:0 map[18]: type Memory, range 32, base 0xe1800000, size 23, enabled pcib1: allocated memory range (0xe1800000-0xe1ffffff) for rid 18 of pci0:1:0:0 pcib0: matched entry for 0.1.INTA (src \134_SB_.LNKA:0) pcib0: slot 1 INTA routed to irq 11 via \134_SB_.LNKA pcib1: slot 0 INTA is routed to irq 11 vgapci0: mem 0xe3000000-0xe3ffffff,0xe2000000-0xe2003fff,0xe1800000-0xe1ffffff irq 11 at device 0.0 on pci1 isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 4.1 on pci0 ata0: at channel 0 on atapci0 ata1: at channel 1 on atapci0 pci0: at device 4.2 (no driver attached) intsmb0: port 0xe800-0xe80f at device 4.3 on pci0 intsmb0: intr IRQ 9 enabled revision 0 smbus0: on intsmb0 smb0: on smbus0 ahc0: port 0xd000-0xd0ff mem 0xe1000000-0xe1000fff irq 15 at device 9.0 on pci0 ahc0: Bugs (0x0025): TMODE_WIDEODD CACHETHEN PCI_MWI ahc0: Defaulting to MEMIO on ahc0: Reading SEEPROM...done. ahc0: Low byte termination Enabled ahc0: Downloading Sequencer Program... 442 instructions downloaded ahc0: Features 0x10001, Bugs 0x25, Flags 0x20485540 aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs em0: port 0xb800-0xb83f mem 0xe0800000-0xe081ffff irq 12 at device 10.0 on pci0 em0: bpf attached em0: Ethernet address: 00:1b:21:0a:8d:db ahc1: port 0xb400-0xb4ff mem 0xe0000000-0xe0000fff irq 10 at device 11.0 on pci0 ahc1: Bugs (0x0040): SCBCHAN_UPLOAD ahc1: Defaulting to MEMIO on ahc1: Reading SEEPROM...done. ahc1: Manual SE Termination ahc1: Manual LVD Termination ahc1: BIOS eeprom is present ahc1: Secondary High byte termination Enabled ahc1: Secondary Low byte termination Enabled ahc1: Primary Low Byte termination Enabled ahc1: Primary High Byte termination Enabled ahc1: Downloading Sequencer Program... 423 instructions downloaded ahc1: Features 0x1def6, Bugs 0x40, Flags 0x20485560 aic7892: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs atapci1: port 0xb000-0xb007,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9800-0x980f mem 0xdf800000-0xdf803fff irq 11 at device 12.0 on pci0 ata2: at channel 0 on atapci1 ata3: at channel 1 on atapci1 fdc0: port 0x3f2-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: fast interrupt uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: fast interrupt atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] pnp_identify: Trying Read_Port at 203 ... pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ahc_isa_probe 0: ioport 0xc00 alloc failed ... pcib0: allocated type 3 (0xdf800-0xdffff) for rid 2 of orm0 isa_probe_children: disabling PnP devices ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it attimer: attimer0 already exists; skipping it fdc: fdc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff,0xd8000-0xda7ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <9 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: scteken (teken terminal) vga0: at port 0x3b0-0x3df iomem 0xa0000-0xbffff on isa0 pcib0: allocated type 4 (0x3b0-0x3df) for rid 0 of vga0 pcib0: allocated type 3 (0xa0000-0xbffff) for rid 0 of vga0 ppc0 failed to probe at irq 7 on isa0 wbwd0 failed to probe on isa0 isa_probe_children: probing PnP devices acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0xe410 Device configuration finished. procfs registered Timecounters tick every 10.000 msec lo0: bpf attached ata0: reset tp1 mask=00 ostat0=ff ostat1=ff ata1: reset tp1 mask=00 ostat0=ff ostat1=ff (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. (noperiph:ahc1:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. ata2: reset tp1 mask=03 ostat0=50 ostat1=00 ata2: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata3: reset tp1 mask=03 ostat0=51 ostat1=00 ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=00 stat1=00 devices=0x10000 ahc0: Selection Timeout on A:2. 0 SCBs aborted ahc0: Selection Timeout on A:3. 0 SCBs aborted ahc0: Selection Timeout on A:4. 0 SCBs aborted (probe5:ahc0:0:5:0): Down reving Protocol Version from 4 to 2? ... (ahc0:A:1:0): Received SDTR period c, offset f Filtered to period c, offset f ahc0: target 1 synchronous at 20.0MHz, offset = 0xf ahc1: Selection Timeout on A:1. 0 SCBs aborted ahc1: Selection Timeout on A:2. 0 SCBs aborted ahc1: Selection Timeout on A:3. 0 SCBs aborted (ahc1:A:4:0): Received WDTR 1 filtered to 0 (ahc1:A:4:0): Target Initiated WDTR (ahc1:A:4:0): Sending WDTR 0 ahc1: target 4 using 8bit transfers (ahc1:A:4:0): Received SDTR period a, offset 79 Filtered to period 0, offset 0 ahc1: target 4 using asynchronous transfers (ahc1:A:4:0): Target Initiated SDTR (ahc1:A:4:0): Sending SDTR period 45, offset 0 ahc1: Selection Timeout on A:5. 0 SCBs aborted ... ahc1: Selection Timeout on A:14. 0 SCBs aborted ahc1: Selection Timeout on A:15. 0 SCBs aborted (ahc1:A:4:0): Sending PPR bus_width 1, period 9, offset 7f, ppr_options 2 (ahc1:A:4:0): Received PPR width 1, period 9, offset 78,options 2 Filtered to width 1, period 9, offset 78, options 2 ahc1: target 4 using 16bit transfers ahc1: target 4 synchronous at 80.0MHz DT, offset = 0x78 (probe7:ahc1:0:0:0): Down reving Protocol Version from 4 to 2? (probe7:ahc1:0:0:0): Down reving Transport Version from 3 to 2? (ahc1:A:4:0): Sending PPR bus_width 1, period 9, offset 78, ppr_options 2 (ahc1:A:4:0): Received PPR width 1, period 9, offset 78,options 2 Filtered to width 1, period 9, offset 78, options 2 (ahc1:A:0:0): Sending WDTR 1 (ahc1:A:0:0): Received WDTR 1 filtered to 1 ahc1: target 0 using 16bit transfers (ahc1:A:0:0): Sending SDTR period c, offset 7f (ahc1:A:0:0): Received SDTR period c, offset f Filtered to period c, offset f ahc1: target 0 synchronous at 20.0MHz, offset = 0xf pass0 at ahc0 bus 0 scbus0 target 0 lun 0 pass0: Fixed Direct Access SCSI-2 device pass0: Serial Number F25V7824 pass0: 20.000MB/s transfers (20.000MHz, offset 15) pass1 at ahc0 bus 0 scbus0 target 1 lun 0 pass1: Fixed Direct Access SCSI-2 device pass1: Serial Number F2587270 pass1: 20.000MB/s transfers (20.000MHz, offset 15) pass2 at ahc0 bus 0 scbus0 target 5 lun 0 pass2: Removable CD-ROM SCSI-2 device pass2: 20.000MB/s transfers (20.000MHz, offset 15) pass3 at ahc0 bus 0 scbus0 target 6 lun 0 pass3: Removable CD-ROM SCSI-2 device pass3: 20.000MB/s transfers (20.000MHz, offset 15) pass4 at ahc1 bus 0 scbus1 target 0 lun 0 pass4: Fixed Direct Access SCSI-2 device pass4: Serial Number 3AL0RR7H0000701423PB pass4: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) pass4: Command Queueing enabled pass5 at ahc1 bus 0 scbus1 target 4 lun 0 pass5: Removable Sequential Access SCSI-4 device pass5: Serial Number QD0719AMC00028 pass5: 160.000MB/s transfers (80.000MHz DT, offset 120, 16bit) pass6 at ata2 bus 0 scbus2 target 0 lun 0 pass6: ATA-7 device pass6: Serial Number B61T05CH pass6: 100.000MB/s transfers (UDMA5, PIO 8192bytes) pass7 at ata3 bus 0 scbus3 target 0 lun 0 pass7: Removable CD-ROM SCSI-0 device pass7: 66.700MB/s transfers (UDMA4, ATAPI 12bytes, PIO 65534bytes) sa0 at ahc1 bus 0 scbus1 target 4 lun 0 sa0: Removable Sequential Access SCSI-4 device sa0: Serial Number QD0719AMC00028 sa0: 160.000MB/s transfers (80.000MHz DT, offset 120, 16bit) ada0 at ata2 bus 0 scbus2 target 0 lun 0 ada0: ATA-7 device ada0: Serial Number B61T05CH ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) ada0: 286188MB (586114704 512 byte sectors: 16H 63S/T 16383C) da10 at ahc1 bus 0 scbus1 target 0 lun 0 da10: Fixed Direct Access SCSI-2 device da10: Serial Number 3AL0RR7H0000701423PB da10: 40.000MB/s transfers (20.000MHz, offset 15, 16bit) da10: Command Queueing enabled da10: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) (ahc0:A:5:0): Sending SDTR period c, offset f Timecounter "TSC" frequency 1405298309 Hz quality 800 GEOM: new disk da0 GEOM: new disk da1 GEOM: new disk da10 GEOM: new disk cd1 GEOM: new disk cd0 GEOM: new disk cd2 GEOM: new disk ada0 (ahc0:A:5:0): Received SDTR period c, offset f Filtered to period c, offset f (ahc0:A:6:0): Sending SDTR period c, offset f cd1 at ahc0 bus 0 scbus0 target 5 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 20.000MB/s transfers (20.000MHz, offset 15) cd1: Attempt to query device size failed: NOT READY, Medium not present - tray closed (ahc0:A:6:0): Received SDTR period c, offset f Filtered to period c, offset f da1 at ahc0 bus 0 scbus0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number F2587270 da1: 20.000MB/s transfers (20.000MHz, offset 15) da1: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da0 at ahc0 bus 0 scbus0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number F25V7824 da0: 20.000MB/s transfers (20.000MHz, offset 15) da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) (ahc0:A:5:0): Sending SDTR period c, offset f (ahc0:A:5:0): Received SDTR period c, offset f Filtered to period c, offset f ... (ahc0:A:6:0): Sending SDTR period c, offset f (ahc0:A:6:0): Received SDTR period c, offset f Filtered to period c, offset f cd0 at ahc0 bus 0 scbus0 target 6 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed (ahc0:A:6:0): Sending SDTR period c, offset f (ahc0:A:6:0): Received SDTR period c, offset f Filtered to period c, offset f ... (ahc0:A:6:0): Sending SDTR period c, offset f (ahc0:A:6:0): Received SDTR period c, offset f Filtered to period c, offset f ata3: reset tp1 mask=03 ostat0=50 ostat1=00 ata3: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata3: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=00 stat1=00 devices=0x10000 (cd2:ata3:0:0:0): got CAM status 0x50 (cd2:ata3:0:0:0): fatal error, failed to attach to device (cd2:ata3:0:0:0): lost device, 4 refs Opened disk cd2 -> 6 (cd2:ata3:0:0:0): removing device entry (ahc0:A:5:0): Sending SDTR period c, offset f (ahc0:A:5:0): Received SDTR period c, offset f Filtered to period c, offset f ... From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 07:11:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ECE6A689 for ; Wed, 17 Apr 2013 07:11:00 +0000 (UTC) (envelope-from olavgg@gmail.com) Received: from mail-la0-x244.google.com (mail-la0-x244.google.com [IPv6:2a00:1450:4010:c03::244]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0A9FAC for ; Wed, 17 Apr 2013 07:11:00 +0000 (UTC) Received: by mail-la0-f68.google.com with SMTP id fk20so121963lab.11 for ; Wed, 17 Apr 2013 00:10:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=VpY/SpCK2b1NCRYc0u+UeDjDm+iUAoFWJ6U7vByigxw=; b=fIHl69eHKVY0RJ0+4thhZMKhMGn06DUSdqIlk2E1rmGkvNNVeiRcxfftFqJH6Fw3Ze frZkxGLBckEQT9qVlPYOoR28QoHCRgnDUOIijzltbNBKSYnS9Ailx0Wm4/5OFUWIuagZ YZ7FfbEGWckTQNX3mK1W4FLu8rQ/88ntgWb79VxKyGv9ASwI77ZlpWHXjtD/XDxotEr3 w03hCMeLJ9wC2kKe+yKCl2aKie/kC2v7HGHssFZ4gyyUCEqlORlnZiD+mMJ5baTXLHrS axgSpNs0nWCuGBbcxOuzT35f5DxaR+tsZaufVaGlyDfaLw4fBksLHfkWQeasTVq+bv5u Q6lg== MIME-Version: 1.0 X-Received: by 10.112.162.130 with SMTP id ya2mr2935476lbb.122.1366182659427; Wed, 17 Apr 2013 00:10:59 -0700 (PDT) Received: by 10.112.23.232 with HTTP; Wed, 17 Apr 2013 00:10:59 -0700 (PDT) Date: Wed, 17 Apr 2013 09:10:59 +0200 Message-ID: Subject: make buildkernel for GENERIC 9-STABLE just hangs, no error From: =?ISO-8859-1?Q?Olav_Gr=F8n=E5s_Gjerde?= To: FreeBSD Stable Mailing List Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 07:11:01 -0000 I have a weird problem while building the GENERIC 9-STABLE kernel. After around 5 minutes of compile time, the process just hangs on same place. No error. I've tried compiling different commits from this week with the same result. The part in the buildkernel process that hangs is this: MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror vers.c ctfconvert -L VERSION -g vers.o linking kernel.debug ctfmerge -L VERSION -g -o kernel.debug ............+ alot of *.o Any suggestions? From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 08:53:56 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95E0CA47 for ; Wed, 17 Apr 2013 08:53:56 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 64946640 for ; Wed, 17 Apr 2013 08:53:56 +0000 (UTC) Received: from omta16.emeryville.ca.mail.comcast.net ([76.96.30.72]) by qmta01.emeryville.ca.mail.comcast.net with comcast id QwmX1l0021ZMdJ4A1wtvlx; Wed, 17 Apr 2013 08:53:55 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta16.emeryville.ca.mail.comcast.net with comcast id Qwtu1l00G1t3BNj8cwtv5s; Wed, 17 Apr 2013 08:53:55 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C6B9C73A33; Wed, 17 Apr 2013 01:53:54 -0700 (PDT) Date: Wed, 17 Apr 2013 01:53:54 -0700 From: Jeremy Chadwick To: Andre Albsmeier Subject: Re: Lost CDROM on 9.1 with ATA_CAM on Promise controller Message-ID: <20130417085354.GA98850@icarus.home.lan> References: <20130416175520.GA9548@bali> <20130416193822.GA83620@icarus.home.lan> <20130417062600.GA15613@bali> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130417062600.GA15613@bali> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366188835; bh=YLa5u2eA6tv5X8B8zyj79otmdpSx8ZmQgUsFDIYq39c=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=M1qiHfSQCTwedIPfje1jVl0/DfAtOao7EeHrPyzZiMI3MWkUZL66TmdrsUYFueEH3 P0ijkbHI5lWMqbr3xh4Q8SBKwVHZrjexrzDYSpJt7sbq8E/oAi7hE39Yyrn3SlnGGs dKtqdPntcgQmJ066Rxf8K25DALBqc3jWPTZI78C56M0xROpNga63RmIM4Fl5PcROeB OGOwgbNEKDie+eRJBCJGMN8qg0P1szsEK20eHqsYCkIjcD5TMFzanRVsCN7PueInVB onxGp4ke6BfsoR7kqK9Ok5nirAawX3sOWRoZo9qUhjbk71Uj5wgJrSPYf5RiEpkAqt VUxmgeVUsQbhA== Cc: Kenneth Merry , Alexander Motin , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 08:53:56 -0000 On Wed, Apr 17, 2013 at 08:26:00AM +0200, Andre Albsmeier wrote: > On Tue, 16-Apr-2013 at 21:38:22 +0200, Jeremy Chadwick wrote: > > On Tue, Apr 16, 2013 at 07:55:20PM +0200, Andre Albsmeier wrote: > > > I have lost one of my CDROM drives (HL-DT-STDVD-RAM GH22LP20/2.00) > > > after going from 7.4 to 9.1 when using ATA_CAM. It is attached to > > > a Promise PDC20268 UDMA100 controller. A standard harddisk drive > > > attached to this controller works well. Cables, controller and drive > > > where replaced already. > > > > > > Kernel gives me: > > > > > > atapci1: port 0xb000-0xb007,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9800-0x980f mem 0xdf800000-0xdf803fff irq 11 at device 12.0 on pci0 > > > ata2: at channel 0 on atapci1 > > > ata3: at channel 1 on atapci1 > > > ... > > > ada0 at ata2 bus 0 scbus2 target 0 lun 0 > > > ada0: ATA-7 device > > > ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > > > ada0: 286188MB (586114704 512 byte sectors: 16H 63S/T 16383C) > > > ... > > > (cd2:ata3:0:0:0): got CAM status 0x50 > > > (cd2:ata3:0:0:0): fatal error, failed to attach to device > > > (cd2:ata3:0:0:0): lost device, 4 refs > > > (cd2:ata3:0:0:0): removing device entry > > > ... > > > > > > Attaching the CDROM drive to the controller that is integrated on > > > the mainboard (Intel PIIX4 UDMA33 controller) does not show this > > > problem (but here I don't have UDMA66). > > > > > > It also works when not using ATA_CAM: > > > > > > ... > > > acd0: DVDR at ata3-master UDMA66 > > > ... > > > > > > So this semes to be a problem with the Promise controller and ATA_CAM. > > > > > > Any ideas? Or should I file PR? > > > > The controller in question is a Promise Ultra100 TX2. > > Right. Tried with an Ultra133, same effect. > > > > > The error message comes from sys/cam/scsi/scsi_cd.c, in function > > cddone(). The logic is a little hard for me to follow (I understand > > about 70% of it). Look at lines 1724 to 1877 for stable/9. > > > > 1. Can you provide full output from a verbose boot when the CD/DVD drive > > is attached to the Promise controller? > > Attached below. I have just filtered out some ahc cruft... > > Later I will try to boot a -current kernel -- just to see > how this behaves... > > > > > 2. What firmware version the card is using? The PDC20268 had many, many > > firmware problems relating to ATAPI devices. > > It is the latest BIOS: 2.20.0.15. > > > > > 3. I wouldn't worry about ATA66 vs. ATA33; this drive can only support > > up to about 22MBytes/second so ATA66 isn't going to get you anything, > > so as a workaround, using the PIIX4 for it would not hurt you. > > Probably. But I already had cdrecord complain when it > came to the funky DMA speed test it is doing. It went > away when using the UDMA66 port. And on the other hand > I sometimes use the PIIX4 port for other stuff and I > do not want to attach the cdrom to the slave port. > > > > > 4. ONLY if this turns out to be a "controller thing": I'm not sure how > > much effort should be spent trying to make this work, as the PDC20268 is > > legacy/deprecated hardware (made/released 13 years ago). > > The whole box is more than 13 years old (good old Asus BX board) ;-) > > But since it worked in 7.4-STABLE I feel that this is some kind > of regression. I do not want to waste anyone's resources in fixing > it -- just if someone is curious and/or has an idea how to fix > it... > > And here is the dmesg: > > {snipping for mail brevity} Thanks. CC'd ken@ and mav@ for advice on this. Here's the dmesg: http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073131.html Short details: The device under scrutiny here is cd2 on ata3, which is an ATAPI IDE-based optical drive. The drive works when either: a) Connected to a different IDE controller (atapci0), or, b) When ATA_CAM is removed (i.e. use ata(4) exclusively). No idea if atapicam(4) during scenario (b) works or not. :-) -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 09:39:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C6EB38D9; Wed, 17 Apr 2013 09:39:14 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D8BB880; Wed, 17 Apr 2013 09:39:14 +0000 (UTC) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id r3H9SIw0004591; Wed, 17 Apr 2013 11:28:18 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.13.6/8.13.6) with ESMTP id r3H9SIAc031059; Wed, 17 Apr 2013 11:28:18 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.6/8.14.6) id r3H9SIZP001848; Date: Wed, 17 Apr 2013 11:28:18 +0200 From: Andre Albsmeier To: Jeremy Chadwick Subject: Re: Lost CDROM on 9.1 with ATA_CAM on Promise controller Message-ID: <20130417092818.GA16400@bali> References: <20130416175520.GA9548@bali> <20130416193822.GA83620@icarus.home.lan> <20130417062600.GA15613@bali> <20130417085354.GA98850@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130417085354.GA98850@icarus.home.lan> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kenneth Merry , Alexander Motin , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 09:39:14 -0000 On Wed, 17-Apr-2013 at 10:53:54 +0200, Jeremy Chadwick wrote: > On Wed, Apr 17, 2013 at 08:26:00AM +0200, Andre Albsmeier wrote: > > On Tue, 16-Apr-2013 at 21:38:22 +0200, Jeremy Chadwick wrote: > > > On Tue, Apr 16, 2013 at 07:55:20PM +0200, Andre Albsmeier wrote: > > > > I have lost one of my CDROM drives (HL-DT-STDVD-RAM GH22LP20/2.00) > > > > after going from 7.4 to 9.1 when using ATA_CAM. It is attached to > > > > a Promise PDC20268 UDMA100 controller. A standard harddisk drive > > > > attached to this controller works well. Cables, controller and drive > > > > where replaced already. > > > > > > > > Kernel gives me: > > > > > > > > atapci1: port 0xb000-0xb007,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9800-0x980f mem 0xdf800000-0xdf803fff irq 11 at device 12.0 on pci0 > > > > ata2: at channel 0 on atapci1 > > > > ata3: at channel 1 on atapci1 > > > > ... > > > > ada0 at ata2 bus 0 scbus2 target 0 lun 0 > > > > ada0: ATA-7 device > > > > ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > > > > ada0: 286188MB (586114704 512 byte sectors: 16H 63S/T 16383C) > > > > ... > > > > (cd2:ata3:0:0:0): got CAM status 0x50 > > > > (cd2:ata3:0:0:0): fatal error, failed to attach to device > > > > (cd2:ata3:0:0:0): lost device, 4 refs > > > > (cd2:ata3:0:0:0): removing device entry > > > > ... > > > > > > > > Attaching the CDROM drive to the controller that is integrated on > > > > the mainboard (Intel PIIX4 UDMA33 controller) does not show this > > > > problem (but here I don't have UDMA66). > > > > > > > > It also works when not using ATA_CAM: > > > > > > > > ... > > > > acd0: DVDR at ata3-master UDMA66 > > > > ... > > > > > > > > So this semes to be a problem with the Promise controller and ATA_CAM. > > > > > > > > Any ideas? Or should I file PR? > > > > > > The controller in question is a Promise Ultra100 TX2. > > > > Right. Tried with an Ultra133, same effect. > > > > > > > > The error message comes from sys/cam/scsi/scsi_cd.c, in function > > > cddone(). The logic is a little hard for me to follow (I understand > > > about 70% of it). Look at lines 1724 to 1877 for stable/9. > > > > > > 1. Can you provide full output from a verbose boot when the CD/DVD drive > > > is attached to the Promise controller? > > > > Attached below. I have just filtered out some ahc cruft... > > > > Later I will try to boot a -current kernel -- just to see > > how this behaves... > > > > > > > > 2. What firmware version the card is using? The PDC20268 had many, many > > > firmware problems relating to ATAPI devices. > > > > It is the latest BIOS: 2.20.0.15. > > > > > > > > 3. I wouldn't worry about ATA66 vs. ATA33; this drive can only support > > > up to about 22MBytes/second so ATA66 isn't going to get you anything, > > > so as a workaround, using the PIIX4 for it would not hurt you. > > > > Probably. But I already had cdrecord complain when it > > came to the funky DMA speed test it is doing. It went > > away when using the UDMA66 port. And on the other hand > > I sometimes use the PIIX4 port for other stuff and I > > do not want to attach the cdrom to the slave port. > > > > > > > > 4. ONLY if this turns out to be a "controller thing": I'm not sure how > > > much effort should be spent trying to make this work, as the PDC20268 is > > > legacy/deprecated hardware (made/released 13 years ago). > > > > The whole box is more than 13 years old (good old Asus BX board) ;-) > > > > But since it worked in 7.4-STABLE I feel that this is some kind > > of regression. I do not want to waste anyone's resources in fixing > > it -- just if someone is curious and/or has an idea how to fix > > it... > > > > And here is the dmesg: > > > > {snipping for mail brevity} > > Thanks. CC'd ken@ and mav@ for advice on this. Here's the dmesg: Thanks for trying to help. > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073131.html > > Short details: > > The device under scrutiny here is cd2 on ata3, which is an ATAPI > IDE-based optical drive. The drive works when either: > > a) Connected to a different IDE controller (atapci0), or, > b) When ATA_CAM is removed (i.e. use ata(4) exclusively). > > No idea if atapicam(4) during scenario (b) works or not. :-) Ha, atapicam... Forgot about this ;-). atapicam works: FreeBSD 9.1-STABLE #8: Wed Apr 17 11:12:17 CEST 2013 ... atapci1: port 0xb000-0xb007,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9800-0x980f mem 0xdf800000-0xdf803fff irq 11 at device 12.0 on pci0 ata2: at channel 0 on atapci1 ata3: at channel 1 on atapci1 ... cd2 at ata3 bus 0 scbus3 target 0 lun 0 cd2: Removable CD-ROM SCSI-0 device cd2: 3.300MB/s transfers cd2: Attempt to query device size failed: NOT READY, Medium not present - tray closed ... Only visible difference to 7.4-STABLE: Here it got 66 MB/s but I think the above 3.3 are just faked up: FreeBSD 7.4-STABLE #0: Tue Aug 14 11:28:27 CEST 2012 ... cd2 at ata2 bus 0 target 0 lun 0 cd2: Removable CD-ROM SCSI-0 device cd2: 66.000MB/s transfers cd2: Attempt to query device size failed: NOT READY, Medium not present - tray closed -Andre > > -- > | Jeremy Chadwick jdc@koitsu.org | > | UNIX Systems Administrator http://jdc.koitsu.org/ | > | Mountain View, CA, US | > | Making life hard for others since 1977. PGP 4BD6C0CB | -- BSD, from the people who brought you TCP/IP. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 09:47:15 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 43E12AE2; Wed, 17 Apr 2013 09:47:15 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mx1.freebsd.org (Postfix) with ESMTP id CDA818F1; Wed, 17 Apr 2013 09:47:14 +0000 (UTC) Received: from mail1.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id r3H9lDOd006632; Wed, 17 Apr 2013 11:47:13 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id r3H9lDgQ001490; Wed, 17 Apr 2013 11:47:13 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.6/8.14.6) id r3H9lCK9001919; Date: Wed, 17 Apr 2013 11:47:12 +0200 From: Andre Albsmeier To: Jeremy Chadwick Subject: Re: Lost CDROM on 9.1 with ATA_CAM on Promise controller Message-ID: <20130417094712.GA16791@bali> References: <20130416175520.GA9548@bali> <20130416193822.GA83620@icarus.home.lan> <20130417062600.GA15613@bali> <20130417085354.GA98850@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130417085354.GA98850@icarus.home.lan> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Kenneth Merry , Alexander Motin , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 09:47:15 -0000 On Wed, 17-Apr-2013 at 10:53:54 +0200, Jeremy Chadwick wrote: > On Wed, Apr 17, 2013 at 08:26:00AM +0200, Andre Albsmeier wrote: > > On Tue, 16-Apr-2013 at 21:38:22 +0200, Jeremy Chadwick wrote: > > > On Tue, Apr 16, 2013 at 07:55:20PM +0200, Andre Albsmeier wrote: > > > > I have lost one of my CDROM drives (HL-DT-STDVD-RAM GH22LP20/2.00) > > > > after going from 7.4 to 9.1 when using ATA_CAM. It is attached to > > > > a Promise PDC20268 UDMA100 controller. A standard harddisk drive > > > > attached to this controller works well. Cables, controller and drive > > > > where replaced already. > > > > > > > > Kernel gives me: > > > > > > > > atapci1: port 0xb000-0xb007,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9800-0x980f mem 0xdf800000-0xdf803fff irq 11 at device 12.0 on pci0 > > > > ata2: at channel 0 on atapci1 > > > > ata3: at channel 1 on atapci1 > > > > ... > > > > ada0 at ata2 bus 0 scbus2 target 0 lun 0 > > > > ada0: ATA-7 device > > > > ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > > > > ada0: 286188MB (586114704 512 byte sectors: 16H 63S/T 16383C) > > > > ... > > > > (cd2:ata3:0:0:0): got CAM status 0x50 > > > > (cd2:ata3:0:0:0): fatal error, failed to attach to device > > > > (cd2:ata3:0:0:0): lost device, 4 refs > > > > (cd2:ata3:0:0:0): removing device entry > > > > ... > > > > > > > > Attaching the CDROM drive to the controller that is integrated on > > > > the mainboard (Intel PIIX4 UDMA33 controller) does not show this > > > > problem (but here I don't have UDMA66). > > > > > > > > It also works when not using ATA_CAM: > > > > > > > > ... > > > > acd0: DVDR at ata3-master UDMA66 > > > > ... > > > > > > > > So this semes to be a problem with the Promise controller and ATA_CAM. > > > > > > > > Any ideas? Or should I file PR? > > > > > > The controller in question is a Promise Ultra100 TX2. > > > > Right. Tried with an Ultra133, same effect. > > > > > > > > The error message comes from sys/cam/scsi/scsi_cd.c, in function > > > cddone(). The logic is a little hard for me to follow (I understand > > > about 70% of it). Look at lines 1724 to 1877 for stable/9. > > > > > > 1. Can you provide full output from a verbose boot when the CD/DVD drive > > > is attached to the Promise controller? > > > > Attached below. I have just filtered out some ahc cruft... > > > > Later I will try to boot a -current kernel -- just to see > > how this behaves... > > > > > > > > 2. What firmware version the card is using? The PDC20268 had many, many > > > firmware problems relating to ATAPI devices. > > > > It is the latest BIOS: 2.20.0.15. > > > > > > > > 3. I wouldn't worry about ATA66 vs. ATA33; this drive can only support > > > up to about 22MBytes/second so ATA66 isn't going to get you anything, > > > so as a workaround, using the PIIX4 for it would not hurt you. > > > > Probably. But I already had cdrecord complain when it > > came to the funky DMA speed test it is doing. It went > > away when using the UDMA66 port. And on the other hand > > I sometimes use the PIIX4 port for other stuff and I > > do not want to attach the cdrom to the slave port. > > > > > > > > 4. ONLY if this turns out to be a "controller thing": I'm not sure how > > > much effort should be spent trying to make this work, as the PDC20268 is > > > legacy/deprecated hardware (made/released 13 years ago). > > > > The whole box is more than 13 years old (good old Asus BX board) ;-) > > > > But since it worked in 7.4-STABLE I feel that this is some kind > > of regression. I do not want to waste anyone's resources in fixing > > it -- just if someone is curious and/or has an idea how to fix > > it... > > > > And here is the dmesg: > > > > {snipping for mail brevity} > > Thanks. CC'd ken@ and mav@ for advice on this. Here's the dmesg: > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073131.html > > Short details: > > The device under scrutiny here is cd2 on ata3, which is an ATAPI > IDE-based optical drive. The drive works when either: > > a) Connected to a different IDE controller (atapci0), or, > b) When ATA_CAM is removed (i.e. use ata(4) exclusively). And just as a note: The -current kernel from https://snapshots.glenbarber.us/Latest/FreeBSD-10.0-CURRENT-i386-20130316-r248381-bootonly.iso shows the same problem... -Andre From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 09:58:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EEA8ECCA for ; Wed, 17 Apr 2013 09:58:30 +0000 (UTC) (envelope-from willy@Offermans.Rompen.nl) Received: from cpsmtpb-ews05.kpnxchange.com (cpsmtpb-ews05.kpnxchange.com [213.75.39.8]) by mx1.freebsd.org (Postfix) with ESMTP id 62EE4973 for ; Wed, 17 Apr 2013 09:58:29 +0000 (UTC) Received: from cpsps-ews28.kpnxchange.com ([10.94.84.194]) by cpsmtpb-ews05.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 17 Apr 2013 11:57:21 +0200 Received: from CPSMTPM-CMT109.kpnxchange.com ([195.121.3.28]) by cpsps-ews28.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Wed, 17 Apr 2013 11:57:21 +0200 Received: from sun.offermans.rompen.nl ([77.170.60.162]) by CPSMTPM-CMT109.kpnxchange.com with Microsoft SMTPSVC(7.0.6002.18264); Wed, 17 Apr 2013 11:57:21 +0200 Received: from squid (squid.vpn.offrom.nl [10.168.0.72]) by sun.offermans.rompen.nl (8.14.5/8.14.4) with ESMTP id r3H9vKtD033023; Wed, 17 Apr 2013 11:57:20 +0200 (CEST) (envelope-from willy@vpn.offrom.nl) Received: from willy by squid with local (Exim 4.72) (envelope-from ) id 1USP79-0006Ei-SW; Wed, 17 Apr 2013 11:57:19 +0200 Date: Wed, 17 Apr 2013 11:57:19 +0200 From: Willy Offermans To: Karl Denninger Subject: Re: IKEv2/IPSEC "Road Warrior" VPN Tunneling? Message-ID: <20130417095719.GH3480@vpn.offrom.nl> References: <516739C9.4080902@denninger.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <516739C9.4080902@denninger.net> User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 17 Apr 2013 09:57:21.0463 (UTC) FILETIME=[F422BC70:01CE3B51] X-RcptDomain: freebsd.org Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Willy@Offermans.Rompen.nl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 09:58:31 -0000 Hello Karl and FreeBSD friends, I recall having read about racoon and roadwarrior. Have a look to /usr/local/share/examples/ipsec-tools/, if you have installed it. I'm also planning to install this on my server. However I have only little time at the moment. I'm also looking for examples of configuration files to work with. Please keep us informed about your progress. On Thu, Apr 11, 2013 at 05:31:37PM -0500, Karl Denninger wrote: > Is there a "cookbook" for setting this up? There are examples for > setting up a tunnel between two fixed-address networks (e.g. a remote > LAN that needs to be "integrated" with a central LAN over IPSec but I > can't find anything addressing the other situation -- remote user(s) > where the connecting IPs are not known in advance, such as a person with > a laptop or smartphone in a random hotel. > > (And is there a better list for this in the freebsd-* paradigm for the > question?) > > -- > -- Karl Denninger > /The Market Ticker ®/ > Cuda Systems LLC > _______________________________________________ > 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" -- Met vriendelijke groeten, With kind regards, Mit freundlichen Gruessen, Willy ************************************* Dr. W.K. Offermans CAT Fellow CAT Catalytic Center Institut für Technische und Makromolekulare Chemie RWTH Aachen Worringerweg 1, Raum 38C-150 D-52074 Aachen, Germany Phone: +49 241 80 28592 Fax: +49 241 80 22593 Home: +31 45 544 49 44 Mobile: +31 681 15 87 68 e-mail: Willy@Offermans.Rompen.nl e-mail: Willy.Offermans@CatalyticCenter.RWTH-Aachen.de From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 11:47:38 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 01697DD7 for ; Wed, 17 Apr 2013 11:47:38 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) by mx1.freebsd.org (Postfix) with ESMTP id 837EB1D0 for ; Wed, 17 Apr 2013 11:47:37 +0000 (UTC) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.14.6/8.14.6) with ESMTP id r3HBlQev030013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Apr 2013 13:47:26 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.14.6/8.14.6/Submit) with ESMTP id r3HBlQnB030010; Wed, 17 Apr 2013 13:47:26 +0200 (CEST) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Wed, 17 Apr 2013 13:47:26 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: =?ISO-8859-1?Q?Olav_Gr=F8n=E5s_Gjerde?= Subject: Re: make buildkernel for GENERIC 9-STABLE just hangs, no error In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2055831798-1879589032-1366199246=:28371" X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on mail.fig.ol.no Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 11:47:38 -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. --2055831798-1879589032-1366199246=:28371 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 17 Apr 2013 09:10+0200, Olav Grønås Gjerde wrote: > I have a weird problem while building the GENERIC 9-STABLE kernel. After > around 5 minutes of compile time, the process just hangs on same place. No > error. I've tried compiling different commits from this week with the same > result. > > The part in the buildkernel process that hangs is this: > MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC > /usr/local/bin/svnversion > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 > --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror > vers.c > ctfconvert -L VERSION -g vers.o > linking kernel.debug > ctfmerge -L VERSION -g -o kernel.debug ............+ alot of *.o > > Any suggestions? No trouble compiling world, custom kernel, and GENERIC kernel, as of r249577, running on amd64 stable/9 r248696. Try resynchronizing your source tree, rm -Rf /usr/obj/*, and recompile world and kernel. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ --2055831798-1879589032-1366199246=:28371-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 15:47:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7EE88C3 for ; Wed, 17 Apr 2013 15:47:32 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) by mx1.freebsd.org (Postfix) with ESMTP id 0B5AF140 for ; Wed, 17 Apr 2013 15:47:31 +0000 (UTC) Received: from [98.139.212.145] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 15:41:23 -0000 Received: from [98.139.213.1] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 15:41:23 -0000 Received: from [127.0.0.1] by smtp101.mail.bf1.yahoo.com with NNFMP; 17 Apr 2013 15:41:23 -0000 X-Yahoo-Newman-Id: 305566.95581.bm@smtp101.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: rik1hBwVM1ngBm7eCZT6OxVypD4nTE1qbHz.owyg95QV_JI uIHYQh112FHpBHr8G7MpoioHXqZErvLABnOFbawrys.AZq50KV3QssyxQJik uH5yFoHjaVa_S1Vshkj_V.3FVlMKx_FLU.caczwhZpzsclLd_iK_RteKWzyX TPXQakDjJxGGIZ85qPISKiD2aLh9PhYOl67ycjfwaUadLh_PbXKj9qYno.sj Sh9lppl8QnDd1sxggJDosWkiWAqCqTdlh7x6CL2gyprs._2PlCG7s1kUJqgq BjoHAApD4jrdc5sO5TRnZj8rZ6tQPOvw9ADBqsIVKUI_UM63JoVpNg6YeFKD 9uZQa1KvKpcT4HARmo.6j0DnfLuImusCrahHqxWDZI.fMAtjA1qPAxJRxbUD 3GMlbse0WDtjXjJ7.IB1wGS5IcR.LgQ5phIk64t7B5cXDSBkkOLo2E9zsbPt RpS6PqUPC1m4kM8A8Wu20r3VvNuOCMItwJm5854X746ZInVBay7.gXcyP4V. O4I2Eibf9e9FzdILrHoID68LnepccpbJfFTaTWVxeGjEPLA-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with ) by smtp101.mail.bf1.yahoo.com with SMTP; 17 Apr 2013 15:41:23 +0000 UTC Message-ID: <516EC2A0.6090102@FreeBSD.org> Date: Wed, 17 Apr 2013 10:41:20 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130324 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jeremy Chadwick Subject: Re: make buildkernel for GENERIC 9-STABLE just hangs, no error (was svn commit: r249549 - in stable/9/sys: amd64/conf i386/conf) References: <201304161609.r3GG9SID009937@svn.freebsd.org> <20130417082956.GA98554@icarus.home.lan> In-Reply-To: <20130417082956.GA98554@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Olav_Gr=F8n=E5s_Gjerde?= , svn-src-all@freebsd.org, freebsd-stable@freebsd.org, svn-src-stable-9@freebsd.org, svn-src-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 15:47:32 -0000 On 04/17/13 03:29, Jeremy Chadwick wrote: > On Tue, Apr 16, 2013 at 04:09:28PM +0000, Brooks Davis wrote: >> Author: brooks >> Date: Tue Apr 16 16:09:27 2013 >> New Revision: 249549 >> URL: http://svnweb.freebsd.org/changeset/base/249549 >> >> Log: >> MFC (much delayed) 234504: >> >> Enable DTrace hooks in GENERIC. >> >> Modified: >> stable/9/sys/amd64/conf/GENERIC >> stable/9/sys/i386/conf/GENERIC >> Directory Properties: >> stable/9/sys/ (props changed) >> >> ... > And here come the complaints, which warrant responses from key folks who > are in the know: > > http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073132.html > It looks like 9 days ago there was a change (r249243) that fixed issues on the userland ctf utilities, so you have to update your userland too if it's not recent (make buildworld works fine). Hope that helps, Pedro. From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 15:51:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 35ACB29D for ; Wed, 17 Apr 2013 15:51:36 +0000 (UTC) (envelope-from andrei693@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id C8636199 for ; Wed, 17 Apr 2013 15:51:35 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id b57so682707eek.39 for ; Wed, 17 Apr 2013 08:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6wqvYPv7P9tR1xZnLjohHMGcqhzKe3UCalPRM71+tMU=; b=mb/DxTXuTE21yhXBiskA7HQDsSJrBsgTeotIyOgxmh/Gaxsjr7FjTdYqLfjQXAzCO6 DtN1x9kaUVkqh/Ez+slvjG135sCDWwz3i4CuwGWXGLag5Or/keA6m0ii2NFtiN30/WQx D/R/GiaZMxVmQb5BpNrEvyd7kU7MjviRw1FC5DDuvrEtNVBbMSi45YzoqeDdpEctFhVM Y+AWVsvqvZrDOAlgbJkUuP28KRPZ1xBBOwGhAIN9y0/TWgwB5J6lVU7XaWwEAmoSGdxQ ATpsVY08+3LSOPIOvgZBYOHUq7XKkkvSxmC7MSY0KrsxZFNgWlpsokQKz3ozk7zqOwLU x2eA== X-Received: by 10.15.34.199 with SMTP id e47mr19519829eev.35.1366213894522; Wed, 17 Apr 2013 08:51:34 -0700 (PDT) Received: from ab_t510i.perfectworld.eu ([87.213.55.5]) by mx.google.com with ESMTPS id j44sm9883380eeu.10.2013.04.17.08.51.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Apr 2013 08:51:33 -0700 (PDT) Message-ID: <516EC503.8020100@gmail.com> Date: Wed, 17 Apr 2013 17:51:31 +0200 From: Andrei Brezan User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130406 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: make buildkernel for GENERIC 9-STABLE just hangs, no error References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 15:51:36 -0000 On 04/17/13 09:10, Olav Grønås Gjerde wrote: > I have a weird problem while building the GENERIC 9-STABLE kernel. After > around 5 minutes of compile time, the process just hangs on same place. No > error. I've tried compiling different commits from this week with the same > result. > > The part in the buildkernel process that hangs is this: > MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC > /usr/local/bin/svnversion > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g -Wall > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include > opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 > --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror > vers.c > ctfconvert -L VERSION -g vers.o > linking kernel.debug > ctfmerge -L VERSION -g -o kernel.debug ............+ alot of *.o > > 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" Ctrl-T (SIGINFO) might give you a hint where it's hanging. -- Andrei From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 17:42:58 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5FECBAA5; Wed, 17 Apr 2013 17:42:58 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) by mx1.freebsd.org (Postfix) with ESMTP id 2336C8D0; Wed, 17 Apr 2013 17:42:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::dc79:2881:589:7d77] (unknown [IPv6:2001:7b8:3a7:0:dc79:2881:589:7d77]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 6743D5C45; Wed, 17 Apr 2013 19:42:57 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: make buildkernel for GENERIC 9-STABLE just hangs, no error (was svn commit: r249549 - in stable/9/sys: amd64/conf i386/conf) From: Dimitry Andric In-Reply-To: <516EC2A0.6090102@FreeBSD.org> Date: Wed, 17 Apr 2013 19:42:43 +0200 Content-Transfer-Encoding: 7bit Message-Id: <13CE3D12-75A7-46A9-920A-F12753E8CF7A@andric.com> References: <201304161609.r3GG9SID009937@svn.freebsd.org> <20130417082956.GA98554@icarus.home.lan> <516EC2A0.6090102@FreeBSD.org> To: Pedro Giffuni X-Mailer: Apple Mail (2.1503) Cc: Jeremy Chadwick , freebsd-stable@freebsd.org, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, svn-src-stable-9@freebsd.org, =?iso-8859-1?Q?Olav_Gr=F8n=E5s_Gjerde?= X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 17:42:58 -0000 On Apr 17, 2013, at 17:41, Pedro Giffuni wrote: > On 04/17/13 03:29, Jeremy Chadwick wrote: >> On Tue, Apr 16, 2013 at 04:09:28PM +0000, Brooks Davis wrote: >>> Author: brooks >>> Date: Tue Apr 16 16:09:27 2013 >>> New Revision: 249549 >>> URL: http://svnweb.freebsd.org/changeset/base/249549 >>> >>> Log: >>> MFC (much delayed) 234504: >>> Enable DTrace hooks in GENERIC. >>> >>> Modified: >>> stable/9/sys/amd64/conf/GENERIC >>> stable/9/sys/i386/conf/GENERIC >>> Directory Properties: >>> stable/9/sys/ (props changed) >>> >>> ... >> And here come the complaints, which warrant responses from key folks who >> are in the know: >> >> http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073132.html >> > > It looks like 9 days ago there was a change (r249243) that fixed > issues on the userland ctf utilities, so you have to update your > userland too if it's not recent (make buildworld works fine). That was only a fix for certain DWARF attributes emitted by clang and/or newer gcc's, which would cause ctfmerge to error out. If ctfmerge is hanging, that is almost certainly another problem. That is, if it is really hanging, isn't it just very slow, maybe? What happens if the original poster lets it run for e.g. an hour? From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 18:02:32 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DB4ED156; Wed, 17 Apr 2013 18:02:32 +0000 (UTC) (envelope-from olavgg@gmail.com) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by mx1.freebsd.org (Postfix) with ESMTP id A6BD19CB; Wed, 17 Apr 2013 18:02:31 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id o10so1887240lbi.20 for ; Wed, 17 Apr 2013 11:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zhD3PfcKZ0mzzjc0BBw078I4sJzw58AplrCbs2Ag6Rw=; b=K4kcmPxC1EiNNGidFVq2ObBsZiMmHRKTTmCPtOrOvc2s86Z61aK28REdze3apRXNRq bfAAvTFntbPZ+NhOigjn/SN5f7eU0T+aO8fGiM1yY6Xu6azRRfckt3jhwo3+548DVmuB H6kfB1Whzxj6fllHgj9ojI6ttwfiNRppHf+p8MMdMQIo50szSuOUXvs8SocHf2ADhNb3 C1pFFrCr8HMXlQqhw5PNNWJVpWTjq3Jy/UwKkGYzGGISe6XSjZKjgbxAkk4ftx4rPUPp J+0EKrlCUYA9/MJ2IWrZXP6GD/G4R6C0eYW/QyzFAvbPKwViCErNdRpubnbCang6nAOk n0TA== MIME-Version: 1.0 X-Received: by 10.152.120.40 with SMTP id kz8mr4049092lab.32.1366221744595; Wed, 17 Apr 2013 11:02:24 -0700 (PDT) Received: by 10.112.23.232 with HTTP; Wed, 17 Apr 2013 11:02:24 -0700 (PDT) In-Reply-To: <13CE3D12-75A7-46A9-920A-F12753E8CF7A@andric.com> References: <201304161609.r3GG9SID009937@svn.freebsd.org> <20130417082956.GA98554@icarus.home.lan> <516EC2A0.6090102@FreeBSD.org> <13CE3D12-75A7-46A9-920A-F12753E8CF7A@andric.com> Date: Wed, 17 Apr 2013 20:02:24 +0200 Message-ID: Subject: Re: make buildkernel for GENERIC 9-STABLE just hangs, no error (was svn commit: r249549 - in stable/9/sys: amd64/conf i386/conf) From: =?ISO-8859-1?Q?Olav_Gr=F8n=E5s_Gjerde?= To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jeremy Chadwick , FreeBSD Stable Mailing List , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, svn-src-stable-9@freebsd.org, Pedro Giffuni X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 18:02:32 -0000 I have to admit that I didn't wait for an hour, as buildkernel usually complete within 30 minutes on my system. I just tried to build the kernel on another very similar system, no problems there. I forgot to mention that I tried to upgrade from an 8-STABLE from last summer directly to the latest 9-STABLE. Most likely its just something very wrong with my setup and a complete reinstallation would probably be a good idea. Thanks for your help. On Wed, Apr 17, 2013 at 7:42 PM, Dimitry Andric wrote: > On Apr 17, 2013, at 17:41, Pedro Giffuni wrote: > > On 04/17/13 03:29, Jeremy Chadwick wrote: > >> On Tue, Apr 16, 2013 at 04:09:28PM +0000, Brooks Davis wrote: > >>> Author: brooks > >>> Date: Tue Apr 16 16:09:27 2013 > >>> New Revision: 249549 > >>> URL: http://svnweb.freebsd.org/changeset/base/249549 > >>> > >>> Log: > >>> MFC (much delayed) 234504: > >>> Enable DTrace hooks in GENERIC. > >>> > >>> Modified: > >>> stable/9/sys/amd64/conf/GENERIC > >>> stable/9/sys/i386/conf/GENERIC > >>> Directory Properties: > >>> stable/9/sys/ (props changed) > >>> > >>> ... > >> And here come the complaints, which warrant responses from key folks who > >> are in the know: > >> > >> > http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073132.html > >> > > > > It looks like 9 days ago there was a change (r249243) that fixed > > issues on the userland ctf utilities, so you have to update your > > userland too if it's not recent (make buildworld works fine). > > That was only a fix for certain DWARF attributes emitted by clang and/or > newer gcc's, which would cause ctfmerge to error out. > > If ctfmerge is hanging, that is almost certainly another problem. That > is, if it is really hanging, isn't it just very slow, maybe? What > happens if the original poster lets it run for e.g. an hour? > > From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 18:03:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 203FE30B for ; Wed, 17 Apr 2013 18:03:59 +0000 (UTC) (envelope-from damonray@mac.hush.com) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by mx1.freebsd.org (Postfix) with ESMTP id F40F6A04 for ; Wed, 17 Apr 2013 18:03:58 +0000 (UTC) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 5683E30551 for ; Wed, 17 Apr 2013 18:03:52 +0000 (UTC) Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) by smtp1.hushmail.com (Postfix) with ESMTP; Wed, 17 Apr 2013 18:03:51 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id D46BD6F443; Wed, 17 Apr 2013 18:03:51 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 17 Apr 2013 13:03:51 -0500 To: "Chris Rees" Subject: Re: Ghosted logins in w/who From: damonray@mac.hush.com In-Reply-To: References: <20130409015643.0817D10E2C8@smtp.hushmail.com> <20130409022837.GA95155@icarus.home.lan> <516428D2.9020701@wenks.ch> <20130410140953.31C3D10E2D3@smtp.hushmail.com> <20130410145934.72F4C10E2D3@smtp.hushmail.com> Message-Id: <20130417180351.D46BD6F443@smtp.hushmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Tom Evans , Fabian Wenk , FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 18:03:59 -0000 I removed /usr/include/utmp.h and restarted inetd/telnetd/sshd. Hopefully that does the trick.. On 4/11/2013 at 12:53 PM, "Chris Rees" wrote:On 10 April 2013 15:59, wrote: > Got it. I'll double check to make sure everything was recompiled > correctly. Thanks! > Damon While you're at it, I'll echo Ronald's concern-- make sure /usr/include/utmp.h does NOT exist for you. If it does, you must run make delete-old in /usr/src. Chris > On 4/10/2013 at 9:49 AM, "Tom Evans" wrote:On Wed, Apr 10, 2013 at > 3:09 PM, wrote: >> If I wipe the utmp file all the w/who content goes away, resets if > you >> will. But in a matter of moments the problem reappears.. is this >> something that needs to be submitted as a bug report do you think? >> Thanks! >> Damon >> > > Hi Damon > > Fabian was explaining to you that utmp was replaced by utmpx. > > All programs in base that wrote to utmp now write to utmpx instead. If > you still have programs not from base that write to utmp, you will get > incorrect/crazy values reported - you must rebuild all tools that > currently write to utmp so that they no longer do so. > > Cheers > > Tom > _______________________________________________ > 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 Wed Apr 17 18:16:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 52E1C592 for ; Wed, 17 Apr 2013 18:16:30 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 00748C3D for ; Wed, 17 Apr 2013 18:16:27 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r3HIGVWw030060; Wed, 17 Apr 2013 13:16:31 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r3HIGVnj030059; Wed, 17 Apr 2013 13:16:31 -0500 (CDT) (envelope-from brooks) Date: Wed, 17 Apr 2013 13:16:31 -0500 From: Brooks Davis To: Olav Gr?n?s Gjerde Subject: Re: make buildkernel for GENERIC 9-STABLE just hangs, no error Message-ID: <20130417181631.GA29166@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 18:16:30 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 17, 2013 at 09:10:59AM +0200, Olav Gr?n?s Gjerde wrote: > I have a weird problem while building the GENERIC 9-STABLE kernel. After > around 5 minutes of compile time, the process just hangs on same place. No > error. I've tried compiling different commits from this week with the same > result. >=20 > The part in the buildkernel process that hangs is this: > MAKE=3Dmake sh /usr/src/sys/conf/newvers.sh GENERIC > /usr/local/bin/svnversion > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -g -W= all > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -inclu= de > opt_global.h -fno-common -finline-limit=3D8000 --param inline-unit-growth= =3D100 > --param large-function-growth=3D1000 -fno-omit-frame-pointer -mcmodel=3D= kernel > -mno-red-zone -mno-mmx -mno-sse -msoft-float > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror > vers.c > ctfconvert -L VERSION -g vers.o > linking kernel.debug > ctfmerge -L VERSION -g -o kernel.debug ............+ alot of *.o >=20 > Any suggestions? In the DTrace commit message thread, you mentioned that you were upgrading from an old 8-STABLE to 9 when you got the hang. Could you quantify how old that 8-STABLE was/is? If it's pre-8.3 it would be really helpful if you could upgrade to 8.3 and test that. If that works then I think a note in UPDATING would be sufficient as our historical policy has been to support upgrading to release X.Y from (X-1).. If it turns out that we need to upgrade to 8.4 we may need to consider backing this out for a bit. -- Brooks --DocE+STaALJfprDB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRbub/XY6L6fI4GtQRAkXwAKDGO40AIu0tThIiuBASck7TS1NXbgCggGuZ me5yjm/EbecoTF+WouDt5OA= =dmkg -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 18:57:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A4F0386E; Wed, 17 Apr 2013 18:57:24 +0000 (UTC) (envelope-from olavgg@gmail.com) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 08D3FF14; Wed, 17 Apr 2013 18:57:23 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id y8so1950843lbh.35 for ; Wed, 17 Apr 2013 11:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mw2I0RxmTXMMUU+lznyV93bstIfe74XREJN2us3bv8A=; b=G+hVf5U4kpFzalv9dh/cTUFJemPjWsuIc5u1AybVGpR8k1GmHAolzvlmRuNriuTCDI VrVm07Vz+tYAhWck0Z+tjuLyeI7tnf6Vo//8zSgGd+zwYwNBOzqbX7qb1cm48dub0Hjm kDXWKqvU561laQyYaCxFSuZNJkucsqT8zkX2B/Exlr5uLHJwo+NnHFrbSQYRQ4gWFsdg 3Yfw5dwg4D77Zpia9OKgIkX0tLjhYumeryIQC3FG2r5Z57/ZiSnPUKK6ND6KsGMflzXO Bd0mY4ct1xmkncK1/HRweJkrCUOZ65tDWG0aOTBRVGH4biQi+UqAY30upSHAnuJ4oqcL +RaA== MIME-Version: 1.0 X-Received: by 10.112.157.165 with SMTP id wn5mr4195972lbb.29.1366225042783; Wed, 17 Apr 2013 11:57:22 -0700 (PDT) Received: by 10.112.23.232 with HTTP; Wed, 17 Apr 2013 11:57:22 -0700 (PDT) In-Reply-To: <20130417181631.GA29166@lor.one-eyed-alien.net> References: <20130417181631.GA29166@lor.one-eyed-alien.net> Date: Wed, 17 Apr 2013 20:57:22 +0200 Message-ID: Subject: Re: make buildkernel for GENERIC 9-STABLE just hangs, no error From: =?ISO-8859-1?Q?Olav_Gr=F8n=E5s_Gjerde?= To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 18:57:24 -0000 It was(sorry) from around 12th June 2012. But I have another system with 8.2-RELEASE that I can upgrade to a commit around 12th June 2012 and then try directly to 9-STABLE(or 8.3 first?) if that would be helpful? On Wed, Apr 17, 2013 at 8:16 PM, Brooks Davis wrote: > On Wed, Apr 17, 2013 at 09:10:59AM +0200, Olav Gr?n?s Gjerde wrote: > > I have a weird problem while building the GENERIC 9-STABLE kernel. After > > around 5 minutes of compile time, the process just hangs on same place. > No > > error. I've tried compiling different commits from this week with the > same > > result. > > > > The part in the buildkernel process that hangs is this: > > MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC > > /usr/local/bin/svnversion > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g > -Wall > > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > > -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > -include > > opt_global.h -fno-common -finline-limit=8000 --param > inline-unit-growth=100 > > --param large-function-growth=1000 -fno-omit-frame-pointer > -mcmodel=kernel > > -mno-red-zone -mno-mmx -mno-sse -msoft-float > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror > > vers.c > > ctfconvert -L VERSION -g vers.o > > linking kernel.debug > > ctfmerge -L VERSION -g -o kernel.debug ............+ alot of *.o > > > > Any suggestions? > > In the DTrace commit message thread, you mentioned that you were > upgrading from an old 8-STABLE to 9 when you got the hang. Could you > quantify how old that 8-STABLE was/is? If it's pre-8.3 it would be > really helpful if you could upgrade to 8.3 and test that. If that works > then I think a note in UPDATING would be sufficient as our historical > policy has been to support upgrading to release X.Y from > (X-1).. If it turns out that we need to upgrade to 8.4 we may > need to consider backing this out for a bit. > > -- Brooks > From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 19:06:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 67BE1CEF for ; Wed, 17 Apr 2013 19:06:04 +0000 (UTC) (envelope-from mazhe@alkumuna.eu) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [IPv6:2a01:e0c:1:1599::10]) by mx1.freebsd.org (Postfix) with ESMTP id D45F5F84 for ; Wed, 17 Apr 2013 19:06:02 +0000 (UTC) Received: from yggdrasil.alkumuna.eu (unknown [IPv6:2a01:e35:8a74:6e70:232:36ff:fe5c:3a87]) by smtp1-g21.free.fr (Postfix) with ESMTP id C01E2940214 for ; Wed, 17 Apr 2013 21:05:55 +0200 (CEST) Received: from justice.alkumuna.eu (ADijon-555-1-356-216.w90-40.abo.wanadoo.fr [90.40.77.216]) (authenticated bits=0) by yggdrasil.alkumuna.eu (8.14.5/8.14.5) with ESMTP id r3HJ5qaN070461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 Apr 2013 21:05:53 +0200 (CEST) (envelope-from mazhe@alkumuna.eu) Date: Wed, 17 Apr 2013 21:05:47 +0200 From: Matthieu Volat To: freebsd-stable@freebsd.org Subject: Re: IKEv2/IPSEC "Road Warrior" VPN Tunneling? Message-Id: <20130417210547.11b60339db0d7c67a52c1284@alkumuna.eu> In-Reply-To: <516739C9.4080902@denninger.net> References: <516739C9.4080902@denninger.net> X-Mailer: Sylpheed 3.3.0 (GTK+ 2.24.17; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Wed__17_Apr_2013_21_05_47_+0200_FNitxUXSrnDTICgn" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 19:06:04 -0000 This is a multi-part message in MIME format. --Multipart=_Wed__17_Apr_2013_21_05_47_+0200_FNitxUXSrnDTICgn Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 11 Apr 2013 17:31:37 -0500 Karl Denninger wrote: > Is there a "cookbook" for setting this up? There are examples for > setting up a tunnel between two fixed-address networks (e.g. a remote > LAN that needs to be "integrated" with a central LAN over IPSec but I > can't find anything addressing the other situation -- remote user(s) > where the connecting IPs are not known in advance, such as a person with > a laptop or smartphone in a random hotel. > > (And is there a better list for this in the freebsd-* paradigm for the > question?) > Sorry for answering this late, As mentionned in another answer, you can start with the roadwarrior server/client configuration in ipsec-tools examples. To work with FreeBSD, the phase1-up.sh and phase1-down.sh scripts must be customized. I've attached both scripts, tell me if it does not work, I'll upload them somewhere (maybe propose them for inclusion in the port tree?) -- Matthieu Volat --Multipart=_Wed__17_Apr_2013_21_05_47_+0200_FNitxUXSrnDTICgn-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 19:18:10 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 326462AF; Wed, 17 Apr 2013 19:18:10 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4C17F; Wed, 17 Apr 2013 19:18:08 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r3HJICQw030453; Wed, 17 Apr 2013 14:18:12 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r3HJICmf030452; Wed, 17 Apr 2013 14:18:12 -0500 (CDT) (envelope-from brooks) Date: Wed, 17 Apr 2013 14:18:12 -0500 From: Brooks Davis To: Olav Gr?n?s Gjerde Subject: Re: make buildkernel for GENERIC 9-STABLE just hangs, no error Message-ID: <20130417191812.GA30231@lor.one-eyed-alien.net> References: <20130417181631.GA29166@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Brooks Davis , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 19:18:10 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 17, 2013 at 08:57:22PM +0200, Olav Gr?n?s Gjerde wrote: > It was(sorry) from around 12th June 2012. > But I have another system with 8.2-RELEASE that I can upgrade to a commit > around 12th June 2012 and then try directly to 9-STABLE(or 8.3 first?) if > that would be helpful? It would be helpful if you could first try an upgrade from 8.2-RELEASE. It would also be good to know if 8.3-RELEASE builds. If we've got a transient issue in the 8.2-STABLE line, we can document it and move on. If it persisted through 8.3-STABLE that's more of an issue. Thanks, Brooks >=20 >=20 > On Wed, Apr 17, 2013 at 8:16 PM, Brooks Davis wrote: >=20 > > On Wed, Apr 17, 2013 at 09:10:59AM +0200, Olav Gr?n?s Gjerde wrote: > > > I have a weird problem while building the GENERIC 9-STABLE kernel. Af= ter > > > around 5 minutes of compile time, the process just hangs on same plac= e. > > No > > > error. I've tried compiling different commits from this week with the > > same > > > result. > > > > > > The part in the buildkernel process that hangs is this: > > > MAKE=3Dmake sh /usr/src/sys/conf/newvers.sh GENERIC > > > /usr/local/bin/svnversion > > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc99 -g > > -Wall > > > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > > > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > > > -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > > > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > > -include > > > opt_global.h -fno-common -finline-limit=3D8000 --param > > inline-unit-growth=3D100 > > > --param large-function-growth=3D1000 -fno-omit-frame-pointer > > -mcmodel=3Dkernel > > > -mno-red-zone -mno-mmx -mno-sse -msoft-float > > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Wer= ror > > > vers.c > > > ctfconvert -L VERSION -g vers.o > > > linking kernel.debug > > > ctfmerge -L VERSION -g -o kernel.debug ............+ alot of *.o > > > > > > Any suggestions? > > > > In the DTrace commit message thread, you mentioned that you were > > upgrading from an old 8-STABLE to 9 when you got the hang. Could you > > quantify how old that 8-STABLE was/is? If it's pre-8.3 it would be > > really helpful if you could upgrade to 8.3 and test that. If that works > > then I think a note in UPDATING would be sufficient as our historical > > policy has been to support upgrading to release X.Y from > > (X-1).. If it turns out that we need to upgrade to 8.4 we may > > need to consider backing this out for a bit. > > > > -- Brooks > > --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD4DBQFRbvV0XY6L6fI4GtQRAg3YAJYltZIMNUuNNtHQun31PqsBLeVGAKCvVwAO GZJbMSL5anFsRddk0TRrJQ== =mD4/ -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 19:28:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 07F4179B for ; Wed, 17 Apr 2013 19:28:02 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:64]) by mx1.freebsd.org (Postfix) with ESMTP id DDE6613B for ; Wed, 17 Apr 2013 19:28:01 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta07.emeryville.ca.mail.comcast.net with comcast id R2D91l0011u4NiLA77U1JS; Wed, 17 Apr 2013 19:28:01 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta21.emeryville.ca.mail.comcast.net with comcast id R7U01l00A1t3BNj8h7U0L9; Wed, 17 Apr 2013 19:28:00 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id EBC4C73A33; Wed, 17 Apr 2013 12:27:59 -0700 (PDT) Date: Wed, 17 Apr 2013 12:27:59 -0700 From: Jeremy Chadwick To: damonray@mac.hush.com Subject: Re: Ghosted logins in w/who Message-ID: <20130417192759.GA9331@icarus.home.lan> References: <20130409015643.0817D10E2C8@smtp.hushmail.com> <20130409022837.GA95155@icarus.home.lan> <516428D2.9020701@wenks.ch> <20130410140953.31C3D10E2D3@smtp.hushmail.com> <20130410145934.72F4C10E2D3@smtp.hushmail.com> <20130417180351.D46BD6F443@smtp.hushmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130417180351.D46BD6F443@smtp.hushmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366226881; bh=+lYa84FYyL+NC/EeeWJMvltQrtethZzyOQtEQK+LvTU=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=RT1CcgslMoegDegQ3eruR83tw0oF8V0a3N9hj2pni9+bF0+GvTdFArflF9GMegSDN r7VGjjSEfHIvNIEuZYJCjYCVJ4oSry96kkZ5e68ovLbGhtTCs2R1OBw3APhqx7PA/A /RclWWZ5yfZviiYOF/FWY6i1kJcr5zADff7xv/oZiKE0l4GvxE93dPTrVvpNKfjYNX 4IqhDckt6WMhHqFpQs8n0KldBE/01Q+dXcEtC1FlVR/Pzbe/9uEOc+hJDom8Lgs1+Z ibDwi0/FzoijIR3j8SU/p2jZO0dgLhi/IsQKqqA4UJYAzd/PyCUNEDjIX/fBqh8sZ5 Jro/P+wlRK9tQ== Cc: Chris Rees , Tom Evans , Fabian Wenk , FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 19:28:02 -0000 On Wed, Apr 17, 2013 at 01:03:51PM -0500, damonray@mac.hush.com wrote: > I removed /usr/include/utmp.h and restarted inetd/telnetd/sshd. > Hopefully that does the trick.. > > On 4/11/2013 at 12:53 PM, "Chris Rees" wrote:On 10 April 2013 15:59, > wrote: > > Got it. I'll double check to make sure everything was recompiled > > correctly. Thanks! > > Damon > > While you're at it, I'll echo Ronald's concern-- make sure > /usr/include/utmp.h does NOT exist for you. > > If it does, you must run make delete-old in /usr/src. > > {removing other stuff due to OP top-posting} Removing /usr/include/utmp.h and restarting daemons will do nothing. Include files (/usr/include) are used during compile-time, not run-time. You will need to rebuild world, and also rebuild all of your ports (do not just go installing packages, rebuild them from source). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 20:09:44 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2227A4EA; Wed, 17 Apr 2013 20:09:44 +0000 (UTC) (envelope-from olavgg@gmail.com) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 782192E4; Wed, 17 Apr 2013 20:09:43 +0000 (UTC) Received: by mail-la0-f49.google.com with SMTP id fs13so1112507lab.22 for ; Wed, 17 Apr 2013 13:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=khwsdwY2tg2Yn/11jj08IKFG+yLpUQmPPngv9p8FCwM=; b=ruieFYNX0zLwecufhpc/USDAirxo06EytMHi1Lg7jOG+pRS4ozI/0TLKi2pzLG3BQ8 4AboE3rkbZ4GOK8zAISCIaSRTOKcJ5G2ECBArl/XruronzLczW9mQFtmfgN0hmkm3Cac GGbjUjh7gCDfjOt7vW8wcEy41BypGuPIxXnIqay0j9r8rzd+b7XszHRFxuMqn3JdglvU bpR2YDpvMHdQZ3TBq5f3dLUkU7EL+au67BOHhyzjHHSdrk88OE2PTu35YrihC9L40FeW WCArXe4TBLGee6rzmYaBlem5FV+lqXPiJbotnqJR8LPny8xz6ILpKh/wwLxaNi24PEo1 FTVA== MIME-Version: 1.0 X-Received: by 10.152.120.40 with SMTP id kz8mr4262331lab.32.1366229382383; Wed, 17 Apr 2013 13:09:42 -0700 (PDT) Received: by 10.112.23.232 with HTTP; Wed, 17 Apr 2013 13:09:42 -0700 (PDT) In-Reply-To: <20130417191812.GA30231@lor.one-eyed-alien.net> References: <20130417181631.GA29166@lor.one-eyed-alien.net> <20130417191812.GA30231@lor.one-eyed-alien.net> Date: Wed, 17 Apr 2013 22:09:42 +0200 Message-ID: Subject: Re: make buildkernel for GENERIC 9-STABLE just hangs, no error From: =?ISO-8859-1?Q?Olav_Gr=F8n=E5s_Gjerde?= To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 20:09:44 -0000 I will try to upgrade from both of those releases and come back to you with my results. Kind regards, Olav On Wed, Apr 17, 2013 at 9:18 PM, Brooks Davis wrote: > On Wed, Apr 17, 2013 at 08:57:22PM +0200, Olav Gr?n?s Gjerde wrote: > > It was(sorry) from around 12th June 2012. > > But I have another system with 8.2-RELEASE that I can upgrade to a commit > > around 12th June 2012 and then try directly to 9-STABLE(or 8.3 first?) if > > that would be helpful? > > It would be helpful if you could first try an upgrade from 8.2-RELEASE. > It would also be good to know if 8.3-RELEASE builds. If we've got a > transient issue in the 8.2-STABLE line, we can document it and move on. > If it persisted through 8.3-STABLE that's more of an issue. > > Thanks, > Brooks > > > > > > > On Wed, Apr 17, 2013 at 8:16 PM, Brooks Davis > wrote: > > > > > On Wed, Apr 17, 2013 at 09:10:59AM +0200, Olav Gr?n?s Gjerde wrote: > > > > I have a weird problem while building the GENERIC 9-STABLE kernel. > After > > > > around 5 minutes of compile time, the process just hangs on same > place. > > > No > > > > error. I've tried compiling different commits from this week with the > > > same > > > > result. > > > > > > > > The part in the buildkernel process that hangs is this: > > > > MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC > > > > /usr/local/bin/svnversion > > > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g > > > -Wall > > > > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > > > > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > > > > -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > > > > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > > > -include > > > > opt_global.h -fno-common -finline-limit=8000 --param > > > inline-unit-growth=100 > > > > --param large-function-growth=1000 -fno-omit-frame-pointer > > > -mcmodel=kernel > > > > -mno-red-zone -mno-mmx -mno-sse -msoft-float > > > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > -Werror > > > > vers.c > > > > ctfconvert -L VERSION -g vers.o > > > > linking kernel.debug > > > > ctfmerge -L VERSION -g -o kernel.debug ............+ alot of *.o > > > > > > > > Any suggestions? > > > > > > In the DTrace commit message thread, you mentioned that you were > > > upgrading from an old 8-STABLE to 9 when you got the hang. Could you > > > quantify how old that 8-STABLE was/is? If it's pre-8.3 it would be > > > really helpful if you could upgrade to 8.3 and test that. If that > works > > > then I think a note in UPDATING would be sufficient as our historical > > > policy has been to support upgrading to release X.Y from > > > (X-1).. If it turns out that we need to upgrade to 8.4 we may > > > need to consider backing this out for a bit. > > > > > > -- Brooks > > > > From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 20:17:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 44778654 for ; Wed, 17 Apr 2013 20:17:41 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:211]) by mx1.freebsd.org (Postfix) with ESMTP id 25D7B331 for ; Wed, 17 Apr 2013 20:17:41 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta11.emeryville.ca.mail.comcast.net with comcast id R5S01l0050vp7WLAB8HhPe; Wed, 17 Apr 2013 20:17:41 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta05.emeryville.ca.mail.comcast.net with comcast id R8Hg1l0071t3BNj8R8Hg1n; Wed, 17 Apr 2013 20:17:40 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 0B8A373A33; Wed, 17 Apr 2013 13:17:40 -0700 (PDT) Date: Wed, 17 Apr 2013 13:17:40 -0700 From: Jeremy Chadwick To: Chris Forgeron Subject: Re: kern/165903: mbuf leak Message-ID: <20130417201739.GA11022@icarus.home.lan> References: <46D80686C389884BB0C047851038EC456D8BCEBC@AA-EX0.acsi.ca> <20130410235347.GA38492@icarus.home.lan> <20130411000818.GA38803@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0EF0@AA-EX0.acsi.ca> <20130413235031.GA8212@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0F52@AA-EX0.acsi.ca> <20130415104238.GP76816@FreeBSD.org> <46D80686C389884BB0C047851038EC456D8C3001@AA-EX0.acsi.ca> <20130416164658.GA81268@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C3FC5@AA-EX0.acsi.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D80686C389884BB0C047851038EC456D8C3FC5@AA-EX0.acsi.ca> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366229861; bh=RzgrazTzNiOhfyoKFWg969Wvn43vgUxNDq35wthH8IU=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=mYVKEYhtkCvBGbhfrmYGD0F+bKSJsEudNFYtcOgGDqRswYHcBH69zLdiUj++57JVF pG6X3+AG0+JWUlFzT7X6iei5sUauy6ZS9qdLI3l3Tkeea/oWrlzEyUCjk/lq6vWWUF thW/7TgLSPiu2zCSgdrxT7UWe+8S0D2V9zKTLg1SJkXQ2GqAB4/BxDPA4J9HY9dg82 COX2A4v1wdjupFscr2MoOcyUYEBNB+h1b8eGnA+VQwh0cgnMzJZAYNnUry+dYVbfoP FYjJjjphju5P+zFnef2Xqo0t5rl8cQ8ew5KWvuP4fFOy6I4bOwj14exHE2NHr7sWMT 6l1L7GtiWyyrQ== Cc: Gleb Smirnoff , "freebsd-stable@freebsd.org" , Jack Vogel , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 20:17:41 -0000 On Wed, Apr 17, 2013 at 05:38:12PM +0000, Chris Forgeron wrote: > Hello, > > I'm happy to report that the patch from Gleb has fixed the problem. > > My system had 256 mbuf clusters in use at boot, and after a day, still only has 256 mbuf clusters in use. > > From the patch, I see we are now dropping these packets (?) - Was the issue that the packets were being queued up for further work, but nothing was being done with them? Not exactly. Please open up the source file and follow along. At line 538, a call to mtod() is performed, which is what allocates the memory for the mbuf used for the ARP header. Now go to lines 543 and 549. These are error checks for certain kinds of ARP headers which are either malformed (line 543) or should not be honoured (line 549). When these error checks proved true, the code simply did "return" to get out of the function it was in (in_arpinput()), but never issued m_freem() to free the previously-allocated mbuf, hence leaking mbufs. The patch changes the "return" into "goto drop". The drop label is at line 873, which is where you'll find the m_freem(), followed immediately by the function returning. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 20:18:04 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9578D793; Wed, 17 Apr 2013 20:18:04 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 5CAC1344; Wed, 17 Apr 2013 20:18:03 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r3HKI8M3030841; Wed, 17 Apr 2013 15:18:08 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r3HKI8LM030840; Wed, 17 Apr 2013 15:18:08 -0500 (CDT) (envelope-from brooks) Date: Wed, 17 Apr 2013 15:18:08 -0500 From: Brooks Davis To: Olav Gr?n?s Gjerde Subject: Re: make buildkernel for GENERIC 9-STABLE just hangs, no error Message-ID: <20130417201808.GA30819@lor.one-eyed-alien.net> References: <20130417181631.GA29166@lor.one-eyed-alien.net> <20130417191812.GA30231@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Brooks Davis , FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 20:18:04 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thank you. You might try with this patch applied. It's not the right patch but only in that it's too agressive about building ctfconvert as a cross tool. Index: Makefile.inc1 =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 --- Makefile.inc1 (revision 249590) +++ Makefile.inc1 (working copy) @@ -1114,9 +1114,7 @@ usr.bin/clang/clang-tblgen .endif =20 -.if ${MK_CDDL} !=3D "no" && \ - ${BOOTSTRAPPING} < 800038 && \ - !(${BOOTSTRAPPING} >=3D 700112 && ${BOOTSTRAPPING} < 799999) +.if ${MK_CDDL} !=3D "no" _dtrace_tools=3D cddl/usr.bin/sgsmsg cddl/lib/libctf lib/libelf \ lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge .endif On Wed, Apr 17, 2013 at 10:09:42PM +0200, Olav Gr?n?s Gjerde wrote: > I will try to upgrade from both of those releases and come back to you wi= th > my results. >=20 > Kind regards, > Olav >=20 >=20 > On Wed, Apr 17, 2013 at 9:18 PM, Brooks Davis wrote: >=20 > > On Wed, Apr 17, 2013 at 08:57:22PM +0200, Olav Gr?n?s Gjerde wrote: > > > It was(sorry) from around 12th June 2012. > > > But I have another system with 8.2-RELEASE that I can upgrade to a co= mmit > > > around 12th June 2012 and then try directly to 9-STABLE(or 8.3 first?= ) if > > > that would be helpful? > > > > It would be helpful if you could first try an upgrade from 8.2-RELEASE. > > It would also be good to know if 8.3-RELEASE builds. If we've got a > > transient issue in the 8.2-STABLE line, we can document it and move on. > > If it persisted through 8.3-STABLE that's more of an issue. > > > > Thanks, > > Brooks > > > > > > > > > > > On Wed, Apr 17, 2013 at 8:16 PM, Brooks Davis > > wrote: > > > > > > > On Wed, Apr 17, 2013 at 09:10:59AM +0200, Olav Gr?n?s Gjerde wrote: > > > > > I have a weird problem while building the GENERIC 9-STABLE kernel. > > After > > > > > around 5 minutes of compile time, the process just hangs on same > > place. > > > > No > > > > > error. I've tried compiling different commits from this week with= the > > > > same > > > > > result. > > > > > > > > > > The part in the buildkernel process that hangs is this: > > > > > MAKE=3Dmake sh /usr/src/sys/conf/newvers.sh GENERIC > > > > > /usr/local/bin/svnversion > > > > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=3Dc= 99 -g > > > > -Wall > > > > > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > > > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > > > > > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > > > > > -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > > > > > -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > > > > -include > > > > > opt_global.h -fno-common -finline-limit=3D8000 --param > > > > inline-unit-growth=3D100 > > > > > --param large-function-growth=3D1000 -fno-omit-frame-pointer > > > > -mcmodel=3Dkernel > > > > > -mno-red-zone -mno-mmx -mno-sse -msoft-float > > > > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > > -Werror > > > > > vers.c > > > > > ctfconvert -L VERSION -g vers.o > > > > > linking kernel.debug > > > > > ctfmerge -L VERSION -g -o kernel.debug ............+ alot of *.o > > > > > > > > > > Any suggestions? > > > > > > > > In the DTrace commit message thread, you mentioned that you were > > > > upgrading from an old 8-STABLE to 9 when you got the hang. Could y= ou > > > > quantify how old that 8-STABLE was/is? If it's pre-8.3 it would be > > > > really helpful if you could upgrade to 8.3 and test that. If that > > works > > > > then I think a note in UPDATING would be sufficient as our historic= al > > > > policy has been to support upgrading to release X.Y from > > > > (X-1).. If it turns out that we need to upgrade to 8.4 we = may > > > > need to consider backing this out for a bit. > > > > > > > > -- Brooks > > > > > > --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRbwN/XY6L6fI4GtQRAn5bAJ4rASddgUfoSVg141zM4jjriUHbRQCfW+kp Gsr/mjILa4IVlQU+HgysprA= =MR/E -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF-- From owner-freebsd-stable@FreeBSD.ORG Wed Apr 17 21:40:57 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 03D83695 for ; Wed, 17 Apr 2013 21:40:57 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by mx1.freebsd.org (Postfix) with ESMTP id D949D90B for ; Wed, 17 Apr 2013 21:40:56 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta02.emeryville.ca.mail.comcast.net with comcast id R7ks1l0020lTkoCA29gwPl; Wed, 17 Apr 2013 21:40:56 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta04.emeryville.ca.mail.comcast.net with comcast id R9gv1l00j1t3BNj8Q9gwoK; Wed, 17 Apr 2013 21:40:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id A018B73A39; Wed, 17 Apr 2013 14:40:55 -0700 (PDT) Date: Wed, 17 Apr 2013 14:40:55 -0700 From: Jeremy Chadwick To: Chris Forgeron Subject: Re: kern/165903: mbuf leak Message-ID: <20130417214055.GA12524@icarus.home.lan> References: <20130410235347.GA38492@icarus.home.lan> <20130411000818.GA38803@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0EF0@AA-EX0.acsi.ca> <20130413235031.GA8212@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C0F52@AA-EX0.acsi.ca> <20130415104238.GP76816@FreeBSD.org> <46D80686C389884BB0C047851038EC456D8C3001@AA-EX0.acsi.ca> <20130416164658.GA81268@icarus.home.lan> <46D80686C389884BB0C047851038EC456D8C3FC5@AA-EX0.acsi.ca> <20130417201739.GA11022@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130417201739.GA11022@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366234856; bh=eXnKSTZYX+GyHDG8s8IpbH0O5OqDrrOiHXkDOs5QpiA=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=MSv0wf9I5pFFZGJXgdhyEJhTXSlXBSiddu3kR6RFnMOG/A735xMOocR0D5qTjyHcX 0WTs5izGepaBioXubYqGWAODoACd8NgqCcIwesJihFownYDTEjzvU+Fg/0GhgZMcgH S5jpCdsYyrJG52p7i8lBT/YZd40bhbvq+HpjD2+7AJ5uSUHY+wNCTL+K1W6jK6PJOX 9xHC33OzrfDe9q3kc45uWihw9y9jFcgLPVCE5grPDUFvUTPGzTC7KgF9Fxoek+APvw jzSQvVMuTFHkKBfPCYujomAgYuUR5gdiNAjjmjYCSKCOvdAQqVzDMnPmYcaWnm3r7c hSigFSmoB1PGg== Cc: Gleb Smirnoff , "freebsd-stable@freebsd.org" , Jack Vogel , John Baldwin X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 17 Apr 2013 21:40:57 -0000 On Wed, Apr 17, 2013 at 01:17:40PM -0700, Jeremy Chadwick wrote: > On Wed, Apr 17, 2013 at 05:38:12PM +0000, Chris Forgeron wrote: > > Hello, > > > > I'm happy to report that the patch from Gleb has fixed the problem. > > > > My system had 256 mbuf clusters in use at boot, and after a day, still only has 256 mbuf clusters in use. > > > > From the patch, I see we are now dropping these packets (?) - Was the issue that the packets were being queued up for further work, but nothing was being done with them? > > ... > > At line 538, a call to mtod() is performed, which is what allocates the > memory for the mbuf used for the ARP header. > > ... John Baldwin let me know that this isn't quite correct -- mtod() is actually just a macro which would turn this: 538 ah = mtod(m, struct arphdr *); Into this: 538 ah = (struct arphdr *)(m)->m_data; The actual mbuf allocation is done within the device driver (em(4) in this case), while the freeing of the mbuf is done within the network layer (if_ether.c in this case). I lazily chose to man mtod and found it was filed under MBUF(9) and made the assumption it did the allocation. The actual allocation itself looks to be MGET(9) and other friends. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Apr 18 02:46:12 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B781F1CC for ; Thu, 18 Apr 2013 02:46:12 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 172C9349 for ; Thu, 18 Apr 2013 02:46:11 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.55]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r3I2H224099027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Apr 2013 11:47:08 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: multipart/signed; boundary="Apple-Mail=_6454BA15-2D03-439B-9796-F388BEC3EFE1"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 18 Apr 2013 11:47:01 +0930 Subject: Linux a.out binaries To: "freebsd-stable@freebsd.org stable" Message-Id: <07612CF9-2DE4-4980-BF03-DF56FBC79BE1@gsoft.com.au> Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Spam-Score: -3.052 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 02:46:12 -0000 --Apple-Mail=_6454BA15-2D03-439B-9796-F388BEC3EFE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have some very old Linux a.out binaries that I have run on a FreeBSD 4 = box. I recently tried them on a 9.1 system but I get an exec format = error when trying to run them. [obtuse 11:45] ~ >/usr/local/rsi/idl_4/bin/bin.linux/idl zsh: exec format error: /usr/local/rsi/idl_4/bin/bin.linux/idl [obtuse 11:45] ~ >file /usr/local/rsi/idl_4/bin/bin.linux/idl /usr/local/rsi/idl_4/bin/bin.linux/idl: Linux/i386 demand-paged = executable (QMAGIC), stripped I presume it has rotted and was removed, does anyone know when? THanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_6454BA15-2D03-439B-9796-F388BEC3EFE1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINWTCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHHTCCBgWg AwIBAgIDBHnoMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwNzA1MDIyMTI5WhcNMTMwNzA2MTU1NDQ5WjBhMRkwFwYDVQQNExBtdW11Rmk0OXh3cGRrUWh3 MR4wHAYDVQQDDBVkb2Nvbm5vckBnc29mdC5jb20uYXUxJDAiBgkqhkiG9w0BCQEWFWRvY29ubm9y QGdzb2Z0LmNvbS5hdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANLhGSNBVp7lteWC Kgmh5gw0Z7wnwJqESu3IYZ885kbCP4lMpZwQv9GOVDCqPuuVUzY+K3kwaf91g/kz2oRcU+bw1bpY iOvwMzwPD1V3hZ7r8NNToUdT/VKQRTVcAP9/Cr4NYekyVTehQZ7GGF7cyqXKvMpOHriW7KzNq7R0 p6eJ2uadOL5VPY+uTsVjmizQlFMl+My34vgkQ1Wo765MRjzHzwvpmWiqHrgjpvJL33bmgHB2ZtbG KcQ55Ze2T2ysAsa+SoDBwYC+8uBhuFtdSl0/Nm2q1eZBFNamCmGzpEjVDQPlAxhOwjde15WMsJPB mTibsOer4LN8cN0XfeBqKrMCAwEAAaOCA7AwggOsMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUGrouPvtucJ95hJDEw/MyVdgH 2JowHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIAYDVR0RBBkwF4EVZG9jb25ub3JA Z3NvZnQuY29tLmF1MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYB BQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcW IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRl IHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1l bnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRl bmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlv bnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAD AgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJM ZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQv MC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t LzANBgkqhkiG9w0BAQUFAAOCAQEAgT50PcSRWSCNYUsBvFh33Iku7Us501FqkCqN2YcnwULjz1z1 9f9BXQd6EpyUpAGjpoclBh8NCwaezXIXbp6qMktLBvoRNiH+dd1HtefqPQ7b4rt5LrS3vrptaVWa Qiqmxg/sFdQ20uNGpXYlUDoIHRoD4DT7oa9n45eLjE3S8Jw2RZO2y0Ve3HZvwpQOkTbYsESBHZmh szYsOHd5kZH1S573LlMffbH1IztIBtx8ozlyT4io3T5e4GJBro1jSepC3oIaqpwnDOzQqdnoPNHd QUxlI0YlhAaYUC9bNNfHJtQo7jyYhQcTK/MGYeJ6NJa5A+6BQWrZhHl7v/OOlaxwyjGCA28wggNr AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwR56DAJBgUrDgMCGgUAoIIBrzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA0MTgwMjE3MDJaMCMG CSqGSIb3DQEJBDEWBBT/mDWr96PxwGkh8xKhzlXcCI3D4DCBpQYJKwYBBAGCNxAEMYGXMIGUMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwR56DCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBHnoMA0GCSqGSIb3DQEBAQUABIIBAM9oESPu2QHh vfEkwjgWPXItcG966L05ZNMN0I1DWQt4V/JEeEAH9YNjhNB35DgPzSe0qtHwEqTcnK1yq+lkuXFn wkMmYxkB+Mxm+x9QUekD+3ieSUGtkDzoaZfF2TFZrH+JDgKSik+Ulsi9TaRAFkRgvQzWpOCYNPdg Lsvz4xlLVN2S+FbtLCr7VKNc4vc2VTmVIfKOEYQgYLVcYQDVymshgO+D2cQ0nEI+A6zWqO5WY10p Lz8w7Mt0hNtOKjIKVq5ZWcdF6trgh+SnHyuq6P0LN8ajExjGlpaVgAnk4cN0cyiIueLUkaJLjy9h vTZxAsBqO63hIIr1i9YU66eYM7UAAAAAAAA= --Apple-Mail=_6454BA15-2D03-439B-9796-F388BEC3EFE1-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 18 03:39:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0379F839 for ; Thu, 18 Apr 2013 03:39:39 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:44:76:96:27:243]) by mx1.freebsd.org (Postfix) with ESMTP id DCB73815 for ; Thu, 18 Apr 2013 03:39:38 +0000 (UTC) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta13.emeryville.ca.mail.comcast.net with comcast id RFKJ1l0060cQ2SLADFfeLx; Thu, 18 Apr 2013 03:39:38 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta10.emeryville.ca.mail.comcast.net with comcast id RFfd1l0071t3BNj8WFfdx0; Thu, 18 Apr 2013 03:39:37 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 1B4C273A33; Wed, 17 Apr 2013 20:39:37 -0700 (PDT) Date: Wed, 17 Apr 2013 20:39:37 -0700 From: Jeremy Chadwick To: Daniel O'Connor Subject: Re: Linux a.out binaries Message-ID: <20130418033937.GA20092@icarus.home.lan> References: <07612CF9-2DE4-4980-BF03-DF56FBC79BE1@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07612CF9-2DE4-4980-BF03-DF56FBC79BE1@gsoft.com.au> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366256378; bh=JcEEwJmsshhG2fQgRB4va5hKa57VVqo13V4kHywNJ1U=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=Xq1xe/lSow5mi67JhIWa9GnnBm4j7Io9vl4z9Z9bM5QJWMK1H3Vk4enFD7TfOOERl hY7VvHjOrpeySLKQGbrhKKFLFa++419TFZY6PczVQCACkjuyS65tJXH0hk2ZKWhNeY QCRMfRE7KorGtGMLh1T75BsCaInU1oLVE0wFdGdqn8hTSpjIjP2pGcDjRMqkTKQgAt mAG+eo9ZQ2F9KrEO2FTbqprDAANKOse+cz3FoK4Im5DHxPja+3OpAc2GAxvhcYrHEM gnej/DNbhbJGOozaMzJKJ0V4dgyZD9JeBfARIZvdGiCCksHBpzzqrxDt1+sXh2NxDY Kyw3unwo2n2pg== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 03:39:39 -0000 On Thu, Apr 18, 2013 at 11:47:01AM +0930, Daniel O'Connor wrote: > I have some very old Linux a.out binaries that I have run on a FreeBSD 4 box. I recently tried them on a 9.1 system but I get an exec format error when trying to run them. > > [obtuse 11:45] ~ >/usr/local/rsi/idl_4/bin/bin.linux/idl > zsh: exec format error: /usr/local/rsi/idl_4/bin/bin.linux/idl > [obtuse 11:45] ~ >file /usr/local/rsi/idl_4/bin/bin.linux/idl > /usr/local/rsi/idl_4/bin/bin.linux/idl: Linux/i386 demand-paged executable (QMAGIC), stripped > > I presume it has rotted and was removed, does anyone know when? Good lord, the number of possibilities here are almost endless. You can't be serious... My first inclination is to ask you if that FreeBSD system is amd64 or i386. Your Linux a.out binaries are i386. If the FreeBSD system is amd64: I don't think this is going to work; I see nothing in /sys/amd64/conf/* that indicates a.out is supported. Sure, 32-bit binaries might be (with COMPAT_FREEBSD32), but that's architecture, not format. If the FreeBSD system is i386: /sys/i386/conf/NOTES mentions a kernel option called COMPAT_AOUT, which **is not** enabled in GENERIC. And of course don't forget COMPAT_LINUX. Also worth noting is the BUGS section of a.out(5). -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Apr 18 03:54:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CB799B32 for ; Thu, 18 Apr 2013 03:54:16 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 147118B3 for ; Thu, 18 Apr 2013 03:54:15 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.55]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id r3I3ruB8009826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Apr 2013 13:24:02 +0930 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: Linux a.out binaries Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: multipart/signed; boundary="Apple-Mail=_53E4FB95-8033-48BE-8197-5982C812EB18"; protocol="application/pkcs7-signature"; micalg=sha1 From: "Daniel O'Connor" In-Reply-To: <20130418033937.GA20092@icarus.home.lan> Date: Thu, 18 Apr 2013 13:23:56 +0930 Message-Id: <2F556011-3252-49E2-9B98-7478B89F0955@gsoft.com.au> References: <07612CF9-2DE4-4980-BF03-DF56FBC79BE1@gsoft.com.au> <20130418033937.GA20092@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1503) X-Spam-Score: -3.052 () ALL_TRUSTED,BAYES_00,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 03:54:17 -0000 --Apple-Mail=_53E4FB95-8033-48BE-8197-5982C812EB18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 18/04/2013, at 13:09, Jeremy Chadwick wrote: >> I presume it has rotted and was removed, does anyone know when? >=20 > Good lord, the number of possibilities here are almost endless. You > can't be serious... Perfectly! I don't think this is any worse than trying to run FreeBSD 1.0 binaries = on -current :) > My first inclination is to ask you if that FreeBSD system is amd64 or > i386. Your Linux a.out binaries are i386. >=20 > If the FreeBSD system is amd64: I don't think this is going to work; > I see nothing in /sys/amd64/conf/* that indicates a.out is supported. > Sure, 32-bit binaries might be (with COMPAT_FREEBSD32), but that's > architecture, not format. Yeah, I wondered if that was the case. It is an amd64 system. > If the FreeBSD system is i386: /sys/i386/conf/NOTES mentions a kernel > option called COMPAT_AOUT, which **is not** enabled in GENERIC. And = of > course don't forget COMPAT_LINUX. >=20 > Also worth noting is the BUGS section of a.out(5). It's looking like running it inside a FreeBSD 4 VM is the easier = solution :) Thankfully it doesn't get much use these days now the person who needs = it can run GDL. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_53E4FB95-8033-48BE-8197-5982C812EB18 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINWTCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHHTCCBgWg AwIBAgIDBHnoMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwNzA1MDIyMTI5WhcNMTMwNzA2MTU1NDQ5WjBhMRkwFwYDVQQNExBtdW11Rmk0OXh3cGRrUWh3 MR4wHAYDVQQDDBVkb2Nvbm5vckBnc29mdC5jb20uYXUxJDAiBgkqhkiG9w0BCQEWFWRvY29ubm9y QGdzb2Z0LmNvbS5hdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANLhGSNBVp7lteWC Kgmh5gw0Z7wnwJqESu3IYZ885kbCP4lMpZwQv9GOVDCqPuuVUzY+K3kwaf91g/kz2oRcU+bw1bpY iOvwMzwPD1V3hZ7r8NNToUdT/VKQRTVcAP9/Cr4NYekyVTehQZ7GGF7cyqXKvMpOHriW7KzNq7R0 p6eJ2uadOL5VPY+uTsVjmizQlFMl+My34vgkQ1Wo765MRjzHzwvpmWiqHrgjpvJL33bmgHB2ZtbG KcQ55Ze2T2ysAsa+SoDBwYC+8uBhuFtdSl0/Nm2q1eZBFNamCmGzpEjVDQPlAxhOwjde15WMsJPB mTibsOer4LN8cN0XfeBqKrMCAwEAAaOCA7AwggOsMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUGrouPvtucJ95hJDEw/MyVdgH 2JowHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIAYDVR0RBBkwF4EVZG9jb25ub3JA Z3NvZnQuY29tLmF1MIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYB BQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcW IFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRl IHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1l bnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRl bmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlv bnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAD AgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJM ZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQv MC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mx L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3Vi LmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29t LzANBgkqhkiG9w0BAQUFAAOCAQEAgT50PcSRWSCNYUsBvFh33Iku7Us501FqkCqN2YcnwULjz1z1 9f9BXQd6EpyUpAGjpoclBh8NCwaezXIXbp6qMktLBvoRNiH+dd1HtefqPQ7b4rt5LrS3vrptaVWa Qiqmxg/sFdQ20uNGpXYlUDoIHRoD4DT7oa9n45eLjE3S8Jw2RZO2y0Ve3HZvwpQOkTbYsESBHZmh szYsOHd5kZH1S573LlMffbH1IztIBtx8ozlyT4io3T5e4GJBro1jSepC3oIaqpwnDOzQqdnoPNHd QUxlI0YlhAaYUC9bNNfHJtQo7jyYhQcTK/MGYeJ6NJa5A+6BQWrZhHl7v/OOlaxwyjGCA28wggNr AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwR56DAJBgUrDgMCGgUAoIIBrzAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA0MTgwMzUzNTdaMCMG CSqGSIb3DQEJBDEWBBRl4EzmqvQ2lEn8LsZjqz6CVTcnmDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwR56DCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYwx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBHnoMA0GCSqGSIb3DQEBAQUABIIBAIl+TqQrXHFO fyUr/deUN9HDStOQN8sm7Eo+OsVRrq8p1iTLdUQO2ZmvZ47XmRad4B+oHZSG01fpjMVvl9edKejU 1T0cm9G+yYstYYM+7axMytHGhtDgl8i6p81+FTHLvcgoHRgYugVl4vaVO8Og23wYsV+gMwXfb/4F AMW1MhDJGEXprdwnxrXFQJuOZYWJWHrhOSgRDL+CkXfUFcKhALRrFqrNHhpywkQDlRE2KPGG3DXj h5yOjE31LF8rSi0YxTEirxJFED65CCbURUOzSCj8T4c/h3ZyLqqCwaoQrALdea5WIXqQNyTqMJ1R 6dFEf/PIlPU/FFJSvInOetePhQsAAAAAAAA= --Apple-Mail=_53E4FB95-8033-48BE-8197-5982C812EB18-- From owner-freebsd-stable@FreeBSD.ORG Thu Apr 18 06:24:52 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 84A7492F for ; Thu, 18 Apr 2013 06:24:52 +0000 (UTC) (envelope-from healthclubprosperitytips61@yahoo.com) Received: from nm37-vm6.bullet.mail.ne1.yahoo.com (nm37-vm6.bullet.mail.ne1.yahoo.com [98.138.229.134]) by mx1.freebsd.org (Postfix) with ESMTP id 575F0DBE for ; Thu, 18 Apr 2013 06:24:52 +0000 (UTC) Received: from [98.138.90.56] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 18 Apr 2013 06:23:03 -0000 Received: from [98.138.226.57] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 18 Apr 2013 06:23:03 -0000 Received: from [127.0.0.1] by smtp208.mail.ne1.yahoo.com with NNFMP; 18 Apr 2013 06:23:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366266183; bh=qeb+34G13cCfNmhMEmkA4i1EBWd71thv4Vv67XGj4/E=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Return-Path:MIME-Version:From:Reply-To:To:Subject:Content-Type:Content-Transfer-Encoding:X-Mailer:Date:Message-ID; b=Sn5TR4YEcz1yp3mBg36a9ha/aixx7RfCLTCP5vv9QbiXiJ1qelU5YumUXfLf/Z6H5rB8vFo9Vzj2IvEPfxaHyrOeV+FhfJN3SoWCNp+lqdKDSEFQBDu9j2nBwzh8XghTWJT8kowSrrj++zs0vJ9KGIcx2Z6KYpUNPwyKhx+wslc= X-Yahoo-Newman-Id: 125903.36012.bm@smtp208.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aJf9uT0VM1lmpVY9XQ3DQOb7OOn3GkWcsi03xTCfn4mVrWT bD4Yx2XHoKerdzBz9j1nXAaBzvj8dHcN1jmADDju.R5x.LZJ4V26Xwt1Kwb7 1dA67S9hXGrQ0bOPHRqjvny3SGrfkWeqhBaEUhQYj4bZTSabz5u6nphuPXY1 TpdktPxN6yvbvLvx7HRMrYUQUSBwk70sRGDpjtUrkT6NOeMN5AFybHOhAI3Q VT62yBjfS7kYI_gYw.hQ6D4oe5FZplLvlCA29_xdPEsOL6NbSGMHHCySyEwP sdu44a5pWxU79J_hI8.k8e2bEg068n9PM9jv0vhCBO97P8TrvyGcXd9ABzXR ZjDGCV_Caa.jQz444lqQt6EpIqT1ai2s.Uu9UaE11CspT4Uyz.3pEtgebnWW CK160t8htfFP4w0UBoql_gasFD8EkWdEumCvhG9bJ.PXoc4Tfa5sJ9awhQWA YOwvqO1CjbfIq_nRqasLzYMfuLnnPWYGUtHkhzXXC2Ge5g6CaFN7FnxnvlZ8 EkqedZrVzyEgCZSI- X-Yahoo-SMTP: WKO.P2qswBAQigtSgMiUBNMPY4s_Yv9IH1A8yneiyIQ_5gJCzK0. X-Rocket-Received: from 50.117.80.165 (healthclubprosperitytips61@74.115.0.205 with login) by smtp208.mail.ne1.yahoo.com with SMTP; 17 Apr 2013 23:23:03 -0700 PDT From: "healthclubprosperitytips61" To: freebsd-stable@freebsd.org Subject: Health Club Business Tips X-Mailer: Smart_Send_2_0_138 Date: Thu, 18 Apr 2013 14:23:00 +0800 Message-ID: <172231341344165815103@CHERRY-PC> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: healthclubprosperitytips61@yahoo.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 06:24:52 -0000 [1]www.healthclubrev.com HEALTH CLUB MARKETING TIP OF THE MONTH: ATTENTION, INTEREST, DESIRE AND ACTION (AIDA) ATTENTION: This is best accomplished with an offer the consumer has never seen before. INTEREST: Focus on the emotional hook in your health club marketing campaign that will create interest and make the consumer want to buy your health club products and your health club services. DESIRE: Consumers buy health club products and health club services for emotional reasons not logical reasons. ACTION: Make sure your health club marketing has a definitive call to action as to why the consumer must take action today. Click on the link below to learn about MMC®'s CASH promotion and how we have raised $250,000 in immediate cash and added more than 500 new members, in just 45 days for numerous Health Clubs. [2]http://www.healthclubrev.com/CASH_PROMOTION.html MMC®'s site has free videos on how to increase revenue (immediate cash, monthly receivables and member retention), capture the difficult to reach market, engage the de-conditioned and the health and fitness conscience prospect, increase revenue in your profit centers e.g. pro-shop, food and beverage, guest fees, personal training and so much more, absolutely free. "I would like to express my appreciation to MMC and all the staff. As a Health Club owner for twenty years, and operating one of the largest Gold's Gym, I did have some initial reservations regarding your Company and the amount of revenue that you indicated were possible with your promotion. I am happy to say that the promotion was a great success and also that the revenues you predicted were very accurate. We were able to add an additional 1200 plus members in a short time. Impact upon the current members was very minimal." Gold's Gym and Racquet club Randy Musloki Owner "The MMC program not only assisted with putting cash in hand but also afforded our staff new insight into sales and membership techniques that will be useful well past the end of the program." Yorktown Racquet, Fitness and Sport Complex Joseph D. Glitz Owner/President Dear Chuck, We have seven hundred (700) new members, money in the bank and a staff that can't wait until the next promotion. I just wanted to take a moment to personally thank you and let you know just how satisfied we were with MMC and you. North Shore Athletic Club JoAnn C. Ribaudo Owner Dear Chuck, I wanted to write you and let you know how satisfied we were with you and Mulligan Marketing. What great couple of months it has been at the club. Now only did your company deliver a "turn-key" promotion, the entire campaign was run with little or no effort on my part, which allowed me to concentrate on my day to day business of running the club. The promotion raised almost $400,000, nearly twice what we projected. In addition, not only did your on-site training have an immediate impact on my sales staff, the techniques you taught them and the materials that you distributed will benefit them for the long term. Your professionalism and enthusiasm throughout the campaign has truly made it a pleasurable experience. It is refreshing to work with someone as honest as you who truly deliver results. The Auburn Club Jennifer Nabbo Wishing you good health and prosperity, Chuck Thompson Founder/President MMC® 904-307-6736 Cell 904-448-5727 Office 877-620-8135 Toll Free If you wish not to receive these free tips on growing your health club and your health and fitness career, simply click on the unsubscribe button below to be taken off our list. [3][Unsubscribe] Notice: It is not our intention to "spam" any person or company. We have received your email through a legitimate avenue. We have been in business for more than 20 plus years and have collected opt-in emails from all of our internal resources i.e. employees, sales consultants, co-op marketing partners, etc. We have never done e-marketing over the past twenty plus years because we never offered anything of value on our site (with the exception of product information), until now. We are simply making an attempt to connect and re-connect with our clients, prospects and associates of past and present and make them aware of our new educational site and domain. We do realize some of you may have forgotten us or don't remember (or know) how we received your email (as we can't remember every email either) and for that we apologize in advance. Please be patient with us. If you do not wish to receive further communication from us please reply with the word "REMOVE" or "UNSUBSCRIBE" in the subject field and we will make every effort to eliminate you from all of our data bases immediately. Also, please make sure you reply from the original e-mail address this message was addressed to, or, include that address in the removal request. Please excuse any inconvenience. References 1. http://www.healthclubrev.com/ 2. http://www.healthclubrev.com/CASH_PROMOTION.html 3. mailto:?subject=Unsubscribe From owner-freebsd-stable@FreeBSD.ORG Thu Apr 18 07:58:55 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DF143DD; Thu, 18 Apr 2013 07:58:55 +0000 (UTC) (envelope-from olavgg@gmail.com) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by mx1.freebsd.org (Postfix) with ESMTP id 424B9198; Thu, 18 Apr 2013 07:58:54 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id q13so2418697lbi.37 for ; Thu, 18 Apr 2013 00:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n8s74KOEsTaleKcHO8GoshGd+O4dN3zmwv86RjUIEKQ=; b=bbC4QaYhalDglTeDnpK8kDP8Qx6Q1LX9FRbviPqLlo8EEM8IPQ0hYHc2fD8Jt+9Tnb avgJbz0y+Cl78yvP3nHaww2nteL5/iJxcXBGBRl2iCEwo7TKSBU4n0kE+IcuyMahflew G8hQFpStiwLV5UICsnPXxRPFxb0fR32XgP5gUgRDvC/sjsCbWFM3awTaQoSlLEWn66k7 SEksKmjNeeCMBbSMYOr/5NEaJ6yH8J3rA3EIk1wFzt+71GwTXuiAFAp4487izlgv8zE1 CwSMeaqlnljzFq/eOfHpAmlx+/Yu8LcKcPj5ZAiQlEkDvHpwYgCw5BScYMa7cQHDL2Qy jIgA== MIME-Version: 1.0 X-Received: by 10.112.131.169 with SMTP id on9mr5171681lbb.124.1366271933890; Thu, 18 Apr 2013 00:58:53 -0700 (PDT) Received: by 10.112.23.232 with HTTP; Thu, 18 Apr 2013 00:58:53 -0700 (PDT) In-Reply-To: <20130417201808.GA30819@lor.one-eyed-alien.net> References: <20130417181631.GA29166@lor.one-eyed-alien.net> <20130417191812.GA30231@lor.one-eyed-alien.net> <20130417201808.GA30819@lor.one-eyed-alien.net> Date: Thu, 18 Apr 2013 09:58:53 +0200 Message-ID: Subject: Re: make buildkernel for GENERIC 9-STABLE just hangs, no error From: =?ISO-8859-1?Q?Olav_Gr=F8n=E5s_Gjerde?= To: Brooks Davis Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Stable Mailing List X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 07:58:55 -0000 I've just upgraded from a clean installation of 8.2-RELEASE and also a clean installation of 8.3-RELEASE to 9-STABLE, without your patch. No problems at all :-) Kind regards, Olav On Wed, Apr 17, 2013 at 10:18 PM, Brooks Davis wrote: > Thank you. You might try with this patch applied. It's not the right > patch but only in that it's too agressive about building ctfconvert as a > cross tool. > > Index: Makefile.inc1 > =================================================================== > --- Makefile.inc1 (revision 249590) > +++ Makefile.inc1 (working copy) > @@ -1114,9 +1114,7 @@ > usr.bin/clang/clang-tblgen > .endif > > -.if ${MK_CDDL} != "no" && \ > - ${BOOTSTRAPPING} < 800038 && \ > - !(${BOOTSTRAPPING} >= 700112 && ${BOOTSTRAPPING} < 799999) > +.if ${MK_CDDL} != "no" > _dtrace_tools= cddl/usr.bin/sgsmsg cddl/lib/libctf lib/libelf \ > lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge > .endif > > On Wed, Apr 17, 2013 at 10:09:42PM +0200, Olav Gr?n?s Gjerde wrote: > > I will try to upgrade from both of those releases and come back to you > with > > my results. > > > > Kind regards, > > Olav > > > > > > On Wed, Apr 17, 2013 at 9:18 PM, Brooks Davis > wrote: > > > > > On Wed, Apr 17, 2013 at 08:57:22PM +0200, Olav Gr?n?s Gjerde wrote: > > > > It was(sorry) from around 12th June 2012. > > > > But I have another system with 8.2-RELEASE that I can upgrade to a > commit > > > > around 12th June 2012 and then try directly to 9-STABLE(or 8.3 > first?) if > > > > that would be helpful? > > > > > > It would be helpful if you could first try an upgrade from 8.2-RELEASE. > > > It would also be good to know if 8.3-RELEASE builds. If we've got a > > > transient issue in the 8.2-STABLE line, we can document it and move on. > > > If it persisted through 8.3-STABLE that's more of an issue. > > > > > > Thanks, > > > Brooks > > > > > > > > > > > > > > > On Wed, Apr 17, 2013 at 8:16 PM, Brooks Davis > > > wrote: > > > > > > > > > On Wed, Apr 17, 2013 at 09:10:59AM +0200, Olav Gr?n?s Gjerde wrote: > > > > > > I have a weird problem while building the GENERIC 9-STABLE > kernel. > > > After > > > > > > around 5 minutes of compile time, the process just hangs on same > > > place. > > > > > No > > > > > > error. I've tried compiling different commits from this week > with the > > > > > same > > > > > > result. > > > > > > > > > > > > The part in the buildkernel process that hangs is this: > > > > > > MAKE=make sh /usr/src/sys/conf/newvers.sh GENERIC > > > > > > /usr/local/bin/svnversion > > > > > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing > -std=c99 -g > > > > > -Wall > > > > > > -Wredundant-decls -Wnested-externs -Wstrict-prototypes > > > > > > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -Wundef > > > > > > -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs > > > > > > -fdiagnostics-show-option -nostdinc -I. -I/usr/src/sys > > > > > > -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS > > > > > -include > > > > > > opt_global.h -fno-common -finline-limit=8000 --param > > > > > inline-unit-growth=100 > > > > > > --param large-function-growth=1000 -fno-omit-frame-pointer > > > > > -mcmodel=kernel > > > > > > -mno-red-zone -mno-mmx -mno-sse -msoft-float > > > > > > -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector > > > -Werror > > > > > > vers.c > > > > > > ctfconvert -L VERSION -g vers.o > > > > > > linking kernel.debug > > > > > > ctfmerge -L VERSION -g -o kernel.debug ............+ alot of *.o > > > > > > > > > > > > Any suggestions? > > > > > > > > > > In the DTrace commit message thread, you mentioned that you were > > > > > upgrading from an old 8-STABLE to 9 when you got the hang. Could > you > > > > > quantify how old that 8-STABLE was/is? If it's pre-8.3 it would be > > > > > really helpful if you could upgrade to 8.3 and test that. If that > > > works > > > > > then I think a note in UPDATING would be sufficient as our > historical > > > > > policy has been to support upgrading to release X.Y from > > > > > (X-1).. If it turns out that we need to upgrade to 8.4 we > may > > > > > need to consider backing this out for a bit. > > > > > > > > > > -- Brooks > > > > > > > > > From owner-freebsd-stable@FreeBSD.ORG Thu Apr 18 11:53:21 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6D48EDD6; Thu, 18 Apr 2013 11:53:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id D5BBB79D; Thu, 18 Apr 2013 11:53:20 +0000 (UTC) Received: by mail-ea0-f171.google.com with SMTP id b15so1192058eae.30 for ; Thu, 18 Apr 2013 04:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kL57ETNIujzLMAuDPLiVdwzx+3/wnUJJQhcsCLW4Bpk=; b=RlJv97dkauOi+y3FHeR4hwnUIKsUSUd4RXP7ejLvrCUGg5GEdhUgXkrShmMul3nTUL qUFUrsoGosKwgXA7StwIJTiZwq8LK8BCvQqZHAgTznPtVhNTeacV2ln2QrDwhe+me2sf qzufBytobsCaBlz/KfMzsz0ZFqIazwtUU5fo4SeTLkuMiOxaU+QIku48lCPwzsOrj/sq W9u34fQKV/0jrFZebjE3L/6jOi2Gzdgh0PvMo5QLtAgmuSnWnzvcbbyHJN8e0OLShT23 QuERivEFrA2CqK5qUxsTAcsxoon3o/bnxZ+z1HBAwI5nfDbIcNEXP/Cj35iqEHJVu0Tp 8Ivw== X-Received: by 10.14.39.5 with SMTP id c5mr29619501eeb.27.1366285998973; Thu, 18 Apr 2013 04:53:18 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (mavhome.mavhome.dp.ua. [213.227.240.37]) by mx.google.com with ESMTPS id cb50sm15238847eeb.14.2013.04.18.04.53.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 04:53:17 -0700 (PDT) Sender: Alexander Motin Message-ID: <516FDEAA.4040207@FreeBSD.org> Date: Thu, 18 Apr 2013 14:53:14 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130413 Thunderbird/17.0.5 MIME-Version: 1.0 To: Andre Albsmeier Subject: Re: Lost CDROM on 9.1 with ATA_CAM on Promise controller References: <20130416175520.GA9548@bali> <20130416193822.GA83620@icarus.home.lan> <20130417062600.GA15613@bali> <20130417085354.GA98850@icarus.home.lan> <20130417094712.GA16791@bali> In-Reply-To: <20130417094712.GA16791@bali> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , Kenneth Merry , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 11:53:21 -0000 On 17.04.2013 12:47, Andre Albsmeier wrote: > On Wed, 17-Apr-2013 at 10:53:54 +0200, Jeremy Chadwick wrote: >> On Wed, Apr 17, 2013 at 08:26:00AM +0200, Andre Albsmeier wrote: >>> On Tue, 16-Apr-2013 at 21:38:22 +0200, Jeremy Chadwick wrote: >>>> On Tue, Apr 16, 2013 at 07:55:20PM +0200, Andre Albsmeier wrote: >>>>> I have lost one of my CDROM drives (HL-DT-STDVD-RAM GH22LP20/2.00) >>>>> after going from 7.4 to 9.1 when using ATA_CAM. It is attached to >>>>> a Promise PDC20268 UDMA100 controller. A standard harddisk drive >>>>> attached to this controller works well. Cables, controller and drive >>>>> where replaced already. >>>>> >>>>> Kernel gives me: >>>>> >>>>> atapci1: port 0xb000-0xb007,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9800-0x980f mem 0xdf800000-0xdf803fff irq 11 at device 12.0 on pci0 >>>>> ata2: at channel 0 on atapci1 >>>>> ata3: at channel 1 on atapci1 >>>>> ... >>>>> ada0 at ata2 bus 0 scbus2 target 0 lun 0 >>>>> ada0: ATA-7 device >>>>> ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) >>>>> ada0: 286188MB (586114704 512 byte sectors: 16H 63S/T 16383C) >>>>> ... >>>>> (cd2:ata3:0:0:0): got CAM status 0x50 >>>>> (cd2:ata3:0:0:0): fatal error, failed to attach to device >>>>> (cd2:ata3:0:0:0): lost device, 4 refs >>>>> (cd2:ata3:0:0:0): removing device entry >>>>> ... >>>>> >>>>> Attaching the CDROM drive to the controller that is integrated on >>>>> the mainboard (Intel PIIX4 UDMA33 controller) does not show this >>>>> problem (but here I don't have UDMA66). >>>>> >>>>> It also works when not using ATA_CAM: >>>>> >>>>> ... >>>>> acd0: DVDR at ata3-master UDMA66 >>>>> ... >>>>> >>>>> So this semes to be a problem with the Promise controller and ATA_CAM. >>>>> >>>>> Any ideas? Or should I file PR? >>>> >>>> The controller in question is a Promise Ultra100 TX2. >>> >>> Right. Tried with an Ultra133, same effect. >>> >>>> >>>> The error message comes from sys/cam/scsi/scsi_cd.c, in function >>>> cddone(). The logic is a little hard for me to follow (I understand >>>> about 70% of it). Look at lines 1724 to 1877 for stable/9. >>>> >>>> 1. Can you provide full output from a verbose boot when the CD/DVD drive >>>> is attached to the Promise controller? >>> >>> Attached below. I have just filtered out some ahc cruft... >>> >>> Later I will try to boot a -current kernel -- just to see >>> how this behaves... >>> >>>> >>>> 2. What firmware version the card is using? The PDC20268 had many, many >>>> firmware problems relating to ATAPI devices. >>> >>> It is the latest BIOS: 2.20.0.15. >>> >>>> >>>> 3. I wouldn't worry about ATA66 vs. ATA33; this drive can only support >>>> up to about 22MBytes/second so ATA66 isn't going to get you anything, >>>> so as a workaround, using the PIIX4 for it would not hurt you. >>> >>> Probably. But I already had cdrecord complain when it >>> came to the funky DMA speed test it is doing. It went >>> away when using the UDMA66 port. And on the other hand >>> I sometimes use the PIIX4 port for other stuff and I >>> do not want to attach the cdrom to the slave port. >>> >>>> >>>> 4. ONLY if this turns out to be a "controller thing": I'm not sure how >>>> much effort should be spent trying to make this work, as the PDC20268 is >>>> legacy/deprecated hardware (made/released 13 years ago). >>> >>> The whole box is more than 13 years old (good old Asus BX board) ;-) >>> >>> But since it worked in 7.4-STABLE I feel that this is some kind >>> of regression. I do not want to waste anyone's resources in fixing >>> it -- just if someone is curious and/or has an idea how to fix >>> it... >>> >>> And here is the dmesg: >>> >>> {snipping for mail brevity} >> >> Thanks. CC'd ken@ and mav@ for advice on this. Here's the dmesg: >> >> http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073131.html >> >> Short details: >> >> The device under scrutiny here is cd2 on ata3, which is an ATAPI >> IDE-based optical drive. The drive works when either: >> >> a) Connected to a different IDE controller (atapci0), or, >> b) When ATA_CAM is removed (i.e. use ata(4) exclusively). > > And just as a note: The -current kernel from > > https://snapshots.glenbarber.us/Latest/FreeBSD-10.0-CURRENT-i386-20130316-r248381-bootonly.iso > > shows the same problem... Some of Promise controllers are known to have problems with ATAPI DMA. Have you tried to disable DMA on that channel or device with loader tunable like like hint.ata.3.mode=PIO4 ? -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Thu Apr 18 21:00:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 76DCE896 for ; Thu, 18 Apr 2013 21:00:41 +0000 (UTC) (envelope-from paulz@vanderzwan.org) Received: from cpsmtpb-ews01.kpnxchange.com (cpsmtpb-ews01.kpnxchange.com [213.75.39.4]) by mx1.freebsd.org (Postfix) with ESMTP id DF060AD for ; Thu, 18 Apr 2013 21:00:40 +0000 (UTC) Received: from cpsps-ews07.kpnxchange.com ([10.94.84.174]) by cpsmtpb-ews01.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 18 Apr 2013 22:59:30 +0200 Received: from CPSMTPM-TLF102.kpnxchange.com ([195.121.3.5]) by cpsps-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 18 Apr 2013 22:59:30 +0200 Received: from mailvm.vanderzwan.org ([77.172.189.82]) by CPSMTPM-TLF102.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Thu, 18 Apr 2013 22:59:30 +0200 Received: from gaspode.vanderzwan.org (gaspode.vanderzwan.org [192.168.178.22]) (authenticated bits=0) by mailvm.vanderzwan.org (8.14.6/8.14.6) with ESMTP id r3IKxTYl021109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 18 Apr 2013 22:59:29 +0200 (CEST) (envelope-from paulz@vanderzwan.org) From: Paul van der Zwan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Make buildworld broken on RELENG_9? Message-Id: Date: Thu, 18 Apr 2013 22:59:29 +0200 To: freebsd-stable@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (mailvm.vanderzwan.org [192.168.178.25]); Thu, 18 Apr 2013 22:59:29 +0200 (CEST) X-OriginalArrivalTime: 18 Apr 2013 20:59:30.0588 (UTC) FILETIME=[9EF3DDC0:01CE3C77] X-RcptDomain: freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 21:00:41 -0000 Since last weekend or so my make buildworld terminate at the following = error: =3D=3D=3D> share/tabset (all) uudecode < /usr/src/share/tabset/3101.uu uudecode < /usr/src/share/tabset/9837.uu uudecode < /usr/src/share/tabset/aa.uu uudecode < /usr/src/share/tabset/aed512.uu uudecode < /usr/src/share/tabset/beehive.uu uudecode < /usr/src/share/tabset/diablo.uu uudecode < /usr/src/share/tabset/dtc382.uu uudecode < /usr/src/share/tabset/hp700-wy.uu uudecode < /usr/src/share/tabset/ibm3101.uu uudecode < /usr/src/share/tabset/std.uu uudecode < /usr/src/share/tabset/stdcrt.uu uudecode < /usr/src/share/tabset/tandem653.uu uudecode < /usr/src/share/tabset/teleray.uu uudecode < /usr/src/share/tabset/vt100.uu uudecode < /usr/src/share/tabset/vt100-w.uu uudecode < /usr/src/share/tabset/wyse-adds.uu uudecode < /usr/src/share/tabset/xerox1720.uu uudecode < /usr/src/share/tabset/xerox1730.uu uudecode < /usr/src/share/tabset/xerox1730-lm.uu uudecode < /usr/src/share/tabset/zenith29.uu =3D=3D=3D> share/termcap (all) gzip -cn /usr/src/share/termcap/termcap.5 > termcap.5.gz TERM=3Ddumb TERMCAP=3Ddumb: ex - /usr/src/share/termcap/termcap.src < = /usr/src/share/termcap/reorder script, 2: Pattern not found *** [termcap] Error code 1 Stop in /usr/src/share/termcap. *** [all] Error code 1 Stop in /usr/src/share. *** [share.all__D] Error code 1 Stop in /usr/src. *** [everything] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 Stop in /usr/src. Even after updateing /usr/src using svn I keep this. Before this build I updated it: $ cd /data/src ; svn up ;=20 U sys/sys/vnode.h U sys/sys U sys/geom/geom_disk.c U sys/geom/geom_int.h U sys/geom/geom_subr.c U sys/geom/geom_dev.c U sys/geom/geom_event.c U sys/ufs/ufs/ufs_lookup.c U sys/ufs/ffs/ffs_softdep.c U sys/cam/cam_xpt.c U sys/cam/cam_periph.c U sys/cam/cam_sim.c U sys/cam/cam_periph.h U sys/cam/cam_sim.h U sys/cam/scsi/scsi_xpt.c U sys/cam/scsi/scsi_da.c U sys/cam/scsi/scsi_pass.c U sys/cam/scsi/scsi_cd.c U sys/cam/ata/ata_da.c U sys/cam/ata/ata_all.c U sys/cam/ata/ata_xpt.c U sys/dev/usb/controller/xhci_pci.c U sys/dev U sys/kern/vfs_cache.c U sys Updated to revision 249624. /etc/make.conf is almost empty : $ cat /etc/make.conf KERNCONF=3Dvbox CFLAGS=3D -O2 -fno-strict-aliasing -pipe COPTFLAGS=3D -O -pipe # added by use.perl 2013-03-12 18:50:12 PERL_VERSION=3D5.14.2 Any ideas ? Paul From owner-freebsd-stable@FreeBSD.ORG Thu Apr 18 21:15:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B39F1F89 for ; Thu, 18 Apr 2013 21:15:51 +0000 (UTC) (envelope-from outbackdingo@gmail.com) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by mx1.freebsd.org (Postfix) with ESMTP id 843201C2 for ; Thu, 18 Apr 2013 21:15:51 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id g12so2330583oah.0 for ; Thu, 18 Apr 2013 14:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YPKXrzctgtTmMooOOqiGsNQpuejECsJly4//s8nVOOs=; b=JwXh/hVxIBqlSeNP9Lw6JbUB7GqmOHFWPaDJC4jzVChrshjpfufLMhLGR31bQ7t4zV 3s7ZhHnIW0Gq7rEnuPkVabTaxSkdDKM+yCQHsaFA/5Vpiknr47B05hPTUEhCOPIZ3Wge 8itXeGxEZlicZcXe0VDMaSM5aeAqamMLfNAVM8caZYGdwxW+EjKUV3pHAQxTSFkmjd4B TenjMQxmu6zSxtw1+Wf/GaPd7hBuI5tOlxC3RZE48Br9nek3jiJALJiLZuH5e8LIWsGv t3TGO6pG3VnKlxKlCRDSbd/0J/ZoTemqtwEjxhIGcZQyxqeH3aoFRNjoG2/n34U16Z7h PL5Q== MIME-Version: 1.0 X-Received: by 10.182.226.162 with SMTP id rt2mr1588830obc.9.1366319750864; Thu, 18 Apr 2013 14:15:50 -0700 (PDT) Received: by 10.76.135.194 with HTTP; Thu, 18 Apr 2013 14:15:50 -0700 (PDT) In-Reply-To: References: Date: Thu, 18 Apr 2013 17:15:50 -0400 Message-ID: Subject: Re: Make buildworld broken on RELENG_9? From: Outback Dingo To: Paul van der Zwan Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 21:15:51 -0000 On Thu, Apr 18, 2013 at 4:59 PM, Paul van der Zwan wrote: > Since last weekend or so my make buildworld terminate at the following > error: > ===> share/tabset (all) > uudecode < /usr/src/share/tabset/3101.uu > uudecode < /usr/src/share/tabset/9837.uu > uudecode < /usr/src/share/tabset/aa.uu > uudecode < /usr/src/share/tabset/aed512.uu > uudecode < /usr/src/share/tabset/beehive.uu > uudecode < /usr/src/share/tabset/diablo.uu > uudecode < /usr/src/share/tabset/dtc382.uu > uudecode < /usr/src/share/tabset/hp700-wy.uu > uudecode < /usr/src/share/tabset/ibm3101.uu > uudecode < /usr/src/share/tabset/std.uu > uudecode < /usr/src/share/tabset/stdcrt.uu > uudecode < /usr/src/share/tabset/tandem653.uu > uudecode < /usr/src/share/tabset/teleray.uu > uudecode < /usr/src/share/tabset/vt100.uu > uudecode < /usr/src/share/tabset/vt100-w.uu > uudecode < /usr/src/share/tabset/wyse-adds.uu > uudecode < /usr/src/share/tabset/xerox1720.uu > uudecode < /usr/src/share/tabset/xerox1730.uu > uudecode < /usr/src/share/tabset/xerox1730-lm.uu > uudecode < /usr/src/share/tabset/zenith29.uu > ===> share/termcap (all) > gzip -cn /usr/src/share/termcap/termcap.5 > termcap.5.gz > TERM=dumb TERMCAP=dumb: ex - /usr/src/share/termcap/termcap.src < > /usr/src/share/termcap/reorder > script, 2: Pattern not found > *** [termcap] Error code 1 > > Stop in /usr/src/share/termcap. > *** [all] Error code 1 > > Stop in /usr/src/share. > *** [share.all__D] Error code 1 > > Stop in /usr/src. > *** [everything] Error code 1 > > Stop in /usr/src. > *** [buildworld] Error code 1 > > Stop in /usr/src. > > Even after updateing /usr/src using svn I keep this. > Before this build I updated it: > $ cd /data/src ; svn up ; > U sys/sys/vnode.h > U sys/sys > U sys/geom/geom_disk.c > U sys/geom/geom_int.h > U sys/geom/geom_subr.c > U sys/geom/geom_dev.c > U sys/geom/geom_event.c > U sys/ufs/ufs/ufs_lookup.c > U sys/ufs/ffs/ffs_softdep.c > U sys/cam/cam_xpt.c > U sys/cam/cam_periph.c > U sys/cam/cam_sim.c > U sys/cam/cam_periph.h > U sys/cam/cam_sim.h > U sys/cam/scsi/scsi_xpt.c > U sys/cam/scsi/scsi_da.c > U sys/cam/scsi/scsi_pass.c > U sys/cam/scsi/scsi_cd.c > U sys/cam/ata/ata_da.c > U sys/cam/ata/ata_all.c > U sys/cam/ata/ata_xpt.c > U sys/dev/usb/controller/xhci_pci.c > U sys/dev > U sys/kern/vfs_cache.c > U sys > Updated to revision 249624. > > /etc/make.conf is almost empty : > $ cat /etc/make.conf > KERNCONF=vbox > CFLAGS= -O2 -fno-strict-aliasing -pipe > COPTFLAGS= -O -pipe > > # added by use.perl 2013-03-12 18:50:12 > PERL_VERSION=5.14.2 > > > Any ideas ? > > Paul > > Odd because i just completed a build world kernel this morning svn info Path: . Working Copy Root Path: /usr/src URL: http://svn.freebsd.org/base/stable/9 Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 249621 Node Kind: directory Schedule: normal Last Changed Author: mav Last Changed Rev: 249621 Last Changed Date: 2013-04-18 11:13:48 +0000 (Thu, 18 Apr 2013) > _______________________________________________ > 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 Thu Apr 18 21:16:30 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AD764117 for ; Thu, 18 Apr 2013 21:16:30 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by mx1.freebsd.org (Postfix) with ESMTP id 936FA1DD for ; Thu, 18 Apr 2013 21:16:30 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta02.emeryville.ca.mail.comcast.net with comcast id RSir1l0020lTkoCA2ZGVvd; Thu, 18 Apr 2013 21:16:29 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta04.emeryville.ca.mail.comcast.net with comcast id RZGU1l00h1t3BNj8QZGUdf; Thu, 18 Apr 2013 21:16:29 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8045573A39; Thu, 18 Apr 2013 14:16:28 -0700 (PDT) Date: Thu, 18 Apr 2013 14:16:28 -0700 From: Jeremy Chadwick To: Paul van der Zwan Subject: Re: Make buildworld broken on RELENG_9? Message-ID: <20130418211628.GA37504@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366319789; bh=N1qBcgFmtmH1k7Sc6to6duAhinSqmyE+ferBax2M7tI=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=cJFMC1dPdwyEe+2rcdr7MVzZTku0MYvCaJrsC5v8VjBltuYkaYIYL73OF4Zs2TytQ oCx5sor/2qe3BqZsUGeeFBFpW6yRIGjjK7aECOgsuAc898Hy7sBfXUJryOU3+IQ9o9 5KnEr4VKVHne55GMw1hDhOBNo30kSe5e/0kgIlsTcXHZL5g9xbeg0hlK2mwk0mS8BD xslSosmw0DpWEB1jP4cOBAH0JVrfym6jsNfO25SrnFn7pqZogN4RXO6r8ZmR+jpCRV b84AwXlVP624SCDV+z9yDxgOpI2G6cEtE+YctnfUzx6/+A62j9XN0yhgsgDLQVilSn 6nr7adXKLsJ8Q== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 21:16:30 -0000 On Thu, Apr 18, 2013 at 10:59:29PM +0200, Paul van der Zwan wrote: > Since last weekend or so my make buildworld terminate at the following error: > ===> share/tabset (all) > uudecode < /usr/src/share/tabset/3101.uu > uudecode < /usr/src/share/tabset/9837.uu > uudecode < /usr/src/share/tabset/aa.uu > uudecode < /usr/src/share/tabset/aed512.uu > uudecode < /usr/src/share/tabset/beehive.uu > uudecode < /usr/src/share/tabset/diablo.uu > uudecode < /usr/src/share/tabset/dtc382.uu > uudecode < /usr/src/share/tabset/hp700-wy.uu > uudecode < /usr/src/share/tabset/ibm3101.uu > uudecode < /usr/src/share/tabset/std.uu > uudecode < /usr/src/share/tabset/stdcrt.uu > uudecode < /usr/src/share/tabset/tandem653.uu > uudecode < /usr/src/share/tabset/teleray.uu > uudecode < /usr/src/share/tabset/vt100.uu > uudecode < /usr/src/share/tabset/vt100-w.uu > uudecode < /usr/src/share/tabset/wyse-adds.uu > uudecode < /usr/src/share/tabset/xerox1720.uu > uudecode < /usr/src/share/tabset/xerox1730.uu > uudecode < /usr/src/share/tabset/xerox1730-lm.uu > uudecode < /usr/src/share/tabset/zenith29.uu > ===> share/termcap (all) > gzip -cn /usr/src/share/termcap/termcap.5 > termcap.5.gz > TERM=dumb TERMCAP=dumb: ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder > script, 2: Pattern not found > *** [termcap] Error code 1 > > Stop in /usr/src/share/termcap. > *** [all] Error code 1 > > Stop in /usr/src/share. > *** [share.all__D] Error code 1 > > Stop in /usr/src. > *** [everything] Error code 1 > > Stop in /usr/src. > *** [buildworld] Error code 1 > > Stop in /usr/src. > > Even after updateing /usr/src using svn I keep this. > Before this build I updated it: > $ cd /data/src ; svn up ; > U sys/sys/vnode.h > U sys/sys > U sys/geom/geom_disk.c > U sys/geom/geom_int.h > U sys/geom/geom_subr.c > U sys/geom/geom_dev.c > U sys/geom/geom_event.c > U sys/ufs/ufs/ufs_lookup.c > U sys/ufs/ffs/ffs_softdep.c > U sys/cam/cam_xpt.c > U sys/cam/cam_periph.c > U sys/cam/cam_sim.c > U sys/cam/cam_periph.h > U sys/cam/cam_sim.h > U sys/cam/scsi/scsi_xpt.c > U sys/cam/scsi/scsi_da.c > U sys/cam/scsi/scsi_pass.c > U sys/cam/scsi/scsi_cd.c > U sys/cam/ata/ata_da.c > U sys/cam/ata/ata_all.c > U sys/cam/ata/ata_xpt.c > U sys/dev/usb/controller/xhci_pci.c > U sys/dev > U sys/kern/vfs_cache.c > U sys > Updated to revision 249624. > > /etc/make.conf is almost empty : > $ cat /etc/make.conf > KERNCONF=vbox > CFLAGS= -O2 -fno-strict-aliasing -pipe > COPTFLAGS= -O -pipe > > # added by use.perl 2013-03-12 18:50:12 > PERL_VERSION=5.14.2 > > Any ideas ? I've been able to build stable/9 world without issue even as recent as last night. I'll rm -fr /usr/obj/* and rebuild world under "script" then go look at the output to see if I see anything anomalous around the area you've shown. I'll reply when that's done. Some things that are (hopefully) unrelated to your issue: 1. Use CFLAGS+=, not =. I cannot stress this enough. This is very important. There are portions of world/kernel that rely on their own set of CFLAGS and this can effectively "stomp over" them in some cases. So use +=. COPTFLAGS is fine to use = for. For details, read (not skim) /usr/share/examples/etc/make.conf. 2. Just an educational point in passing since we're talking about CFLAGS and so on: if you ever choose to set CPUTYPE, use ?= not =. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Apr 18 23:36:27 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E6612985 for ; Thu, 18 Apr 2013 23:36:27 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by mx1.freebsd.org (Postfix) with ESMTP id CB5A2A2B for ; Thu, 18 Apr 2013 23:36:27 +0000 (UTC) Received: from omta13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by qmta02.emeryville.ca.mail.comcast.net with comcast id RXHB1l00617UAYkA2bcT79; Thu, 18 Apr 2013 23:36:27 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta13.emeryville.ca.mail.comcast.net with comcast id RbcS1l00j1t3BNj8ZbcSG2; Thu, 18 Apr 2013 23:36:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 64F8B73A33; Thu, 18 Apr 2013 16:36:26 -0700 (PDT) Date: Thu, 18 Apr 2013 16:36:26 -0700 From: Jeremy Chadwick To: Paul van der Zwan Subject: Re: Make buildworld broken on RELENG_9? Message-ID: <20130418233626.GA39582@icarus.home.lan> References: <20130418211628.GA37504@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130418211628.GA37504@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366328187; bh=bawC60B98/NGKaD/KbjiX0BgOdaPmhCSVlBdtlGWLBU=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=b7pHSuVhhcY+mswtSAxyS/Db7opJbpr6JxGUfVeQIhW5IaOWjoeZ88rwBOle1enOM iwPDSD/anSZWf5TG9V4HrdPCoyPbXUzEV7dtj/2wCYlgon3MQGJCNXf/h5G3vGePgi SUNpKa0I0T2RQqAeAdpiFzlr9PvOgY1hrSH3nPbKhLnFFkfcuUJ3XFeh1SA0SEhUdM gHZckDup9L+59gXEZJw794J+OSPnFGu20eEoFgp9uFQBAJp5Pvvawhp3tA2zbrEC2e okVfSOIwVma/rePnrasadtz8P9eXfvta32LT1PavTEfauKD+9S6j1CI5kG5HNG0GFa bUKMhSfsIAs/Q== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 18 Apr 2013 23:36:28 -0000 On Thu, Apr 18, 2013 at 02:16:28PM -0700, Jeremy Chadwick wrote: > On Thu, Apr 18, 2013 at 10:59:29PM +0200, Paul van der Zwan wrote: > > Since last weekend or so my make buildworld terminate at the following error: > > ===> share/tabset (all) > > uudecode < /usr/src/share/tabset/3101.uu > > uudecode < /usr/src/share/tabset/9837.uu > > uudecode < /usr/src/share/tabset/aa.uu > > uudecode < /usr/src/share/tabset/aed512.uu > > uudecode < /usr/src/share/tabset/beehive.uu > > uudecode < /usr/src/share/tabset/diablo.uu > > uudecode < /usr/src/share/tabset/dtc382.uu > > uudecode < /usr/src/share/tabset/hp700-wy.uu > > uudecode < /usr/src/share/tabset/ibm3101.uu > > uudecode < /usr/src/share/tabset/std.uu > > uudecode < /usr/src/share/tabset/stdcrt.uu > > uudecode < /usr/src/share/tabset/tandem653.uu > > uudecode < /usr/src/share/tabset/teleray.uu > > uudecode < /usr/src/share/tabset/vt100.uu > > uudecode < /usr/src/share/tabset/vt100-w.uu > > uudecode < /usr/src/share/tabset/wyse-adds.uu > > uudecode < /usr/src/share/tabset/xerox1720.uu > > uudecode < /usr/src/share/tabset/xerox1730.uu > > uudecode < /usr/src/share/tabset/xerox1730-lm.uu > > uudecode < /usr/src/share/tabset/zenith29.uu > > ===> share/termcap (all) > > gzip -cn /usr/src/share/termcap/termcap.5 > termcap.5.gz > > TERM=dumb TERMCAP=dumb: ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder > > script, 2: Pattern not found > > *** [termcap] Error code 1 > > > > Stop in /usr/src/share/termcap. > > *** [all] Error code 1 > > > > Stop in /usr/src/share. > > *** [share.all__D] Error code 1 > > > > Stop in /usr/src. > > *** [everything] Error code 1 > > > > Stop in /usr/src. > > *** [buildworld] Error code 1 > > > > Stop in /usr/src. > > > > Even after updateing /usr/src using svn I keep this. > > Before this build I updated it: > > $ cd /data/src ; svn up ; > > U sys/sys/vnode.h > > U sys/sys > > U sys/geom/geom_disk.c > > U sys/geom/geom_int.h > > U sys/geom/geom_subr.c > > U sys/geom/geom_dev.c > > U sys/geom/geom_event.c > > U sys/ufs/ufs/ufs_lookup.c > > U sys/ufs/ffs/ffs_softdep.c > > U sys/cam/cam_xpt.c > > U sys/cam/cam_periph.c > > U sys/cam/cam_sim.c > > U sys/cam/cam_periph.h > > U sys/cam/cam_sim.h > > U sys/cam/scsi/scsi_xpt.c > > U sys/cam/scsi/scsi_da.c > > U sys/cam/scsi/scsi_pass.c > > U sys/cam/scsi/scsi_cd.c > > U sys/cam/ata/ata_da.c > > U sys/cam/ata/ata_all.c > > U sys/cam/ata/ata_xpt.c > > U sys/dev/usb/controller/xhci_pci.c > > U sys/dev > > U sys/kern/vfs_cache.c > > U sys > > Updated to revision 249624. > > > > /etc/make.conf is almost empty : > > $ cat /etc/make.conf > > KERNCONF=vbox > > CFLAGS= -O2 -fno-strict-aliasing -pipe > > COPTFLAGS= -O -pipe > > > > # added by use.perl 2013-03-12 18:50:12 > > PERL_VERSION=5.14.2 > > > > Any ideas ? > > I've been able to build stable/9 world without issue even as recent as > last night. I'll rm -fr /usr/obj/* and rebuild world under "script" > then go look at the output to see if I see anything anomalous around > the area you've shown. I'll reply when that's done. > > {snip} Can't reproduce the issue. root@testbox:/usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/9 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 249628 Node Kind: directory Schedule: normal Last Changed Author: mav Last Changed Rev: 249624 Last Changed Date: 2013-04-18 06:19:41 -0700 (Thu, 18 Apr 2013) Here's what I get, around where yours fails: ===> share/termcap (all) gzip -cn /usr/src/share/termcap/termcap.5 > termcap.5.gz TERM=dumb TERMCAP=dumb: ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder cap_mkdb -l termcap ===> share/timedef (all) grep -v '^#' < /usr/src/share/timedef/am_ET.UTF-8.src > am_ET.UTF-8.out Note that yours says "script, 2: Pattern not found" with no mention of cap_mkdb. My guess is that you have one of the following: a) A corrupted src/share/termcap/Makefile, b) A corrupted SVN repo, c) Silent filesystem corruption, d) Physical disk issues (e.g. bit rot). I've put the full output of my build here (~791KBytes): http://jdc.koitsu.org/freebsd/output.20130418.txt.gz Contents of my /etc/src.conf, which should have no bearing on your issue: WITHOUT_CLANG=true WITHOUT_INET6=true WITHOUT_IPFILTER=true WITHOUT_LIB32=true WITHOUT_KERBEROS=true WITHOUT_PAM_SUPPORT=true WITHOUT_SENDMAIL=true WITH_OPENSSH_NONE_CIPHER=true If you want to "start fresh" with your repo and use SVN, do this: rm -fr /usr/src rm -fr /usr/src/.svn svn checkout svn://svn.freebsd.org/base/stable/9 /usr/src Then do this before retrying buildworld: rm -fr /usr/obj/* cd /usr/src make buildworld -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Apr 19 12:45:37 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BE024D9D for ; Fri, 19 Apr 2013 12:45:37 +0000 (UTC) (envelope-from SRS0=ZKI/hawV=OG=beatsnet.com=beat.siegenthaler@beatsnet.com) Received: from vulcan.beatsnet.com (vulcan.beatsnet.com [IPv6:2001:470:1f0b:102::bea1]) by mx1.freebsd.org (Postfix) with ESMTP id 56FA11DE for ; Fri, 19 Apr 2013 12:45:36 +0000 (UTC) Received: from mbp-wl.beatsnet.com (zux165-132.adsl.green.ch [80.254.165.132]) (authenticated bits=0) by vulcan.beatsnet.com (8.14.5/8.14.5) with ESMTP id r3JCjLWw057584 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Fri, 19 Apr 2013 14:45:34 +0200 (CEST) (envelope-from beat.siegenthaler@beatsnet.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=beatsnet.com; s=VULCAN_DKIM; t=1366375535; bh=GZ9Z8qEOlPLFgSmsk689QhTTcreD45NbZCoJlOR71PM=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=ZuobLp9VX8fEI6DLSMgdcRNisz7j7G89lQmeiZR4pQVs2JqWKCT696PeBdEnTVPIZ otpTIBzoXO9f6tk6hn6Xj2Fe4BvUBJOxOXW5Ha6Z8MhR6+PL1TaHl3fdeNsELZxpoB u7boMuSfTE27ip4U/9S702eBloGVg7T4F4uqgtME= Message-ID: <51713C5C.9070009@beatsnet.com> Date: Fri, 19 Apr 2013 14:45:16 +0200 From: Beat Siegenthaler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Unable to get sendmail submission port to listen on IPv6 X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (vulcan.beatsnet.com [193.138.215.102]); Fri, 19 Apr 2013 14:45:34 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.97.7 at vulcan.beatsnet.com X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 12:45:37 -0000 Hi all, I did not recognize that 587 is only listening onIy on IPv4. Maybe it's new, maybe it was alltime so. sendmail 25090 root 4u IPv4 0xfffffe01e810f3d0 0t0 TCP *:25 (LISTEN) sendmail 25090 root 5u IPv6 0xfffffe01a988f000 0t0 TCP *:25 (LISTEN) sendmail 25090 root 6u IPv4 0xfffffe011c53d000 0t0 TCP *:587 (LISTEN) FreeBSD 9.1-STABLE #8 r248707 freebsd.submit.mc states: dnl If you use IPv6 only, change [127.0.0.1] to [IPv6:::1] FEATURE(`msp', `[127.0.0.1]')dnl But IPv6:::1 makes no difference, same picture only listen v4. hostname.domain.com grown over the years. TLS, some milters, SRS Hack. And working fine so far. Any hint for me? kind regards, Beat From owner-freebsd-stable@FreeBSD.ORG Fri Apr 19 14:00:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3BEC0C10 for ; Fri, 19 Apr 2013 14:00:14 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id 22B25390 for ; Fri, 19 Apr 2013 14:00:13 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta03.emeryville.ca.mail.comcast.net with comcast id Rpd71l00A16AWCUA3q0ChR; Fri, 19 Apr 2013 14:00:12 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta06.emeryville.ca.mail.comcast.net with comcast id Rq0B1l00G1t3BNj8Sq0Bnl; Fri, 19 Apr 2013 14:00:12 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 72C9D73A33; Fri, 19 Apr 2013 07:00:11 -0700 (PDT) Date: Fri, 19 Apr 2013 07:00:11 -0700 From: Jeremy Chadwick To: Beat Siegenthaler Subject: Re: Unable to get sendmail submission port to listen on IPv6 Message-ID: <20130419140011.GA87089@icarus.home.lan> References: <51713C5C.9070009@beatsnet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51713C5C.9070009@beatsnet.com> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366380012; bh=vJ/1KCIafWS7nxtqSlFTVWxV+Tc4lJTrkbjpzXns5xo=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=lFtVokGhaDD/NR8TKoYV/+C3bN/ain92piluNbgSs1zy6ImPiZheqAb7pX3XRsQFw KgLQtHh7MKnEdRmLny0RzWjgGH2/vk0qpZHXi+4FfKDt2Qg1fmwFORb6V26fpDZEsV jW2wILqQtBIkIJJDnW1OgMi0yP+Lq1shavUg5+Eld826fIZWQwWnU2TDXRiQwtucBb GOYlPgE984IMYjo246qYtx/ryN6EyTIcqWLp2ZytuTv3OvgVztRg6Pvn0xewZrwG++ sFqwX4UDaHrXxYyZyTSVFeD2H6NAA1J3T6RRZ7K58y7DVmqVMnN+aLpsG1upWfDRZ1 e2DPK9rWovAhQ== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 14:00:14 -0000 On Fri, Apr 19, 2013 at 02:45:16PM +0200, Beat Siegenthaler wrote: > Hi all, > > I did not recognize that 587 is only listening onIy on IPv4. Maybe it's > new, maybe it was alltime so. > > sendmail 25090 root 4u IPv4 0xfffffe01e810f3d0 0t0 > TCP *:25 (LISTEN) > sendmail 25090 root 5u IPv6 0xfffffe01a988f000 0t0 > TCP *:25 (LISTEN) > sendmail 25090 root 6u IPv4 0xfffffe011c53d000 0t0 > TCP *:587 (LISTEN) > > FreeBSD 9.1-STABLE #8 r248707 > > freebsd.submit.mc states: > > dnl If you use IPv6 only, change [127.0.0.1] to [IPv6:::1] > FEATURE(`msp', `[127.0.0.1]')dnl > > But IPv6:::1 makes no difference, same picture only listen v4. > > hostname.domain.com grown over the years. TLS, some milters, SRS Hack. > And working fine so far. > > Any hint for me? Note: I have not used sendmail in years, so I'm going off of memory. Multiple things: 1. The files that "control" sendmail are `hostname`.mc and `hostname`.submit.mc. The freebsd.mc and freebsd.submit.mc are "stock" examples. I assume you're already familiar with the need to run "make" in /etc/mail. 2. `hostname`.mc controls options/features for the daemon -- i.e. the thing that is listening on TCP ports. `hostname`.submit.mc is for outbound mail. You're wanting sendmail to listen on TCP port 587, which is what's used by SMTP clients (ex. Eudora, Thunderbird, etc.) trying to send mail to sendmail (rather than the classic model/method of using port 25). 3. What you need to add is here: http://lists.freebsd.org/pipermail/freebsd-questions/2004-March/040006.html Good luck. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Apr 19 15:52:55 2013 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D0C6890D; Fri, 19 Apr 2013 15:52:55 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) by mx1.freebsd.org (Postfix) with ESMTP id 252262C4; Fri, 19 Apr 2013 15:52:54 +0000 (UTC) Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.13.6/8.13.6) with ESMTP id r3J4cdLO030344; Fri, 19 Apr 2013 06:38:39 +0200 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail3.siemens.de (8.13.6/8.13.6) with ESMTP id r3J4cdfd010050; Fri, 19 Apr 2013 06:38:39 +0200 Received: (from localhost) by curry.mchp.siemens.de (8.14.6/8.14.6) id r3J4cdnX009303; Date: Fri, 19 Apr 2013 06:38:39 +0200 From: Andre Albsmeier To: Alexander Motin Subject: Re: Lost CDROM on 9.1 with ATA_CAM on Promise controller Message-ID: <20130419043839.GA7685@bali> References: <20130416175520.GA9548@bali> <20130416193822.GA83620@icarus.home.lan> <20130417062600.GA15613@bali> <20130417085354.GA98850@icarus.home.lan> <20130417094712.GA16791@bali> <516FDEAA.4040207@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <516FDEAA.4040207@FreeBSD.org> X-Echelon: X-Advice: Drop that crappy M$-Outlook, I'm tired of your viruses! User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jeremy Chadwick , Kenneth Merry , "freebsd-stable@freebsd.org" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 15:52:55 -0000 On Thu, 18-Apr-2013 at 13:53:14 +0200, Alexander Motin wrote: > On 17.04.2013 12:47, Andre Albsmeier wrote: > > On Wed, 17-Apr-2013 at 10:53:54 +0200, Jeremy Chadwick wrote: > >> On Wed, Apr 17, 2013 at 08:26:00AM +0200, Andre Albsmeier wrote: > >>> On Tue, 16-Apr-2013 at 21:38:22 +0200, Jeremy Chadwick wrote: > >>>> On Tue, Apr 16, 2013 at 07:55:20PM +0200, Andre Albsmeier wrote: > >>>>> I have lost one of my CDROM drives (HL-DT-STDVD-RAM GH22LP20/2.00) > >>>>> after going from 7.4 to 9.1 when using ATA_CAM. It is attached to > >>>>> a Promise PDC20268 UDMA100 controller. A standard harddisk drive > >>>>> attached to this controller works well. Cables, controller and drive > >>>>> where replaced already. > >>>>> > >>>>> Kernel gives me: > >>>>> > >>>>> atapci1: port 0xb000-0xb007,0xa800-0xa803,0xa400-0xa407,0xa000-0xa003,0x9800-0x980f mem 0xdf800000-0xdf803fff irq 11 at device 12.0 on pci0 > >>>>> ata2: at channel 0 on atapci1 > >>>>> ata3: at channel 1 on atapci1 > >>>>> ... > >>>>> ada0 at ata2 bus 0 scbus2 target 0 lun 0 > >>>>> ada0: ATA-7 device > >>>>> ada0: 100.000MB/s transfers (UDMA5, PIO 8192bytes) > >>>>> ada0: 286188MB (586114704 512 byte sectors: 16H 63S/T 16383C) > >>>>> ... > >>>>> (cd2:ata3:0:0:0): got CAM status 0x50 > >>>>> (cd2:ata3:0:0:0): fatal error, failed to attach to device > >>>>> (cd2:ata3:0:0:0): lost device, 4 refs > >>>>> (cd2:ata3:0:0:0): removing device entry > >>>>> ... > >>>>> > >>>>> Attaching the CDROM drive to the controller that is integrated on > >>>>> the mainboard (Intel PIIX4 UDMA33 controller) does not show this > >>>>> problem (but here I don't have UDMA66). > >>>>> > >>>>> It also works when not using ATA_CAM: > >>>>> > >>>>> ... > >>>>> acd0: DVDR at ata3-master UDMA66 > >>>>> ... > >>>>> > >>>>> So this semes to be a problem with the Promise controller and ATA_CAM. > >>>>> > >>>>> Any ideas? Or should I file PR? > >>>> > >>>> The controller in question is a Promise Ultra100 TX2. > >>> > >>> Right. Tried with an Ultra133, same effect. > >>> > >>>> > >>>> The error message comes from sys/cam/scsi/scsi_cd.c, in function > >>>> cddone(). The logic is a little hard for me to follow (I understand > >>>> about 70% of it). Look at lines 1724 to 1877 for stable/9. > >>>> > >>>> 1. Can you provide full output from a verbose boot when the CD/DVD drive > >>>> is attached to the Promise controller? > >>> > >>> Attached below. I have just filtered out some ahc cruft... > >>> > >>> Later I will try to boot a -current kernel -- just to see > >>> how this behaves... > >>> > >>>> > >>>> 2. What firmware version the card is using? The PDC20268 had many, many > >>>> firmware problems relating to ATAPI devices. > >>> > >>> It is the latest BIOS: 2.20.0.15. > >>> > >>>> > >>>> 3. I wouldn't worry about ATA66 vs. ATA33; this drive can only support > >>>> up to about 22MBytes/second so ATA66 isn't going to get you anything, > >>>> so as a workaround, using the PIIX4 for it would not hurt you. > >>> > >>> Probably. But I already had cdrecord complain when it > >>> came to the funky DMA speed test it is doing. It went > >>> away when using the UDMA66 port. And on the other hand > >>> I sometimes use the PIIX4 port for other stuff and I > >>> do not want to attach the cdrom to the slave port. > >>> > >>>> > >>>> 4. ONLY if this turns out to be a "controller thing": I'm not sure how > >>>> much effort should be spent trying to make this work, as the PDC20268 is > >>>> legacy/deprecated hardware (made/released 13 years ago). > >>> > >>> The whole box is more than 13 years old (good old Asus BX board) ;-) > >>> > >>> But since it worked in 7.4-STABLE I feel that this is some kind > >>> of regression. I do not want to waste anyone's resources in fixing > >>> it -- just if someone is curious and/or has an idea how to fix > >>> it... > >>> > >>> And here is the dmesg: > >>> > >>> {snipping for mail brevity} > >> > >> Thanks. CC'd ken@ and mav@ for advice on this. Here's the dmesg: > >> > >> http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073131.html > >> > >> Short details: > >> > >> The device under scrutiny here is cd2 on ata3, which is an ATAPI > >> IDE-based optical drive. The drive works when either: > >> > >> a) Connected to a different IDE controller (atapci0), or, > >> b) When ATA_CAM is removed (i.e. use ata(4) exclusively). > > > > And just as a note: The -current kernel from > > > > https://snapshots.glenbarber.us/Latest/FreeBSD-10.0-CURRENT-i386-20130316-r248381-bootonly.iso > > > > shows the same problem... > > Some of Promise controllers are known to have problems with ATAPI DMA. > Have you tried to disable DMA on that channel or device with loader > tunable like like hint.ata.3.mode=PIO4 ? Interestingly, now it attaches properly: cd2 at ata3 bus 0 scbus3 target 0 lun 0 cd2: Removable CD-ROM SCSI-0 device cd2: 16.700MB/s transfers (PIO4, ATAPI 12bytes, PIO 65534bytes) cd2: Attempt to query device size failed: NOT READY, Medium not present - tray closed Anyway, this thing worked until 7.4-STABLE in DMA66 mode and burned quite a few DVDs. And it attaches under 9.1 without ATA_CAM and even with atapicam (although here it probes with 3.300MB/s transfers and I didn't try to burn a DVD actually). So while I cannot prove that this controller doesn't have problems with ATAPI DMA, especially 7.4 found a way to make it work anyway... Thanks, -Andre > > -- > Alexander Motin -- Amateurs like Linux, but professionals prefer FreeBSD. From owner-freebsd-stable@FreeBSD.ORG Fri Apr 19 19:58:00 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B5B2AD25 for ; Fri, 19 Apr 2013 19:58:00 +0000 (UTC) (envelope-from paulz@vanderzwan.org) Received: from cpsmtpb-ews07.kpnxchange.com (cpsmtpb-ews07.kpnxchange.com [213.75.39.10]) by mx1.freebsd.org (Postfix) with ESMTP id 27FFB1B60 for ; Fri, 19 Apr 2013 19:57:59 +0000 (UTC) Received: from cpsps-ews23.kpnxchange.com ([10.94.84.189]) by cpsmtpb-ews07.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 19 Apr 2013 21:57:49 +0200 Received: from CPSMTPM-TLF102.kpnxchange.com ([195.121.3.5]) by cpsps-ews23.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 19 Apr 2013 21:57:49 +0200 Received: from mailvm.vanderzwan.org ([77.172.189.82]) by CPSMTPM-TLF102.kpnxchange.com with Microsoft SMTPSVC(7.5.7601.17514); Fri, 19 Apr 2013 21:57:49 +0200 Received: from [IPv6:2001:1af8:fefb::12dd:b1ff:feb3:1119] ([IPv6:2001:1af8:fefb:0:12dd:b1ff:feb3:1119]) (authenticated bits=0) by mailvm.vanderzwan.org (8.14.6/8.14.6) with ESMTP id r3JJvhCH025684 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Apr 2013 21:57:48 +0200 (CEST) (envelope-from paulz@vanderzwan.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Make buildworld broken on RELENG_9? From: Paul van der Zwan In-Reply-To: <20130418233626.GA39582@icarus.home.lan> Date: Fri, 19 Apr 2013 21:57:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130418211628.GA37504@icarus.home.lan> <20130418233626.GA39582@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1503) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (mailvm.vanderzwan.org [IPv6:2001:1af8:fefb::25]); Fri, 19 Apr 2013 21:57:49 +0200 (CEST) X-OriginalArrivalTime: 19 Apr 2013 19:57:49.0587 (UTC) FILETIME=[2B65AE30:01CE3D38] X-RcptDomain: freebsd.org Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 19:58:00 -0000 On 19 Apr 2013, at 1:36 , Jeremy Chadwick wrote: > On Thu, Apr 18, 2013 at 02:16:28PM -0700, Jeremy Chadwick wrote: >> On Thu, Apr 18, 2013 at 10:59:29PM +0200, Paul van der Zwan wrote: >>> Since last weekend or so my make buildworld terminate at the = following error: >>> =3D=3D=3D> share/tabset (all) >>> uudecode < /usr/src/share/tabset/3101.uu >>> uudecode < /usr/src/share/tabset/9837.uu >>> uudecode < /usr/src/share/tabset/aa.uu >>> uudecode < /usr/src/share/tabset/aed512.uu >>> uudecode < /usr/src/share/tabset/beehive.uu >>> uudecode < /usr/src/share/tabset/diablo.uu >>> uudecode < /usr/src/share/tabset/dtc382.uu >>> uudecode < /usr/src/share/tabset/hp700-wy.uu >>> uudecode < /usr/src/share/tabset/ibm3101.uu >>> uudecode < /usr/src/share/tabset/std.uu >>> uudecode < /usr/src/share/tabset/stdcrt.uu >>> uudecode < /usr/src/share/tabset/tandem653.uu >>> uudecode < /usr/src/share/tabset/teleray.uu >>> uudecode < /usr/src/share/tabset/vt100.uu >>> uudecode < /usr/src/share/tabset/vt100-w.uu >>> uudecode < /usr/src/share/tabset/wyse-adds.uu >>> uudecode < /usr/src/share/tabset/xerox1720.uu >>> uudecode < /usr/src/share/tabset/xerox1730.uu >>> uudecode < /usr/src/share/tabset/xerox1730-lm.uu >>> uudecode < /usr/src/share/tabset/zenith29.uu >>> =3D=3D=3D> share/termcap (all) >>> gzip -cn /usr/src/share/termcap/termcap.5 > termcap.5.gz >>> TERM=3Ddumb TERMCAP=3Ddumb: ex - /usr/src/share/termcap/termcap.src = < /usr/src/share/termcap/reorder >>> script, 2: Pattern not found >>> *** [termcap] Error code 1 >>>=20 >>> Stop in /usr/src/share/termcap. >>> *** [all] Error code 1 >>>=20 >>> Stop in /usr/src/share. >>> *** [share.all__D] Error code 1 >>>=20 >>> Stop in /usr/src. >>> *** [everything] Error code 1 >>>=20 >>> Stop in /usr/src. >>> *** [buildworld] Error code 1 >>>=20 >>> Stop in /usr/src. >>>=20 >>> Even after updateing /usr/src using svn I keep this. >>> Before this build I updated it: >>> $ cd /data/src ; svn up ;=20 >>> U sys/sys/vnode.h >>> U sys/sys >>> U sys/geom/geom_disk.c >>> U sys/geom/geom_int.h >>> U sys/geom/geom_subr.c >>> U sys/geom/geom_dev.c >>> U sys/geom/geom_event.c >>> U sys/ufs/ufs/ufs_lookup.c >>> U sys/ufs/ffs/ffs_softdep.c >>> U sys/cam/cam_xpt.c >>> U sys/cam/cam_periph.c >>> U sys/cam/cam_sim.c >>> U sys/cam/cam_periph.h >>> U sys/cam/cam_sim.h >>> U sys/cam/scsi/scsi_xpt.c >>> U sys/cam/scsi/scsi_da.c >>> U sys/cam/scsi/scsi_pass.c >>> U sys/cam/scsi/scsi_cd.c >>> U sys/cam/ata/ata_da.c >>> U sys/cam/ata/ata_all.c >>> U sys/cam/ata/ata_xpt.c >>> U sys/dev/usb/controller/xhci_pci.c >>> U sys/dev >>> U sys/kern/vfs_cache.c >>> U sys >>> Updated to revision 249624. >>>=20 >>> /etc/make.conf is almost empty : >>> $ cat /etc/make.conf >>> KERNCONF=3Dvbox >>> CFLAGS=3D -O2 -fno-strict-aliasing -pipe >>> COPTFLAGS=3D -O -pipe >>>=20 >>> # added by use.perl 2013-03-12 18:50:12 >>> PERL_VERSION=3D5.14.2 >>>=20 >>> Any ideas ? >>=20 >> I've been able to build stable/9 world without issue even as recent = as >> last night. I'll rm -fr /usr/obj/* and rebuild world under "script" >> then go look at the output to see if I see anything anomalous around >> the area you've shown. I'll reply when that's done. >>=20 >> {snip} >=20 > Can't reproduce the issue. >=20 > root@testbox:/usr/src # svn info > Path: . > Working Copy Root Path: /usr/src > URL: svn://svn.freebsd.org/base/stable/9 > Repository Root: svn://svn.freebsd.org/base > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > Revision: 249628 > Node Kind: directory > Schedule: normal > Last Changed Author: mav > Last Changed Rev: 249624 > Last Changed Date: 2013-04-18 06:19:41 -0700 (Thu, 18 Apr 2013) >=20 > Here's what I get, around where yours fails: >=20 > =3D=3D=3D> share/termcap (all) > gzip -cn /usr/src/share/termcap/termcap.5 > termcap.5.gz > TERM=3Ddumb TERMCAP=3Ddumb: ex - /usr/src/share/termcap/termcap.src < = /usr/src/share/termcap/reorder > cap_mkdb -l termcap > =3D=3D=3D> share/timedef (all) > grep -v '^#' < /usr/src/share/timedef/am_ET.UTF-8.src > = am_ET.UTF-8.out >=20 > Note that yours says "script, 2: Pattern not found" with no mention of > cap_mkdb. >=20 > My guess is that you have one of the following: >=20 > a) A corrupted src/share/termcap/Makefile, > b) A corrupted SVN repo, Deleted the content of src/share/termcap and reran svn. Now the build succeeds. > c) Silent filesystem corruption, > d) Physical disk issues (e.g. bit rot). >=20 /usr/src is NFS mounted from an OpenIndiana server so the underlying FS = is ZFS, so no bitrot or silent corruption should be possible. I made a snapshot before I deleted the files and ran svn: $ ls -l /data//src/.zfs/snapshot/20130419/share/termcap/ total 669 -rw-r--r-- 1 paulz home 731 Nov 18 22:26 Makefile -rw-r--r-- 1 paulz home 2501 Nov 18 22:26 README -rw-r--r-- 1 paulz home 1467 Nov 18 22:26 reorder -rw-r--r-- 1 paulz home 3531 Nov 18 22:26 tck -rw-r--r-- 1 paulz home 66181 Nov 18 22:26 termcap.5 -rw-r--r-- 1 paulz home 214309 Apr 16 18:55 termcap.src $ ls -l total 669 -rw-r--r-- 1 paulz home 731 Apr 19 17:01 Makefile -rw-r--r-- 1 paulz home 2501 Apr 19 17:01 README -rw-r--r-- 1 paulz home 1467 Apr 19 17:01 reorder -rw-r--r-- 1 paulz home 3531 Apr 19 17:01 tck -rw-r--r-- 1 paulz home 66181 Apr 19 17:01 termcap.5 -rw-r--r-- 1 paulz home 208289 Apr 19 17:01 termcap.src So it looks like termcap.src was very different but somehow svn never = updated that file. I have only used svn to pull in the FreeBSD source so at the moment no = idea if that is normal, but it surprised my that this happened.. Paul From owner-freebsd-stable@FreeBSD.ORG Fri Apr 19 20:21:42 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 40211313 for ; Fri, 19 Apr 2013 20:21:42 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id 23D761CB6 for ; Fri, 19 Apr 2013 20:21:42 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta03.emeryville.ca.mail.comcast.net with comcast id Rpsj1l0011vN32cA3wMhFR; Fri, 19 Apr 2013 20:21:41 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id RwMg1l00U1t3BNj8iwMgMQ; Fri, 19 Apr 2013 20:21:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 366FB73A33; Fri, 19 Apr 2013 13:21:40 -0700 (PDT) Date: Fri, 19 Apr 2013 13:21:40 -0700 From: Jeremy Chadwick To: Paul van der Zwan Subject: Re: Make buildworld broken on RELENG_9? Message-ID: <20130419202140.GA93675@icarus.home.lan> References: <20130418211628.GA37504@icarus.home.lan> <20130418233626.GA39582@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366402901; bh=cbpBEgKDTXFcFwid/9ux0rtpObhcC+UDTW+HecDcqFw=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=BOxD1npg1g5nqhuHayA+gbnhd9b+J2Dg28pfnBdW3c2QjfhrXiDwXsa39bBmK7jI/ FO2FJBv7rkiEYenOoQ/ZxwlLz41FH9S4SkcFk1QMCcYO5hsj6tswPOZ48+J27gD8Fj R+2ibTJb4rYZNSdekv1YftioWgbHyJ3T8Gu1i9dWzPc29+BZpXff0CYbGosLt/AKXf fL0mhjj8hmepGlDcJMo39gw9QYFd3GSmyIO0e+tUcyJKdp1/8LDjde2/kXiWD7JUOP Z1L2I4MWLJuKTSPnCuwSio2z1oTorcMts254plAeq7ar6FFkcPTdj55aMeE6ehE49X 6vcjvpPmxMNew== Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 19 Apr 2013 20:21:42 -0000 On Fri, Apr 19, 2013 at 09:57:46PM +0200, Paul van der Zwan wrote: > > On 19 Apr 2013, at 1:36 , Jeremy Chadwick wrote: > > > On Thu, Apr 18, 2013 at 02:16:28PM -0700, Jeremy Chadwick wrote: > >> On Thu, Apr 18, 2013 at 10:59:29PM +0200, Paul van der Zwan wrote: > >>> Since last weekend or so my make buildworld terminate at the following error: > >>> ===> share/tabset (all) > >>> uudecode < /usr/src/share/tabset/3101.uu > >>> uudecode < /usr/src/share/tabset/9837.uu > >>> uudecode < /usr/src/share/tabset/aa.uu > >>> uudecode < /usr/src/share/tabset/aed512.uu > >>> uudecode < /usr/src/share/tabset/beehive.uu > >>> uudecode < /usr/src/share/tabset/diablo.uu > >>> uudecode < /usr/src/share/tabset/dtc382.uu > >>> uudecode < /usr/src/share/tabset/hp700-wy.uu > >>> uudecode < /usr/src/share/tabset/ibm3101.uu > >>> uudecode < /usr/src/share/tabset/std.uu > >>> uudecode < /usr/src/share/tabset/stdcrt.uu > >>> uudecode < /usr/src/share/tabset/tandem653.uu > >>> uudecode < /usr/src/share/tabset/teleray.uu > >>> uudecode < /usr/src/share/tabset/vt100.uu > >>> uudecode < /usr/src/share/tabset/vt100-w.uu > >>> uudecode < /usr/src/share/tabset/wyse-adds.uu > >>> uudecode < /usr/src/share/tabset/xerox1720.uu > >>> uudecode < /usr/src/share/tabset/xerox1730.uu > >>> uudecode < /usr/src/share/tabset/xerox1730-lm.uu > >>> uudecode < /usr/src/share/tabset/zenith29.uu > >>> ===> share/termcap (all) > >>> gzip -cn /usr/src/share/termcap/termcap.5 > termcap.5.gz > >>> TERM=dumb TERMCAP=dumb: ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder > >>> script, 2: Pattern not found > >>> *** [termcap] Error code 1 > >>> > >>> Stop in /usr/src/share/termcap. > >>> *** [all] Error code 1 > >>> > >>> Stop in /usr/src/share. > >>> *** [share.all__D] Error code 1 > >>> > >>> Stop in /usr/src. > >>> *** [everything] Error code 1 > >>> > >>> Stop in /usr/src. > >>> *** [buildworld] Error code 1 > >>> > >>> Stop in /usr/src. > >>> > >>> Even after updateing /usr/src using svn I keep this. > >>> Before this build I updated it: > >>> $ cd /data/src ; svn up ; > >>> U sys/sys/vnode.h > >>> U sys/sys > >>> U sys/geom/geom_disk.c > >>> U sys/geom/geom_int.h > >>> U sys/geom/geom_subr.c > >>> U sys/geom/geom_dev.c > >>> U sys/geom/geom_event.c > >>> U sys/ufs/ufs/ufs_lookup.c > >>> U sys/ufs/ffs/ffs_softdep.c > >>> U sys/cam/cam_xpt.c > >>> U sys/cam/cam_periph.c > >>> U sys/cam/cam_sim.c > >>> U sys/cam/cam_periph.h > >>> U sys/cam/cam_sim.h > >>> U sys/cam/scsi/scsi_xpt.c > >>> U sys/cam/scsi/scsi_da.c > >>> U sys/cam/scsi/scsi_pass.c > >>> U sys/cam/scsi/scsi_cd.c > >>> U sys/cam/ata/ata_da.c > >>> U sys/cam/ata/ata_all.c > >>> U sys/cam/ata/ata_xpt.c > >>> U sys/dev/usb/controller/xhci_pci.c > >>> U sys/dev > >>> U sys/kern/vfs_cache.c > >>> U sys > >>> Updated to revision 249624. > >>> > >>> /etc/make.conf is almost empty : > >>> $ cat /etc/make.conf > >>> KERNCONF=vbox > >>> CFLAGS= -O2 -fno-strict-aliasing -pipe > >>> COPTFLAGS= -O -pipe > >>> > >>> # added by use.perl 2013-03-12 18:50:12 > >>> PERL_VERSION=5.14.2 > >>> > >>> Any ideas ? > >> > >> I've been able to build stable/9 world without issue even as recent as > >> last night. I'll rm -fr /usr/obj/* and rebuild world under "script" > >> then go look at the output to see if I see anything anomalous around > >> the area you've shown. I'll reply when that's done. > >> > >> {snip} > > > > Can't reproduce the issue. > > > > root@testbox:/usr/src # svn info > > Path: . > > Working Copy Root Path: /usr/src > > URL: svn://svn.freebsd.org/base/stable/9 > > Repository Root: svn://svn.freebsd.org/base > > Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f > > Revision: 249628 > > Node Kind: directory > > Schedule: normal > > Last Changed Author: mav > > Last Changed Rev: 249624 > > Last Changed Date: 2013-04-18 06:19:41 -0700 (Thu, 18 Apr 2013) > > > > Here's what I get, around where yours fails: > > > > ===> share/termcap (all) > > gzip -cn /usr/src/share/termcap/termcap.5 > termcap.5.gz > > TERM=dumb TERMCAP=dumb: ex - /usr/src/share/termcap/termcap.src < /usr/src/share/termcap/reorder > > cap_mkdb -l termcap > > ===> share/timedef (all) > > grep -v '^#' < /usr/src/share/timedef/am_ET.UTF-8.src > am_ET.UTF-8.out > > > > Note that yours says "script, 2: Pattern not found" with no mention of > > cap_mkdb. > > > > My guess is that you have one of the following: > > > > a) A corrupted src/share/termcap/Makefile, > > b) A corrupted SVN repo, > > Deleted the content of src/share/termcap and reran svn. > Now the build succeeds. Not surprised. :-) > > c) Silent filesystem corruption, > > d) Physical disk issues (e.g. bit rot). > > > /usr/src is NFS mounted from an OpenIndiana server so the underlying FS is ZFS, so no bitrot or silent corruption > should be possible. As long as the pool configuration is using something that ZFS can induce recovery from (specifically: mirrors, raidzX, or a combination of vdevs that make such possible), then that's true. If a stripe of disks, or a single disk, then only detection of such problems is possible. zpool status will shed light on the situation. > I made a snapshot before I deleted the files and ran svn: > $ ls -l /data//src/.zfs/snapshot/20130419/share/termcap/ > total 669 > -rw-r--r-- 1 paulz home 731 Nov 18 22:26 Makefile > -rw-r--r-- 1 paulz home 2501 Nov 18 22:26 README > -rw-r--r-- 1 paulz home 1467 Nov 18 22:26 reorder > -rw-r--r-- 1 paulz home 3531 Nov 18 22:26 tck > -rw-r--r-- 1 paulz home 66181 Nov 18 22:26 termcap.5 > -rw-r--r-- 1 paulz home 214309 Apr 16 18:55 termcap.src > $ ls -l > total 669 > -rw-r--r-- 1 paulz home 731 Apr 19 17:01 Makefile > -rw-r--r-- 1 paulz home 2501 Apr 19 17:01 README > -rw-r--r-- 1 paulz home 1467 Apr 19 17:01 reorder > -rw-r--r-- 1 paulz home 3531 Apr 19 17:01 tck > -rw-r--r-- 1 paulz home 66181 Apr 19 17:01 termcap.5 > -rw-r--r-- 1 paulz home 208289 Apr 19 17:01 termcap.src > > So it looks like termcap.src was very different but somehow svn never updated that file. > I have only used svn to pull in the FreeBSD source so at the moment no idea if that is normal, > but it surprised my that this happened.. I also find this interesting -- note that multiple files I have are different sizes than yours (the only ones which are the same size are README and tck). root@icarus:/usr/src # ls -l /usr/src/share/termcap/ total 288 -rw-r--r-- 1 root wheel 797 Jan 24 16:58 Makefile -rw-r--r-- 1 root wheel 2501 Jan 24 16:58 README -rw-r--r-- 1 root wheel 1533 Jan 24 16:58 reorder -rw-r--r-- 1 root wheel 3531 Jan 24 16:58 tck -rw-r--r-- 1 root wheel 66248 Jan 24 16:58 termcap.5 -rw-r--r-- 1 root wheel 208361 Jan 24 16:58 termcap.src root@icarus:/usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/stable/9 Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 249650 Node Kind: directory Schedule: normal Last Changed Author: mm Last Changed Rev: 249643 Last Changed Date: 2013-04-19 02:19:10 -0700 (Fri, 19 Apr 2013) And now to try something: root@icarus:/usr/src # cp -pR share/termcap /tmp root@icarus:/usr/src # rm -fr share/termcap root@icarus:/usr/src # svn update Updating '.': Restored 'share/termcap' Restored 'share/termcap/Makefile' Restored 'share/termcap/README' Restored 'share/termcap/termcap.5' Restored 'share/termcap/tck' Restored 'share/termcap/termcap.src' Restored 'share/termcap/reorder' A lib/libpmc/pmc.haswelluc.3 A lib/libpmc/pmc.haswell.3 U lib/libpmc/Makefile U lib/libpmc/libpmc.c U lib/libpmc U sys/dev/hwpmc/pmc_events.h U sys/dev/hwpmc/hwpmc_intel.c U sys/dev/hwpmc/hwpmc_core.c U sys/dev/hwpmc/hwpmc_uncore.c U sys/dev U sys/sys/pmc.h U sys/sys U sys Updated to revision 249658. root@icarus:/usr/src # ls -l /usr/src/share/termcap/ total 288 -rw-r--r-- 1 root wheel 797 Apr 19 13:14 Makefile -rw-r--r-- 1 root wheel 2501 Apr 19 13:14 README -rw-r--r-- 1 root wheel 1533 Apr 19 13:14 reorder -rw-r--r-- 1 root wheel 3531 Apr 19 13:14 tck -rw-r--r-- 1 root wheel 66248 Apr 19 13:14 termcap.5 -rw-r--r-- 1 root wheel 208361 Apr 19 13:14 termcap.src root@icarus:/usr/src # diff -ruN share/termcap /tmp/termcap root@icarus:/usr/src # Are you following a different branch than I am? I'm using stable/9, as shown. The SVN mirror I use is also shown. If you're following stable/9, then something is very much out of whack on your system, or the SVN repo you're using is giving you very strange results. My recommendations: 1. Try a different SVN repo mirror, 2. Remove NFS from the picture entirely; use a local disk instead, at least for testing/figuring this out, 3. Start over fresh. DO NOT just delete individual files or dirs -- there is a "database" SVN uses (just like csup/cvsup!) to try and keep track of what's what. To start over fresh: rm -fr /usr/src /usr/src/.svn svn checkout svn://wherever/base/stable/9 /usr/src Good luck, and I look forward to the results of your investigation. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Apr 20 12:42:31 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 31745D83; Sat, 20 Apr 2013 12:42:31 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4D31BF6; Sat, 20 Apr 2013 12:42:29 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id r3KCTkCP035122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Apr 2013 14:29:47 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id r3KCTih5097139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Apr 2013 14:29:44 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id r3KCTiR6004541; Sat, 20 Apr 2013 14:29:44 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id r3KCTiJi004540; Sat, 20 Apr 2013 14:29:44 +0200 (CEST) (envelope-from ticso) Date: Sat, 20 Apr 2013 14:29:44 +0200 From: Bernd Walter To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130420122944.GD3401@cicely7.cicely.de> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515CAA04.1050108@FreeBSD.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Jeremy Chadwick , Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: ticso@cicely.de List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 12:42:31 -0000 On Thu, Apr 04, 2013 at 12:15:32AM +0200, Matthias Andree wrote: > I have just sent more information to the PR at > http://www.freebsd.org/cgi/query-pr.cgi?pr=157397 > > The short summary (more info in the PR) is: > > - limiting tags to 31 does not help > > - disabling NCQ appears to help in initial testing, but warrants more > testing > > - error happens during WRITE_FPDMA_QUEUED, > > - File system in question is SU+J UFS2 mounted on /usr, and I can for > instance "rm -rf /usr/obj" or just log into GNOME and try to open a > gnome-terminal to trigger stalls; > > - Linux uses 31 tags (for different reason) and has no drive quirks, but > a controller quirk; > > for Jeremy's topic #6, regarding the ATI/AMD SB7x0 that I am using, it > might be worthwhile investigating the AHCI_HFLAG_IGN_SERR_INTERNAL flag > - it gets set by Linux on the SB700 that my computer is using, see > ahci_error_intr() in libahci.h - I am not going to interpret that for > lack of expertise, but it does affect error handling and appears to > ignore a certain condition. > > Why only my Samsung HDD drive triggers this but not the WD drive, I do > not know yet. I have had data corruption with Samsung drive and CAM connected to an onboard intel AHCI. The system was known good running with an older FreeBSD version and was brought back into service for another use case with a fresh installation. Regulary on major filesystem write activity we got random FS corruptions and panics. My assumption was broen NCQ firmware on the drive, but have nothing to proof this assumtion. We switched to old ata driver and lived with this until we replaced the whole machine. Don't know if the machine still exists somewhere. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 20 13:21:45 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B6CE7311 for ; Sat, 20 Apr 2013 13:21:45 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [186.193.48.13]) by mx1.freebsd.org (Postfix) with ESMTP id 400641D34 for ; Sat, 20 Apr 2013 13:21:44 +0000 (UTC) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) by zeus.linuxinfo.com.br (Postfix) with ESMTP id 1F6B3466A45D for ; Sat, 20 Apr 2013 10:19:25 -0300 (BRT) X-Virus-Scanned: amavisd-new at zeus.linuxinfo.com.br Received: from zeus.linuxinfo.com.br ([127.0.0.1]) by zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Auwl-AlEJVrN for ; Sat, 20 Apr 2013 10:19:21 -0300 (BRT) Received: from MacBook-de-Gondim-2.local (unknown [186.193.48.8]) by zeus.linuxinfo.com.br (Postfix) with ESMTPSA id 0A1B2466A458 for ; Sat, 20 Apr 2013 10:19:21 -0300 (BRT) Message-ID: <5172965A.9080600@bsdinfo.com.br> Date: Sat, 20 Apr 2013 10:21:30 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Possible DoS in mpd 5.6 pppoe server Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 13:21:45 -0000 Hi all, I'm doing tests with mpdas pppoeserver. Tried to simulate an attack of 1000 connections using an incorrect login and after a certain time can cause a kernel panic in the system. Below the panicgenerated: http://pastebin.com/nUXGVR3y Other equipment I do: # for (( i=0; i < 1000; i++ )); do ppp -ddial intnet ; done My System: Intel Motherboard Server S5500BC with Dual Processor Xeon(R) CPU E5606 @ 2.13GHz 8Gb ram I do not understand programming in Cor Assembly. But could someone tell me if what happened was a system problem or hardware? Best regards, Gondim From owner-freebsd-stable@FreeBSD.ORG Sat Apr 20 14:48:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CFC21151 for ; Sat, 20 Apr 2013 14:48:41 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by mx1.freebsd.org (Postfix) with ESMTP id B07A11FAA for ; Sat, 20 Apr 2013 14:48:41 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id q11so2739793pdj.25 for ; Sat, 20 Apr 2013 07:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LY+E3tAxvKyher3Swf4KMgE1ZlU8hJzJ9HJ9VJeP5MA=; b=i+kSc4E1uljd/rpSMH8lMMjABNsCH1N5Gf/XYfoqV5QHkraTaO80Afhc00TR7LjIMI 4W+hpLXaQgZwf4enqSe6WqMyxgofrTkvXE32jVOg/G4Y/QAhe1TU0Nt7mKIDwokYmezd Ao7CBZb0XUgtgFT29zcwQ+61cUo4dWpTdotKpNgaE4ARTqslyO3YxLS5VfCE+ZtlUadw vKabZRMtTUK59/bluVNme2p8+LRPPoOR9zHazUh/+P114Z5+PF/2pAZsRryHa38WVnHS xxOobe14yphw2LSeMaWvJMX3yWY7u0xkG+XP5mKk9HZFxG/qm7Xscg8Wamm8Z6pnitDr Cx7Q== MIME-Version: 1.0 X-Received: by 10.68.90.36 with SMTP id bt4mr24121916pbb.42.1366469315075; Sat, 20 Apr 2013 07:48:35 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.70.27.99 with HTTP; Sat, 20 Apr 2013 07:48:35 -0700 (PDT) In-Reply-To: <5172965A.9080600@bsdinfo.com.br> References: <5172965A.9080600@bsdinfo.com.br> Date: Sat, 20 Apr 2013 07:48:35 -0700 X-Google-Sender-Auth: ZMYJcwDdoRNqmGoPBPOpqbFZfmk Message-ID: Subject: Re: Possible DoS in mpd 5.6 pppoe server From: Adrian Chadd To: Marcelo Gondim Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 14:48:41 -0000 Can you provide more information about the configuration of mpd and ppp? the panic is in the dummynet code; can you provide information about your ipfw/dummynet setup? Thanks, adrian On 20 April 2013 06:21, Marcelo Gondim wrote: > Hi all, > > I'm doing tests with mpdas pppoeserver. Tried to simulate an attack of 1000 > connections using an incorrect login and after a certain time can cause a > kernel panic in the system. Below the panicgenerated: > > http://pastebin.com/nUXGVR3y > > Other equipment I do: > > # for (( i=0; i < 1000; i++ )); do ppp -ddial intnet ; done > > My System: > > Intel Motherboard Server S5500BC with Dual Processor Xeon(R) CPU E5606 @ > 2.13GHz > 8Gb ram > > I do not understand programming in Cor Assembly. But could someone tell me > if what happened was a system problem or hardware? > > Best regards, > > Gondim > > _______________________________________________ > 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 Sat Apr 20 16:10:25 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7EF38890 for ; Sat, 20 Apr 2013 16:10:25 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id CBDE7293 for ; Sat, 20 Apr 2013 16:10:24 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r3KGAAGd009818; Sat, 20 Apr 2013 23:10:11 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5172BDDD.4010509@rdtc.ru> Date: Sat, 20 Apr 2013 23:10:05 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Marcelo Gondim Subject: Re: Possible DoS in mpd 5.6 pppoe server References: <5172965A.9080600@bsdinfo.com.br> In-Reply-To: <5172965A.9080600@bsdinfo.com.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 16:10:25 -0000 On 20.04.2013 20:21, Marcelo Gondim wrote: > Hi all, > > I'm doing tests with mpdas pppoeserver. Tried to simulate an attack of > 1000 connections using an incorrect login and after a certain time can > cause a kernel panic in the system. Below the panicgenerated: > > http://pastebin.com/nUXGVR3y You seem to use dummynet and the problem is not in mpd/pppoe code, it's it the dummynet code. Look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/162558 for workarounds. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 20 17:17:24 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 632B5510; Sat, 20 Apr 2013 17:17:24 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [186.193.48.13]) by mx1.freebsd.org (Postfix) with ESMTP id BCAA369A; Sat, 20 Apr 2013 17:17:23 +0000 (UTC) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) by zeus.linuxinfo.com.br (Postfix) with ESMTP id 82215466A45D; Sat, 20 Apr 2013 14:15:09 -0300 (BRT) X-Virus-Scanned: amavisd-new at zeus.linuxinfo.com.br Received: from zeus.linuxinfo.com.br ([127.0.0.1]) by zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9iqb8ch-QCr; Sat, 20 Apr 2013 14:15:06 -0300 (BRT) Received: from MacBook-de-Gondim-2.local (unknown [186.193.54.69]) by zeus.linuxinfo.com.br (Postfix) with ESMTPSA id 17E0F466A458; Sat, 20 Apr 2013 14:15:00 -0300 (BRT) Message-ID: <5172CD95.2080904@bsdinfo.com.br> Date: Sat, 20 Apr 2013 14:17:09 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Possible DoS in mpd 5.6 pppoe server References: <5172965A.9080600@bsdinfo.com.br> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 17:17:24 -0000 Hi Adrian, Thanks for your help. :) My mpd.conf: ============ startup: # configure mpd users #set user foo bar admin set user suporte papatango set user admin tutumineiro admin # configure the console set console self 192.168.8.34 5005 set console open # configure the web server set web self 0.0.0.0 5006 set web open default: load pppoe_server pppoe_server: create bundle template B set iface disable proxy-arp set iface enable tcpmssfix set ipcp dns 8.8.8.8 8.8.4.4 #set ipcp enable vjcomp set iface up-script /usr/local/etc/mpd5/addclient.sh set iface down-script /usr/local/etc/mpd5/removeclient.sh set ippool add pool1 10.10.0.1 10.10.255.254 set ipcp ranges 10.51.0.1/32 ippool pool1 create link template common pppoe #set link enable multilink set link action bundle B set link disable chap pap eap set link mtu 1492 set link mru 1492 set link enable pap load radius create link template igb1 common set pppoe iface igb1 set pppoe acname "IntBSD1" set pppoe service "*" set link enable incoming set auth max-logins 1 set link max-children 5000 create link template igb2 common set pppoe iface igb2 set pppoe acname "IntBSD2" set pppoe service "*" set link enable incoming set auth max-logins 1 set link max-children 5000 create link template igb3 common set pppoe iface igb3 set pppoe acname "IntBSD3" set pppoe service "*" set link enable incoming set auth max-logins 1 set link max-children 5000 radius: set radius server localhost xuxupedra 1812 1813 set radius retries 3 set radius timeout 3 # send the given IP in the RAD_NAS_IP_ADDRESS attribute to the server. set radius me 127.0.0.1 # send accounting updates every 5 minutes set auth acct-update 300 # enable RADIUS, and fallback to mpd.secret, if RADIUS auth failed set auth enable radius-auth # enable RADIUS accounting set auth enable radius-acct # protect our requests with the message-authenticator set radius enable message-authentic My ppp.conf: intnet: set device PPPoE:re0 set mru 1492 set mtu 1492 set authname hercilia201254 set authkey 12345 set login set dial enable dns add default HISADDR set timeout 0 open The test server is off now, but I'll get ipfw and dummynet settings in the Companyand post it here. Em 20/04/13 11:48, Adrian Chadd escreveu: > Can you provide more information about the configuration of mpd and ppp? > > the panic is in the dummynet code; can you provide information about > your ipfw/dummynet setup? > > Thanks, > > > > adrian > > > On 20 April 2013 06:21, Marcelo Gondim wrote: >> Hi all, >> >> I'm doing tests with mpdas pppoeserver. Tried to simulate an attack of 1000 >> connections using an incorrect login and after a certain time can cause a >> kernel panic in the system. Below the panicgenerated: >> >> http://pastebin.com/nUXGVR3y >> >> Other equipment I do: >> >> # for (( i=0; i < 1000; i++ )); do ppp -ddial intnet ; done >> >> My System: >> >> Intel Motherboard Server S5500BC with Dual Processor Xeon(R) CPU E5606 @ >> 2.13GHz >> 8Gb ram >> >> I do not understand programming in Cor Assembly. But could someone tell me >> if what happened was a system problem or hardware? >> >> Best regards, >> >> Gondim >> >> _______________________________________________ >> 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 Sat Apr 20 17:26:14 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D8B147C4 for ; Sat, 20 Apr 2013 17:26:14 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [186.193.48.13]) by mx1.freebsd.org (Postfix) with ESMTP id 99C3674E for ; Sat, 20 Apr 2013 17:26:14 +0000 (UTC) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) by zeus.linuxinfo.com.br (Postfix) with ESMTP id 1E2EB466A45D for ; Sat, 20 Apr 2013 14:24:03 -0300 (BRT) X-Virus-Scanned: amavisd-new at zeus.linuxinfo.com.br Received: from zeus.linuxinfo.com.br ([127.0.0.1]) by zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htYSgAnDcxCU for ; Sat, 20 Apr 2013 14:24:00 -0300 (BRT) Received: from MacBook-de-Gondim-2.local (unknown [186.193.54.69]) by zeus.linuxinfo.com.br (Postfix) with ESMTPSA id 8561A466A458 for ; Sat, 20 Apr 2013 14:24:00 -0300 (BRT) Message-ID: <5172CFB2.3010708@bsdinfo.com.br> Date: Sat, 20 Apr 2013 14:26:10 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Possible DoS in mpd 5.6 pppoe server References: <5172965A.9080600@bsdinfo.com.br> <5172BDDD.4010509@rdtc.ru> In-Reply-To: <5172BDDD.4010509@rdtc.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 17:26:14 -0000 Em 20/04/13 13:10, Eugene Grosbein escreveu: > On 20.04.2013 20:21, Marcelo Gondim wrote: >> Hi all, >> >> I'm doing tests with mpdas pppoeserver. Tried to simulate an attack of >> 1000 connections using an incorrect login and after a certain time can >> cause a kernel panic in the system. Below the panicgenerated: >> >> http://pastebin.com/nUXGVR3y > You seem to use dummynet and the problem is not in mpd/pppoe code, > it's it the dummynet code. Look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/162558 > for workarounds. Ok :) I will try this: - net.isr.bindthreads=1 in /boot/loader.conf; - net.isr.direct=1 and net.isr.direct_force=1 in /etc/sysctl.conf From owner-freebsd-stable@FreeBSD.ORG Sat Apr 20 17:33:16 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5DC23A50 for ; Sat, 20 Apr 2013 17:33:16 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id AC04D797 for ; Sat, 20 Apr 2013 17:33:15 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.6/8.14.6) with ESMTP id r3KHX6Eg043713; Sun, 21 Apr 2013 00:33:07 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <5172D14D.8040009@rdtc.ru> Date: Sun, 21 Apr 2013 00:33:01 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Marcelo Gondim Subject: Re: Possible DoS in mpd 5.6 pppoe server References: <5172965A.9080600@bsdinfo.com.br> <5172BDDD.4010509@rdtc.ru> <5172CFB2.3010708@bsdinfo.com.br> In-Reply-To: <5172CFB2.3010708@bsdinfo.com.br> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 17:33:16 -0000 On 21.04.2013 00:26, Marcelo Gondim wrote: >> You seem to use dummynet and the problem is not in mpd/pppoe code, >> it's it the dummynet code. Look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/162558 >> for workarounds. > Ok :) I will try this: > > - net.isr.bindthreads=1 in /boot/loader.conf; > - net.isr.direct=1 and net.isr.direct_force=1 in /etc/sysctl.conf For 9.x and newer, net.isr.XXX knobs names have changed but defaults are fine - if you have not messed them, you should be OK. From owner-freebsd-stable@FreeBSD.ORG Sat Apr 20 17:52:36 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 66E76105; Sat, 20 Apr 2013 17:52:36 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [186.193.48.13]) by mx1.freebsd.org (Postfix) with ESMTP id E5B51830; Sat, 20 Apr 2013 17:52:35 +0000 (UTC) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) by zeus.linuxinfo.com.br (Postfix) with ESMTP id 72108466A45D; Sat, 20 Apr 2013 14:50:24 -0300 (BRT) X-Virus-Scanned: amavisd-new at zeus.linuxinfo.com.br Received: from zeus.linuxinfo.com.br ([127.0.0.1]) by zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSP-WPumZzcK; Sat, 20 Apr 2013 14:50:21 -0300 (BRT) Received: from MacBook-de-Gondim-2.local (unknown [186.193.54.69]) by zeus.linuxinfo.com.br (Postfix) with ESMTPSA id 51555466A458; Sat, 20 Apr 2013 14:50:20 -0300 (BRT) Message-ID: <5172D5DE.2060109@bsdinfo.com.br> Date: Sat, 20 Apr 2013 14:52:30 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Possible DoS in mpd 5.6 pppoe server References: <5172965A.9080600@bsdinfo.com.br> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 17:52:36 -0000 Hi, My ipfw rules, pf rules and dummynet: fw="/sbin/ipfw" ext_if="igb0" $fw disable one_pass $fw -f flush $fw zero $fw table all flush $fw -f pipe flush ssh_port="4321" $fw add allow all from any to any via lo0 $fw add deny all from 127.0.0.0/8 to any $fw add deny all from any to 127.0.0.0/8 $fw add check-state # velocidade de 1024kbps $fw add pipe 1 ip from "table(10)" to any in via ng* $fw add pipe 2 ip from any to "table(10)" out via ng* $fw pipe 1 config bw 1024Kbit/s queue 128 mask src-ip 255.255.255.255 $fw pipe 2 config bw 1024Kbit/s queue 128 mask dst-ip 255.255.255.255 # velocidade de 2048kbps $fw add pipe 3 ip from "table(11)" to any in via ng* $fw add pipe 4 ip from any to "table(11)" out via ng* $fw pipe 3 config bw 2048Kbit/s queue 256 mask src-ip 255.255.255.255 $fw pipe 4 config bw 2048Kbit/s queue 256 mask dst-ip 255.255.255.255 # velocidade de 10240kbps $fw add pipe 5 ip from "table(12)" to any in via ng* $fw add pipe 6 ip from any to "table(12)" out via ng* $fw pipe 5 config bw 10240Kbit/s queue 1280 mask src-ip 255.255.255.255 $fw pipe 6 config bw 10240Kbit/s queue 1280 mask dst-ip 255.255.255.255 # velocidade de 64kbps $fw add pipe 7 ip from "table(13)" to any in via ng* $fw add pipe 8 ip from any to "table(13)" out via ng* $fw pipe 7 config bw 64Kbit/s queue 8 mask src-ip 255.255.255.255 $fw pipe 8 config bw 64Kbit/s queue 8 mask dst-ip 255.255.255.255 $fw add allow icmp from any to any icmptypes 0,3,8,11,12 $fw add deny icmp from any to any PF Rules: ======= ext_if = "igb0" table persist { 10.0.0.0/8 } set skip on lo0 set limit states 40000 nat on $ext_if from to any -> 192.168.8.34 Em 20/04/13 11:48, Adrian Chadd escreveu: > Can you provide more information about the configuration of mpd and ppp? > > the panic is in the dummynet code; can you provide information about > your ipfw/dummynet setup? > > Thanks, > > > > adrian > > > On 20 April 2013 06:21, Marcelo Gondim wrote: >> Hi all, >> >> I'm doing tests with mpdas pppoeserver. Tried to simulate an attack of 1000 >> connections using an incorrect login and after a certain time can cause a >> kernel panic in the system. Below the panicgenerated: >> >> http://pastebin.com/nUXGVR3y >> >> Other equipment I do: >> >> # for (( i=0; i < 1000; i++ )); do ppp -ddial intnet ; done >> >> My System: >> >> Intel Motherboard Server S5500BC with Dual Processor Xeon(R) CPU E5606 @ >> 2.13GHz >> 8Gb ram >> >> I do not understand programming in Cor Assembly. But could someone tell me >> if what happened was a system problem or hardware? >> >> Best regards, >> >> Gondim >> >> _______________________________________________ >> 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 Sat Apr 20 18:16:05 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 96120809 for ; Sat, 20 Apr 2013 18:16:05 +0000 (UTC) (envelope-from SRS0=sh+W3Dm7=OH=beatsnet.com=beat.siegenthaler@beatsnet.com) Received: from vulcan.beatsnet.com (vulcan.beatsnet.com [IPv6:2001:470:1f0b:102::bea1]) by mx1.freebsd.org (Postfix) with ESMTP id 16670923 for ; Sat, 20 Apr 2013 18:16:04 +0000 (UTC) Received: from mbp-wl.beatsnet.com ([IPv6:2001:1620:f14:0:9144:ac4f:1918:ea]) (authenticated bits=0) by vulcan.beatsnet.com (8.14.5/8.14.5) with ESMTP id r3KIFl8s055604 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK) for ; Sat, 20 Apr 2013 20:15:58 +0200 (CEST) (envelope-from beat.siegenthaler@beatsnet.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=beatsnet.com; s=VULCAN_DKIM; t=1366481762; bh=ulA3qqqfbqJJsUv0K0ClKXQ0es8OVmxKcRKIcFvA/8o=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ieaYkxlcz4M/lDmerKf5mJ0zjH4eGxzWD8DkuG84Ia1yJtDUJL8rir6k50ZtaCz6N 38KTT8g9vsD0818CurqiwPCyG3kbdvwGqmXT41n6DqF3T42ks+OQBr+sRipKlwyVc5 UTh62k24dVsF0mUo9I7ugTODOAT9gux6Tk1hvFuc= Message-ID: <5172DB52.4060008@beatsnet.com> Date: Sat, 20 Apr 2013 20:15:46 +0200 From: Beat Siegenthaler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Unable to get sendmail submission port to listen on IPv6 References: <51713C5C.9070009@beatsnet.com> <20130419140011.GA87089@icarus.home.lan> In-Reply-To: <20130419140011.GA87089@icarus.home.lan> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (vulcan.beatsnet.com [IPv6:2001:470:1f0b:102::bea1]); Sat, 20 Apr 2013 20:15:58 +0200 (CEST) X-Virus-Scanned: clamav-milter 0.97.7 at vulcan.beatsnet.com X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 18:16:05 -0000 On 19.04.13 16:00, Jeremy Chadwick wrote: >> Hi all, >> >> I did not recognize that 587 is only listening onIy on IPv4. Maybe it's >> new, maybe it was alltime so. >> >> sendmail 25090 root 4u IPv4 0xfffffe01e810f3d0 0t0 TCP *:25 (LISTEN) >> sendmail 25090 root 5u IPv6 0xfffffe01a988f000 0t0 TCP *:25 (LISTEN) >> sendmail 25090 root 6u IPv4 0xfffffe011c53d000 0t0 TCP *:587 (LISTEN) >> Still no luck... >> >> Multiple things: >> >> 1. The files that "control" sendmail are `hostname`.mc and >> `hostname`.submit.mc. The freebsd.mc and freebsd.submit.mc are "stock" >> examples. >> >> I assume you're already familiar with the need to run "make" in >> /etc/mail. Of course. Yes. > > 2. `hostname`.mc controls options/features for the daemon -- i.e. the > thing that is listening on TCP ports. `hostname`.submit.mc is for > outbound mail. You're wanting sendmail to listen on TCP port 587, which > is what's used by SMTP clients (ex. Eudora, Thunderbird, etc.) trying to > send mail to sendmail (rather than the classic model/method of using > port 25). Yes, You are right. I was confused, about "`hostname`.submit.mc" and port 587 named "submission" in /etc/services > > 3. What you need to add is here: > > http://lists.freebsd.org/pipermail/freebsd-questions/2004-March/040006.html I tried this and many other things, believe me. Result is always the same. (Many Providers block 25 for residential networks nowadays) And I hate it when i have delays caused by ports not listening on IPv6. Did somebody managed to have 587 listening v6? with 9-STABLE Kind regards, Beat From owner-freebsd-stable@FreeBSD.ORG Sat Apr 20 19:01:20 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8CACE3C3 for ; Sat, 20 Apr 2013 19:01:20 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 481F7A6E for ; Sat, 20 Apr 2013 19:01:20 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:7258:12ff:fe22:d94b]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.6/8.14.6) with ESMTP/inet6 id r3KJ0eGp073345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 21 Apr 2013 04:00:45 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 21 Apr 2013 04:00:42 +0900 Message-ID: From: Hajimu UMEMOTO To: Beat Siegenthaler Subject: Re: Unable to get sendmail submission port to listen on IPv6 In-Reply-To: <5172DB52.4060008@beatsnet.com> References: <51713C5C.9070009@beatsnet.com> <20130419140011.GA87089@icarus.home.lan> <5172DB52.4060008@beatsnet.com> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/24.3 (i386-portbld-freebsd9.1) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 9.1-STABLE X-PGP-Key: http://www.mahoroba.org/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 21 Apr 2013 04:00:46 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.7 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-5.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on asuka.mahoroba.org Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 19:01:20 -0000 Hi, >>>>> On Sat, 20 Apr 2013 20:15:46 +0200 >>>>> Beat Siegenthaler said: beat.siegenthaler> Did somebody managed to have 587 listening v6? with 9-STABLE Yes, it's working fine on my 9-STABLE box. % sockstat | grep sendmail smmsp sendmail 18673 3 dgram -> /var/run/log root sendmail 3081 3 dgram -> /var/run/logpriv root sendmail 3081 4 tcp4 *:25 *:* root sendmail 3081 5 tcp6 *:25 *:* root sendmail 3081 6 tcp4 *:587 *:* root sendmail 3081 7 tcp6 *:587 *:* You need the following lines in your `hostname`.mc: FEATURE(`no_default_msa')dnl DAEMON_OPTIONS(`Name=IPv4, Family=inet')dnl DAEMON_OPTIONS(`Name=IPv6, Family=inet6')dnl DAEMON_OPTIONS(`Port=587, Name=MSA-IPv4, M=Ea, Family=inet')dnl DAEMON_OPTIONS(`Port=587, Name=MSA-IPv6, M=Ea, Family=inet6')dnl Sincerely, -- Hajimu UMEMOTO ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.mahoroba.org/~ume/ From owner-freebsd-stable@FreeBSD.ORG Sat Apr 20 19:13:51 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 551E06D7 for ; Sat, 20 Apr 2013 19:13:51 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp6.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3cd3:cd67:fafa:3d78]) by mx1.freebsd.org (Postfix) with ESMTP id B996AAF6 for ; Sat, 20 Apr 2013 19:13:50 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.2.117.99]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.6/8.14.6) with ESMTP id r3KJDbBQ054856 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 20 Apr 2013 20:13:43 +0100 (BST) (envelope-from matthew@FreeBSD.org) DKIM-Filter: OpenDKIM Filter v2.8.2 smtp.infracaninophile.co.uk r3KJDbBQ054856 Authentication-Results: smtp.infracaninophile.co.uk/r3KJDbBQ054856; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy) Message-ID: <5172E8DA.5000503@FreeBSD.org> Date: Sat, 20 Apr 2013 20:13:30 +0100 From: Matthew Seaman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Unable to get sendmail submission port to listen on IPv6 References: <51713C5C.9070009@beatsnet.com> <20130419140011.GA87089@icarus.home.lan> <5172DB52.4060008@beatsnet.com> In-Reply-To: <5172DB52.4060008@beatsnet.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2LVBBQMLTUWBWBILLBUMW" X-Virus-Scanned: clamav-milter 0.97.7 at lucid-nonsense.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lucid-nonsense.infracaninophile.co.uk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 19:13:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2LVBBQMLTUWBWBILLBUMW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20/04/2013 19:15, Beat Siegenthaler wrote: > On 19.04.13 16:00, Jeremy Chadwick wrote: >>> Hi all, >>> >>> I did not recognize that 587 is only listening onIy on IPv4. Maybe it= 's >>> new, maybe it was alltime so. >>> >>> sendmail 25090 root 4u IPv4 0xfffffe01e810f3d0 0t0 TCP *:25 (LI= STEN) >>> sendmail 25090 root 5u IPv6 0xfffffe01a988f000 0t0 TCP *:25 (LI= STEN) >>> sendmail 25090 root 6u IPv4 0xfffffe011c53d000 0t0 TCP *:587 (L= ISTEN) >>> > Still no luck... >>> >>> Multiple things: >>> >>> 1. The files that "control" sendmail are `hostname`.mc and >>> `hostname`.submit.mc. The freebsd.mc and freebsd.submit.mc are "stoc= k" >>> examples. >>> >>> I assume you're already familiar with the need to run "make" in >>> /etc/mail. > Of course. Yes. >> >> 2. `hostname`.mc controls options/features for the daemon -- i.e. the >> thing that is listening on TCP ports. `hostname`.submit.mc is for >> outbound mail. You're wanting sendmail to listen on TCP port 587, whi= ch >> is what's used by SMTP clients (ex. Eudora, Thunderbird, etc.) trying = to >> send mail to sendmail (rather than the classic model/method of using >> port 25). > Yes, You are right. I was confused, about "`hostname`.submit.mc" and > port 587 named "submission" in /etc/services >> >> 3. What you need to add is here: >> >> http://lists.freebsd.org/pipermail/freebsd-questions/2004-March/040006= =2Ehtml > I tried this and many other things, believe me. Result is always the sa= me. > (Many Providers block 25 for residential networks nowadays) > And I hate it when i have delays caused by ports not listening on IPv6.= > Did somebody managed to have 587 listening v6? with 9-STABLE >=20 Sure. lucid-nonsense:/home/matthew:# sockstat | grep sendmail smmsp sendmail 2737 3 dgram -> /var/run/log root sendmail 2735 3 dgram -> /var/run/logpriv root sendmail 2735 4 tcp6 2001:8b0:151:1:54f9:9484:e8b0:12d1:25 *:* smmsp sendmail 2453 3 dgram -> /var/run/log root sendmail 2450 3 tcp4 127.0.0.1:25 *:* root sendmail 2450 4 dgram -> /var/run/logpriv root sendmail 2450 5 tcp4 81.2.117.97:25 *:* root sendmail 2450 6 tcp6 2001:8b0:151:1:3cd3:cd67:fafa:3d78:25 *:* root sendmail 2450 7 tcp6 ::1:25 *:* root sendmail 2450 8 tcp4 127.0.0.1:587 *:* root sendmail 2450 9 tcp4 81.2.117.97:587 *:* root sendmail 2450 10 tcp6 2001:8b0:151:1:3cd3:cd67:fafa:3d78:587 *:* root sendmail 2450 11 tcp6 ::1:587 *:* The only change I made to the ${HOSTNAME}.submit.mc was to tell it to listen on ::1 -- the last two lines look like this: dnl If you use IPv6 only, change [127.0.0.1] to [IPv6:::1] FEATURE(`msp', `[IPv6:::1]', `MSA')dnl For ${HOSTNAME}.mc, you need at least the following to have the sendmail daemon listen on the specified addresses (IPv4 and IPv6): FEATURE(no_default_msa)dnl ## overridden with DAEMON_OPTIONS below [...] dnl dnl Where the sendmail daemon should talk dnl CLIENT_OPTIONS(`Name=3DIPv4, Addr=3D127.0.0.1, Family=3Dinet')dnl CLIENT_OPTIONS(`Name=3DIPv4, Addr=3D81.2.117.97, Family=3Dinet')dnl CLIENT_OPTIONS(`Name=3DIPv6, Addr=3D::1, Family=3Dinet6')dnl CLIENT_OPTIONS(`Name=3DIPv6, Addr=3D2001:8b0:151:1:3cd3:cd67:fafa:3d78, Family=3Dinet6')dnl dnl dnl Where the sendmail daemon should listen dnl DAEMON_OPTIONS(`Name=3DIPv4, Addr=3D127.0.0.1, M=3DA, Family=3Dinet')dnl DAEMON_OPTIONS(`Name=3DIPv4, Addr=3D81.2.117.97, M=3DA, Family=3Dinet')dn= l DAEMON_OPTIONS(`Name=3DIPv6, Addr=3D2001:8b0:151:1:3cd3:cd67:fafa:3d78, M= =3DA, Family=3Dinet6')dnl DAEMON_OPTIONS(`Name=3DIPv6, Addr=3D::1, M=3DA, Family=3Dinet6')dnl DAEMON_OPTIONS(`Name=3DMSA, Addr=3D127.0.0.1, Port=3D587, M=3DE')dnl DAEMON_OPTIONS(`Name=3DMSA, Addr=3D81.2.117.97, Port=3D587, M=3DEa')dnl DAEMON_OPTIONS(`Name=3DMSA, Addr=3D2001:8b0:151:1:3cd3:cd67:fafa:3d78, Port=3D587, M=3DEa, Family=3Dinet6')dnl DAEMON_OPTIONS(`Name=3DMSA, Addr=3D::1, Port=3D587, M=3DE, Family=3Dinet6= ')dnl Pay attention to the M=3D... flags in the above: they control whether authentication is required and whether an authenticated connection can relay through the server. You'll almost certainly want to enable SASL for providing login and probably TLS to prevent snooping of passwords on the wire. SASL provides alternatives, but STARTTLS followed by LOGIN works for me. Matthew --=20 Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey ------enig2LVBBQMLTUWBWBILLBUMW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFy6OEACgkQ8Mjk52CukIx8gQCfXpe48nXy4udQkzLrrAaEdv2v Rs8AoIssVLH82Z69xSrSDXxSK+nHr6RV =PSN6 -----END PGP SIGNATURE----- ------enig2LVBBQMLTUWBWBILLBUMW-- From owner-freebsd-stable@FreeBSD.ORG Sat Apr 20 21:29:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F3AEC3B for ; Sat, 20 Apr 2013 21:29:59 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:16]) by mx1.freebsd.org (Postfix) with ESMTP id 4FBEEF5C for ; Sat, 20 Apr 2013 21:29:59 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta01.emeryville.ca.mail.comcast.net with comcast id SMA71l0061vN32cA1MVz8s; Sat, 20 Apr 2013 21:29:59 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta22.emeryville.ca.mail.comcast.net with comcast id SMVy1l00D1t3BNj8iMVyl1; Sat, 20 Apr 2013 21:29:58 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 04DF773A33; Sat, 20 Apr 2013 14:29:58 -0700 (PDT) Date: Sat, 20 Apr 2013 14:29:58 -0700 From: Jeremy Chadwick To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? Message-ID: <20130420212957.GA19158@icarus.home.lan> References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> <20130403233815.GA65719@icarus.home.lan> <515CC704.90302@FreeBSD.org> <20130404010526.GA66858@icarus.home.lan> <515D3312.3010109@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515D3312.3010109@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366493399; bh=CwqtmSuUoQhEabOXV8j+PTjvQvi/2D3CiVf10Y9epcY=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=kPwYv+2g6KOY3Z+mj2yqMrXjYr2YmkXHyZ0k7uSaL6pyDzTDxEXoR+bzGK0SrA2PI rUh/UrSsMEnWQb3KquAFFzgbrGgR3TZSexY92MGRT/0BMVQmpRle1LDwPq+02XuODa jJPsRX2SNSJH5uw2KQvqMUMTIo8ksIdY00qCBXjoe8cPfj3gylcDh5LNnSqDa0n4/e 1yugZq2w52MlvRuhixME3TbGzkuLX/NhEesBk/BGFxDHnfIow+siariLdOyFPcFgk+ U0ypSVybVG7qCuhB5X+NemGvyHASRYwwqkVwplJ1H62Cq1o3Ik7bvqnCfM+tTfyaAF HxqnFTaJcjyyQ== Cc: Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 21:29:59 -0000 On Thu, Apr 04, 2013 at 10:00:18AM +0200, Matthias Andree wrote: > Am 04.04.2013 03:05, schrieb Jeremy Chadwick: > > { snipping stuff I have no comment on. reference thread: } > { > http://lists.freebsd.org/pipermail/freebsd-stable/2013-April/073036.html } > > > One piece of evidence that refutes my theory is that if Windows and/or > > Linux partition are something you boot into and use often, I would > > imagine NCQ would be used in both of those environments and would suffer > > from the same issue. Although Windows tends to hide all sorts of > > transient errors from the user (sigh), Linux tends to be like FreeBSD > > with regards to such issues (on the console anyway; you wouldn't see > > such messages normally inside of X). > > Now, the FreeBSD slice is the only partition on that disk that would > likely see concurrent write accesses (think "make -j8" on a quadcore > computer) which is more prone to ferret out such alignment contention. > > The NTFS partition is aligned on a multi-MB boundary, so wouldn't hit > the problem anyways. > > The Linux partition is in ext4 format for mostly sequential access to > files usually in excess of 10 MB each. > > Linux's ext4 jumps through several hoops to end up with bulk writes, > like extents, delayed allocations (to avoid fragmentation), reordering > of data and metadata writes, serialized log writes and all that stuff, > and it would appear I am permitting it to cache writes -- Linux uses > write barriers to enforce proper ordering of journal/meta-data writes. > > It would be rather hard to hit ATA taskfile timeouts, the expected rate > with which the drive needs to do a partial write is orders of magnitude > lower. > > Any good "concurrent write" exercise tools for Unix that I could run on > the Linux ext4 partition that you would propose? The only tool I'm familiar with is bonnie++. But I don't think this (partition alignment) is what matters now. Your smartctl output has shed some light on your situation. > >> - I am running with kern.cam.ada.default_timeout=5 which makes the > >> computer recover faster > > > > I can definitely imagine cases where a drive using NCQ but doing writes > > to a non-aligned partition could take longer than 5 seconds to respond > > to an ATA CDB (this is different than a SATA or AHCI layer timeout). I am > > not telling you "change this back to 30", but it might not be helping > > your situation at all given my above theory. > > My feeling is that the stalls are mostly from the error handler and the > overall time the drive is "frozen" gets shorter. If it had not _felt_ > faster, I'd not have left that in sysctl.conf in the first place. Your understanding of what that sysctl does is wrong, or I'm misunderstanding what you're saying (very possible!). How I interpret what you're saying: that the sysctl somehow "decreases stall times" during I/O operations that fail. This is incorrect. What that sysctl does is define the number of seconds that transpire ***before*** the CAM layer says "Okay, I didn't get a response to the ATA CDB I sent the disk", and then re-submits the same CDB to the disk. Rephrased: in the case of a disk stalling on an I/O request, you will experience the effects of that stall no matter what that sysctl is set to. A lower value in that sysctl will result in CAM spitting out nasties on the console + hitting the CDB retry submission scenario sooner, which if the drive is awake/responsive by that time will go smoothly. That's all it does. Thus a value of 5 indicates a device/drive did not respond to a CDB within 5 seconds, and a value of 30 indicates a device/drive did not respond to a CDB within 30 seconds. Regardless, those lengths of time are VERY long for an I/O operation on a mechanical HDD. When you get to the bottom of my Email, you'll understand why I screamed at you about adjusting that sysctl. > > Finally: could you please provide output from "smartctl -x /dev/ada1"? > > I would like to rule out any possibility of your drive having some other > > kind of issue that might cause it to go catatonic. Thanks. > > I have fetched the data with Linux this time (should not make a > difference as it's all drive internal data, not host OS stuff). > > Looks sane to me, . > I'll be happy to refetch this data with a more current smartctl version > under FreeBSD if required. Oh look, it's the Samsung SpinPoint series, especially the EcoGreen ("EG") series. No joke: ~60% of the "problem reports" I deal with when it comes to "weird wonky problems" stem from this drive series. I have no idea why, but they're a common pain point for me. First, about the shown sector size: smartmontools 5.41 was the first release to show the sector sizes per ATA IDENTIFY. I assume they got this right from the get-go. So as of this moment I'm going to assume that this drive really is a 512-byte sector drive. Politely, your analysis of the drive ("looks sane to me") is an indicator of why SMART output needs to be interpreted by a person who is familiar with the information. That drive *does not* look sane to me. :-) The first thing that comes to my attention is attribute 199, indicating that the drive has experienced a total of 14 CRC errors during its lifetime (10779 hours as of that moment). Usually this attribute is zeroed at the factory (other attributes are often not). Just yesterday I wrote a very long/detailed analysis about what this attribute means, so I'll just link you to that post. Please focus on just the part about CRC errors: http://www.dslreports.com/forum/r28219261- The next thing I see are 14 errors in your SMART error log. It's worth noting that this number correlates with the CRC error count above (though depending on drive firmware they may not have a symbiotic relationship). Your SMART error log consists of entries indicating the drive itself sent back error conditions to the controller/OS (which FreeBSD or Linux would show on the console). The timestamps of these events are based on power-on hour count, so the most recent event was at 7747 hours, but there are others going back all the way to 6528 hours. Sadly, the SMART error log is very small (2 sectors / 1024 bytes), so only the last 8 errors can be shown. Key points about these errors: - The LBAs being accessed varies/is all over the board, indicating that it's very unlikely this anomaly is being caused by physical defects on the platters (the drive also shows no remapped LBAs or pending/suspect LBAs, which further supports that theory), - The ATA commands which lead up to the error also vary. Many are for write requests, and from some entries I can see that the OS was doing NCQ writes (WRITE FPDMA QUEUED) and then suddenly decided to do a classic 28-bit LBA write (WRITE DMA). I'm not sure why an OS would do this (there's nothing optimal about it) unless there were conditions occurring where the OS/ATA driver said "this NCQ write isn't working (timeout, etc.), let me retry with a classic 28-bit LBA write". There is one entry (the last) which shows a similar situation happening but with NCQ reads. - These are conditions that short, long, select (LBA range scan), and conveyance SMART tests would probably not detect. Like I said: it seems to be all over the board. This is not the first time I have seen this behaviour with SpinPoint drives. Bernd Walter responded indicating that his experience indicated that the issue related to NCQ compatibility. This would not surprise me. NCQ incompatibilities have happened in the past; the most notable (to me) was between Maxtor drives and nVidia SATA controllers. Both companies blamed the other, yet both came out with "fixes" (Maxtor with a firmware update, nVidia with a driver update). Neither company stated anything concrete/useful publicly (oh America, so stock-focused you are). My personal opinion is that the bug was in Maxtor's firmware, and nVidia ceased use of NCQ requests to drives matching specific model numbers (similar to what we do in FreeBSD, re: 4KB quirks). What doesn't help is that SpinPoint drives have a history of pretty awful firmware bugs, such as this one, which still blows my mind to this day: http://sourceforge.net/apps/trac/smartmontools/wiki/SamsungF4EGBadBlocks Your drive is using firmware version 1AG01118, but I can't easily find a newer firmware because of the whole Seagate/Samsung buyout (Seagate buying out Samsung's MHDD division). Because of the "random" nature of this issue, my opinion is that what you're experiencing is caused by one of the following: - The "EG" series are known to park their heads excessively, and much to my annoyance, do not track this behaviour in SMART (normally it's tracked in attribute 193, which the drive lacks (probably intentionally)). This head-parking nonsense is known to cause problems in certain situations, reported by the OS as timeouts and I/O errors as the drive is trying to wake up and respond to the CDB. There are many drives on the markets that do this now, and I generally boycott them all (it's only useful for laptops). I can talk at length about that some other time, or you can find/read my blog (I wrote an article about the WD30EFRX doing this -- at least on WD drives you can inhibit the behaviour, while on Seagate you can't). I noticed that SMART attribute 3 on your drive indicates it takes roughly 6.2 seconds to spin up. This may change over time as well (often getting worse as the drive gets older (spindle motors do wear down over time)). Now take into consideration the sysctl you changed, and what I said earlier about me knowing some conditions where a drive may take >5 seconds to handle certain I/O ops. - NCQ bugs in the drive's firmware. You can try to talk to Samsung about this, but you'll probably get no where due to how deep within companies actual engineers live. My suggestions to you at this point in time: - Remove the sysctl and leave it at its default (30 seconds). Or if you really must adjust it, set it to 15. YMMV with this. - Replace the drive and/or choose another drive vendor. My suggestions for FreeBSD at this time: - Regardless of what the root cause of the above is, we really do need a no-NCQ quirk, and we also need to print the quirks used (in a similar fashion to how CPU features are shown) during boot. I can try to write the code for this, but I am going to need help. Kernel land is not something I'm generally good at. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Apr 20 21:56:02 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 136851BB; Sat, 20 Apr 2013 21:56:02 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [IPv6:2a01:348:0:15:5d59:5c40:0:1]) by mx1.freebsd.org (Postfix) with ESMTP id C7E5E100F; Sat, 20 Apr 2013 21:56:01 +0000 (UTC) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id F1547E66B9; Sat, 20 Apr 2013 23:03:28 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=mail; bh=myoFeo613IMy PAw4h8WuPp+Iyz0=; b=siGBW8JHM5SPwVjSmLA9yKJ/m+WQYJwbppNXq4gIKxU1 o73egMURhgiQ24O7FpoG2YHwv4CMK/UkQQuGxoTJ9tIX8ob7vHux2QzbUp0G/Uao M8ZOxqU3UYAOhfUFQT43RgfRjefwLfZ8iH7bUY+jRPsZ4ep1YOCFbdLzHHIne2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=cran.org.uk; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=mail; b=BnbgfL g0uV8j7kYs6mCyW3bj9Z2NvlMUMD+KJO668I3NClnMB3CjhmttJl5sWkTBpFrPr/ 6SzKKVL4f+FI5hVYzd1sZ0CgKs8qzgQyvAzk9mepp2izzMeYSW2pJIK5fLxkCzXj iLTXWd26++3hETX6+8KAYQxwYdiIBpETLTY9g= Received: from mb.local (unknown [93.89.81.205]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 68765E66B3; Sat, 20 Apr 2013 23:03:28 +0100 (BST) Message-ID: <51730EE7.8060301@cran.org.uk> Date: Sat, 20 Apr 2013 22:55:51 +0100 From: Bruce Cran User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Matthias Andree Subject: Re: Any objections/comments on axing out old ATA stack? References: <51536306.5030907@FreeBSD.org> <20130331130409.GO3178@equilibrium.bsdes.net> <515B25D8.7050902@FreeBSD.org> <515BF5AE.4050804@FreeBSD.org> <515CAA04.1050108@FreeBSD.org> <20130403233815.GA65719@icarus.home.lan> <515CC704.90302@FreeBSD.org> <20130404010526.GA66858@icarus.home.lan> <515D3312.3010109@FreeBSD.org> In-Reply-To: <515D3312.3010109@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jeremy Chadwick , Alexander Motin , freebsd-current@freebsd.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 21:56:02 -0000 On 04/04/2013 09:00, Matthias Andree wrote: > Any good "concurrent write" exercise tools for Unix that I could run > on the Linux ext4 partition that you would propose? benchmarks/fio is good for that. -- Bruce Cran From owner-freebsd-stable@FreeBSD.ORG Sat Apr 20 23:08:59 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0FBD924F for ; Sat, 20 Apr 2013 23:08:59 +0000 (UTC) (envelope-from gondim@bsdinfo.com.br) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [186.193.48.13]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1C71218 for ; Sat, 20 Apr 2013 23:08:57 +0000 (UTC) Received: from zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) by zeus.linuxinfo.com.br (Postfix) with ESMTP id 09782466A45D; Sat, 20 Apr 2013 20:06:44 -0300 (BRT) X-Virus-Scanned: amavisd-new at zeus.linuxinfo.com.br Received: from zeus.linuxinfo.com.br ([127.0.0.1]) by zeus.linuxinfo.com.br (zeus.linuxinfo.com.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8VKXveFYzIO; Sat, 20 Apr 2013 20:06:40 -0300 (BRT) Received: from MacBook-de-Gondim-2.local (unknown [186.193.54.69]) by zeus.linuxinfo.com.br (Postfix) with ESMTPSA id 3D967466A458; Sat, 20 Apr 2013 20:06:36 -0300 (BRT) Message-ID: <51731FFE.5020304@bsdinfo.com.br> Date: Sat, 20 Apr 2013 20:08:46 -0300 From: Marcelo Gondim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Eugene Grosbein Subject: Re: Possible DoS in mpd 5.6 pppoe server References: <5172965A.9080600@bsdinfo.com.br> <5172BDDD.4010509@rdtc.ru> <5172CFB2.3010708@bsdinfo.com.br> <5172D14D.8040009@rdtc.ru> In-Reply-To: <5172D14D.8040009@rdtc.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 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, 20 Apr 2013 23:08:59 -0000 Em 20/04/13 14:33, Eugene Grosbein escreveu: > On 21.04.2013 00:26, Marcelo Gondim wrote: > >>> You seem to use dummynet and the problem is not in mpd/pppoe code, >>> it's it the dummynet code. Look at http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/162558 >>> for workarounds. >> Ok :) I will try this: >> >> - net.isr.bindthreads=1 in /boot/loader.conf; >> - net.isr.direct=1 and net.isr.direct_force=1 in /etc/sysctl.conf > For 9.x and newer, net.isr.XXX knobs names have changed but defaults are fine - > if you have not messed them, you should be OK. > > > Eugene, Does FreeBSD 8.3-STABLEis best for this use or this problem also occurs in 8.x? Best regards, Gondim