From owner-freebsd-stable@FreeBSD.ORG Sun May 1 02:28:32 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B11716A4CE for ; Sun, 1 May 2005 02:28:32 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5016043D49 for ; Sun, 1 May 2005 02:28:32 +0000 (GMT) (envelope-from craig@feniz.gank.org) Received: by ion.gank.org (mail, from userid 1001) id DED2F2B1EB; Sat, 30 Apr 2005 21:28:31 -0500 (CDT) Date: Sat, 30 Apr 2005 21:28:29 -0500 From: Craig Boston To: Jon Noack Message-ID: <20050501022828.GA94865@nowhere> Mail-Followup-To: Craig Boston , Jon Noack , Ronald Klop , freebsd-stable@freebsd.org References: <4266C966.90701@alumni.rice.edu> <4266DBEC.5000503@alumni.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4266DBEC.5000503@alumni.rice.edu> User-Agent: Mutt/1.4.2.1i cc: freebsd-stable@freebsd.org cc: Ronald Klop Subject: Re: [PATCH] securelevel and make installworld X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 01 May 2005 02:28:32 -0000 On Wed, Apr 20, 2005 at 05:47:08PM -0500, Jon Noack wrote: > The attached diff is against -CURRENT but applies cleanly to 5.4-RC3. > It adds a check to the installworld target in src/Makefile.inc1 to > ensure we are not in secure mode. What about cases where installing in secure mode is both valid and will not fail? For example, consider using installworld to create a jail environment. If the target directory is empty, no schg files need to be overwritten and the install will succeed even with securelevel 3. Some users may also have their system configured so that schg is not set on system files (INSTALLFLAGS_EDIT=:N-fschg, among other methods). Arguably this is not very secure, but perhaps they are using securelevel for something else. Perhaps protecting firewall rules or sensitive files? IMHO, it's not the system's place to second guess what it is told to do. Craig From owner-freebsd-stable@FreeBSD.ORG Sun May 1 07:18:40 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B861316A4CE for ; Sun, 1 May 2005 07:18:40 +0000 (GMT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id D779843D4C for ; Sun, 1 May 2005 07:18:39 +0000 (GMT) (envelope-from netch@lucky.net) Received: from burka.carrier.kiev.ua (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id j417IZJa073697 for ; Sun, 1 May 2005 10:18:37 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.13.1/8.13.1/Submit) id j417IZIJ073694 for stable@freebsd.org; Sun, 1 May 2005 10:18:35 +0300 (EEST) (envelope-from netch) Date: Sun, 1 May 2005 10:18:35 +0300 From: Valentin Nechayev To: stable@freebsd.org Message-ID: <20050501071835.GA81673@lucky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-42: On X-Verify-Sender: Address has been verified (burka.carrier.kiev.ua) X-Antivirus: Dr.Web (R) for Mail Servers on kozlik.carrier.kiev.ua host X-Antivirus-Code: 100000 Subject: 5.4-RC3: "giving up on 3 buffers" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2005 07:18:40 -0000 Hi, I have got system on 5.4-RC3 which stably fails to reboot correctly with the message in subject: After reboot, some file systems (/var and /var2) aren't correctly unmounted. I can debug it if someone helps in this (what to debug and what to print). -netch- From owner-freebsd-stable@FreeBSD.ORG Sun May 1 09:54:52 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCFCA16A4CE for ; Sun, 1 May 2005 09:54:52 +0000 (GMT) Received: from burka.carrier.kiev.ua (burka.carrier.kiev.ua [193.193.193.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DB9D43D49 for ; Sun, 1 May 2005 09:54:51 +0000 (GMT) (envelope-from netch@lucky.net) Received: from burka.carrier.kiev.ua (netch@localhost [127.0.0.1]) by burka.carrier.kiev.ua with ESMTP id j419slHx004794; Sun, 1 May 2005 12:54:49 +0300 (EEST) (envelope-from netch@burka.carrier.kiev.ua) Received: (from netch@localhost) by burka.carrier.kiev.ua (8.13.1/8.13.1/Submit) id j419slR4004789; Sun, 1 May 2005 12:54:47 +0300 (EEST) (envelope-from netch) Date: Sun, 1 May 2005 12:54:47 +0300 From: Valentin Nechayev To: stable@freebsd.org Message-ID: <20050501095447.GB81673@lucky.net> References: <20050501071835.GA81673@lucky.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050501071835.GA81673@lucky.net> X-42: On X-Verify-Sender: Address has been verified (burka.carrier.kiev.ua) X-Antivirus: Dr.Web (R) for Mail Servers on kozlik.carrier.kiev.ua host X-Antivirus-Code: 100000 Subject: Re: 5.4-RC3: "giving up on 3 buffers"; "pfs_vncache_unload: 1 entries remaining" X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: netch@lucky.net List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2005 09:54:53 -0000 Sun, May 01, 2005 at 10:18:35, netch wrote about "5.4-RC3: "giving up on 3 buffers"": > I have got system on 5.4-RC3 which stably fails to reboot correctly > with the message in subject: Next message after him: pfs_vncache_unload: 1 entries remaining After reboot: WARNING: / was not properly dismounted /var isn't unmounted also. Another partitions are explicitly unmounted in /etc/rc.shutdown so this reduce harm of shutdown failures. Disabling softupdates changes nothing. Kernel config, boot dmesg and head of fs dump follows. > After reboot, some file systems (/var and /var2) aren't correctly unmounted. > I can debug it if someone helps in this (what to debug and what to print). ==={{{ nn154 machine i386 cpu I686_CPU ident nn154 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=15000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. options MSGBUF_SIZE=131072 device apic # I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device sl # Kernel SLIP device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter options CPU_ENABLE_SSE options INCLUDE_CONFIG_FILE # Include this file in kernel # altq(9). Enable the base part of the hooks with the ALTQ option. # Individual disciplines must be built into the base system and can not be # loaded as modules at this point. In order to build a SMP kernel you must # also have the ALTQ_NOPCC option. options ALTQ options ALTQ_CBQ # Class Bases Queueing options ALTQ_RED # Random Early Detection options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler options ALTQ_CDNR # Traffic conditioner options ALTQ_PRIQ # Priority Queueing options ALTQ_DEBUG # netgraph(4). Enable the base netgraph code with the NETGRAPH option. # Individual node types can be enabled with the corresponding option # listed below; however, this is not strictly necessary as netgraph # will automatically load the corresponding KLD module if the node type # is not already compiled into the kernel. Each type below has a # corresponding man page, e.g., ng_async(8). options NETGRAPH #netgraph(4) system options IPFIREWALL #firewall options IPFIREWALL_DEFAULT_TO_ACCEPT #allow everything by default options IPFIREWALL_FORWARD #packet destination changes options IPFIREWALL_FORWARD_EXTENDED #all packet dest changes options IPDIVERT #divert sockets options DUMMYNET options UDF #Universal Disk Format # Use real implementations of the aio_* system calls. There are numerous # stability and security issues in the current aio code that make it # unsuitable for inclusion on machines with untrusted local users. options VFS_AIO options LIBICONV # Optional character code conversion support with LIBICONV. # Each option requires their base file system and LIBICONV. options CD9660_ICONV options MSDOSFS_ICONV options UDF_ICONV ===}}} ==={{{ Copyright (c) 1992-2005 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 5.4-RC3 #1: Sun Apr 24 00:33:47 EEST 2005 root@iv.nn.kiev.ua:/var2/usr/obj/5/var/REL5/src/sys/nn154 WARNING: debug.mpsafenet forced to 0 as aio requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. Preloaded elf kernel "/boot//kernel/kernel" at 0xc07aa000. Calibrating clock(s) ... i8254 clock: 1193004 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 799434216 Hz CPU: Intel Celeron (799.43-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x686 Stepping = 6 Features=0x383f9ff real memory = 268435456 (256 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000825000 - 0x000000000fb37fff, 254881792 bytes (62227 pages) avail memory = 257130496 (245 MB) bios32: Found BIOS32 Service Directory header at 0xc00fad00 bios32: Entry = 0xfb190 (c00fb190) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb1c0 pnpbios: Found PnP BIOS data at 0xc00fbbb0 pnpbios: Entry = f0000:bbe0 Rev = 1.0 Other BIOS signatures found: null: random: mem: Pentium Pro MTRR support enabled io: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=11308086) pcibios: BIOS version 2.10 Found $PIR table, 10 entries at 0xc00fded0 PCI-Only Interrupts: 5 7 9 11 Location Bus Device Pin Link IRQs slot 1 0 2 A 0x60 3 4 5 7 9 10 11 14 15 slot 1 0 2 B 0x61 3 4 5 7 9 10 11 14 15 slot 1 0 2 C 0x62 3 4 5 7 9 10 11 14 15 slot 1 0 2 D 0x63 3 4 5 7 9 10 11 14 15 slot 2 2 8 A 0x68 3 4 5 7 9 10 11 14 15 slot 2 2 8 B 0x69 3 4 5 7 9 10 11 14 15 slot 2 2 8 C 0x6a 3 4 5 7 9 10 11 14 15 slot 2 2 8 D 0x6b 3 4 5 7 9 10 11 14 15 slot 3 2 0 A 0x60 3 4 5 7 9 10 11 14 15 slot 3 2 0 B 0x61 3 4 5 7 9 10 11 14 15 slot 3 2 0 C 0x62 3 4 5 7 9 10 11 14 15 slot 3 2 0 D 0x63 3 4 5 7 9 10 11 14 15 slot 4 2 1 A 0x61 3 4 5 7 9 10 11 14 15 slot 4 2 1 B 0x62 3 4 5 7 9 10 11 14 15 slot 4 2 1 C 0x63 3 4 5 7 9 10 11 14 15 slot 4 2 1 D 0x60 3 4 5 7 9 10 11 14 15 slot 5 2 6 A 0x62 3 4 5 7 9 10 11 14 15 slot 5 2 6 B 0x63 3 4 5 7 9 10 11 14 15 slot 5 2 6 C 0x60 3 4 5 7 9 10 11 14 15 slot 5 2 6 D 0x61 3 4 5 7 9 10 11 14 15 slot 6 2 7 A 0x63 3 4 5 7 9 10 11 14 15 slot 6 2 7 B 0x60 3 4 5 7 9 10 11 14 15 slot 6 2 7 C 0x61 3 4 5 7 9 10 11 14 15 slot 6 2 7 D 0x62 3 4 5 7 9 10 11 14 15 slot 7 2 9 A 0x61 3 4 5 7 9 10 11 14 15 slot 7 2 9 B 0x62 3 4 5 7 9 10 11 14 15 slot 7 2 9 C 0x63 3 4 5 7 9 10 11 14 15 slot 7 2 9 D 0x60 3 4 5 7 9 10 11 14 15 slot 8 2 10 A 0x62 3 4 5 7 9 10 11 14 15 slot 8 2 10 B 0x63 3 4 5 7 9 10 11 14 15 slot 8 2 10 C 0x60 3 4 5 7 9 10 11 14 15 slot 8 2 10 D 0x61 3 4 5 7 9 10 11 14 15 embedded 0 31 A 0x60 3 4 5 7 9 10 11 14 15 embedded 0 31 B 0x61 3 4 5 7 9 10 11 14 15 embedded 0 31 C 0x6b 3 4 5 7 9 10 11 14 15 embedded 0 31 D 0x63 3 4 5 7 9 10 11 14 15 embedded 0 1 A 0x60 3 4 5 7 9 10 11 14 15 embedded 0 1 B 0x61 3 4 5 7 9 10 11 14 15 embedded 0 1 C 0x62 3 4 5 7 9 10 11 14 15 embedded 0 1 D 0x63 3 4 5 7 9 10 11 14 15 pcib0: pcibus 0 on motherboard pir0: on motherboard $PIR: Links after initial probe: Link IRQ Rtd Ref IRQs 0x60 255 N 9 3 4 5 7 9 10 11 14 15 0x61 255 N 9 3 4 5 7 9 10 11 14 15 0x62 255 N 8 3 4 5 7 9 10 11 14 15 0x63 255 N 9 3 4 5 7 9 10 11 14 15 0x68 255 N 1 3 4 5 7 9 10 11 14 15 0x69 255 N 1 3 4 5 7 9 10 11 14 15 0x6a 255 N 1 3 4 5 7 9 10 11 14 15 0x6b 255 N 2 3 4 5 7 9 10 11 14 15 $PIR: Found matching pin for 2.10.INTA at func 0: 11 $PIR: Found matching pin for 0.31.INTB at func 5: 7 $PIR: Found matching pin for 0.31.INTC at func 4: 9 $PIR: Found matching pin for 0.31.INTD at func 2: 11 $PIR: Links after initial IRQ discovery: Link IRQ Rtd Ref IRQs 0x60 255 N 9 3 4 5 7 9 10 11 14 15 0x61 7 Y 9 3 4 5 7 9 10 11 14 15 0x62 11 Y 8 3 4 5 7 9 10 11 14 15 0x63 11 Y 9 3 4 5 7 9 10 11 14 15 0x68 255 N 1 3 4 5 7 9 10 11 14 15 0x69 255 N 1 3 4 5 7 9 10 11 14 15 0x6a 255 N 1 3 4 5 7 9 10 11 14 15 0x6b 9 Y 2 3 4 5 7 9 10 11 14 15 $PIR: IRQs used by BIOS: 7 9 11 $PIR: Interrupt Weights: [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ] [ 0 0 0 0 0 0 0 9 0 2 0 17 0 0 0 0 ] pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e4000000, size 26, enabled found-> vendor=0x8086, dev=0x1130, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1131, revid=0x02 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x244e, revid=0x02 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2440, revid=0x02 bus=0, slot=31, 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) map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=0x8086, dev=0x244b, revid=0x02 bus=0, slot=31, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000d000, size 5, enabled $PIR: 0:31 INTD routed to irq 11 found-> vendor=0x8086, dev=0x2442, revid=0x02 bus=0, slot=31, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[20]: type 4, range 32, base 0000d400, size 5, enabled $PIR: 0:31 INTC routed to irq 9 found-> vendor=0x8086, dev=0x2444, revid=0x02 bus=0, slot=31, func=4 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=9 map[10]: type 4, range 32, base 0000d800, size 8, enabled map[14]: type 4, range 32, base 0000dc00, size 6, enabled $PIR: 0:31 INTB routed to irq 7 found-> vendor=0x8086, dev=0x2445, revid=0x02 bus=0, slot=31, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 agp0: mem 0xe4000000-0xe7ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe4000000 agp0: allocating GATT for aperture of size 36M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xec000000-0xedffffff pcib1: prefetched decode 0xea000000-0xebffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base ec000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xec000000-0xecffffff map[14]: type 3, range 32, base ea000000, size 25, enabled pcib1: device (null) requested decoded memory range 0xea000000-0xebffffff $PIR: Found IRQ 5 for link 0x60 from 5 7 9 11 $PIR: ROUTE_INTERRUPT failed. found-> vendor=0x10de, dev=0x002c, revid=0x15 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=5 powerspec 1 supports D0 D3 current D0 pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xee000000-0xee0fffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: physical bus=2 map[10]: type 4, range 32, base 0000c000, size 8, enabled pcib2: device (null) requested decoded I/O range 0xc000-0xc0ff map[14]: type 1, range 32, base ee000000, size 8, enabled pcib2: device (null) requested decoded memory range 0xee000000-0xee0000ff $PIR: 2:10 INTA routed to irq 11 found-> vendor=0x10ec, dev=0x8139, revid=0x10 bus=2, slot=10, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x20 (8000 ns), maxlat=0x40 (16000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 rl0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc000 pcib2: device re0 requested decoded I/O range 0xc000-0xc0ff pcib2: device rl0 requested decoded I/O range 0xc000-0xc0ff rl0: port 0xc000-0xc0ff mem 0xee000000-0xee0000ff irq 11 at device 10.0 on pci2 pcib2: device rl0 requested decoded I/O range 0xc000-0xc0ff miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: bpf attached rl0: Ethernet address: 00:40:f4:65:6e:f8 rl0: [GIANT-LOCKED] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: reset tp2 stat0=50 stat1=00 devices=0x9 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1-master: stat=0x52 err=0x01 lsb=0x00 msb=0x00 ata1-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=52 stat1=00 devices=0x1 ata1: [MPSAFE] pci0: at device 31.2 (no driver attached) pci0: at device 31.4 (no driver attached) pci0: at device 31.5 (no driver attached) pnpbios: 16 devices, largest 78 bytes PNP0200: adding dma mask 0x10 PNP0200: adding io range 0-0xf, size=0x10, align=0 PNP0200: adding io range 0x81-0x83, size=0x3, align=0 PNP0200: adding io range 0x87-0x87, size=0x1, align=0 PNP0200: adding io range 0x89-0x8b, size=0x3, align=0 PNP0200: adding io range 0x8f-0x91, size=0x3, align=0 PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0 pnpbios: handle 1 device ID PNP0200 (0002d041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0 pnpbios: handle 2 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 pnpbios: handle 3 device ID PNP0b00 (000bd041) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0 PNP0303: adding io range 0x64-0x64, size=0x1, align=0 pnpbios: handle 4 device ID PNP0303 (0303d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0 pnpbios: handle 5 device ID PNP0800 (0008d041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0 pnpbios: handle 6 device ID PNP0c04 (040cd041) INT0800: adding fixed memory32 range 0xffb80000-0xffbfffff, size=0x80000 pnpbios: handle 7 device ID INT0800 (0008d425) PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0xffb00000-0xffb7ffff, size=0x80000 PNP0c01: adding fixed memory32 range 0xfff00000-0xffffffff, size=0x100000 PNP0c01: adding fixed memory32 range 0xfee00000-0xfee0ffff, size=0x10000 PNP0c01: adding fixed memory32 range 0x100000-0xfffffff, size=0xff00000 pnpbios: handle 8 device ID PNP0c01 (010cd041) PNP0c02: adding fixed memory32 range 0xf0000-0xf3fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf4000-0xf7fff, size=0x4000 PNP0c02: adding fixed memory32 range 0xf8000-0xfbfff, size=0x4000 PNP0c02: adding fixed memory32 range 0xfc000-0xfffff, size=0x4000 pnpbios: handle 9 device ID PNP0c02 (020cd041) PNP0a03: adding io range 0x294-0x297, size=0x4, align=0 PNP0a03: adding io range 0x4d0-0x4d1, size=0x2, align=0 PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 PNP0a03: adding io range 0x480-0x48f, size=0x10, align=0 PNP0a03: adding io range 0x4000-0x40f7, size=0xf8, align=0 pnpbios: handle 10 device ID PNP0a03 (030ad041) PNP0f13: adding irq mask 0x1000 pnpbios: handle 11 device ID PNP0f13 (130fd041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 pnpbios: handle 12 device ID PNP0501 (0105d041) PNP0501: adding irq mask 0x8 PNP0501: adding io range 0x2f8-0x2ff, size=0x8, align=0 pnpbios: handle 16 device ID PNP0501 (0105d041) PNPb006: adding irq mask 0x400 PNPb006: adding io range 0x330-0x331, size=0x2, align=0 pnpbios: handle 17 device ID PNPb006 (06b0d041) PNPb02f: adding io range 0x201-0x207, size=0x7, align=0 PNPb02f: adding io range 0x200-0x200, size=0x1, align=0 pnpbios: handle 18 device ID PNPb02f (2fb0d041) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff on isa0 pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices unknown: can't assign resources (port) unknown: at port 0x60 on isa0 unknown: failed to probe at port 0x61 on isa0 unknown: failed to probe at iomem 0xffb80000-0xffbfffff on isa0 unknown: can't assign resources (irq) unknown: at irq 12 on isa0 unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources (port) unknown: at port 0x2f8-0x2ff on isa0 unknown: failed to probe at port 0x330-0x331 irq 10 on isa0 unknown: failed to probe at port 0x200,0x201-0x207 on isa0 Device configuration finished. procfs registered Timecounter "TSC" frequency 799434216 Hz quality 800 Timecounters tick every 10.000 msec DUMMYNET initialized (011031) ipfw2 initialized, divert enabled, rule-based forwarding enabled, default to accept, logging disabled lo0: bpf attached ata0-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ata0-master: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ata0-master: setting PIO4 on Intel ICH2 chip ata0-master: setting UDMA100 on Intel ICH2 chip ata0-slave: setting PIO4 on Intel ICH2 chip ata0-slave: setting UDMA33 on Intel ICH2 chip ad0: ATA-7 disk at ata0-master ad0: 114498MB (234493056 sectors), 232632 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 [0] f:80 typ:6 s(CHS):0/1/1 e(CHS):186/254/63 s:63 l:3004092 [1] f:00 typ:15 s(CHS):577/0/1 e(CHS):1023/254/63 s:9269505 l:225215235 [2] f:00 typ:165 s(CHS):187/0/1 e(CHS):257/254/63 s:3004155 l:1140615 [3] f:00 typ:165 s(CHS):258/0/1 e(CHS):576/254/63 s:4144770 l:5124735 GEOM: Configure ad0s1, start 32256 length 1538095104 end 1538127359 GEOM: Configure ad0s2, start 4745986560 length 115310200320 end 120056186879 GEOM: Configure ad0s3, start 1538127360 length 583994880 end 2122122239 GEOM: Configure ad0s4, start 2122122240 length 2623864320 end 4745986559 [0] f:61 typ:116 s(CHS):288/110/36 e(CHS):366/104/37 s:1701998624 l:1629516659 [1] f:6e typ:101 s(CHS):107/121/32 e(CHS):10/121/13 s:1330184192 l:538976288 [2] f:20 typ:83 s(CHS):345/32/19 e(CHS):324/77/19 s:538989391 l:1398362912 [3] f:7f typ:187 s(CHS):65/1/0 e(CHS):96/0/7 s:-385848730 l:65339 acd0: CDROM drive at ata0 as slave acd0: read 6890KB/s (6890KB/s), 128KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata1-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata1-master: setting PIO4 on Intel ICH2 chip ata1-master: setting UDMA100 on Intel ICH2 chip ad2: ATA-5 disk at ata1-master ad2: 39266MB (80418240 sectors), 79780 C, 16 H, 63 S, 512 B ad2: 16 secs/int, 1 depth queue, UDMA100 MBREXT Slice 5 on ad0s2: [0] f:00 typ:165 s(CHS):577/1/1 e(CHS):1023/254/63 s:63 l:15888222 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:15888285 l:2040255 GEOM: Configure ad0s5, start 32256 length 8134769664 end 8134801919 MBREXT Slice 6 on ad0s2: [0] f:00 typ:131 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:2040192 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:17928540 l:514080 GEOM: Configure ad0s6, start 8134834176 length 1044578304 end 9179412479 MBREXT Slice 7 on ad0s2: [0] f:00 typ:130 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:514017 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:18442620 l:16065 GEOM: Configure ad0s7, start 9179444736 length 263176704 end 9442621439 MBREXT Slice 8 on ad0s2: [0] f:00 typ:3 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:16002 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:18458685 l:1654695 GEOM: Configure ad0s8, start 9442653696 length 8193024 end 9450846719 MBREXT Slice 9 on ad0s2: [0] f:00 typ:3 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:1654632 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:20113380 l:642600 GEOM: Configure ad0s9, start 9450878976 length 847171584 end 10298050559 MBREXT Slice 10 on ad0s2: [0] f:00 typ:131 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:642537 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:20755980 l:31985415 GEOM: Configure ad0s10, start 10298082816 length 328978944 end 10627061759 MBREXT Slice 11 on ad0s2: [0] f:00 typ:165 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:31985352 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:52741395 l:1975995 GEOM: Configure ad0s11, start 10627094016 length 16376500224 end 27003594239 MBREXT Slice 12 on ad0s2: [0] f:00 typ:165 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:1975932 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:151364367 l:73850868 GEOM: Configure ad0s12, start 27003626496 length 1011677184 end 28015303679 MBREXT Slice 13 on ad0s2: [0] f:00 typ:165 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:73850805 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s13, start 77498588160 length 37811612160 end 115310200319 [0] f:00 typ:165 s(CHS):577/1/1 e(CHS):1023/254/63 s:63 l:15888222 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:15888285 l:2040255 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s2s1, start 32256 length 8134769664 end 8134801919 GEOM: Configure ad0s2s2, start 8134801920 length 1044610560 end 9179412479 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad0s3a, start 0 length 583994880 end 583994879 GEOM: Configure ad0s3c, start 0 length 583994880 end 583994879 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad0s4a, start 0 length 524288000 end 524287999 GEOM: Configure ad0s4c, start 0 length 2623864320 end 2623864319 GEOM: Configure ad0s4e, start 524288000 length 2097152000 end 2621439999 GEOM: new disk ad2 WARNING: Expected rawoffset 9269505, found 9269568 GEOM: Configure ad0s5b, start 8192 length 524288000 end 524296191 GEOM: Configure ad0s5c, start 0 length 8134769664 end 8134769663 GEOM: Configure ad0s5e, start 524296192 length 7603321344 end 8127617535 WARNING: Expected rawoffset 9269505, found 30025548 GEOM: Configure ad0s11b, start 8192 length 524279808 end 524287999 GEOM: Configure ad0s11c, start 0 length 16376500224 end 16376500223 GEOM: Configure ad0s11e, start 524288000 length 15852212224 end 16376500223 WARNING: Expected rawoffset 9269505, found 62010963 GEOM: Configure ad0s12c, start 0 length 1011677184 end 1011677183 WARNING: Expected rawoffset 9269505, found 160633935 GEOM: Configure ad0s13c, start 0 length 37811612160 end 37811612159 GEOM: Configure ad0s13e, start 0 length 37811612160 end 37811612159 WARNING: Expected rawoffset 63, found 9269568 GEOM: Configure ad0s2s1b, start 8192 length 524288000 end 524296191 GEOM: Configure ad0s2s1c, start 0 length 8134769664 end 8134769663 GEOM: Configure ad0s2s1e, start 524296192 length 7603321344 end 8127617535 MBREXT Slice 5 on ad0s2s2: [0] f:00 typ:131 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:2040192 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:17928540 l:514080 GEOM: Configure ad0s2s5, start 32256 length 1044578304 end 1044610559 [0] f:00 typ:131 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:2040192 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:17928540 l:514080 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s2s2s1, start 32256 length 1044578304 end 1044610559 GEOM: Configure ad0s2s2s2, start 9179412480 length 263208960 end 9442621439 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:2 s(CHS):0/1/1 e(CHS):255/254/63 s:63 l:4112577 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:15 s(CHS):974/0/1 e(CHS):1023/254/63 s:15647310 l:64758015 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad2s1, start 32256 length 2105639424 end 2105671679 GEOM: Configure ad2s3, start 8011422720 length 33156103680 end 41167526399 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 MBREXT Slice 5 on ad2s3: [0] f:00 typ:131 s(CHS):974/1/1 e(CHS):1013/254/63 s:63 l:642537 [1] f:00 typ:5 s(CHS):1014/0/1 e(CHS):1017/254/63 s:642600 l:64260 GEOM: Configure ad2s5, start 32256 length 328978944 end 329011199 MBREXT Slice 6 on ad2s3: [0] f:00 typ:131 s(CHS):1014/1/1 e(CHS):1017/254/63 s:63 l:64197 [1] f:00 typ:5 s(CHS):1018/0/1 e(CHS):1023/254/63 s:706860 l:16386300 GEOM: Configure ad2s6, start 329043456 length 32868864 end 361912319 MBREXT Slice 7 on ad2s3: [0] f:00 typ:3 s(CHS):1018/1/1 e(CHS):1023/254/63 s:63 l:16386237 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:17093160 l:16386300 GEOM: Configure ad2s7, start 361944576 length 8389753344 end 8751697919 MBREXT Slice 8 on ad2s3: [0] f:00 typ:12 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:16386237 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:33479460 l:1044225 GEOM: Configure ad2s8, start 8751730176 length 8389753344 end 17141483519 MBREXT Slice 9 on ad2s3: [0] f:00 typ:130 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:1044162 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:34523685 l:2040255 GEOM: Configure ad2s9, start 17141515776 length 534610944 end 17676126719 MBREXT Slice 10 on ad2s3: [0] f:00 typ:131 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:2040192 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:36563940 l:10297665 GEOM: Configure ad2s10, start 17676158976 length 1044578304 end 18720737279 MBREXT Slice 11 on ad2s3: [0] f:00 typ:12 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:10297602 [1] f:00 typ:5 s(CHS):1023/254/63 e(CHS):1023/254/63 s:46861605 l:17896410 GEOM: Configure ad2s11, start 18720769536 length 5272372224 end 23993141759 MBREXT Slice 12 on ad2s3: [0] f:00 typ:12 s(CHS):1023/254/63 e(CHS):1023/254/63 s:63 l:17896347 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad2s12, start 23993174016 length 9162929664 end 33156103679 [0] f:00 typ:131 s(CHS):974/1/1 e(CHS):1013/254/63 s:63 l:642537 [1] f:00 typ:5 s(CHS):1014/0/1 e(CHS):1017/254/63 s:642600 l:64260 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad2s3s1, start 32256 length 328978944 end 329011199 GEOM: Configure ad2s3s2, start 329011200 length 32901120 end 361912319 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 MBREXT Slice 5 on ad2s3s2: [0] f:00 typ:131 s(CHS):1014/1/1 e(CHS):1017/254/63 s:63 l:64197 [1] f:00 typ:5 s(CHS):1018/0/1 e(CHS):1023/254/63 s:706860 l:16386300 GEOM: Configure ad2s3s5, start 32256 length 32868864 end 32901119 [0] f:00 typ:131 s(CHS):1014/1/1 e(CHS):1017/254/63 s:63 l:64197 [1] f:00 typ:5 s(CHS):1018/0/1 e(CHS):1023/254/63 s:706860 l:16386300 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad2s3s2s1, start 32256 length 32868864 end 32901119 GEOM: Configure ad2s3s2s2, start 361912320 length 8389785600 end 8751697919 Mounting root from ufs:/dev/ad0s3a WARNING: / was not properly dismounted start_init: trying /sbin/init /var3: correcting fs_sblockloc from 65536 to 8192 ===}}} ==={{{ magic 11954 (UFS1) time Sun May 1 12:49:57 2005 id [ 3c4af93b 4c774041 ] ncg 4 size 285153 blocks 280664 bsize 16384 shift 14 mask 0xffffc000 fsize 2048 shift 11 mask 0xfffff800 frag 8 shift 3 fsbtodb 2 minfree 8% optim time symlinklen 60 maxbpg 4096 maxcontig 7 contigsumsize 7 nbfree 19731 ndir 436 nifree 62068 nffree 5130 cpg 92 bpg 11776 fpg 94208 ipg 17664 nindir 4096 inopb 128 nspf 4 maxfilesize 1126174852055039 sbsize 2048 cgsize 16384 cgoffset 1024 cgmask 0xffffffff csaddr 1128 cssize 2048 rotdelay 0ms rps 60 trackskew 0 interleave 1 nsect 4096 npsect 4096 spc 4096 sblkno 8 cblkno 16 iblkno 24 dblkno 1128 cgrotor 0 fmod 0 ronly 0 clean 0 avgfpdir 64 avgfilesize 16384 flags none fsmnt / volname swuid 0 cs[].cs_(nbfree,ndir,nifree,nffree): (8437,81,16845,430) (3480,270,12833,2909) (7814,42,15550,1791) (0,43,16840,0) cylinders in last group 3 blocks in last group 316 cg 0: magic 90255 tell 8000 time Sun May 1 12:49:56 2005 ===}}} -netch- From owner-freebsd-stable@FreeBSD.ORG Sun May 1 10:38:58 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5D0D16A4CE for ; Sun, 1 May 2005 10:38:58 +0000 (GMT) Received: from smtp-one-2.wash.one.se (smtp-one-2.one.se [213.80.101.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84DE443D49 for ; Sun, 1 May 2005 10:38:57 +0000 (GMT) (envelope-from carl@thegoodone.mine.nu) Received: from localhost (smtp-one-2.local [127.0.0.1]) by re-injector2.wash.one.se (Postfix) with ESMTP id 8F2BB66C93A; Sun, 1 May 2005 10:38:38 +0000 (GMT) Received: from smtp-one-2.wash.one.se ([127.0.0.1]) by localhost (smtp-one-2.wash.one.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35953-05; Sun, 1 May 2005 10:38:35 +0000 (GMT) Received: from thegoodone.mine.nu (81-170-146-19.bahnhofbredband.net [81.170.146.19]) by smtp-one-2.wash.one.se (Postfix) with ESMTP id 8BAFC66C88D; Sun, 1 May 2005 10:38:34 +0000 (GMT) Message-ID: <4274B1B8.5080303@thegoodone.mine.nu> Date: Sun, 01 May 2005 12:38:48 +0200 From: Carl Gustavsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Richards References: <0C9AA1AB019C4A44AE29659CF2BB203202E9C1@gir.routemaster.net> In-Reply-To: <0C9AA1AB019C4A44AE29659CF2BB203202E9C1@gir.routemaster.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0517-6, 2005-04-30), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: by amavisd-new at one.se (smtp-one-2) X-Spam-Status: No, hits=-0.319 tagged_above=-999 required=7 tests=AWL, BAYES_00, OACYS_CONS_6, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL, TW_PT, TW_TX, TW_XF X-Spam-Level: cc: freebsd-stable@freebsd.org Subject: Re: wifi limited to 180KBps X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 01 May 2005 10:38:59 -0000 Chris Richards wrote: >Hi Everyone, > >I have installed a Netgear 802.11b (MA311) PCI card into my freebsd box >but I can't get it to transfer data faster than 180KBps in either >direction. I have tried the card in 2 freebsd boxes one running 5.1 >Release and the other 5.4 Stable, no difference. I also ran trafshow on >wi0 and the traffic looks to come in bursts. > >I have included my config below, can anyone see a problem? > >Thank you. > >-Chris > >----------------------------------------------- >wi0: mem 0x40400000-0x40400fff irq 21 at device 10.0 >on pci2 >wi0: using RF:PRISM2.5 MAC:ISL3874A(Mini-PCI) >wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.9) >wi0: Ethernet address: 00:09:5b:69:15:58 >wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > >su-2.05b# uname -a >FreeBSD spunky2.routemaster.net 5.4-STABLE FreeBSD 5.4-STABLE #3: Thu >Apr 21 01:03:43 EST 2005 >chrisric@spunky2.routemaster.net:/usr/obj/usr/src/sys/SPUNKY2 i386 > >su-2.05b# ifconfig wi0 >wi0: flags=8843 mtu 1500 > inet6 fe80::209:5bff:fe69:1558%wi0 prefixlen 64 scopeid 0x2 > inet 10.10.11.254 netmask 0xffffff00 broadcast 10.10.11.255 > ether 00:09:5b:69:15:58 > media: IEEE 802.11 Wireless Ethernet DS/11Mbps >(DS/2Mbps ) > status: associated > ssid Spunky_AP 1:Spunky_AP > stationname "FreeBSD WaveLAN/IEEE node" > channel 6 authmode OPEN powersavemode OFF powersavesleep 100 > rtsthreshold 2312 protmode CTS > wepmode OFF weptxkey 1 > >NIC serial number: [ 99SA01000000 ] >Station name: [ FreeBSD WaveLAN/IEEE node ] >SSID for IBSS creation: [ Spunky_AP ] >Current netname (SSID): [ Spunky_AP ] >Desired netname (SSID): [ Spunky_AP ] >Current BSSID: [ 00:09:5b:69:15:58 ] >Channel list: [ 7ff ] >IBSS channel: [ 6 ] >Current channel: [ 6 ] >Comms quality/signal/noise: [ 0 81 27 ] >dBm Coms Quality: [ 0 -73 -73 ] >Promiscuous mode: [ Off ] >Process 802.11b Frame: [ Off ] >Intersil-Prism2 based card: [ 1 ] >Port type (1=BSS, 3=ad-hoc): [ 6 ] >MAC address: [ 00:09:5b:69:15:58 ] >TX rate (selection): [ 11 ] >TX rate (actual speed): [ 2 ] >RTS/CTS handshake threshold: [ 2312 ] >Create IBSS: [ Off ] >Access point density: [ 1 ] >Power Mgmt (1=on, 0=off): [ 0 ] >Max sleep time: [ 100 ] >PRI Identity: [ 21 0 1 1 ] >STA Identity: [ 31 9 1 4 ] >Card ID register: [ 8013 0 1 0 ] >Regulatory Domains: [ usa ] >Temperature Range: [ 1 ] >WEP encryption: [ Off ] >TX encryption key: [ 1 ] >Encryption keys: [ ][ ][ ][ ] >_______________________________________________ >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" > > Hi I have the same problem, its a bug in the hostap-driver that limit it to 2Mbps. See this: media: IEEE 802.11 Wireless Ethernet DS/11Mbps (DS/2Mbps ) You have declared that you want 11 Mbps but it sets to maximum 2Mbps. From owner-freebsd-stable@FreeBSD.ORG Sun May 1 11:34:44 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 582B516A4CE for ; Sun, 1 May 2005 11:34:44 +0000 (GMT) Received: from cmailg2.svr.pol.co.uk (cmailg2.svr.pol.co.uk [195.92.195.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0156F43D48 for ; Sun, 1 May 2005 11:34:44 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from user-6037.l3.c1.dsl.pol.co.uk ([81.77.23.149] helo=jayton.ath.cx) by cmailg2.svr.pol.co.uk with esmtp (Exim 4.41) id 1DSCig-0004Tn-GU for freebsd-stable@freebsd.org; Sun, 01 May 2005 12:34:42 +0100 From: Jayton Garnett To: freebsd-stable@freebsd.org In-Reply-To: <20050430120037.5448916A4DF@hub.freebsd.org> References: <20050430120037.5448916A4DF@hub.freebsd.org> Content-Type: text/plain Organization: codegurus.org Date: Sun, 01 May 2005 12:34:58 +0100 Message-Id: <1114947298.71683.17.camel@jayton.ath.cx> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Weird jdk14 build X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jay@codegurus.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2005 11:34:44 -0000 Hello, This weekend i've been reinstalling fbsd on my desktop and while installing /usr/ports/java//jdk14 (yes i downloaded all the files from sun and the patch-kit) While it was compiling I had a syntax error something like expected "(" somewhere or other, but i noticed this little message before that error: ====================================================================== Warning: This JDK may be unstable. You are advised to use the native FreeBSD JDK, in ports/java/jdk14. This Java VM will attempt to obtain some system information by accessing files in linux's procfs. You must install the Linux emulation procfs filesystem for this to work correctly. The JVM will exhibit various problems otherwise. This can be accomplished by adding the following line to your /etc/fstab file: linprocfs /compat/linux/proc linprocfs rw 0 0 and then, as root, executing the commands: kldload linprocfs mount /compat/linux/proc ======================================================================= Well thats just weird since i was in /usr/ports/java/jdk14 when installing java. I have since added that line to my fstab(so i dont have to do this next time), loaded linprocfs and mounted /compat/linux/proc. It is currently compiling fine now since i have done that, but could anyone tell me why it says to use the native fbsd jdk14 when i was using it in the first place and it wanted me to enable linux proc compat. ? Is it just that they need to update the build messages for the native fbsd jdk14? Pitty there are no packages for this. Cheers, Jayton Garnett From owner-freebsd-stable@FreeBSD.ORG Sun May 1 13:20:57 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F47916A4CE for ; Sun, 1 May 2005 13:20:57 +0000 (GMT) Received: from mail28.sea5.speakeasy.net (mail28.sea5.speakeasy.net [69.17.117.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36D0B43D1F for ; Sun, 1 May 2005 13:20:57 +0000 (GMT) (envelope-from freebsd-stable-local@be-well.no-ip.com) Received: (qmail 16422 invoked from network); 1 May 2005 13:20:56 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail28.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 1 May 2005 13:20:56 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 52E5A55; Sun, 1 May 2005 09:20:55 -0400 (EDT) Sender: lowell@be-well.ilk.org To: jay@codegurus.org References: <20050430120037.5448916A4DF@hub.freebsd.org> <1114947298.71683.17.camel@jayton.ath.cx> From: Lowell Gilbert Date: 01 May 2005 09:20:55 -0400 In-Reply-To: <1114947298.71683.17.camel@jayton.ath.cx> Message-ID: <443bt7rsjs.fsf@be-well.ilk.org> Lines: 47 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-stable@freebsd.org Subject: Re: Weird jdk14 build X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2005 13:20:57 -0000 Jayton Garnett writes: > Hello, > > This weekend i've been reinstalling fbsd on my desktop and while > installing /usr/ports/java//jdk14 (yes i downloaded all the files from > sun and the patch-kit) While it was compiling I had a syntax error > something like expected "(" somewhere or other, but i noticed this > little message before that error: > > ====================================================================== > Warning: This JDK may be unstable. You are advised to use the native > FreeBSD JDK, in ports/java/jdk14. > > This Java VM will attempt to obtain some system information by > accessing files in linux's procfs. You must install the Linux > emulation procfs filesystem for this to work correctly. The JVM > will exhibit various problems otherwise. This can be accomplished > by adding the following line to your /etc/fstab file: > > linprocfs /compat/linux/proc linprocfs rw 0 0 > > and then, as root, executing the commands: > > kldload linprocfs > mount /compat/linux/proc > ======================================================================= > > Well thats just weird since i was in /usr/ports/java/jdk14 when > installing java. > > I have since added that line to my fstab(so i dont have to do this next > time), loaded linprocfs and mounted /compat/linux/proc. > It is currently compiling fine now since i have done that, but could > anyone tell me why it says to use the native fbsd jdk14 when i was using > it in the first place and it wanted me to enable linux proc compat. ? > > Is it just that they need to update the build messages for the native > fbsd jdk14? No; you need to use Java to build Java. Therefore, the procedure is to use the precompiled Linux jdk to build the native one. Once the native one is built, you can remove the Linux one. > Pitty there are no packages for this. Yes. But it's not free software, so that's the way it goes. From owner-freebsd-stable@FreeBSD.ORG Sun May 1 13:50:45 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18E8216A4CE for ; Sun, 1 May 2005 13:50:45 +0000 (GMT) Received: from mail.efacilitas.de (efacilitas.de [213.133.110.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6B6043D1F for ; Sun, 1 May 2005 13:50:44 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-39-77.dynamic.qsc.de [212.202.39.77]) by mail.efacilitas.de (Postfix) with ESMTP id 9917C123AEA for ; Sun, 1 May 2005 15:49:33 +0200 (CEST) Received: from localhost (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id ECC4312B227 for ; Sun, 1 May 2005 15:50:36 +0200 (CEST) Received: from eurystheus.local ([192.168.1.67]) by localhost (eurystheus.locaL [192.168.1.67]) (amavisd-new, port 10024) with ESMTP id 41407-10 for ; Sun, 1 May 2005 15:50:32 +0200 (CEST) Received: from [192.168.1.67] (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id CD9A012B0B2 for ; Sun, 1 May 2005 15:50:32 +0200 (CEST) Message-ID: <4274DEA8.4050301@cs.tu-berlin.de> Date: Sun, 01 May 2005 15:50:32 +0200 From: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at example.com Subject: merging src/etc/rc.d/ppp-user 1.7 to -stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 01 May 2005 13:50:45 -0000 Hello, how much time does it take until the changes of src/etc/rc.d/ppp-user 1.7 will merged into -stable? It's annoying for me to patch it manually in order that '/etc/rc.d/ppp-user stop' will work properly. What are guidelines for merging code from -current to -stable in general? Thanks Björn From owner-freebsd-stable@FreeBSD.ORG Sun May 1 14:10:17 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 927D916A4CE for ; Sun, 1 May 2005 14:10:17 +0000 (GMT) Received: from aurora-solutions.co.uk (aurora-solutions.co.uk [217.155.123.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 352A843D1F for ; Sun, 1 May 2005 14:10:17 +0000 (GMT) (envelope-from stuart@aurora-solutions.co.uk) Received: from dsl-217-155-123-104.zen.co.uk ([217.155.123.104]) by aurora-solutions.co.uk with esmtpa (Exim 4.43) id 1DSF4c-0005tT-2a for freebsd-stable@freebsd.org; Sun, 01 May 2005 15:05:31 +0100 Message-ID: <4274E348.7040909@aurora-solutions.co.uk> Date: Sun, 01 May 2005 15:10:16 +0100 From: "O'Reilly, Stuart" Organization: Aurora Solutions User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.4 (-----) X-Spam-Report: Content analysis details: (-5.4 points) pts rule name description -------------------------------------------------- -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 1% [score: 0.0000]white-list Subject: FreeBSD & Serial ATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: stuart@aurora-solutions.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2005 14:10:17 -0000 Hi guys, Firstly, please go easy, i'm new to the list. I'm in the process of building / upgrading a server and have chosen FreeBSD to run it. One requirement is the ability to support RAID 1. I am looking at adding a Serial ATA PCI card but i'm unsure which is best. The motherboard itself doesn't support Serial ATA and I don't want to change it since it's a decent P4 motherboard and at the moment it's an unncessary expense. I've looked in the archives and seen the name 3ware comes as a recommendation. Does anyone know where I can get hold of one these in the UK. The ususal e-stores don't seem to stock them. Failing that, I've been looking at Adaptec and the 1210AS has taken my eye. Anyone have any experience of this card. The system is a P4 1.8Ghz system with 512MB RAM and 2 x 80GB drives running in RAID 1. The system will be co-lo'd so something reliable is required. Many thanks. Stuart From owner-freebsd-stable@FreeBSD.ORG Sun May 1 14:19:19 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECC3216A4CE for ; Sun, 1 May 2005 14:19:19 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E12643D1F for ; Sun, 1 May 2005 14:19:17 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j41EMt0D044390; Sun, 1 May 2005 08:22:55 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4274E553.3050405@samsco.org> Date: Sun, 01 May 2005 08:18:59 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stuart@aurora-solutions.co.uk References: <4274E348.7040909@aurora-solutions.co.uk> In-Reply-To: <4274E348.7040909@aurora-solutions.co.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD & Serial ATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 01 May 2005 14:19:20 -0000 O'Reilly, Stuart wrote: > Hi guys, > > Firstly, please go easy, i'm new to the list. > > I'm in the process of building / upgrading a server and have chosen > FreeBSD to run it. One requirement is the ability to support RAID 1. I > am looking at adding a Serial ATA PCI card but i'm unsure which is best. > The motherboard itself doesn't support Serial ATA and I don't want to > change it since it's a decent P4 motherboard and at the moment it's an > unncessary expense. > > I've looked in the archives and seen the name 3ware comes as a > recommendation. Does anyone know where I can get hold of one these in > the UK. The ususal e-stores don't seem to stock them. > > Failing that, I've been looking at Adaptec and the 1210AS has taken my > eye. Anyone have any experience of this card. > > The system is a P4 1.8Ghz system with 512MB RAM and 2 x 80GB drives > running in RAID 1. The system will be co-lo'd so something reliable is > required. > > Many thanks. > There are a number of high quality SATA RAID cards on the market. If you have the money, I'd highly suggest getting one that has a real RAID co-processor on it. The MegaRAID line from LSI is good, as are the new cards from Areca. Scott From owner-freebsd-stable@FreeBSD.ORG Sun May 1 14:41:44 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FA8D16A4CE for ; Sun, 1 May 2005 14:41:44 +0000 (GMT) Received: from mail.efacilitas.de (efacilitas.de [213.133.110.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB9A543D4C for ; Sun, 1 May 2005 14:41:43 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-39-77.dynamic.qsc.de [212.202.39.77]) by mail.efacilitas.de (Postfix) with ESMTP id CCD81123A75; Sun, 1 May 2005 16:40:32 +0200 (CEST) Received: from localhost (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id 1010E12B1B9; Sun, 1 May 2005 16:41:36 +0200 (CEST) Received: from eurystheus.local ([192.168.1.67]) by localhost (eurystheus.locaL [192.168.1.67]) (amavisd-new, port 10024) with ESMTP id 82037-03; Sun, 1 May 2005 16:41:31 +0200 (CEST) Received: from [192.168.1.67] (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id 032C312B1B8; Sun, 1 May 2005 16:41:30 +0200 (CEST) Message-ID: <4274EA9A.2060800@cs.tu-berlin.de> Date: Sun, 01 May 2005 16:41:30 +0200 From: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stuart@aurora-solutions.co.uk References: <4274E348.7040909@aurora-solutions.co.uk> In-Reply-To: <4274E348.7040909@aurora-solutions.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at example.com cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD & Serial ATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 01 May 2005 14:41:44 -0000 O'Reilly, Stuart wrote: > I'm in the process of building / upgrading a server and have chosen > FreeBSD to run it. One requirement is the ability to support RAID 1. > I am looking at adding a Serial ATA PCI card but i'm unsure which is > best. This is a low-budget suggestion: I have good experiences with RocketRAID 1520 and 1640. I'm running a 1640 with three SATA drives since one year without problems; it's just a little bit slow. Highpoint offers binary FreeBSD drivers for these controllers, but I think that people don't like this kind of support because Highpoint neglects it for older models and this dependency might be dangerous in future. Keep in mind: you'll get what you pay for. Regards Björn From owner-freebsd-stable@FreeBSD.ORG Sun May 1 15:45:14 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DA8816A4CE for ; Sun, 1 May 2005 15:45:14 +0000 (GMT) Received: from aurora-solutions.co.uk (aurora-solutions.co.uk [217.155.123.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CF9C43D1F for ; Sun, 1 May 2005 15:45:14 +0000 (GMT) (envelope-from stuart@aurora-solutions.co.uk) Received: from dsl-217-155-123-104.zen.co.uk ([217.155.123.104]) by aurora-solutions.co.uk with esmtpa (Exim 4.43) id 1DSGYV-00061p-19 for freebsd-stable@freebsd.org; Sun, 01 May 2005 16:40:28 +0100 Message-ID: <4274F989.8040303@aurora-solutions.co.uk> Date: Sun, 01 May 2005 16:45:13 +0100 From: "O'Reilly, Stuart" Organization: Aurora Solutions User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4274E348.7040909@aurora-solutions.co.uk> <4274EA9A.2060800@cs.tu-berlin.de> In-Reply-To: <4274EA9A.2060800@cs.tu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -5.4 (-----) X-Spam-Report: Content analysis details: (-5.4 points) pts rule name description -------------------------------------------------- -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 1% [score: 0.0000]white-list Subject: Re: FreeBSD & Serial ATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: stuart@aurora-solutions.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2005 15:45:14 -0000 %< ---- snipped ---- > This is a low-budget suggestion: > > I have good experiences with RocketRAID 1520 and 1640. I'm running a > 1640 with three SATA drives since one year without problems; it's just a > little bit slow. Highpoint offers binary FreeBSD drivers for these > controllers, but I think that people don't like this kind of support > because Highpoint neglects it for older models and this dependency might > be dangerous in future. Keep in mind: you'll get what you pay for. > > Regards > Björn I've been looking at the Highpoint RocketRAID controllers and seen that they come with FreeBSD drivers. It's just a question of what is good and what to avoid. I am prepared to spend between £40 - £70 on a mid range reliable card. I've done RAID setups in linux before (slackware) but never in FreeBSD so i'm looking for recommendations. Not worried about hot swapping capability. Stuart. From owner-freebsd-stable@FreeBSD.ORG Sun May 1 16:34:04 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3F6B16A4CE for ; Sun, 1 May 2005 16:34:04 +0000 (GMT) Received: from mail.efacilitas.de (efacilitas.de [213.133.110.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 202D443D3F for ; Sun, 1 May 2005 16:34:04 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-39-77.dynamic.qsc.de [212.202.39.77]) by mail.efacilitas.de (Postfix) with ESMTP id 8CF6B123939; Sun, 1 May 2005 18:32:52 +0200 (CEST) Received: from localhost (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id C95D312B1B8; Sun, 1 May 2005 18:33:55 +0200 (CEST) Received: from eurystheus.local ([192.168.1.67]) by localhost (eurystheus.locaL [192.168.1.67]) (amavisd-new, port 10024) with ESMTP id 89968-08; Sun, 1 May 2005 18:33:49 +0200 (CEST) Received: from [192.168.1.67] (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id 779D612B102; Sun, 1 May 2005 18:33:49 +0200 (CEST) Message-ID: <427504EC.9030709@cs.tu-berlin.de> Date: Sun, 01 May 2005 18:33:48 +0200 From: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stuart@aurora-solutions.co.uk References: <4274E348.7040909@aurora-solutions.co.uk> <4274EA9A.2060800@cs.tu-berlin.de> <4274F989.8040303@aurora-solutions.co.uk> In-Reply-To: <4274F989.8040303@aurora-solutions.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at example.com cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD & Serial ATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 01 May 2005 16:34:05 -0000 O'Reilly, Stuart wrote: > I've been looking at the Highpoint RocketRAID controllers and seen > that they come with FreeBSD drivers. It's just a question of what is > good and what to avoid. I am prepared to spend between £40 - £70 on a > mid range reliable card. £70 is not a hell of a lot. Highpoint offers only drivers up to 4.8 and 5.1 for a RR1520; it might be discontinued. The RR1640 is more comfortable because it attracts attention with a painful acoustic signal on hard disk failure. You can even reinitialise the controller or verify a disk array remote with a GUI from another machine. This is much for a controller of this price range. ;-) > I've done RAID setups in linux before (slackware) but never in FreeBSD > so i'm looking for recommendations. Not worried about hot swapping > capability. By the way, hot swapping works. Björn From owner-freebsd-stable@FreeBSD.ORG Sun May 1 17:15:09 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1568116A4CE for ; Sun, 1 May 2005 17:15:09 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 0D4B043D41 for ; Sun, 1 May 2005 17:15:08 +0000 (GMT) (envelope-from martin.dieringer@gmx.de) Received: (qmail invoked by alias); 01 May 2005 17:15:06 -0000 Received: from pD9E78110.dip0.t-ipconnect.de (EHLO dieringer.dyndns.org) [217.231.129.16] by mail.gmx.net (mp027) with SMTP; 01 May 2005 19:15:06 +0200 X-Authenticated: #21464393 Received: (qmail 1086 invoked by uid 1000); 1 May 2005 17:15:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 May 2005 17:15:05 -0000 Date: Sun, 1 May 2005 19:15:05 +0200 (CEST) From: Martin Dieringer To: freebsd-stable@freebsd.org Message-ID: <20050501191119.R873@pc.dieringer.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Y-GMX-Trusted: 0 Subject: sudden reboots when running vmware3 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Martin Dieringer List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 May 2005 17:15:09 -0000 I think I have this since I switched to 5.x. After a day or two the machine resets when I have vmware3 running (with windows XP). Without vmware it runs for weeks without problems. I updated the kernel yesterday, today it rebooted. Is this a known problem? Any ideas where this comes from? thanks martin From owner-freebsd-stable@FreeBSD.ORG Sun May 1 19:21:09 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6B1816A4CE for ; Sun, 1 May 2005 19:21:09 +0000 (GMT) Received: from smtp-one-2.wash.one.se (smtp-one-2.one.se [213.80.101.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09FB143D2D for ; Sun, 1 May 2005 19:21:09 +0000 (GMT) (envelope-from carl@thegoodone.mine.nu) Received: from localhost (smtp-one-2.local [127.0.0.1]) by re-injector2.wash.one.se (Postfix) with ESMTP id C6BBA66CEC9; Sun, 1 May 2005 19:20:49 +0000 (GMT) Received: from smtp-one-2.wash.one.se ([127.0.0.1]) by localhost (smtp-one-2.wash.one.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47959-02; Sun, 1 May 2005 19:20:48 +0000 (GMT) Received: from thegoodone.mine.nu (81-170-146-19.bahnhofbredband.net [81.170.146.19]) by smtp-one-2.wash.one.se (Postfix) with ESMTP id 7BAF866CEC7; Sun, 1 May 2005 19:20:47 +0000 (GMT) Message-ID: <42752C1F.80102@thegoodone.mine.nu> Date: Sun, 01 May 2005 21:21:03 +0200 From: Carl Gustavsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marco Stroosnijder , freebsd-stable@freebsd.org References: <0C9AA1AB019C4A44AE29659CF2BB203202E9C1@gir.routemaster.net> <4274B1B8.5080303@thegoodone.mine.nu> <1114971968.697.22.camel@freebsd.stromanz.org> In-Reply-To: <1114971968.697.22.camel@freebsd.stromanz.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0517-6, 2005-04-30), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: by amavisd-new at one.se (smtp-one-2) X-Spam-Status: No, hits=0.672 tagged_above=-999 required=7 tests=AWL, BAYES_05, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Subject: Re: wifi limited to 180KBps X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 01 May 2005 19:21:09 -0000 Marco Stroosnijder wrote: >Carl, > >Just a hunch... asymetric I/O in your pccard slot? >Try geting and puting files via ftp between the two hosts. >There is a big differance between getting and putting files!! >(number of reads and writes from "pccard slot") >I had problems with normal ethernet 100 Mbit pccards 750 KB max "write". > > > My wireless network consists of a server with a PCI wifi card (Netgear MA311) which acts as a accesspoint and a laptop (Dell Lattitude D600) with a Intel Pro/Wireless 2200BG mini-PCI card. The problem is with the MA311-card. >Wireless links have 2-10 % package loss by default. >To check for package loss or for a general bad link, I just use ping >-a/-A to hear if packets are lost. Ping will be auditable on i.e. in >case of failure, this beats the crap out of watching those sequence >numbers. This may also show succes and failure in bursts. > >Maybe you should (if possible) adjust the rate to 11Mbps or (try to) >"enforce" it from the "other side". Most likely using ifconfig +mediaopt > > >>wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >> >> > >According to the ifconfig output the wi0 interface is 2Mbps >(DS/2Mbps ) > >Further down your output you find this: > > >>TX rate (selection): [ 11 ] >>TX rate (actual speed): [ 2 ] >> >> > >2Mbit = (theo. aprox.) 256 KBytes - >minus package loss and other factors = 220 KBytes MAX (?)... >Maybe 180 KBytes is not so bad? > >My 2 cents, >Marco Stroosnijder > > The problem is that it won't set to 11Mbps. It's a bug. There is a hack to lock the rate at 11Mbps but when you got bad signal it don't go down as it should and you get high packet loss. See: http://lists.freebsd.org/pipermail/freebsd-hackers/2005-February/010102.html - Carl From owner-freebsd-stable@FreeBSD.ORG Sun May 1 20:47:48 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4567616A4CE for ; Sun, 1 May 2005 20:47:48 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 240E743D1D for ; Sun, 1 May 2005 20:47:48 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 1A07972DD9; Sun, 1 May 2005 13:47:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 1510072DCB for ; Sun, 1 May 2005 13:47:48 -0700 (PDT) Date: Sun, 1 May 2005 13:47:48 -0700 (PDT) From: Doug White To: freebsd-stable@freebsd.org Message-ID: <20050501133053.O3887@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Opteron deadlock fix committed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 01 May 2005 20:47:48 -0000 Hey folks, Yesterday I committed a workaround for a deadlock condition in RELENG_5 and RELENG_5_4 caused by errata in AMD Opteron and Athlon64 processors. (-CURRENT after April 8 is not affected due to changes in critical sections.) The deadlock appeared under heavy load, particularly with lots of I/O interrupts, in SMP environments on both FreeBSD/amd64 and FreeBSD/i386. Specifically, a spinwait as part of inter-processor TLB flushing triggered Errata 106, which causes the cache on the spinning processor to not update. To workaround the issue we enabled interrupts during the spinwait, which breaks the lock on the cache when an interrupt occurs. AMD also offers a workaround that the BIOS can implement, but not all systems have applied the errata. This workaround will appear in 5.4-RELEASE. In addition, I committed a KDB feature written by Stephen Uphoff (ups) to assist in debugging SMP situations where one processor is stuck with interrupts disabled. Since the regular cpustop IPI won't get through in that case, he implemented an NMI handler to perform the stop. This feature, compiled in with the kernel option KDB_STOP_NMI and activated by debug.kdb.stop_cpus_with_nmi, is available on all current branches and will ship with 5.4-RELEASE. If you have had problems with deadlock conditions on AMD processors in an SMP environment, we urge you to update to the latest RELENG_5, or try the upcoming 5.4-RC4. I want to thank the following individuals for their help in debugging and fixing the deadlock issue: Paul Vixie and Peter Losher at ISC Stephen Uphoff (ups) Alan Cox (alc) John Baldwin (jhb) The rest of the FreeBSD RE team -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Sun May 1 23:05:50 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D79B316A4CE for ; Sun, 1 May 2005 23:05:50 +0000 (GMT) Received: from gwmail1.grupos.com.br (gwmail1.grupos.com.br [66.90.64.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 491D343D2D for ; Sun, 1 May 2005 23:05:50 +0000 (GMT) (envelope-from marcus@corp.grupos.com.br) Received: from corp.grupos.com.br (unknown [150.162.166.55]) by gwmail1.grupos.com.br (Postfix) with ESMTP id 7F0B13EB18 for ; Sun, 1 May 2005 20:05:36 -0300 (BRT) Received: from [192.168.1.3] (unknown [200.180.5.227]) (Authenticated sender: marcus@corp.grupos.com.br) by corp.grupos.com.br (Postfix) with ESMTP id 1D50B559C for ; Sun, 1 May 2005 20:05:35 -0300 (BRT) Message-ID: <427560D1.1000704@corp.grupos.com.br> Date: Sun, 01 May 2005 20:05:53 -0300 From: Marcus Grando Organization: Grupos Internet User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Content-Type: multipart/mixed; boundary="------------090207010107040903030100" Subject: IPFILTER (LOR) and RELENG_5_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 01 May 2005 23:05:51 -0000 This is a multi-part message in MIME format. --------------090207010107040903030100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ipfilter show many backtraces (LOR) in dmesg, it's critical? Attached traces. -- Marcus Grando Grupos Internet S/A marcus(at)corp.grupos.com.br --------------090207010107040903030100 Content-Type: text/plain; name="debug.orca" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="debug.orca" Starting apache2. em0: Link is up 1000 Mbps Full Duplex lock order reversal 1st 0xc28d49b4 inp (udpinp) @ /usr/src/sys/netinet/udp_usrreq.c:772 2nd 0xc073a7c0 ipf filter rwlock (ipf filter rwlock) @ /usr/src/sys/contrib/ipfilter/netinet/fil.c:1107 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c074d3b0,c074bbf0,c071800c) at kdb_backtrace+0x29 witness_checkorder(c073a7c0,1,c06ccc8f,453) at witness_checkorder+0x544 _sx_slock(c073a7c0,c06ccc8f,453,0,c276b600) at _sx_slock+0x50 fr_check(c276b6c0,14,c23fe800,1,e74a7ad4) at fr_check+0x430 fr_check_wrapper(0,e74a7ad4,c23fe800,2,c28d4924) at fr_check_wrapper+0x2a pfil_run_hooks(c0771b80,e74a7b48,c23fe800,2,c28d4924) at pfil_run_hooks+0xbd ip_output(c276b600,0,e74a7b14,0,0) at ip_output+0x57e udp_output(c28d4924,c276b600,0,0,c2840780) at udp_output+0x493 udp_send(c28c9a20,0,c276b600,0,0) at udp_send+0x1a sosend(c28c9a20,0,e74a7c50,c276b600,0) at sosend+0x5e7 kern_sendit(c2840780,31,e74a7ccc,0,0) at kern_sendit+0x104 sendit(c2840780,31,e74a7ccc,0,82a1024) at sendit+0x161 sendto(c2840780,e74a7d14,6,7,202) at sendto+0x4d syscall(2f,2f,2f,8281000,3846de64) at syscall+0x227 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (133, FreeBSD ELF32, sendto), eip = 0x383f6b9b, esp = 0xbfbfddcc, ebp = 0xbfbfddf8 --- lock order reversal 1st 0xc29cf144 inp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:371 2nd 0xc073a7c0 ipf filter rwlock (ipf filter rwlock) @ /usr/src/sys/contrib/ipfilter/netinet/fil.c:1107 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c074d360,c074bbf0,c071800c) at kdb_backtrace+0x29 witness_checkorder(c073a7c0,1,c06ccc8f,453) at witness_checkorder+0x544 _sx_slock(c073a7c0,c06ccc8f,453,0,c2977a00) at _sx_slock+0x50 fr_check(c2977a40,14,c23fe800,1,e74cbb38) at fr_check+0x430 fr_check_wrapper(0,e74cbb38,c23fe800,2,c29cf0b4) at fr_check_wrapper+0x2a pfil_run_hooks(c0771b80,e74cbbac,c23fe800,2,c29cf0b4) at pfil_run_hooks+0xbd ip_output(c2977a00,0,e74cbb78,0,0) at ip_output+0x57e tcp_output(c29d01bc,c28ca800,c28ca798,c2845a80,e74cbca8) at tcp_output+0x1144 tcp_usr_connect(c28ca798,c2574a50,c2845a80) at tcp_usr_connect+0xeb soconnect(c28ca798,c2574a50,c2845a80,0,c27fa660) at soconnect+0x7c kern_connect(c2845a80,b,c2574a50,c2574a50,0) at kern_connect+0x74 connect(c2845a80,e74cbd14,3,0,292) at connect+0x2f syscall(2f,2f,2f,84e1c00,2) at syscall+0x227 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (98, FreeBSD ELF32, connect), eip = 0x3876eddb, esp = 0xbfabbba0, ebp = 0xbfabbbcc --- lock order reversal 1st 0xc0771fec tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:617 2nd 0xc073a7c0 ipf filter rwlock (ipf filter rwlock) @ /usr/src/sys/contrib/ipfilter/netinet/fil.c:1107 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c074d388,c074bbf0,c071800c) at kdb_backtrace+0x29 witness_checkorder(c073a7c0,1,c06ccc8f,453) at witness_checkorder+0x544 _sx_slock(c073a7c0,c06ccc8f,453,0,c28dde00) at _sx_slock+0x50 fr_check(c291e810,14,c23fe800,1,e4f3fae8) at fr_check+0x430 fr_check_wrapper(0,e4f3fae8,c23fe800,2,0) at fr_check_wrapper+0x2a pfil_run_hooks(c0771b80,e4f3fb5c,c23fe800,2,0) at pfil_run_hooks+0xbd ip_output(c28dde00,0,e4f3fb28,0,0,0) at ip_output+0x57e tcp_respond(0,c291e810,c291e824,c28dde00,f3553cd2,0,14) at tcp_respond+0x3e1 tcp_input(c28dde00,14,5bb7cbc8,0,0) at tcp_input+0x313b ip_input(c28dde00) at ip_input+0x539 netisr_processqueue(c0771218) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xbe ithread_loop(c2392680,e4f3fd48,c2392680,c052c5ec,0) at ithread_loop+0x124 fork_exit(c052c5ec,c2392680,e4f3fd48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4f3fd7c, ebp = 0 --- lock order reversal 1st 0xc077274c udp (udp) @ /usr/src/sys/netinet/udp_usrreq.c:246 2nd 0xc073a7c0 ipf filter rwlock (ipf filter rwlock) @ /usr/src/sys/contrib/ipfilter/netinet/fil.c:1107 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c074d3d8,c074bbf0,c071800c) at kdb_backtrace+0x29 witness_checkorder(c073a7c0,1,c06ccc8f,453) at witness_checkorder+0x544 _sx_slock(c073a7c0,c06ccc8f,453,0,c276a400) at _sx_slock+0x50 fr_check(c276a4c8,14,c23fe800,1,e4f3fb0c) at fr_check+0x430 fr_check_wrapper(0,e4f3fb0c,c23fe800,2,0) at fr_check_wrapper+0x2a pfil_run_hooks(c0771b80,e4f3fb80,c23fe800,2,0) at pfil_run_hooks+0xbd ip_output(c276a400,0,e4f3fb4c,0,0) at ip_output+0x57e icmp_send(c276a400,0,c276a400) at icmp_send+0x55 icmp_reflect(c276a400,c291f010,c276a4c8,14) at icmp_reflect+0x2d6 icmp_error(c28ddd00,3,3,0,0) at icmp_error+0x212 udp_input(c28ddd00,14,51b7cbc8,0,0) at udp_input+0x4d0 ip_input(c28ddd00) at ip_input+0x539 netisr_processqueue(c0771218) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xbe ithread_loop(c2392680,e4f3fd48,c2392680,c052c5ec,0) at ithread_loop+0x124 fork_exit(c052c5ec,c2392680,e4f3fd48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4f3fd7c, ebp = 0 --- Waiting on "ipf IP state rwlock" with the following non-sleepable locks held: exclusive sleep mutex inp (tcpinp) r = 0 (0xc3833bd0) locked @ /usr/src/sys/netinet/tcp_input.c:744 KDB: stack backtrace: kdb_backtrace(1,1,1,c23a6a80,c073a864) at kdb_backtrace+0x29 witness_warn(5,c0744cf4,c06dcc2a,c06cd145,c071800c) at witness_warn+0x19a cv_wait(c073a864,c0744cf4,0,0,92e2f6a1) at cv_wait+0xad _sx_slock(c073a840,c06ccf4b,643) at _sx_slock+0x68 fr_checkstate(c2929540,e4f3f9e0,0,c2929500,0) at fr_checkstate+0x4b1 fr_check(c2929540,14,c23fe800,1,e4f3fa88) at fr_check+0x51c fr_check_wrapper(0,e4f3fa88,c23fe800,2,c3833b40) at fr_check_wrapper+0x2a pfil_run_hooks(c0771b80,e4f3fafc,c23fe800,2,c3833b40) at pfil_run_hooks+0xbd ip_output(c2929500,0,e4f3fac8,0,0) at ip_output+0x57e tcp_output(c29a9378) at tcp_output+0x1144 tcp_input(c2927100,14,61b7cbc8,0,0) at tcp_input+0x2ec7 ip_input(c2927100) at ip_input+0x539 netisr_processqueue(c0771218) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xbe ithread_loop(c2392680,e4f3fd48,c2392680,c052c5ec,0) at ithread_loop+0x124 fork_exit(c052c5ec,c2392680,e4f3fd48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4f3fd7c, ebp = 0 --- Waiting on "ipf IP state rwlock" with the following non-sleepable locks held: exclusive sleep mutex inp (tcpinp) r = 0 (0xc37aaf54) locked @ /usr/src/sys/netinet/tcp_input.c:744 KDB: stack backtrace: kdb_backtrace(1,1,1,c23a6a80,c073a864) at kdb_backtrace+0x29 witness_warn(5,c0744cf4,c06dcc2a,c06cd145,c071800c) at witness_warn+0x19a cv_wait(c073a864,c0744cf4,0,0,6ce9de9a) at cv_wait+0xad _sx_slock(c073a840,c06ccf4b,643) at _sx_slock+0x68 fr_checkstate(c34f7c40,e4f3f9e0,0,c34f7c00,0) at fr_checkstate+0x4b1 fr_check(c34f7c40,14,c23fe800,1,e4f3fa88) at fr_check+0x51c fr_check_wrapper(0,e4f3fa88,c23fe800,2,c37aaec4) at fr_check_wrapper+0x2a pfil_run_hooks(c0771b80,e4f3fafc,c23fe800,2,c37aaec4) at pfil_run_hooks+0xbd ip_output(c34f7c00,0,e4f3fac8,0,0) at ip_output+0x57e tcp_output(c35c8000) at tcp_output+0x1144 tcp_input(c3546600,14,61b7cbc8,0,0) at tcp_input+0x2ec7 ip_input(c3546600) at ip_input+0x539 netisr_processqueue(c0771218) at netisr_processqueue+0x6e swi_net(0) at swi_net+0xbe ithread_loop(c2392680,e4f3fd48,c2392680,c052c5ec,0) at ithread_loop+0x124 fork_exit(c052c5ec,c2392680,e4f3fd48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4f3fd7c, ebp = 0 --- Waiting on "ipf IP state rwlock" with the following non-sleepable locks held: exclusive sleep mutex inp (tcpinp) r = 0 (0xc4530144) locked @ /usr/src/sys/netinet/tcp_usrreq.c:602 KDB: stack backtrace: kdb_backtrace(1,1,1,c2b76a80,c073a864) at kdb_backtrace+0x29 witness_warn(5,c0744cf4,c06dcc2a,c06cd145,c071800c) at witness_warn+0x19a cv_wait(c073a864,c0744cf4,0,0,b970a161) at cv_wait+0xad _sx_slock(c073a840,c06ccf4b,643) at _sx_slock+0x68 fr_checkstate(c2928540,e76499d8,0,c2928500,0) at fr_checkstate+0x4b1 fr_check(c2928540,14,c256e800,1,e7649a80) at fr_check+0x51c fr_check_wrapper(0,e7649a80,c256e800,2,c45300b4) at fr_check_wrapper+0x2a pfil_run_hooks(c0771b80,e7649af4,c256e800,2,c45300b4) at pfil_run_hooks+0xbd ip_output(c2928500,0,e7649ac0,0,0) at ip_output+0x57e tcp_output(c380f1bc) at tcp_output+0x1144 tcp_usr_rcvd(c655e510,0,c655e578,0,c06e66c3) at tcp_usr_rcvd+0x82 soreceive(c655e510,0,e7649c88,0,0) at soreceive+0xb79 soo_read(c3156374,e7649c88,c2f72980,0,c2b76a80) at soo_read+0x41 dofileread(c2b76a80,c3156374,9,80e2008,1000) at dofileread+0x95 read(c2b76a80,e7649d14,3,f,296) at read+0x3b syscall(2f,2f,2f,9,12c) at syscall+0x227 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x3829c5db, esp = 0xbfbfe7ec, ebp = 0xbfbfe818 --- --------------090207010107040903030100-- From owner-freebsd-stable@FreeBSD.ORG Mon May 2 00:41:48 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 231A916A4CE for ; Mon, 2 May 2005 00:41:48 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE0C143D1F for ; Mon, 2 May 2005 00:41:47 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j420fgXB031871; Sun, 1 May 2005 20:41:42 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31349-07; Sun, 1 May 2005 20:41:42 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j420fbLw031851; Sun, 1 May 2005 20:41:37 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.12.11) with ESMTP id j420fVqD090876; Sun, 1 May 2005 20:41:31 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050501203904.04dc2288@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sun, 01 May 2005 20:41:12 -0400 To: stuart@aurora-solutions.co.uk, freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <4274E348.7040909@aurora-solutions.co.uk> References: <4274E348.7040909@aurora-solutions.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b Subject: Re: FreeBSD & Serial ATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 00:41:48 -0000 At 10:10 AM 01/05/2005, O'Reilly, Stuart wrote: >The system is a P4 1.8Ghz system with 512MB RAM and 2 x 80GB drives >running in RAID 1. The system will be co-lo'd so something reliable is >required. I have had really good luck with the 3ware 8xxx cards for some time. A 2 port version can be had for ~$100USD. I have quite a few running 4.x and now RELENG_5 with great results. You can also pull off the SMART info from the drives via the smartmontools as well as monitor the status via CLI and httpd apps. ---Mike From owner-freebsd-stable@FreeBSD.ORG Mon May 2 03:20:32 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7478516A4CE for ; Mon, 2 May 2005 03:20:32 +0000 (GMT) Received: from proxy.ddcom.co.jp (proxy.ddcom.co.jp [211.121.191.163]) by mx1.FreeBSD.org (Postfix) with SMTP id B488E43D55 for ; Mon, 2 May 2005 03:20:31 +0000 (GMT) (envelope-from rees@ddcom.co.jp) Received: (qmail 18915 invoked by alias); 2 May 2005 03:32:19 -0000 Received: from unknown (HELO matthew) (10.10.10.11) by mail.ddcom.local with SMTP; 2 May 2005 03:32:19 -0000 Date: Mon, 02 May 2005 12:20:30 +0900 From: Joel To: freebsd-stable@freebsd.org In-Reply-To: <42714CD9.5080104@elischer.org> References: <20050428204732.GA3804@panix.com> <42714CD9.5080104@elischer.org> Message-Id: <20050502121827.22C8.REES@ddcom.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.00.06 Subject: Re: USB changes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 03:20:32 -0000 On Thu, 28 Apr 2005 13:51:37 -0700 Julian Elischer wrote > > > Joe Altman wrote: > > >On Thu, Apr 28, 2005 at 01:40:50PM -0700, Julian Elischer wrote: > > > > > >>Since I can't make this happen here, I'm going to need help.. > >> > >> > > > >What do you need? Relatively speaking, I'm sort of a newbie at the > >more complex aspects of bugs, and this strikes me as somewhat complex. > > > >But if you are willing to tell me what you need, and how to proceed or > >what to read to help you, I'll do what I can. > > > > > > I asked you to add 2 lines to that file and try again. If I were Joe, I'd be wondering if that meant re-compiling the kernel. Did this go anywhere? (I also have UHB hardware that fusses on boot.) -- Joel Rees digitcom, inc. $B3t<02q ** From owner-freebsd-stable@FreeBSD.ORG Mon May 2 06:02:54 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76E2A16A4CE for ; Mon, 2 May 2005 06:02:54 +0000 (GMT) Received: from tehran.sytes.net (c23-52.icpnet.pl [62.21.23.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id B77AD43D2F for ; Mon, 2 May 2005 06:02:53 +0000 (GMT) (envelope-from weirdo@tehran.sytes.net) Received: by tehran.sytes.net (Postfix, from userid 1001) id 74C8D621F; Mon, 2 May 2005 08:02:50 +0200 (CEST) Date: Mon, 2 May 2005 08:02:50 +0200 From: =?utf-8?Q?Stanis=C5=82aw?= Halik To: freebsd-stable@freebsd.org Message-ID: <20050502060250.GA15424@tehran.sytes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: crash on forwarding ipv6 packets with ipfilter X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 06:02:54 -0000 hello, I got a strange crash which is was happening all along from 5.3. I wasn't mentioning it, because there was 'ipfilter mpsafe fixes' position in 5.4 todo list, but it looks that crash is happening no matter these fixes are on or not. To help with freebsd sourcerouting problems (different default gateways for different interfaces), I tried forwarding ipv6 packets to correct gateway: #v+ weirdo:~$ cat /etc/ipf.rules pass out quick on gif0 to gif1:3ffe:80ef:900:1::1 from 3ffe:80ee:2479::/48 to any #v- I also added routes like `route add gif1:3ffe:80ef:900:1::1 -iface gif1', of course. And here's the crash: I'm using dhcp client to obtain my ipv4 address, which changes over time; when interface is down and there are forwarded packets passing by, system will hang. I'm using x11, symptoms are: stopped mouse cursor and music stopped playing (;->). To reproduce this, simply add a forward rule for ipv6 packets and /etc/rc.d/dhclient stop, or `DOWN' interface in some other way (alhrough i'm no ifconfig expert). I would be very grateful if you would help me this problem, as I'd like to be able to have multiple default gateways for ipv6 tunnels. regards, -- Stanislaw Halik :: http://weirdo.ltd.pl From owner-freebsd-stable@FreeBSD.ORG Mon May 2 08:14:40 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9B4116A4CE; Mon, 2 May 2005 08:14:40 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30E7743D54; Mon, 2 May 2005 08:14:40 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DSW4c-00041V-Ll; Mon, 02 May 2005 11:14:38 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 May 2005 11:14:38 +0300 From: Danny Braniss Message-ID: cc: stable@freebsd.org Subject: MNT_USER? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 08:14:41 -0000 after doing a mount_nfs as root (from the console or via su), statfs reports that MNT_USER flags is set! this is also true with 5.4. is this a bug or feature? the problem can be seen with: #include #include #include #include int main(int argc, char *argv[]) { struct statfs stbuf; int fd; if (argc != 2) { fprintf(stderr, "Usage: noexec directory\n"); return -1; } if (statfs(argv[1], &stbuf) != 0) { perror("statfs"); return -1; } printf("FLAGS: 0x%08X\n", stbuf.f_flags); if (stbuf.f_flags & MNT_NOEXEC) printf("MNT_NOEXEC\n"); return 0; } From owner-freebsd-stable@FreeBSD.ORG Mon May 2 09:01:20 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9918116A4CE for ; Mon, 2 May 2005 09:01:20 +0000 (GMT) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2254343D53 for ; Mon, 2 May 2005 09:01:20 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from Sonomago (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 813DF19F3B for ; Mon, 2 May 2005 02:01:35 -0700 (PDT) From: "Darren Pilgrim" To: Date: Mon, 2 May 2005 02:01:06 -0700 Message-ID: <000001c54ef5$7d6767d0$0a2a15ac@Sonomago> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Subject: ndis with Intel 2915 wireless, getting "NDIS ERROR" messages and deattach on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 09:01:20 -0000 I'm trying to get my wireless NIC working using the ndis driver, but during boot I get an attach, a stream of what appear to be errors, followed by "device_attach: ndis0 attach returned 6". The basic specs for the configuration are: FreeBSD src: RELENG_5 as of 2005/04/30, about 4pm PDT (-0700) Machine: Dell Inspiron 6000 NIC: Intel PRO/Wireless 2915ABG miniPCI (Dell PCI ID) NDIS drivers: Windows 2000 (NDIS 5.0), driver file is "w29n50.sys" Windows XP (NDIS 5.1), driver file is "w29n51.sys" I could not find non-NT drivers for this NIC. Both drivers produce the following output during boot: ndis0: mem 0xdfcfd000-0xdfcfdfff irq 5 at device 3.0 on pci3 ndis0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xdfcfd000 ndis0: [MPSAFE] ndis0: NDIS API version: ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x2fb ndis0: NDIS ERROR: c00013a7 (unknown error) ndis0: NDIS NUMERRORS: 2 ndis0: argptr: 0x4e4f4c41 ndis0: argptr: 0x191 ndis0: NDIS ERROR: c000138d (unknown error) ndis0: NDIS NUMERRORS: 0 ndis0: init handler failed device_attach: ndis0 attach returned 6 Subsequent boots appear to produce identical data. The dmesg outputs for each driver and the driver files themselves are available upon request. Is this fixed in -current? From owner-freebsd-stable@FreeBSD.ORG Mon May 2 09:24:45 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31FFF16A4CE for ; Mon, 2 May 2005 09:24:45 +0000 (GMT) Received: from aurora-solutions.co.uk (aurora-solutions.co.uk [217.155.123.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id C82F943D2D for ; Mon, 2 May 2005 09:24:44 +0000 (GMT) (envelope-from stuart@aurora-solutions.co.uk) Received: from dsl-217-155-123-104.zen.co.uk ([217.155.123.104]) by aurora-solutions.co.uk with esmtpa (Exim 4.43) id 1DSX5k-00005s-JK for freebsd-stable@freebsd.org; Mon, 02 May 2005 10:19:54 +0100 Message-ID: <4275F1DC.1020501@aurora-solutions.co.uk> Date: Mon, 02 May 2005 10:24:44 +0100 From: "O'Reilly, Stuart" Organization: Aurora Solutions User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4274E348.7040909@aurora-solutions.co.uk> <6.2.1.2.0.20050501203904.04dc2288@64.7.153.2> In-Reply-To: <6.2.1.2.0.20050501203904.04dc2288@64.7.153.2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -5.4 (-----) X-Spam-Report: Content analysis details: (-5.4 points) pts rule name description -------------------------------------------------- -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 1% [score: 0.0000]white-list Subject: Re: FreeBSD & Serial ATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: stuart@aurora-solutions.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 09:24:45 -0000 %< --------- snipped > I have had really good luck with the 3ware 8xxx cards for some time. A > 2 port version can be had for ~$100USD. I have quite a few running 4.x > and now RELENG_5 with great results. You can also pull off the SMART > info from the drives via the smartmontools as well as monitor the status > via CLI and httpd apps. > > ---Mike Mike, Do you have any information on where I might obtain the 3ware range in the UK. I had a look at their website and they listed a couple of suppliers in the UK, but I can't find any e-shops which sell them. Stuart. From owner-freebsd-stable@FreeBSD.ORG Mon May 2 10:33:38 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B758216A4CE for ; Mon, 2 May 2005 10:33:38 +0000 (GMT) Received: from smtp-one-2.wash.one.se (smtp-one-2.one.se [213.80.101.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30E3543D54 for ; Mon, 2 May 2005 10:33:36 +0000 (GMT) (envelope-from carl@thegoodone.mine.nu) Received: from localhost (smtp-one-2.local [127.0.0.1]) by re-injector2.wash.one.se (Postfix) with ESMTP id 1CDB666C906; Mon, 2 May 2005 10:33:16 +0000 (GMT) Received: from smtp-one-2.wash.one.se ([127.0.0.1]) by localhost (smtp-one-2.wash.one.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67144-02; Mon, 2 May 2005 10:33:14 +0000 (GMT) Received: from thegoodone.mine.nu (81-170-146-19.bahnhofbredband.net [81.170.146.19]) by smtp-one-2.wash.one.se (Postfix) with ESMTP id F3C4C66C907; Mon, 2 May 2005 10:33:13 +0000 (GMT) Message-ID: <427601FA.7080106@thegoodone.mine.nu> Date: Mon, 02 May 2005 12:33:30 +0200 From: Carl Gustavsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren Pilgrim References: <000001c54ef5$7d6767d0$0a2a15ac@Sonomago> In-Reply-To: <000001c54ef5$7d6767d0$0a2a15ac@Sonomago> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0517-6, 2005-04-30), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: by amavisd-new at one.se (smtp-one-2) X-Spam-Status: No, hits=-0.459 tagged_above=-999 required=7 tests=AWL, BAYES_00, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: cc: freebsd-stable@freebsd.org Subject: Re: ndis with Intel 2915 wireless, getting "NDIS ERROR" messages and deattach on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 10:33:38 -0000 Have you tested the iwi-driver? See: http://damien.bergamini.free.fr/ipw/iwi-freebsd.html From owner-freebsd-stable@FreeBSD.ORG Mon May 2 11:33:02 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 287C316A4CE for ; Mon, 2 May 2005 11:33:02 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5D4C43D55 for ; Mon, 2 May 2005 11:33:01 +0000 (GMT) (envelope-from robbak@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1433016wri for ; Mon, 02 May 2005 04:33:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Kkrx+vr2bwVFSRtFuyoYwlosCU0tnmUb3EDsmOKuVSShBDO69QprO+kTR8Dm6KanM/9o9kwZXiii64UtmTAy5eUbni2MqUC8RsfdEoEnLtV4cDX3/ibrjKzF6vTxkYadkFTuyfvYO6LNSyD0sJjY80C9AWezvGL3Ib2jU8fAyXE= Received: by 10.54.48.21 with SMTP id v21mr521946wrv; Mon, 02 May 2005 04:33:01 -0700 (PDT) Received: by 10.54.14.15 with HTTP; Mon, 2 May 2005 04:33:01 -0700 (PDT) Message-ID: Date: Mon, 2 May 2005 21:33:01 +1000 From: Robert Backhaus To: freebsd-stable@freebsd.org In-Reply-To: <443bt7rsjs.fsf@be-well.ilk.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050430120037.5448916A4DF@hub.freebsd.org> <1114947298.71683.17.camel@jayton.ath.cx> <443bt7rsjs.fsf@be-well.ilk.org> cc: jay@codegurus.org Subject: Re: Weird jdk14 build X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Robert Backhaus List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 11:33:02 -0000 On 01 May 2005 09:20:55 -0400, Lowell Gilbert wrote: > Jayton Garnett writes: >=20 > > Hello, > > > > This weekend i've been reinstalling fbsd on my desktop and while > > installing /usr/ports/java//jdk14 (yes i downloaded all the files from > > sun and the patch-kit) While it was compiling I had a syntax error > > something like expected "(" somewhere or other, but i noticed this > > little message before that error: > > > > =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=3D=3D=3D > > Warning: This JDK may be unstable. You are advised to use the native > > FreeBSD JDK, in ports/java/jdk14. <> > No; you need to use Java to build Java. Therefore, the procedure is > to use the precompiled Linux jdk to build the native one. Once the > native one is built, you can remove the Linux one. To further clarify: That message is being produced while installing a linux JDK, which is needed to bootstrap the new native build. Yes, it's really annoying. To save this annoyance, make a package of it when you are done, merely for your own use, however. the linux JDK can (and should) be 'pkg_deinstall'ed when you are done.=20 pkg_deinstall linux-sun-jdk1.4\* From owner-freebsd-stable@FreeBSD.ORG Mon May 2 12:29:29 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67E2316A4CE for ; Mon, 2 May 2005 12:29:29 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DC5543D3F for ; Mon, 2 May 2005 12:29:28 +0000 (GMT) (envelope-from jameskamlyn@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so2246528nzk for ; Mon, 02 May 2005 05:29:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=WTh+wrfMjtVjyShrG5jMjaYUu2pMTH9jB18H3Gi5vPO5+PA5QZkrFDTmLRF5oovRRuXXO0wmTAbpdskg6Kja8YWKWackIH41t+yQzU4EAWj2+bnIV9NUd6IXZ/2TDDVkkGeZWnX/2cW3grF+3Khio0ehf8JNpuL9Ss+oogGEexY= Received: by 10.36.101.20 with SMTP id y20mr248131nzb; Mon, 02 May 2005 05:29:28 -0700 (PDT) Received: by 10.36.41.8 with HTTP; Mon, 2 May 2005 05:29:28 -0700 (PDT) Message-ID: Date: Mon, 2 May 2005 13:29:28 +0100 From: James Kamlyn To: stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Fatal trap on boot with RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: James Kamlyn List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 12:29:29 -0000 Hi, I'm getting a fatal trap shortly after boot on an up to date 5.4-STABLE box that had previously run 4.11-STABLE flawlessly. Without the debugging options in the kernel the box just locks up. For reference the motherboard is a Abit VH6. If you need any more details, please let me know. Regards, James. kernel trap 1 with interrupts disabled Fatal trap 1: privileged instruction fault while in kernel mode instruction pointer =3D 0x8:0xc04feae4 stack pointer =3D 0x10:0xdc4d9be8 frame pointer =3D 0x10:0xdc4d9bec code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 11 (idle) [thread pid 11 tid 100003 ] Stopped at _mtx_unlock_spin_flags+0x30: cmpl $0xc06bc6e4,0(%ebx) db> wh Tracing pid 11 tid 100003 td 0xc19fd480 _mtx_unlock_spin_flags(c06eb9e0,0,c06890ab,68d,c06e8400) at _mtx_unlock_spin_flags+0x30 witness_lock_list_get(c06ed230,c19fd480,c06e8400,e3,dc4d9c44) at witness_lock_list_get+0x8d witness_lock(c06e8400,a,c0682572,e3,dc4d9cb8) at witness_lock+0xae _mtx_lock_spin_flags(c06e8400,2,c0682572,e3,dc4d9cb8) at _mtx_lock_spin_flags+0xa4 hardclock(dc4d9cb8) at hardclock+0x4a clkintr(dc4d9cb8) at clkintr+0x87 intr_execute_handlers(c06d89c0,dc4d9cb8,c19fcc5c,c04f4018,0) at intr_execute_handlers+0x91 atpic_handle_intr(0) at atpic_handle_intr+0x92 Xatpic_intr0() at Xatpic_intr0+0x20 --- interrupt, eip =3D 0xc0641ed5, esp =3D 0xdc4d9cfc, ebp =3D 0xdc4d9cfc -= -- cpu_idle_default(dc4d9d0c,c04f4041,dc4d9d24,c04f3e70,0) at cpu_idle_default= +0x5 cpu_idle(dc4d9d24,c04f3e70,0,dc4d9d38,0) at cpu_idle+0x1f idle_proc(0,dc4d9d38,0,c04f4018,0) at idle_proc+0x29 fork_exit(c04f4018,0,dc4d9d38) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip =3D 0, esp =3D 0xdc4d9d6c, ebp =3D 0 --- db> # kgdb kernel.debug /var/crash/vmcore.15=20 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you ar= e welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:160 160 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:160 #1 0xc05064e0 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 10 #2 0xc050678b in panic (fmt=3D0xc0673317 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc0466c71 in db_panic (addr=3D-1068504348, have_addr=3D0, count=3D-1,= =20 modif=3D0xdc4d9a40 "") at /usr/src/sys/ddb/db_command.c:435 #4 0xc0466c08 in db_command (last_cmdp=3D0xc06dcda4, cmd_table=3D0x0,=20 aux_cmd_tablep=3D0xc06a7a3c, aux_cmd_tablep_end=3D0xc06a7a40) at /usr/src/sys/ddb/db_command.c:349 #5 0xc0466cd0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #6 0xc0468855 in db_trap (type=3D1, code=3D0) at /usr/src/sys/ddb/db_main.= c:221 #7 0xc051c736 in kdb_trap (type=3D1, code=3D0, tf=3D0xdc4d9ba8) at /usr/src/sys/kern/subr_kdb.c:468 #8 0xc064a7e5 in trap_fatal (frame=3D0xdc4d9ba8, eva=3D0) at /usr/src/sys/i386/i386/trap.c:812 #9 0xc064a39c in trap (frame=3D {tf_fs =3D 24, tf_es =3D -999423984, tf_ds =3D -1066532848, tf_edi = =3D -1066218188, tf_esi =3D 227, tf_ebp =3D -598893588, tf_isp =3D -598893612, tf_ebx =3D -1066485280, tf_edx =3D 1677, tf_ecx =3D -1066889045, tf_eax =3D -1046489984, tf_trapno =3D 1, tf_err =3D 0, tf_eip =3D - 1068504348, tf_cs =3D 8, tf_eflags =3D 65666, tf_esp =3D -1066336984, tf_ss =3D -598893560}) at /usr/src/sys/i386/i386/trap.c:622 #10 0xc063abfa in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #11 0x00000018 in ?? () #12 0xc46e0010 in ?? () ---Type to continue, or q to quit--- #13 0xc06e0010 in default_fkeytab () #14 0xc072cd34 in __pcpu () #15 0x000000e3 in ?? () #16 0xdc4d9bec in ?? () #17 0xdc4d9bd4 in ?? () #18 0xc06eb9e0 in w_lock_list_free () #19 0x0000068d in ?? () #20 0xc06890ab in ?? () #21 0xc19fd480 in ?? () #22 0x00000001 in ?? () #23 0x00000000 in ?? () #24 0xc04feae4 in _mtx_unlock_spin_flags (m=3D0xc06eb9e0, opts=3D0, file=3D= 0x0,=20 line=3D0) at /usr/src/sys/kern/kern_mutex.c:387 #25 0xc0525f01 in witness_lock_list_get () at /usr/src/sys/kern/subr_witness.c:1677 #26 0xc0524f0a in witness_lock (lock=3D0xc06e8400, flags=3D0,=20 file=3D0xc0682572 "/usr/src/sys/kern/kern_clock.c", line=3D227) at /usr/src/sys/kern/subr_witness.c:990 #27 0xc04feaac in _mtx_lock_spin_flags (m=3D0xc06e8400, opts=3D2,=20 file=3D0xc0682572 "/usr/src/sys/kern/kern_clock.c", line=3D227) at /usr/src/sys/kern/kern_mutex.c:380 #28 0xc04e2c46 in hardclock (frame=3D0xdc4d9cb8) at /usr/src/sys/kern/kern_clock.c:227 #29 0xc064ceef in clkintr (frame=3D0xdc4d9cb8) ---Type to continue, or q to quit--- at /usr/src/sys/i386/isa/clock.c:191 #30 0xc063e42d in intr_execute_handlers (isrc=3D0xc06d89c0, iframe=3D0xdc4d= 9cb8) at /usr/src/sys/i386/i386/intr_machdep.c:201 #31 0xc064cd92 in atpic_handle_intr (iframe=3D {if_vec =3D 0, if_fs =3D 24, if_es =3D -598933488, if_ds =3D -1068564464, if_edi =3D 0, if_esi =3D -1068548072, if_ebp =3D -598893316, if_ebx =3D -1046492068, if_edx =3D -1066498048, if_ecx =3D 2, if_eax =3D 0, if_eip =3D -1067180331, if_cs =3D 8, if_eflags =3D 582, if_esp =3D -5 98893308, if_ss =3D -1067180297}) at /usr/src/sys/i386/isa/atpic.c:558 #32 0xc063ac90 in Xatpic_intr0 () at atpic_vector.s:70 #33 0x00000000 in ?? () #34 0x00000018 in ?? () #35 0xdc4d0010 in ?? () #36 0xc04f0010 in knote_alloc (waitok=3D-598893300) at uma.h:275 #37 0xc0641ef7 in cpu_idle () at /usr/src/sys/i386/i386/machdep.c:1135 #38 0xc04f4041 in idle_proc (dummy=3D0x0) at /usr/src/sys/kern/kern_idle.c:= 120 #39 0xc04f3e70 in fork_exit (callout=3D0xc04f4018 , arg=3D0x0,= =20 frame=3D0xdc4d9d38) at /usr/src/sys/kern/kern_fork.c:791 #40 0xc063ac5c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 209 (kgdb) list *0xc04feae4 0xc04feae4 is in _mtx_unlock_spin_flags (/usr/src/sys/kern/kern_mutex.c:388= ). 383 void 384 _mtx_unlock_spin_flags(struct mtx *m, int opts, const char *file, int line) 385 { 386 =20 387 MPASS(curthread !=3D NULL); 388 KASSERT(m->mtx_object.lo_class =3D=3D &lock_class_mtx_spin, 389 ("mtx_unlock_spin() of sleep mutex %s @ %s:%d", 390 m->mtx_object.lo_name, file, line)); 391 WITNESS_UNLOCK(&m->mtx_object, opts | LOP_EXCLUSIVE, file, line); 392 LOCK_LOG_LOCK("UNLOCK", &m->mtx_object, opts, m->mtx_recurse, file, (kgdb) KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2005 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 5.4-STABLE #1: Sun May 1 22:07:54 UTC 2005 root@ignite:/usr/obj/usr/src/sys/IGNITE WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (935.47-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x686 Stepping =3D 6 Features=3D0x383f9ff real memory =3D 805240832 (767 MB) avail memory =3D 782434304 (746 MB) npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: mem 0xd4000000-0xd4ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xe000-0xe00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 viapropm0: SMBus I/O base at 0x5000 viapropm0: SMBus I/O base at 0x5000 viapropm0: SMBus revision code 0x0 smbus0: on viapropm0 smb0: on smbus0 fxp0: port 0xec00-0xec1f mem 0xd7000000-0xd70fffff,0xd7100000-0xd7100fff irq 11 at device 15.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:08:c7:99:45:26 orm0: at iomem 0xc8000-0xc87ff,0xc0000-0xc7fff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 935465664 Hz quality 800 Timecounters tick every 10.000 msec Expensive timeout(9) function: 0xc0538004(0) 0.005552378 s ad0: 114473MB [232581/16/63] at ata0-master UDMA66 From owner-freebsd-stable@FreeBSD.ORG Mon May 2 12:51:14 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86A9E16A4CF for ; Mon, 2 May 2005 12:51:14 +0000 (GMT) Received: from 82-168-79-254-bbxl.xdsl.tiscali.nl (82-168-75-155-bbxl.xdsl.tiscali.nl [82.168.75.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B08E43D2F for ; Mon, 2 May 2005 12:51:13 +0000 (GMT) (envelope-from rene@82-168-79-254-bbxl.xdsl.tiscali.nl) Received: from 82-168-79-254-bbxl.xdsl.tiscali.nl (localhost [127.0.0.1]) j42CpAd7001014; Mon, 2 May 2005 14:51:10 +0200 (CEST) (envelope-from rene@82-168-79-254-bbxl.xdsl.tiscali.nl) Received: (from rene@localhost)j42Cp5V2001013; Mon, 2 May 2005 14:51:05 +0200 (CEST) (envelope-from rene) Date: Mon, 2 May 2005 14:51:05 +0200 From: Rene Ladan To: stable@freebsd.org, bzeeb+freebsd+lor@zabbadoz.net Message-ID: <20050502125104.GA987@82-168-79-254-bbxl.xdsl.tiscali.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: bpf/fxp RELENG_5 LOR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 12:51:14 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD 5.4-STABLE #0: Mon May 2 02:26:10 CEST 2005 root@82-168-79-254-bbxl.xdsl.tiscali.nl:/usr/obj/usr/src/sys/RENE #tcpdump fxp0: promiscuous mode enabled lock order reversal 1st 0xc066de80 bpf global lock (bpf global lock) @ /usr/src/sys/net/bpf.c:= 385 2nd 0xc14c9264 fxp0 (network driver) @ /usr/src/sys/modules/fxp/../../dev/= fxp/if_fxp.c:2394 KDB: stack backtrace: kdb_backtrace(c05fd3e5,c14c9264,c14a47e0,c06fe820,c06fe7bd) at 0xc04b0aee = =3D kdb_backtrace+0x2e witness_checkorder(c14c9264,9,c06fe7bd,95a,c0648ec0) at 0xc04bbb86 =3D witn= ess_checkorder+0x6a6 _mtx_lock_flags(c14c9264,0,c06fe7bd,95a,c14c9264) at 0xc048a9ca =3D _mtx_lo= ck_flags+0x8a fxp_ioctl(c14c9000,80206910,cae60aa8,c06212fc,c156d9dc) at 0xc06fe14e =3D f= xp_ioctl+0x5e ifpromisc(c14c9000,0,c06024ea,129,c1cdd200) at 0xc050a358 =3D ifpromisc+0xe8 bpf_detachd(c1cdd200,0,c06024ea,181,c1bfa528) at 0xc0504d85 =3D bpf_detachd= +0xe5 bpfclose(c1b07700,1,2000,c19d1000,c0628e20) at 0xc0504ff4 =3D bpfclose+0xb4 spec_close(cae60b70,cae60b98,c0500ba7,cae60b70,1) at 0xc04542d8 =3D spec_cl= ose+0x378 spec_vnoperate(cae60b70,1,c060242a,140,c063ad40) at 0xc0452e58 =3D spec_vno= perate+0x18 vn_close(c1bfa528,1,c198cd00,c19d1000,c066d240) at 0xc0500ba7 =3D vn_close+= 0x67 vn_closefile(c1d82a18,c19d1000,c05f685f,849,c1d82a18) at 0xc0501d34 =3D vn_= closefile+0xc4 fdrop_locked(c1d82a18,c19d1000,c05f685f,834) at 0xc0471cde =3D fdrop_locked= +0xbe fdrop(c1d82a18,c19d1000,c05f685f,77c,cae60c7c,c04bc210,c066d240,cae60c78,c0= 4bbc67,0,c1cdd32c,246,c06212fc,c1cdd32c,3ea,c05f685f,cae60ca0,c048aada,c1cd= d32c,1,c05f9016,12b) at 0xc0471c0c =3D fdrop+0x3c closef(c1d82a18,c19d1000,c05f685f,3ea,c19d1000) at 0xc0470032 =3D closef+0x= 3d2 close(c19d1000,cae60d04,4,439,1) at 0xc046cfdc =3D close+0x22c syscall(2f,2f,2f,280f1a2d,817f000) at 0xc05d9fe0 =3D syscall+0x2c0 Xint0x80_syscall() at 0xc05c885f =3D Xint0x80_syscall+0x1f --- syscall (6, FreeBSD ELF32, close), eip =3D 0x282506df, esp =3D 0xbfbfea= bc, ebp =3D 0xbfbfead8 --- KDB: enter: witness_checkorder fxp0: promiscuous mode disabled --=20 "It won't fit on the line." -- me, 2001 --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCdiI4vz70qa4zXcwRAtS1AJ4laW9eK1n8WyKzEvr21+3UelwsiACgpE+6 MhphO04reSOec45CXojYz5o= =KmLa -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-stable@FreeBSD.ORG Mon May 2 13:45:11 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBB4D16A4CE for ; Mon, 2 May 2005 13:45:11 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6194C43D3F for ; Mon, 2 May 2005 13:45:11 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DSbEU-000Bhv-Gf; Mon, 02 May 2005 16:45:10 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Matthew Jacob In-reply-to: Your message of Thu, 14 Apr 2005 11:31:37 -0700 . Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 02 May 2005 16:45:10 +0300 From: Danny Braniss Message-ID: cc: stable@freebsd.org Subject: Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 13:45:11 -0000 > Yes, the 234X cards have been supported for quite a while. > = it seems not all of them: it's a QLA2342/ISP2312 and im getting: isp1: port 0x2400-0x24ff mem = 0xfe8e0000-0xfe8e0fff irq 24 at device 8.0 on pci3 isp1: bad execution throttle of 0- using 16 isp2: port 0x2000-0x20ff mem = 0xfe8f0000-0xfe8f0fff irq 27 at device 8.1 on pci3 isp2: bad execution throttle of 0- using 16 > DELL has a clone card which up until recently wasn't supported. > = > The 236X/63XX cards are not yet supported. > = > On 4/14/05, wsk wrote: > > folks: > > Can the Qlogic 2340 Fibre Channel card works on FreeBSD now? > > DELL released a newest Server PE6850 with this card.thx > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= =2Eorg" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > = From owner-freebsd-stable@FreeBSD.ORG Mon May 2 13:49:13 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAD4916A4CE for ; Mon, 2 May 2005 13:49:13 +0000 (GMT) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B2A143D55 for ; Mon, 2 May 2005 13:49:13 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr8.xs4all.nl (8.12.11/8.12.11) with ESMTP id j42Dn6su071564; Mon, 2 May 2005 15:49:06 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.3/8.13.1) with ESMTP id j42Dn5BQ015708; Mon, 2 May 2005 15:49:05 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.3/8.13.1/Submit) id j42Dn5Td015707; Mon, 2 May 2005 15:49:05 +0200 (CEST) (envelope-from wb) Date: Mon, 2 May 2005 15:49:05 +0200 From: Wilko Bulte To: Danny Braniss Message-ID: <20050502134905.GA15646@freebie.xs4all.nl> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.4-STABLE User-Agent: Mutt/1.5.9i X-Virus-Scanned: by XS4ALL Virus Scanner cc: Matthew Jacob cc: stable@freebsd.org Subject: Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 13:49:14 -0000 On Mon, May 02, 2005 at 04:45:10PM +0300, Danny Braniss wrote.. > > Yes, the 234X cards have been supported for quite a while. > > > it seems not all of them: > it's a QLA2342/ISP2312 and im getting: > isp1: port 0x2400-0x24ff mem > 0xfe8e0000-0xfe8e0fff irq 24 at device 8.0 on pci3 > isp1: bad execution throttle of 0- using 16 > isp2: port 0x2000-0x20ff mem > 0xfe8f0000-0xfe8f0fff irq 27 at device 8.1 on pci3 > isp2: bad execution throttle of 0- using 16 Have you loaded the ispfw.ko firmware module? Matt tests the driver against that firmware, not against all the firmware revs Qlogic has released over time. > > > DELL has a clone card which up until recently wasn't supported. > > > > The 236X/63XX cards are not yet supported. > > > > On 4/14/05, wsk wrote: > > > folks: > > > Can the Qlogic 2340 Fibre Channel card works on FreeBSD now? > > > DELL released a newest Server PE6850 with this card.thx > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > > _______________________________________________ > 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" --- end of quoted text --- -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Mon May 2 13:53:56 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33FC916A4CF for ; Mon, 2 May 2005 13:53:56 +0000 (GMT) Received: from ll.mit.edu (LLMAIL.LL.MIT.EDU [129.55.12.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BF8243D54 for ; Mon, 2 May 2005 13:53:55 +0000 (GMT) (envelope-from mak@ll.mit.edu) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j42DrsSX022291 for ; Mon, 2 May 2005 09:53:54 -0400 (EDT) Received: from koerber.llan.ll.mit.edu( ), claiming to be "[155.34.104.109]" via SMTP by llpost, id smtpdAAAhjaWwR; Mon May 2 09:53:50 2005 Message-ID: <427630ED.80000@ll.mit.edu> Date: Mon, 02 May 2005 09:53:49 -0400 From: "Michael A. Koerber" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.unix.bsd.freebsd.misc To: stable@freebsd.org X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: mount_msdosfs /dev/fd0 causes reboot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 13:53:56 -0000 I'm using 5.3-RELEASE and issuing the subject command, after a few seconds pause, causes a reboot. There are no /var/log/messages. In one case I saw a "stray irq 9" message flash across the console. Has anyone come across this problem? tnx mike From owner-freebsd-stable@FreeBSD.ORG Mon May 2 14:07:01 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4F3B16A4CE for ; Mon, 2 May 2005 14:07:01 +0000 (GMT) Received: from 82-168-79-254-bbxl.xdsl.tiscali.nl (82-168-75-155-bbxl.xdsl.tiscali.nl [82.168.75.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id D164143D55 for ; Mon, 2 May 2005 14:07:00 +0000 (GMT) (envelope-from rene@82-168-79-254-bbxl.xdsl.tiscali.nl) Received: from 82-168-79-254-bbxl.xdsl.tiscali.nl (localhost [127.0.0.1]) j42E6xEm001344 for ; Mon, 2 May 2005 16:06:59 +0200 (CEST) (envelope-from rene@82-168-79-254-bbxl.xdsl.tiscali.nl) Received: (from rene@localhost)j42E6wtf001343 for stable@freebsd.org; Mon, 2 May 2005 16:06:58 +0200 (CEST) (envelope-from rene) Date: Mon, 2 May 2005 16:06:58 +0200 From: Rene Ladan To: stable@freebsd.org Message-ID: <20050502140658.GA1273@82-168-79-254-bbxl.xdsl.tiscali.nl> References: <20050502125104.GA987@82-168-79-254-bbxl.xdsl.tiscali.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <20050502125104.GA987@82-168-79-254-bbxl.xdsl.tiscali.nl> User-Agent: Mutt/1.4.2.1i Subject: Re: bpf/fxp RELENG_5 LOR X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 14:07:01 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 02, 2005 at 02:51:05PM +0200, Rene Ladan wrote: >=20 > FreeBSD 5.4-STABLE #0: Mon May 2 02:26:10 CEST 2005 > root@82-168-79-254-bbxl.xdsl.tiscali.nl:/usr/obj/usr/src/sys/RENE >=20 > #tcpdump >=20 > fxp0: promiscuous mode enabled >=20 > lock order reversal > 1st 0xc066de80 bpf global lock (bpf global lock) @ /usr/src/sys/net/bpf.= c:385 > 2nd 0xc14c9264 fxp0 (network driver) @ /usr/src/sys/modules/fxp/../../de= v/fxp/if_fxp.c:2394 >=20 > fxp0: promiscuous mode disabled Of course, to obfuscate debugging, this only happens sporadically, e.g. when using tcpdump the first time. :( This and related fxp LORs all point to some file and to src/sys/dev/fxp/if_fxp.c, at places where a FXP_LOCK(sc), with sc of type fxp_softc * is done. from src/sys/dev/fxp/fxpvar.h: #define FXP_LOCK(_sc) mtx_lock(&(_sc)->sc_mtx) Regards, Rene --=20 "It won't fit on the line." -- me, 2001 --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCdjQBvz70qa4zXcwRAvnyAJ4nkUxreTaBnCXRIPc9z7a1m8Ed7gCfVCCm r6B3fMk7XdCA209PlNkeBBo= =vjvP -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-stable@FreeBSD.ORG Mon May 2 14:07:31 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 921AB16A4CE for ; Mon, 2 May 2005 14:07:31 +0000 (GMT) Received: from ll.mit.edu (LLMAIL.LL.MIT.EDU [129.55.12.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2679643D49 for ; Mon, 2 May 2005 14:07:31 +0000 (GMT) (envelope-from mak@ll.mit.edu) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j42E7UPk014147 for ; Mon, 2 May 2005 10:07:30 -0400 (EDT) Received: from koerber.llan.ll.mit.edu( ), claiming to be "[155.34.104.109]" via SMTP by llpost, id smtpdAAAvWaOxA; Mon May 2 10:07:11 2005 Message-ID: <4276340E.3060204@ll.mit.edu> Date: Mon, 02 May 2005 10:07:10 -0400 From: "Michael A. Koerber" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.unix.bsd.freebsd.misc To: stable@freebsd.org X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: burncd erase hangs at 83% X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 14:07:31 -0000 All, 1. I've noticed that on two separate systems, both running 5.3-RELEASE that 'burncd -vef /dev/acd0 erase' hangs at 83%. This is true for a couple different CD-RW discs (one brand new, never been used). 2. I've been able to burn ISO file systems with no problems. However, I've not been able to burn audio CD's using any of the burncd methods in the handbook nor with any of the "googled" burncd incantations. 3. Are these burncd (known) problems? Is there a near term fix? tnx mike From owner-freebsd-stable@FreeBSD.ORG Mon May 2 14:07:46 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 233A816A4D1 for ; Mon, 2 May 2005 14:07:46 +0000 (GMT) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26B9A43D58 for ; Mon, 2 May 2005 14:07:45 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (kvenmb@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j42E7gtU095418 for ; Mon, 2 May 2005 16:07:42 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j42E7gFv095417; Mon, 2 May 2005 16:07:42 +0200 (CEST) (envelope-from olli) Date: Mon, 2 May 2005 16:07:42 +0200 (CEST) Message-Id: <200505021407.j42E7gFv095417@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <42732577.9020100@geminix.org> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 14:07:47 -0000 Uwe Doering wrote: > Oliver Fromme wrote: > > If they're really identical (i.e. the same size and same > > geometry), then you can use dd(1) for duplication, like > > this: > > > > # dd if=/dev/ad0 of=/dev/ad1 bs=64k conv=noerror,sync > > > > The "noerror,sync" part is important so the dd command will > > not stop when it hits any bad spots on the source drive and > > instead will fill the blocks with zeroes on the destination > > drive. Since it's only the swap partition, you shouldn't > > lose any data. > > I would like to point out that the conclusion you're drawing in the last > sentence is invalid IMHO. I'm afraid I don't agree. > "indefinite wait buffer" messages at > apparently random block numbers just indicate that the pager was unable > to access the swap area (in its entirety!) when it wanted to. It means > that the disk drive was either dead at that point in time or busy trying > to deal with a bad sector. > > This sector could have been anywhere on the disk. It just kept the disk > drive busy for long enough that the pager started to complain. The OP specifically said that the swap_pager messages were the only kernel messages that he got. That indicates that only the swap partition is affected, because otherwise there would have been other kernel messages indicating I/O errors from one of the filesystems on that disk. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "C++ is to C as Lung Cancer is to Lung." -- Thomas Funke From owner-freebsd-stable@FreeBSD.ORG Mon May 2 14:36:10 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D593D16A4CF for ; Mon, 2 May 2005 14:36:10 +0000 (GMT) Received: from mail24.sea5.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9288143D54 for ; Mon, 2 May 2005 14:36:10 +0000 (GMT) (envelope-from freebsd-stable-local@be-well.no-ip.com) Received: (qmail 21636 invoked from network); 2 May 2005 14:36:10 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail24.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 2 May 2005 14:36:10 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 97CA755; Mon, 2 May 2005 10:36:09 -0400 (EDT) Sender: lowell@be-well.ilk.org To: "Michael A. Koerber" References: <427630ED.80000@ll.mit.edu> From: Lowell Gilbert Date: 02 May 2005 10:36:09 -0400 In-Reply-To: <427630ED.80000@ll.mit.edu> Message-ID: <44fyx5d7ae.fsf@be-well.ilk.org> Lines: 14 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: stable@freebsd.org Subject: Re: mount_msdosfs /dev/fd0 causes reboot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 14:36:11 -0000 "Michael A. Koerber" writes: > I'm using 5.3-RELEASE and issuing the subject command, after a few > seconds pause, causes a reboot. There are no /var/log/messages. In one > case I saw a "stray irq 9" message flash across the console. Has anyone > come across this problem? The IRQ 9 is *probably* unrelated. Although it doesn't excuse the presence of bugs in the first place, problems with mounted filesystems affect the kernel itself, so I've always been leery of mounting filesystems from unreliable media (like floppies) and usually stick to using mtools. Do you have the mtools port installed? From owner-freebsd-stable@FreeBSD.ORG Mon May 2 14:38:07 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 455C116A4CE for ; Mon, 2 May 2005 14:38:07 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6C6C43D41 for ; Mon, 2 May 2005 14:38:06 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DSc3h-000Cky-9c; Mon, 02 May 2005 17:38:05 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Wilko Bulte In-Reply-To: Message from Wilko Bulte <20050502134905.GA15646@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 May 2005 17:38:04 +0300 From: Danny Braniss Message-ID: cc: Matthew Jacob cc: stable@freebsd.org Subject: Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 14:38:07 -0000 > On Mon, May 02, 2005 at 04:45:10PM +0300, Danny Braniss wrote.. > > > Yes, the 234X cards have been supported for quite a while. > > > > > it seems not all of them: > > it's a QLA2342/ISP2312 and im getting: > > isp1: port 0x2400-0x24ff mem > > 0xfe8e0000-0xfe8e0fff irq 24 at device 8.0 on pci3 > > isp1: bad execution throttle of 0- using 16 > > isp2: port 0x2000-0x20ff mem > > 0xfe8f0000-0xfe8f0fff irq 27 at device 8.1 on pci3 > > isp2: bad execution throttle of 0- using 16 > > > Have you loaded the ispfw.ko firmware module? Matt tests the driver > against that firmware, not against all the firmware revs Qlogic has > released over time. BINGO! and i thought isp does the firmware update ... thanks, danny From owner-freebsd-stable@FreeBSD.ORG Mon May 2 15:14:59 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE28516A4D0 for ; Mon, 2 May 2005 15:14:59 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4483043D54 for ; Mon, 2 May 2005 15:14:59 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so894114rnf for ; Mon, 02 May 2005 08:14:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I8GohwU1KIA0GrQBTN83+HIxIIwEMEK3l/pdynpu4+WCQfygszCowwfDbKHSbsQSflKBR/8ZF/tnR42oV7yl3hs/NBSgiGXR4BlxzDEtAaaQJRJODzH7rx9J4oWt0L0W64pZ5fFnt0yIq7lYdW4zZCxkr5QQAC9Ibr6Uz96N9fk= Received: by 10.38.97.4 with SMTP id u4mr5819508rnb; Mon, 02 May 2005 08:14:58 -0700 (PDT) Received: by 10.38.104.23 with HTTP; Mon, 2 May 2005 08:14:58 -0700 (PDT) Message-ID: <7579f7fb0505020814743a97ff@mail.gmail.com> Date: Mon, 2 May 2005 08:14:58 -0700 From: Matthew Jacob To: Danny Braniss In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050502134905.GA15646@freebie.xs4all.nl> cc: Wilko Bulte cc: stable@freebsd.org Subject: Re: Can isp driver support Qlogic 2340 on FreeBSD5.x or later? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Matthew Jacob List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 15:15:00 -0000 Yeah, sorry- the newer QLogic cards have firmware that has a different protocol that I haven't written the code for yet. In general, always load the firmware module as well. *EVENTUALLY* we'll be able to unload it and reclaim the member. On 5/2/05, Danny Braniss wrote: > > On Mon, May 02, 2005 at 04:45:10PM +0300, Danny Braniss wrote.. > > > > Yes, the 234X cards have been supported for quite a while. > > > > > > > it seems not all of them: > > > it's a QLA2342/ISP2312 and im getting: > > > isp1: port 0x2400-0x24ff mem > > > 0xfe8e0000-0xfe8e0fff irq 24 at device 8.0 on pci3 > > > isp1: bad execution throttle of 0- using 16 > > > isp2: port 0x2000-0x20ff mem > > > 0xfe8f0000-0xfe8f0fff irq 27 at device 8.1 on pci3 > > > isp2: bad execution throttle of 0- using 16 > > > > > > Have you loaded the ispfw.ko firmware module? Matt tests the driver > > against that firmware, not against all the firmware revs Qlogic has > > released over time. > BINGO! > and i thought isp does the firmware update ... >=20 > thanks, > danny >=20 > From owner-freebsd-stable@FreeBSD.ORG Mon May 2 15:34:11 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C416F16A4CF for ; Mon, 2 May 2005 15:34:11 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3422843D2F for ; Mon, 2 May 2005 15:34:11 +0000 (GMT) (envelope-from des@des.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFV007PICBBXR60@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 02 May 2005 17:28:23 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFV00KLBCME2IB0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 02 May 2005 17:35:03 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 168F145131; Mon, 02 May 2005 17:34:09 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 2AC1A9D1C7; Mon, 02 May 2005 17:34:05 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 1C2A233C39; Mon, 02 May 2005 17:34:05 +0200 (CEST) Date: Mon, 02 May 2005 17:34:05 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <426F5A6E.4050208@eurocom.od.ua> To: Alexander Rusinov Message-id: <86acndmyky.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <426E5713.3010906@eurocom.od.ua> <747dc8f30504260812ee3c47e@mail.gmail.com> <426E5EA5.8000703@eurocom.od.ua> <426F3AFA.9020900@konvergencia.hu> <426F5A6E.4050208@eurocom.od.ua> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: cc: freebsd-stable@freebsd.org Subject: Re: PostgreSQL in FreeBSD jails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 15:34:11 -0000 An unknown poster wrote: > AFAIR PostgreSQL generates the shared memory identifier based on > the port it is runing on. It is possible to run two instances of > PostgreSQL on different ports, so it should work if they are in > seperate jails. Correct. Alexander Rusinov writes: > I guess this is a workaround but not a solution though. There are two possible solutions: - hack the SysV IPC code to use separate namespaces for each jail - make PostgreSQL use POSIX shared memory instead of SysV shared memory I suspect that the latter is significantly easier, and would probably improve performance as well. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Mon May 2 16:08:47 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F24B16A4CE; Mon, 2 May 2005 16:08:47 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 7999D43D5A; Mon, 2 May 2005 16:08:46 +0000 (GMT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 2 May 2005 17:08:45 +0100 (BST) To: Danny Braniss In-Reply-To: Your message of "Mon, 02 May 2005 11:14:38 +0300." Date: Mon, 02 May 2005 17:08:44 +0100 From: Ian Dowse Message-ID: <200505021708.aa58927@salmon.maths.tcd.ie> cc: stable@freebsd.org cc: current@freebsd.org Subject: Re: MNT_USER? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 16:08:47 -0000 In message , Danny Braniss writes: > >after doing a mount_nfs as root (from the console or via su), statfs reports >that MNT_USER flags is set! this is also true with 5.4. It's a bug in the statfs reporting for NFS filesystems. It should be fixed now in -CURRENT (revision 1.174 of sys/nfsclient/nfs_vfsops.c). I'll merge this to -STABLE in a week or so. Ian From owner-freebsd-stable@FreeBSD.ORG Mon May 2 16:22:23 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65A5416A4CF for ; Mon, 2 May 2005 16:22:23 +0000 (GMT) Received: from aurora-solutions.co.uk (aurora-solutions.co.uk [217.155.123.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id E877343D49 for ; Mon, 2 May 2005 16:22:22 +0000 (GMT) (envelope-from stuart@aurora-solutions.co.uk) Received: from dsl-217-155-123-104.zen.co.uk ([217.155.123.104]) by aurora-solutions.co.uk with esmtpa (Exim 4.43) id 1DSdbs-0000Y3-4b for freebsd-stable@freebsd.org; Mon, 02 May 2005 17:17:29 +0100 Message-ID: <427653BF.2090104@aurora-solutions.co.uk> Date: Mon, 02 May 2005 17:22:23 +0100 From: "O'Reilly, Stuart" Organization: Aurora Solutions User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4274E348.7040909@aurora-solutions.co.uk> <4274EA9A.2060800@cs.tu-berlin.de> In-Reply-To: <4274EA9A.2060800@cs.tu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -5.4 (-----) X-Spam-Report: Content analysis details: (-5.4 points) pts rule name description -------------------------------------------------- -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 1% [score: 0.0000]white-list Subject: Re: FreeBSD & Serial ATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: stuart@aurora-solutions.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 16:22:23 -0000 %< ----------- snipped > I have good experiences with RocketRAID 1520 and 1640. I'm running a > 1640 with three SATA drives since one year without problems; it's just a > little bit slow. Highpoint offers binary FreeBSD drivers for these > controllers, but I think that people don't like this kind of support > because Highpoint neglects it for older models and this dependency might > be dangerous in future. Keep in mind: you'll get what you pay for. > > Regards > Björn Can someone just answer a quick question. One of the suggestions mentioned was the Highpoint RocketRAID 1520 controller which is a low cost solutions however support for FreeBSD stopped at v5.1. However, scrolling down the list of driver software for the RocketRAID 1520, Highpoint offer the option of downloading the Linux Open Source Driver and compiling it yourself. To quote the website: "Support Linux kernel version 2.2.x to 2.6.x on x86 and x86_64 platform." Would this be a suitable option since (as I understand it), FreeBSD is i386. Sorry if I sound like i'm trying to get blood from a stone. ;) Stuart, From owner-freebsd-stable@FreeBSD.ORG Mon May 2 16:28:38 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BA1316A4CE for ; Mon, 2 May 2005 16:28:38 +0000 (GMT) Received: from ll.mit.edu (LLMAIL.LL.MIT.EDU [129.55.12.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB61E43D58 for ; Mon, 2 May 2005 16:28:37 +0000 (GMT) (envelope-from mak@ll.mit.edu) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id j42GSb5T002981 for ; Mon, 2 May 2005 12:28:37 -0400 (EDT) Received: from koerber.llan.ll.mit.edu( ), claiming to be "[155.34.104.109]" via SMTP by llpost, id smtpdAAA.Uaagf; Mon May 2 12:28:21 2005 Message-ID: <42765525.6060607@ll.mit.edu> Date: Mon, 02 May 2005 12:28:21 -0400 From: "Michael A. Koerber" User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org References: <427630ED.80000@ll.mit.edu> <44fyx5d7ae.fsf@be-well.ilk.org> In-Reply-To: <44fyx5d7ae.fsf@be-well.ilk.org> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: mount_msdosfs /dev/fd0 causes reboot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 16:28:38 -0000 mtools was actually my first attempt at accessing the floppy drive. Exactly the same end result. I issued 'mdir a:' and after a few seconds I was watching my system reboot. After doing that twice with mdir, I uninstalled mtools thinking it was the problem. When I saw mount_msdosfs gave me the same result, I began to suspect something more basic to be at fault. mike --------------------- Dr Michael A. Koerber x3250 Lowell Gilbert wrote: > "Michael A. Koerber" writes: > > >>I'm using 5.3-RELEASE and issuing the subject command, after a few >>seconds pause, causes a reboot. There are no /var/log/messages. In one >>case I saw a "stray irq 9" message flash across the console. Has anyone >>come across this problem? > > > The IRQ 9 is *probably* unrelated. > > Although it doesn't excuse the presence of bugs in the first place, > problems with mounted filesystems affect the kernel itself, so I've > always been leery of mounting filesystems from unreliable media (like > floppies) and usually stick to using mtools. Do you have the mtools > port installed? > > From owner-freebsd-stable@FreeBSD.ORG Mon May 2 16:39:47 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCE8E16A4CF for ; Mon, 2 May 2005 16:39:47 +0000 (GMT) Received: from mail.helenmarks.co.uk (mail.helenmarks.co.uk [82.68.196.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F86343D41 for ; Mon, 2 May 2005 16:39:47 +0000 (GMT) (envelope-from dom@goodforbusiness.co.uk) Received: from localhost (localhost [127.0.0.1]) by mail.helenmarks.co.uk (Postfix) with ESMTP id BA1601707E; Mon, 2 May 2005 17:39:43 +0100 (BST) Received: from mail.helenmarks.co.uk ([127.0.0.1]) by localhost (mail.helenmarks.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29261-02; Mon, 2 May 2005 17:39:39 +0100 (BST) Received: from egg.helenmarks.co.uk (egg.helenmarks.co.uk [192.168.15.3]) by mail.helenmarks.co.uk (Postfix) with ESMTP id DA7F81707B; Mon, 2 May 2005 17:39:39 +0100 (BST) From: Dominic Marks Organization: GoodforBusiness.co.uk To: stuart@aurora-solutions.co.uk Date: Mon, 2 May 2005 17:40:17 +0100 User-Agent: KMail/1.8 References: <4274E348.7040909@aurora-solutions.co.uk> <4274EA9A.2060800@cs.tu-berlin.de> <427653BF.2090104@aurora-solutions.co.uk> In-Reply-To: <427653BF.2090104@aurora-solutions.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200505021740.18676.dom@goodforbusiness.co.uk> X-Virus-Scanned: By ClamAV 0.80 cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD & Serial ATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 16:39:47 -0000 On Monday 02 May 2005 17:22, O'Reilly, Stuart wrote: > %< ----------- snipped > > > I have good experiences with RocketRAID 1520 and 1640. I'm running a > > 1640 with three SATA drives since one year without problems; it's just a > > little bit slow. Highpoint offers binary FreeBSD drivers for these > > controllers, but I think that people don't like this kind of support > > because Highpoint neglects it for older models and this dependency might > > be dangerous in future. Keep in mind: you'll get what you pay for. > > > > Regards > > Bj=F6rn > > Can someone just answer a quick question. One of the suggestions > mentioned was the Highpoint RocketRAID 1520 controller which is a low > cost solutions however support for FreeBSD stopped at v5.1. > > However, scrolling down the list of driver software for the RocketRAID > 1520, Highpoint offer the option of downloading the Linux Open Source > Driver and compiling it yourself. To quote the website: > > "Support Linux kernel version 2.2.x to 2.6.x on x86 and x86_64 platform." > > Would this be a suitable option since (as I understand it), FreeBSD is > i386. =46reeBSD has an i386 version, but it isn't only available for i386. See:=20 http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/archs.= html Regarding the driver for Linux: Often the guts of drivers distributed in this way are binary and the interf= ace=20 which brings the binary and the kernel together is all that is publicly=20 accessible. You will (quite literally) have more luck getting a binary=20 Windows driver to work on FreeBSD than a binary Linux driver. > Sorry if I sound like i'm trying to get blood from a stone. ;) Be wary of cheap controllers which burden your system with extra work inste= ad=20 of less. > Stuart, > _______________________________________________ > 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" HTH, =2D-=20 Dominic GoodforBusiness.co.uk I.T. Services for SMEs in the UK. From owner-freebsd-stable@FreeBSD.ORG Mon May 2 18:11:24 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F8DD16A4CE for ; Mon, 2 May 2005 18:11:24 +0000 (GMT) Received: from smtp-bedford-dr.mitre.org (smtp-bedford-dr-x.mitre.org [192.160.51.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id B999443D60 for ; Mon, 2 May 2005 18:11:23 +0000 (GMT) (envelope-from jandrese@mitre.org) Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with SMTP id j42IBNT24080 for ; Mon, 2 May 2005 14:11:23 -0400 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id 87FC24F8DC for ; Mon, 2 May 2005 14:11:22 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.28.8]) j42IBMX23964 for ; Mon, 2 May 2005 14:11:22 -0400 Received: from mm112324-2k.mitre.org (128.29.24.104) by mailhub2.mitre.org with SMTP id 11325094; Mon, 02 May 2005 14:11:15 -0400 Message-ID: <42766D43.7000500@mitre.org> Date: Mon, 02 May 2005 14:11:15 -0400 From: Jason Andresen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: gvinum: All subdisks marked stale after a reboot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 18:11:24 -0000 Hello, I've run into a problem while trying to migrate and old vinum array to gvinum (via blowing away all vinum info and rebuilding it in gvinum). The array builds ok, but when I reboot every subdisk is marked stale and the plex is marked down. What am I doing wrong here? More importantly, what info would I need to provide to help debug this problem? Here's the array: 10 drives: D media1 State: up /dev/ad4s1 A: 1843/78159 MB (2%) D media2 State: up /dev/ad6s1 A: 0/76316 MB (0%) D media3 State: up /dev/ad8s1 A: 0/76316 MB (0%) D media4 State: up /dev/ad10s1 A: 0/76316 MB (0%) D media5 State: up /dev/ad12s1 A: 0/76316 MB (0%) D media6 State: up /dev/ad14s1 A: 0/76316 MB (0%) D media7 State: up /dev/ad16s1 A: 0/76316 MB (0%) D media8 State: up /dev/ad18s1 A: 0/76316 MB (0%) D media9 State: up /dev/ad20s1 A: 0/76316 MB (0%) D mediaa State: up /dev/ad22s1 A: 0/76316 MB (0%) 1 volume: V media State: down Plexes: 1 Size: 670 GB 1 plex: P media.p0 R5 State: down Subdisks: 10 Size: 670 GB 10 subdisks: S media.p0.s0 State: stale D: media1 Size: 74 GB S media.p0.s1 State: stale D: media2 Size: 74 GB S media.p0.s2 State: stale D: media3 Size: 74 GB S media.p0.s3 State: stale D: media4 Size: 74 GB S media.p0.s4 State: stale D: media5 Size: 74 GB S media.p0.s5 State: stale D: media6 Size: 74 GB S media.p0.s6 State: stale D: media7 Size: 74 GB S media.p0.s7 State: stale D: media8 Size: 74 GB S media.p0.s8 State: stale D: media9 Size: 74 GB S media.p0.s9 State: stale D: mediaa Size: 74 GB From owner-freebsd-stable@FreeBSD.ORG Mon May 2 20:14:48 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 741AA16A4D1 for ; Mon, 2 May 2005 20:14:48 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9EBD43D82 for ; Mon, 2 May 2005 20:14:47 +0000 (GMT) (envelope-from chrcoluk@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so960229rng for ; Mon, 02 May 2005 13:14:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ul8NYvkj7YYVq8sqr7LcHhXYh/ywglQk+dW+c+dU2AtxQlEL6L85CrTMhdFBmck3O8UyDVR+iucj7rONMoFGRdJMw3tNOYTrAJb32JpdHk2NdUoUuXrJI1IRqJ31FFVNRtQaNcR9Tfs0GjAPi9Xx4C+dz+4FO2kmsadZ1FgJMjE= Received: by 10.38.76.61 with SMTP id y61mr6610660rna; Mon, 02 May 2005 13:14:47 -0700 (PDT) Received: by 10.39.1.30 with HTTP; Mon, 2 May 2005 13:14:47 -0700 (PDT) Message-ID: <3aaaa3a05050213142a9dc5@mail.gmail.com> Date: Mon, 2 May 2005 21:14:47 +0100 From: Chris To: Claus Guttesen In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <427396DA.60302@samsco.org> cc: stable@freebsd.org cc: developers@freebsd.org Subject: Re: FreeBSD 5.4 release status X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Chris List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 20:14:48 -0000 On 4/30/05, Claus Guttesen wrote: > > As you probably noticed, we are a bit behind on the 5.4 release. There > > was a major stability problem reported several weeks ago in a particlar > > high load, high profile environment, and we decided that it was in > > everyones best interest to get it resolved before the release. Well, > > thanks to the tireless efforts of Doug White and Stephen Uphoff and > > several others, the bug has been found, fixed, and verified. As soon > > as it and a few other fixes get merged in, we will start the RC4 build > > process and hopefully release it for testing late this weekend. After > > that, unless another show-stopper comes up, we expect to build and > > release 5.4-RELEASE next weekend. >=20 > Nice to hear. I have a four-way opteron-postgresql-server which is > running low on disk-space, larger disks are right next to my desk, > just waiting :-) >=20 > Are there any finer details related to the four-way or larger-bug? >=20 > regards > Claus > ___ Hi I am abit confused here, have seen a post from someone using 5.4-STABLE how is that possible if 5.4 isnt RELEASE yet, and good news on the bug fix. Chris ____________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Mon May 2 20:42:57 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF97C16A4CF for ; Mon, 2 May 2005 20:42:57 +0000 (GMT) Received: from saturn.criticalmagic.com (saturn.criticalmagic.com [69.61.68.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C52643D7E for ; Mon, 2 May 2005 20:42:57 +0000 (GMT) (envelope-from rcoleman@criticalmagic.com) Received: from [10.40.30.162] (delta.ciphertrust.com [216.235.158.34]) by saturn.criticalmagic.com (Postfix) with ESMTP id 3CA463BD53; Mon, 2 May 2005 16:42:54 -0400 (EDT) Message-ID: <4276910A.3040100@criticalmagic.com> Date: Mon, 02 May 2005 16:43:54 -0400 From: Richard Coleman Organization: Critical Magic User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <426E5713.3010906@eurocom.od.ua> <747dc8f30504260812ee3c47e@mail.gmail.com> <426E5EA5.8000703@eurocom.od.ua> <426F3AFA.9020900@konvergencia.hu> <426F5A6E.4050208@eurocom.od.ua> <86acndmyky.fsf@xps.des.no> In-Reply-To: <86acndmyky.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: Alexander Rusinov cc: freebsd-stable@freebsd.org Subject: Re: PostgreSQL in FreeBSD jails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 20:42:57 -0000 Dag-Erling Smørgrav wrote: > There are two possible solutions: > > - hack the SysV IPC code to use separate namespaces for each jail > > - make PostgreSQL use POSIX shared memory instead of SysV shared > memory > > I suspect that the latter is significantly easier, and would probably > improve performance as well. > > DES It might be easier to hack PostgreSQL so that the shared memory identifier depends not only on the port, but also on the IP address (which will of course be different for each jail). Or better yet, to be able to specify the shared memory identifier to use directly in the config file. Richard Coleman rcoleman@criticalmagic.com From owner-freebsd-stable@FreeBSD.ORG Mon May 2 21:03:34 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4511216A4CF for ; Mon, 2 May 2005 21:03:34 +0000 (GMT) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4BF643D7E for ; Mon, 2 May 2005 21:03:33 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 15AD764DC36; Mon, 2 May 2005 18:03:33 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 06726-05; Mon, 2 May 2005 21:03:29 +0000 (GMT) Received: from ganymede.hub.org (blk-222-80-207.eastlink.ca [24.222.80.207]) by hub.org (Postfix) with ESMTP id 99F4764DC35; Mon, 2 May 2005 18:03:32 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 8DCAC350FE; Mon, 2 May 2005 18:03:31 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 8CC3C340CF; Mon, 2 May 2005 18:03:31 -0300 (ADT) Date: Mon, 2 May 2005 18:03:31 -0300 (ADT) From: "Marc G. Fournier" To: Richard Coleman In-Reply-To: <4276910A.3040100@criticalmagic.com> Message-ID: <20050502180152.I53065@ganymede.hub.org> References: <426E5713.3010906@eurocom.od.ua> <747dc8f30504260812ee3c47e@mail.gmail.com> <426E5EA5.8000703@eurocom.od.ua> <426F3AFA.9020900@konvergencia.hu> <426F5A6E.4050208@eurocom.od.ua> <86acndmyky.fsf@xps.des.no> <4276910A.3040100@criticalmagic.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-703306083-1115067811=:53065" X-Virus-Scanned: by amavisd-new at hub.org cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: freebsd-stable@freebsd.org cc: Alexander Rusinov Subject: Re: PostgreSQL in FreeBSD jails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 21:03:34 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-703306083-1115067811=:53065 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE yOn Mon, 2 May 2005, Richard Coleman wrote: > Dag-Erling Sm=F8rgrav wrote: >> There are two possible solutions: >>=20 >> - hack the SysV IPC code to use separate namespaces for each jail >>=20 >> - make PostgreSQL use POSIX shared memory instead of SysV shared >> memory >>=20 >> I suspect that the latter is significantly easier, and would probably >> improve performance as well. >>=20 >> DES > > It might be easier to hack PostgreSQL so that the shared memory identifie= r=20 > depends not only on the port, but also on the IP address (which will of= =20 > course be different for each jail). Or better yet, to be able to specify= the=20 > shared memory identifier to use directly in the config file. You've all lost me here ... what exactly is the problem? PostgreSQL works= =20 under FreeBSD 4.x jails without any modifications, so how is PostgreSQL=20 itself currently broken? It seems to me that the problem is with FreeBSD= =20 5.x's jail side of things, if the same daemon runs fine under 4.x, but,=20 nto under 5.x ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 --0-703306083-1115067811=:53065-- From owner-freebsd-stable@FreeBSD.ORG Mon May 2 21:04:02 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EE1C16A4D0 for ; Mon, 2 May 2005 21:04:02 +0000 (GMT) Received: from mail.rulez.sk (DaEmoN.RuLeZ.sK [84.16.32.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8330143D7E for ; Mon, 2 May 2005 21:04:01 +0000 (GMT) (envelope-from danger@rulez.sk) Received: from localhost (localhost [127.0.0.1]) by mail.rulez.sk (Postfix) with ESMTP id 18B404505E; Mon, 2 May 2005 23:04:00 +0200 (CEST) Received: from danger.mcrn.sk (danger.mcrn.sk [84.16.37.254]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rulez.sk (Postfix) with ESMTP id F236445058; Mon, 2 May 2005 23:03:57 +0200 (CEST) Date: Mon, 2 May 2005 23:03:52 +0200 From: Daniel Gerzo X-Priority: 3 (Normal) Message-ID: <156270629.20050502230352@rulez.sk> To: Chris , stable@freebsd.org In-Reply-To: <3aaaa3a05050213142a9dc5@mail.gmail.com> References: <427396DA.60302@samsco.org> <3aaaa3a05050213142a9dc5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mail.rulez.sk X-Spam-Status: No, hits=-1.502 tagged_above=-999 required=5 tests=AWL, BAYES_00, PRIORITY_NO_NAME X-Spam-Level: Subject: Re[2]: FreeBSD 5.4 release status X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Gerzo List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 21:04:02 -0000 Hello Chris, Monday, May 2, 2005, 10:14:47 PM, you wrote these comments: > Hi I am abit confused here, have seen a post from someone using > 5.4-STABLE how is that possible if 5.4 isnt RELEASE yet, and good news RELENG_5 has a -STABLE tag since RELENG_5_4 was branched, so if you use _5 you will get 5.4-STABLE and if you use _5_4, you will get 5.4-RC4. > on the bug fix. > Chris -- Best regards DanGer, ICQ: 261701668 | e-mail protecting at: http://www.2pu.net/ http://danger.rulez.sk | proxy list at: http://www.proxy-web.com/ | FreeBSD - The Power to Serve! [ "Be a dear and turn the shower massage head on pulsate." -- Servo ] From owner-freebsd-stable@FreeBSD.ORG Mon May 2 21:07:49 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6480916A4CE; Mon, 2 May 2005 21:07:49 +0000 (GMT) Received: from shiva.nextrials.com (shiva.nextrials.com [64.81.74.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 027E643D69; Mon, 2 May 2005 21:07:49 +0000 (GMT) (envelope-from dannyman@toldme.com) Received: from [192.168.1.102] (mito.sr.nextrials.com [192.168.1.102]) by shiva.nextrials.com (Postfix) with ESMTP id AB4E83C2872; Mon, 2 May 2005 14:07:48 -0700 (PDT) Message-ID: <4276969D.1030800@toldme.com> Date: Mon, 02 May 2005 14:07:41 -0700 From: Danny Howard User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050418) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Helmer References: <426D481D.7080502@palisadesys.com> <426DB02B.4050807@FreeBSD.org> <20050426092631.GA50783@stack.nl> <426FE073.4000102@palisadesys.com> In-Reply-To: <426FE073.4000102@palisadesys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Marc Olzheim cc: freebsd-stable@FreeBSD.org cc: Ade Lovett Subject: Re: FreeBSD 5.3p6-5.4RC3, Supermicro X6DHR-8G,Dual3.6GHzXeons,Adaptec aic7902 SCSI interface doesn't work in UP kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 21:07:49 -0000 Guy Helmer wrote: > > > These new Supermicro X6DHR-8G 800MHz FSB systems seem to be working OK > (even under load) when running a kernel with SMP enabled. I offered > my configuration in case jhb or someone else would be interested in > what seems to be an interrupt routing problem. Guy, I LOVE YOU, dude! I had ... well, let us just say, some frustration with a new system with this mobo until I read your post that the SMP kernel works. Which is funny, because SMP is turned off, by default, because of some stability issues on one-proc hyperthreaded machines! On the other hand, the non-SMP craps itself spectacularly on at least one multi-proc machine!? I just wish I had read your post last week, and not started with such silliness on a Monday. :) Thanks a bunch, to all who have puzzled over these things before me! Sincerely, -danny -- http://dannyman.toldme.com/ From owner-freebsd-stable@FreeBSD.ORG Mon May 2 21:17:00 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7F3E16A4D1 for ; Mon, 2 May 2005 21:17:00 +0000 (GMT) Received: from mail1.panix.com (mail1.panix.com [166.84.1.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59E4B43D46 for ; Mon, 2 May 2005 21:17:00 +0000 (GMT) (envelope-from fj@panix.com) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail1.panix.com (Postfix) with ESMTP id B5A2558AD4 for ; Mon, 2 May 2005 17:16:59 -0400 (EDT) Received: (from fj@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id j42LGxX10339 for freebsd-stable@freebsd.org; Mon, 2 May 2005 17:16:59 -0400 (EDT) Date: Mon, 2 May 2005 17:16:59 -0400 From: Joe Altman To: freebsd-stable@freebsd.org Message-ID: <20050502211659.GA22451@panix.com> Mail-Followup-To: Joe Altman , freebsd-stable@freebsd.org References: <20050502120109.9800816A510@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050502120109.9800816A510@hub.freebsd.org> User-Agent: Mutt/1.4.2.1i Subject: Re: USB changes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 21:17:01 -0000 It did go somewhere; Julian altered two files in the relevant source and after I updated the issue was resolved. > 13. Re: USB changes. (Joel) > > Message: 13 > Date: Mon, 02 May 2005 12:20:30 +0900 > From: Joel > Subject: Re: USB changes. > To: freebsd-stable@freebsd.org > Message-ID: <20050502121827.22C8.REES@ddcom.co.jp> > Content-Type: text/plain; charset="ISO-2022-JP" > > > If I were Joe, I'd be wondering if that meant re-compiling the kernel. > > Did this go anywhere? (I also have UHB hardware that fusses on boot.) > _______________________________________________ > 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" > > End of freebsd-stable Digest, Vol 108, Issue 1 > ********************************************** -- I don't care what you think. This is not a stylishly insouciant stroll out of the jungle, here. It's more like we've fallen out of our trees and rolled, butt-naked before the entire galaxy, downhill. That, and we seem to have a teensy problem lifting ourselves off the ground. From owner-freebsd-stable@FreeBSD.ORG Mon May 2 21:22:17 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B05F16A4CF for ; Mon, 2 May 2005 21:22:17 +0000 (GMT) Received: from cicero2.cybercity.dk (cicero2.cybercity.dk [212.242.40.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 823E643D83 for ; Mon, 2 May 2005 21:22:16 +0000 (GMT) (envelope-from freebsd-stable@motd.dk) Received: from bart.motd.dk (port95.ds1-ro.adsl.cybercity.dk [212.242.60.98]) by cicero2.cybercity.dk (Postfix) with ESMTP id E11F518F536 for ; Mon, 2 May 2005 23:22:13 +0200 (CEST) Received: from localhost (localhost.motd.dk [127.0.0.1]) by bart.motd.dk (Postfix) with ESMTP id 0363C60E4 for ; Mon, 2 May 2005 23:24:09 +0200 (CEST) Received: from bart.motd.dk ([127.0.0.1]) by localhost (bart.motd.dk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00733-04 for ; Mon, 2 May 2005 23:24:06 +0200 (CEST) Received: from home03 (unknown [192.168.10.3]) by bart.motd.dk (Postfix) with ESMTP id 507AD60D2 for ; Mon, 2 May 2005 23:24:06 +0200 (CEST) From: "Tom Jensen" To: Date: Mon, 2 May 2005 23:22:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVPXP/tAA2sDpUGRwmFaIoXzo03hg== Message-Id: <20050502212406.507AD60D2@bart.motd.dk> X-Virus-Scanned: by amavisd-new at motd.dk Subject: Panic in 5.4RC2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 21:22:17 -0000 System info: FreeBSD bart.motd.dk 5.4-RC2 FreeBSD 5.4-RC2 #2: Fri Apr 15 21:14:30 CEST 2005 root@bart.motd.dk:/usr/obj/usr/src/sys/CUSTOM i386 Got the following panic when trying to recover data from a crappy cd I got at crash dump so please let me know if further info is needed. - T sgbufp = 0xc101cfe4 magic = 63062, size = 32740, r= 186528, w = 186977, ptr = 0xc1015000, cksum= 2196678 kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x57c fault code = supervisor read, page not present instruction pointer = 0x8:0xc06413bd stack pointer = 0x10:0xc9bbfc04 frame pointer = 0x10:0xc9bbfc08 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 1 (init) db> where Tracing pid 1 tid 100002 td 0xc13df300 turnstile_setowner(c13d37c0,510) at turnstile_setowner+0xd turnstile_wait(c13d37c0,c15ad230,510) at turnstile_wait+0xb7 _mtx_lock_sleep(c15ad230,c13df300,0,0,0) at _mtx_lock_sleep+0xad kern_wait(c13df300,ffffffff,c9bbfc94,0,c9bbfc98) at kern_wait+0xfa wait4(c13df300,c9bbfd14,4,f3,282) at wait4+0x1f syscall(bfbf002f,bfbf002f,bfbf002f,bfbfef04,bfbfeef8) at syscall+0x27b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (7, FreeBSD ELF32, wait4), eip = 0x8051e07, esp = 0xbfbfedcc, ebp = 0xbfbfede8 --- From owner-freebsd-stable@FreeBSD.ORG Mon May 2 21:29:27 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A9BA16A4CE for ; Mon, 2 May 2005 21:29:27 +0000 (GMT) Received: from smtp806.mail.sc5.yahoo.com (smtp806.mail.sc5.yahoo.com [66.163.168.185]) by mx1.FreeBSD.org (Postfix) with SMTP id 2907A43D5E for ; Mon, 2 May 2005 21:29:27 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.205.64 with login) by smtp806.mail.sc5.yahoo.com with SMTP; 2 May 2005 21:29:26 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id B9882610A; Mon, 2 May 2005 16:29:25 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 08413-05; Mon, 2 May 2005 16:29:24 -0500 (CDT) Received: from [127.0.0.1] (optimator [192.168.1.11]) by optimator.noacks.org (Postfix) with ESMTP id 0EF0760D2; Mon, 2 May 2005 16:29:24 -0500 (CDT) Message-ID: <42769BB3.1050509@alumni.rice.edu> Date: Mon, 02 May 2005 16:29:23 -0500 From: Jonathan Noack User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Marc G. Fournier" References: <426E5713.3010906@eurocom.od.ua> <747dc8f30504260812ee3c47e@mail.gmail.com> <426E5EA5.8000703@eurocom.od.ua> <426F3AFA.9020900@konvergencia.hu> <426F5A6E.4050208@eurocom.od.ua> <86acndmyky.fsf@xps.des.no> <4276910A.3040100@criticalmagic.com> <20050502180152.I53065@ganymede.hub.org> In-Reply-To: <20050502180152.I53065@ganymede.hub.org> X-Enigmail-Version: 0.91.0.0 OpenPGP: id=991D8195; url=http://www.noacks.org/cert/noackjr.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF8602D63DF47EB192E3F8BDD" X-Virus-Scanned: amavisd-new at noacks.org cc: =?ISO-8859-1?Q?Dag-Erli?= =?ISO-8859-1?Q?ng_Sm=F8rgrav?= cc: Richard Coleman cc: freebsd-stable@freebsd.org cc: Alexander Rusinov Subject: Re: PostgreSQL in FreeBSD jails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 21:29:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF8602D63DF47EB192E3F8BDD Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 5/2/2005 4:03 PM, Marc G. Fournier wrote: > yOn Mon, 2 May 2005, Richard Coleman wrote: >> Dag-Erling Sm=F8rgrav wrote: >>> There are two possible solutions: >>> >>> - hack the SysV IPC code to use separate namespaces for each jail >>> >>> - make PostgreSQL use POSIX shared memory instead of SysV shared >>> memory >>> >>> I suspect that the latter is significantly easier, and would probably= >>> improve performance as well. >>> >>> DES >> >> It might be easier to hack PostgreSQL so that the shared memory=20 >> identifier depends not only on the port, but also on the IP address=20 >> (which will of course be different for each jail). Or better yet, to = >> be able to specify the shared memory identifier to use directly in the= =20 >> config file. >=20 > You've all lost me here ... what exactly is the problem? PostgreSQL=20 > works under FreeBSD 4.x jails without any modifications, so how is=20 > PostgreSQL itself currently broken? It seems to me that the problem is= =20 > with FreeBSD 5.x's jail side of things, if the same daemon runs fine=20 > under 4.x, but, nto under 5.x ... From my reading on this thread: PostgreSQL generates the shared memory identifier based on the port it=20 is running on, but (on 5.x at least) shared memory is not segregated=20 between jails. Thus, a new instance will corrupt the shared memory of=20 another instance (in another jail, on another IP address, etc.) *if*=20 they are running on the same port. The workaround is to ensure every=20 instance (regardless of jail or IP address) is running on a unique port. --=20 Jonathan Noack | noackjr@alumni.rice.edu | OpenPGP: 0x991D8195 --------------enigF8602D63DF47EB192E3F8BDD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCdpuzUFz01pkdgZURAiAUAJ9V3OQnGBQb1S5qM6t2UPBdswRpdwCfcXoN HFm10lNix5rqSgxyKNVQzKI= =OJEI -----END PGP SIGNATURE----- --------------enigF8602D63DF47EB192E3F8BDD-- From owner-freebsd-stable@FreeBSD.ORG Mon May 2 21:48:34 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CA4916A4CE for ; Mon, 2 May 2005 21:48:34 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BF4843D5F for ; Mon, 2 May 2005 21:48:33 +0000 (GMT) (envelope-from des@des.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFV008UZTMSJ630@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 02 May 2005 23:42:28 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFV00KUOTXVZM00@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Mon, 02 May 2005 23:49:07 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 90F5E45165; Mon, 02 May 2005 23:48:13 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 4984345131; Mon, 02 May 2005 23:48:10 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 2A69533C39; Mon, 02 May 2005 23:48:10 +0200 (CEST) Date: Mon, 02 May 2005 23:48:10 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <4276910A.3040100@criticalmagic.com> To: Richard Coleman Message-id: <867jih5mg5.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <426E5713.3010906@eurocom.od.ua> <747dc8f30504260812ee3c47e@mail.gmail.com> <426E5EA5.8000703@eurocom.od.ua> <426F3AFA.9020900@konvergencia.hu> <426F5A6E.4050208@eurocom.od.ua> <86acndmyky.fsf@xps.des.no> <4276910A.3040100@criticalmagic.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: cc: Alexander Rusinov cc: freebsd-stable@freebsd.org Subject: Re: PostgreSQL in FreeBSD jails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 21:48:34 -0000 Richard Coleman writes: > It might be easier to hack PostgreSQL so that the shared memory > identifier depends not only on the port, but also on the IP address > (which will of course be different for each jail). Or better yet, to > be able to specify the shared memory identifier to use directly in the > config file. That's not a sufficiently general solution. First of all, in most setups postgresql runs either a) without TCP/IP; b) only on 127.0.0.1; c) on all interfaces. Very rarely does it listen only on one single identifiable IP address. Therefore, relying on the IP address is useless. Besides, the shm id is an integer, which makes it difficult to encode both the IP address and the port number without collisions. The ideal solution is to use a type of shared memory that does not need a namespace at all. One option is to use a threads instead of child processes. This would require a major rewrite of the backend, and is not likely to happen any time soon. The other option is to add support for mmap()-based shared memory. I happen to have a patch, but testing it properly and getting it approved and merged will take a while. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Mon May 2 22:12:28 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C12BC16A4CF for ; Mon, 2 May 2005 22:12:28 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F12643D5E for ; Mon, 2 May 2005 22:12:28 +0000 (GMT) (envelope-from avleeuwen@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so2565430nzf for ; Mon, 02 May 2005 15:12:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=RwiAvS6Mo6M2lPzhEb22CDt/DTf39Po4PPq3nYTa+x1Ipn4A/XfMS7astyycOWurDBnKZFaoRUcSSd2O3EX99NfYSQtMUQrWzrmpPpj0D/qi2/ZP1B7Gsyl4cjRq3ZnmzflHX93mBcIowgyiceU+j1GjoP6vFmlS74+Ia58vFCM= Received: by 10.36.56.8 with SMTP id e8mr601219nza; Mon, 02 May 2005 15:12:27 -0700 (PDT) Received: by 10.36.79.12 with HTTP; Mon, 2 May 2005 15:12:26 -0700 (PDT) Message-ID: Date: Tue, 3 May 2005 00:12:26 +0200 From: Arjan Van Leeuwen To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Panic: icmp_error: bad length X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Arjan Van Leeuwen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 22:12:28 -0000 My 5.3-RELEASE server just paniced with 'icmp_error: bad length". I have no possibilities to do any debugging on this machine, as it runs off a compactflash card with limited space. This could be caused by the crappy built-in Realtek cards, or maybe by something on my own network. Is there a known way to avoid this panic (or stop the error causing a panic)? Thanks, Arjan From owner-freebsd-stable@FreeBSD.ORG Mon May 2 22:20:50 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2555516A4CF for ; Mon, 2 May 2005 22:20:50 +0000 (GMT) Received: from smtp817.mail.sc5.yahoo.com (smtp817.mail.sc5.yahoo.com [66.163.170.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 851C143D46 for ; Mon, 2 May 2005 22:20:49 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.205.64 with login) by smtp817.mail.sc5.yahoo.com with SMTP; 2 May 2005 20:30:06 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id AD835610A; Mon, 2 May 2005 15:30:05 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07040-17; Mon, 2 May 2005 15:30:02 -0500 (CDT) Received: from [127.0.0.1] (optimator [192.168.1.11]) by optimator.noacks.org (Postfix) with ESMTP id B54ED60D2; Mon, 2 May 2005 15:30:01 -0500 (CDT) Message-ID: <42768DC3.5070100@alumni.rice.edu> Date: Mon, 02 May 2005 15:29:55 -0500 From: Jonathan Noack User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris References: <427396DA.60302@samsco.org> <3aaaa3a05050213142a9dc5@mail.gmail.com> In-Reply-To: <3aaaa3a05050213142a9dc5@mail.gmail.com> X-Enigmail-Version: 0.91.0.0 OpenPGP: id=991D8195; url=http://www.noacks.org/cert/noackjr.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCA3E15A89BEBECC78E60E712" X-Virus-Scanned: amavisd-new at noacks.org cc: stable@freebsd.org cc: developers@freebsd.org cc: Claus Guttesen Subject: Re: FreeBSD 5.4 release status X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2005 22:20:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCA3E15A89BEBECC78E60E712 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 5/2/2005 3:14 PM, Chris wrote: > On 4/30/05, Claus Guttesen wrote: >>>As you probably noticed, we are a bit behind on the 5.4 release. There >>>was a major stability problem reported several weeks ago in a particlar >>>high load, high profile environment, and we decided that it was in >>>everyones best interest to get it resolved before the release. Well, >>>thanks to the tireless efforts of Doug White and Stephen Uphoff and >>>several others, the bug has been found, fixed, and verified. As soon >>>as it and a few other fixes get merged in, we will start the RC4 build >>>process and hopefully release it for testing late this weekend. After >>>that, unless another show-stopper comes up, we expect to build and >>>release 5.4-RELEASE next weekend. >> >>Nice to hear. I have a four-way opteron-postgresql-server which is >>running low on disk-space, larger disks are right next to my desk, >>just waiting :-) >> >>Are there any finer details related to the four-way or larger-bug? >> >>regards >>Claus > > Hi I am abit confused here, have seen a post from someone using > 5.4-STABLE how is that possible if 5.4 isnt RELEASE yet, and good news > on the bug fix. When RELENG_5_4 was branched, RELENG_5 went from 5.4-PRERELEASE to 5.4-STABLE to reflect that it is once again open for less-restricted development. As 5.4 will be released via the RELENG_5_4 branch, it is normal and expected to have 5.4-STABLE around before 5.4-RELEASE. -- Jonathan Noack | noackjr@alumni.rice.edu | OpenPGP: 0x991D8195 --------------enigCA3E15A89BEBECC78E60E712 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iD8DBQFCdo3JUFz01pkdgZURAl2hAJ49RlFVxbQIroPDdnBmUH82QK9+mQCgk8RE 8uVzH1P7vwEXSV+g+Yu95+w= =Y+WM -----END PGP SIGNATURE----- --------------enigCA3E15A89BEBECC78E60E712-- From owner-freebsd-stable@FreeBSD.ORG Mon May 2 23:41:29 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 945A316A4CE for ; Mon, 2 May 2005 23:41:29 +0000 (GMT) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 560E343D6B for ; Mon, 2 May 2005 23:41:29 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from Sonomago (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 75FA519F3B; Mon, 2 May 2005 16:41:45 -0700 (PDT) From: "Darren Pilgrim" To: "'Carl Gustavsson'" Date: Mon, 2 May 2005 16:41:18 -0700 Message-ID: <000d01c54f70$73c0bdf0$9f3598d1@Sonomago> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <427601FA.7080106@thegoodone.mine.nu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal cc: freebsd-stable@freebsd.org Subject: RE: ndis with Intel 2915 wireless, getting "NDIS ERROR" messages and deattach on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 02 May 2005 23:41:29 -0000 From: Carl Gustavsson > > Have you tested the iwi-driver? > See: http://damien.bergamini.free.fr/ipw/iwi-freebsd.html I haven't yet. Reading that page has brought up another questions. On the page it says 5-STABLE doesn't support WPA. My wireless network uses WPA. Is this still the case? I know -stable is -stable, but WPA something of a show-stopper, if you ask me. Fortunately, my neighborhood is a well-covered sea of open "linksys" and "NETGEAR" APs in default configuration with to test the driver. From owner-freebsd-stable@FreeBSD.ORG Tue May 3 01:59:00 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7137816A4CF for ; Tue, 3 May 2005 01:58:59 +0000 (GMT) Received: from bloom.cse.buffalo.edu (bloom.cse.Buffalo.EDU [128.205.32.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1EA643D60 for ; Tue, 3 May 2005 01:58:58 +0000 (GMT) (envelope-from kensmith@FreeBSD.org) Received: from bloom.cse.buffalo.edu (localhost.cse.buffalo.edu [127.0.0.1]) by bloom.cse.buffalo.edu (8.13.3/8.12.4) with ESMTP id j431wr0h008855 for ; Mon, 2 May 2005 21:58:53 -0400 (EDT) Received: (from kensmith@localhost) by bloom.cse.buffalo.edu (8.13.3/8.13.1/Submit) id j431wrb1008854 for freebsd-stable@freebsd.org; Mon, 2 May 2005 21:58:53 -0400 (EDT) (envelope-from kensmith) Date: Mon, 2 May 2005 21:58:53 -0400 From: Ken Smith To: freebsd-stable@freebsd.org Message-ID: <20050503015853.GA8842@bloom.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: FreeBSD 5.4-RC4 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 01:59:00 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Announcement ------------ The FreeBSD Release Engineering Team is pleased to announce the availability of FreeBSD 5.4-RC4, the fourth Release Candidate of the FreeBSD 5.4 release cycle. This will be the last Release Candidate, unless a major problem is discovered as part of RC4 testing the final release will be made early next week. This RC contains fixes to all known major issues. We encourage people to help with testing so any final bugs can be identified and worked out. =20 Availability of ISO images and support for doing FTP based installs is given below. If you have an older system you want to update using the normal CVS/cvsup source based upgrade the branch tag to use is RELENG_5_4. Problem reports can be submitted using the send-pr(1) command, and/or posted to the "freebsd-stable@freebsd.org" mailing list. A schedule and the current todo list for the 5.4 Release Cycle are availabl= e: http://www.freebsd.org/releases/5.4R/schedule.html http://www.freebsd.org/releases/5.4R/todo.html The packages being provided as part of RC4 are what is expected to come with the final release for the alpha, amd64, i386, pc98, and sparc64 architectures. There will be a few more adjustments made to the package set for ia64. Special thanks to Doug White (Looksmart), Stephan Uphoff, Alan Cox (Rice University), Robert Watson (SPARTA), John Baldwin (The Weather Channel), Paul Vixie (ISC), and Peter Losher (ISC) for their work tracking down and fixing the last big show-stopper. Availability ------------ The RC4 ISOs and FTP support for all architectures are available now on most of the FreeBSD Mirror sites. A list of the mirror sites is available here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mirrors-ftp.html The MD5s of the ISO images are: MD5 (5.4-RC4-alpha-bootonly.iso) =3D 042b154c74b3ad917040dc84a5821e05 MD5 (5.4-RC4-alpha-disc1.iso) =3D 7266c40da24def01941daa82cf80f15b MD5 (5.4-RC4-alpha-disc2.iso) =3D fd0d199ea31afd48d3c59cef6111ba9a MD5 (5.4-RC4-amd64-bootonly.iso) =3D 819852f18e41ebe4d4d42fce3bdd35a4 MD5 (5.4-RC4-amd64-disc1.iso) =3D acf6a5193ff3d7caef1d4492fcac2c9a MD5 (5.4-RC4-amd64-disc2.iso) =3D 293a4670f7bcfb1bb30289c06327b8fc MD5 (5.4-RC4-i386-bootonly.iso) =3D ff8d96644b2cf28cfc4b00d4061f78aa MD5 (5.4-RC4-i386-disc1.iso) =3D e133e34e5b92804e00816cad8b3e4559 MD5 (5.4-RC4-i386-disc2.iso) =3D 019af1777c83c90e7b366cb2bddc13a9 MD5 (5.4-RC4-ia64-bootonly.iso) =3D 992a2ee2644fea1e0c5c3199f1ed7255 MD5 (5.4-RC4-ia64-disc1.iso) =3D ae7a494707ab7d29309c812570012c26 MD5 (5.4-RC4-ia64-disc2.iso) =3D 73a1ebcd38deccbbf6534ef1d9c0d11f MD5 (5.4-RC4-ia64-livefs.iso) =3D 914aff32dc853114b7ec89f789556683 MD5 (5.4-RC4-pc98-disc1.iso) =3D 28e3d46e59291e3b695f9bd59c7024d1 MD5 (5.4-RC4-sparc64-bootonly.iso) =3D 1afcd18c7edd19d8f2ea3ec6212c2771 MD5 (5.4-RC4-sparc64-disc1.iso) =3D a7c18eeef17c8873310c829b3f6bba84 MD5 (5.4-RC4-sparc64-disc2.iso) =3D fb4e2af7a3a16aa15fe35c5f424340f1 -ken --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCdtrb/G14VSmup/YRArqiAJ9eL9+fyxyz2JjyAxUvp+ybSio0FQCfbGus OiiSSCw5tVn2J+lZbrqNxgk= =XXQy -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-stable@FreeBSD.ORG Tue May 3 02:53:22 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67D3A16A4CE for ; Tue, 3 May 2005 02:53:22 +0000 (GMT) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3A1243D41 for ; Tue, 3 May 2005 02:53:21 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from Sonomago (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 3D69019F3B; Mon, 2 May 2005 19:53:38 -0700 (PDT) From: "Darren Pilgrim" To: "'Darren Pilgrim'" , "'Carl Gustavsson'" Date: Mon, 2 May 2005 19:53:08 -0700 Message-ID: <000001c54f8b$40b43ed0$9afb40d8@Sonomago> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <000d01c54f70$73c0bdf0$9f3598d1@Sonomago> cc: freebsd-stable@freebsd.org Subject: RE: ndis with Intel 2915 wireless, getting "NDIS ERROR" messagesand deattach on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 02:53:22 -0000 > From: Darren Pilgrim > From: Carl Gustavsson =20 > >=20 > > Have you tested the iwi-driver? > > See: http://damien.bergamini.free.fr/ipw/iwi-freebsd.html >=20 > I haven't yet. Reading that page has brought up another questions. = On the > page it says 5-STABLE doesn't support WPA. My wireless network uses = WPA. > Is this still the case? I know -stable is -stable, but WPA something = of a > show-stopper, if you ask me. >=20 > Fortunately, my neighborhood is a well-covered sea of open "linksys" = and > "NETGEAR" APs in default configuration with to test the driver. I'm using driver version 1.3.4 and firmware version 2.2. The driver = appears to attach just fine:=20 iwi0: mem 0xdfcfd000-0xdfcfdfff = irq 5 at device 3.0 on pci3 iwi0: Ethernet address: 00:0e:35:f6:d6:5c iwi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps = 24Mbps 36Mbps 48Mbps 54Mbps However, when I attempt to associate and get an IP address, I get "iwi0: fatal error" when running dhclient. Setting debug.iwi=3D10 and debug.ieee80211=3D10, I get the following debug output when I run the = firmware download and dhclient commands: # iwicontrol iwi0 -d /root/if_iwi/firmware-2.2 -m bss Firmware cached: boot 6464, ucode 16326, main 166952 # dhclient iwi0 INTR!0x01000000 INTR!0x01000000 Setting MAC address to 00:0e:35:f6:d6:5c TX!CMD!11!6 INTR!0x00000800 Configuring adapter TX!CMD!6!20 INTR!0x00000800 Setting power mode to 0 TX!CMD!17!4 INTR!0x00000800 Setting RTS threshold to 2312 TX!CMD!15!4 INTR!0x00000800 Setting .11bg supported rates (12) TX!CMD!22!16 INTR!0x00000800 Setting .11a supported rates (8) TX!CMD!22!16 INTR!0x00000800 Setting initialization vector to 693451133 TX!CMD!34!4 INTR!0x00000800 Enabling adapter TX!CMD!2!0 INTR!0x00000800 ieee80211_next_scan: chan 56->60 Start scanning TX!CMD!20!60 INTR!0x00000800 INTR!0x00000002 Notification (20) INTR!0x00000002 Scan channel (36) INTR!0x00000002 Scan channel (40) INTR!0x00000002 Scan channel (44) INTR!0x00000002 Scan channel (48) INTR!0x00000002 RX!DATA!68!52!58 ieee80211_recv_mgmt: new probe response on chan 52 (bss chan 52) "191" = from 00:0c:db:81:5e:a8 ieee80211_recv_mgmt: caps 0x401 bintval 100 erp 0x0 ieee80211_recv_mgmt: country info 55 53 20 24 04 11 34 04 17 95 05 1e INTR!0x00000002 Notification (25) Scan channel (52) INTR!0x00000002 RX!DATA!68!56!50 ieee80211_recv_mgmt: new probe response on chan 56 (bss chan 56) "191" = from 00:0c:db:81:5e:4a ieee80211_recv_mgmt: caps 0x401 bintval 100 erp 0x0 ieee80211_recv_mgmt: country info 55 53 20 24 04 11 34 04 17 95 05 1e INTR!0x00000002 Notification (25) Scan channel (56) INTR!0x00000002 Scan channel (60) INTR!0x00000002 Scan channel (64) INTR!0x00000002 Scan channel (149) INTR!0x00000002 Scan channel (153) INTR!0x00000002 Scan channel (157) INTR!0x40000000 iwi0: fatal error At which point dhclient stalls for several seconds before switching to = its background mode. `ifconfig iwi0` then shows "status: no carrier" and no = IP address assignment. From owner-freebsd-stable@FreeBSD.ORG Tue May 3 05:43:31 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9A3816A4CE; Tue, 3 May 2005 05:43:30 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD36243D88; Tue, 3 May 2005 05:43:30 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id C197372DD4; Mon, 2 May 2005 22:43:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id BFE2272DCB; Mon, 2 May 2005 22:43:30 -0700 (PDT) Date: Mon, 2 May 2005 22:43:30 -0700 (PDT) From: Doug White To: freebsd-stable@freebsd.org Message-ID: <20050502222223.P19845@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: re@freebsd.org Subject: Experimental ttwwakeup() panic patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 05:43:31 -0000 Hey folks, I've taken a crack at working around the ttwwakeup() panic thats been reported now and again. My early analysis, based on debugging output from rwatson, is that a defunct struct tty gets reused without cleaning out the associated (stale) knote structures, and the ttwwakeup() at the end of sioopen() jumps off into space when it finds them. This patch is against RELENG_5 but the logic should apply to -CURRENT, although the patch likely won't as ttymalloc() is organized differently there. I did some basic testing on my UP box and didn't see any abberant behavior afterwards. However I can't reproduce the panic in question, so if you're good at triggering the panic give this a spin. http://people.freebsd.org/~dwhite/tty.c.20050502.patch -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Tue May 3 06:07:51 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1FD216A4CE for ; Tue, 3 May 2005 06:07:51 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FA2343D46 for ; Tue, 3 May 2005 06:07:51 +0000 (GMT) (envelope-from des@des.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFW0082ZGRFJ5B0@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 03 May 2005 08:02:03 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFW00MGRH2IFKE0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 03 May 2005 08:08:42 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 52AA945165; Tue, 03 May 2005 08:07:49 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 8B00F45131; Tue, 03 May 2005 08:07:45 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 5509133C39; Tue, 03 May 2005 08:07:45 +0200 (CEST) Date: Tue, 03 May 2005 08:07:45 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050502180152.I53065@ganymede.hub.org> To: "Marc G. Fournier" Message-id: <86psw84zbi.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <426E5713.3010906@eurocom.od.ua> <747dc8f30504260812ee3c47e@mail.gmail.com> <426E5EA5.8000703@eurocom.od.ua> <426F3AFA.9020900@konvergencia.hu> <426F5A6E.4050208@eurocom.od.ua> <86acndmyky.fsf@xps.des.no> <4276910A.3040100@criticalmagic.com> <20050502180152.I53065@ganymede.hub.org> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: cc: Alexander Rusinov cc: Richard Coleman cc: freebsd-stable@freebsd.org Subject: Re: PostgreSQL in FreeBSD jails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 06:07:51 -0000 "Marc G. Fournier" writes: > You've all lost me here ... what exactly is the problem? You can't run multiple instances of PostgreSQL on the same machine (even in chroot or jail, even without TCP/IP support) without changing the port number in postgresql.conf. PostgreSQL creates shared memory segments with keys based on the port number, so separate instances will try to create and use the same segments if configured to use the same port number. > PostgreSQL > works under FreeBSD 4.x jails without any modifications, so how is > PostgreSQL itself currently broken? It seems to me that the problem > is with FreeBSD 5.x's jail side of things, if the same daemon runs > fine under 4.x, but, nto under 5.x ... PostgreSQL has always had this problem, both on 4.x and 5.x. A hack was put in place last November to work around it, but it still exists, and while it may now be possible (with 8.0) for multiple postmasters to run on the same machine, it is also still possible for malicious code in one jail to crash postmasters in other jails. The underlying problem is that FreeBSD does not have separate SHM namespaces in each jail, but, as has already been pointed out, that problem is fairly hard to fix. Patching PostgreSQL to use something else than SysV shared memory is easier and will benefit other OSes as well. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Tue May 3 06:18:27 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CC7316A4CE for ; Tue, 3 May 2005 06:18:27 +0000 (GMT) Received: from cyclone.mail.adnap.net.au (cyclone.mail.adnap.net.au [203.6.132.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C945743D60 for ; Tue, 3 May 2005 06:18:26 +0000 (GMT) (envelope-from tim@spyderweb.com.au) Received: from bofh.spyderweb.com.au (202-6-154-85.ip.adam.com.au [202.6.154.85]) by cyclone.mail.adnap.net.au (Postfix) with ESMTP id 4ECDC988BD for ; Tue, 3 May 2005 15:48:25 +0930 (CST) Received: from spyderweb.com.au (localhost [127.0.0.1]) by bofh.spyderweb.com.au (8.13.3/8.13.3) with ESMTP id j432A8mH002319 for ; Tue, 3 May 2005 11:40:09 +0930 (CST) (envelope-from tim@spyderweb.com.au) Date: Tue, 3 May 2005 11:40:08 +0930 From: Tim Aslat To: freebsd-stable@freebsd.org Message-ID: <20050503114008.0959da15@bofh.spyderweb.com.au> Organization: Spyderweb Consulting X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Strange SMP problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 06:18:27 -0000 Hi All, Just had a strange problem with my desktop. I rebuilt world from sources downloaded a few hours ago, rebooted and everything worked fine. Then I noticed that I had HTT turned off, rebooted, enabled HTT in the bios and booted up again. The system seemed to work ok, until I tried loading several apps under X (mozilla, firefox, dillo, xmms) when they would just freeze. They couldn't be killed, even using kill -9, and none of the windows actually loaded onto the desktop. The desktop itself (fluxbox) loaded perfectly, as did some of the dockapps I have installed. I rebooted again, turned off HTT and lo & behold, everything is working perfectly again. I have SMP compiled into the kernel, however I had the machine in non-HTT mode when I rebuilt world & kernel this morning. Could that have had something to do with it? There were no core dumps, or traces I could do, the system just ground to a halt and had to be hard reset. bofh.zaphod [11:39am] [~] >uname -a FreeBSD bofh.spyderweb.com.au 5.4-STABLE FreeBSD 5.4-STABLE #19: Tue May 3 10:19:03 CST 2005 root@bofh.spyderweb.com.au:/usr/obj/usr/src/sys/BOFH i386 Cheers Tim -- Tim Aslat Spyderweb Consulting http://www.spyderweb.com.au Phone: +61 8 84193434 Mobile: +61 0401088479 From owner-freebsd-stable@FreeBSD.ORG Tue May 3 07:56:09 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDC6E16A4CF for ; Tue, 3 May 2005 07:56:09 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 904E043D5A for ; Tue, 3 May 2005 07:56:09 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from ranger.anduin.net ([81.0.162.52] helo=[192.168.1.110]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DSsGA-0006Aj-VP for stable@freebsd.org; Tue, 03 May 2005 09:56:03 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 03 May 2005 09:54:54 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: "stable@freebsd.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: gmirror oddities X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 07:56:10 -0000 Hi! I've been using gmirror for a while to safeguard my system disks. I have taken the slice-based mirror approach, where I use, say, ad0s1 and ad2s1 as providers. On one of my servers, this seems to be impossible. I create the mirror using ad2s1 first (to keep my system running while I do some of the work), and then I re-initialize ad0s1 (making it exactly the size of ad2s1) before using gmirror insert to add it to the mirror. However, at this point - when doing a gmirror list - it turns out that it never added ad0s1 as a provider, but ad0 itself! As a result, I now have a load of slices (ad0a, ad0b, ad0d, ad0e, ad0f) instead of having the same structure as I have on ad2s1. It's just like ad2s1, just without the "s1" part. I've tried "dd if=/dev/zero of=/dev/ad0 bs=65536" a couple of times, in case some old provider metadata was stored there. I also have exactly the same setup in another server, the only difference being that it behaves as expected.. Am I doing something blatantly wrong here? This IS supposed to work, right? I've even found a very nice description of how to do it at http://people.freebsd.org/~rse/mirror/ confirming that what I'm doing is right. I'm on 5.4-PRERELEASE, but this problem has been there since 5.3-p2 or something, which was when I first tried this. Anyone? Thanks, /Eirik From owner-freebsd-stable@FreeBSD.ORG Tue May 3 08:18:31 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E0B316A4EE for ; Tue, 3 May 2005 08:18:31 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C45243D39 for ; Tue, 3 May 2005 08:18:30 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <427733D2.5020300@geminix.org> Date: Tue, 03 May 2005 10:18:26 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050501 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@FreeBSD.ORG References: <200505021407.j42E7gFv095417@lurza.secnetix.de> In-Reply-To: <200505021407.j42E7gFv095417@lurza.secnetix.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1DSsbs-000PpE-61; Tue, 03 May 2005 10:18:29 +0200 Subject: Re: kernel: swap_pager: indefinite wait buffer - on 5.3-RELEASE-p5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 08:18:31 -0000 Oliver Fromme wrote: > Uwe Doering wrote: > > Oliver Fromme wrote: > > > If they're really identical (i.e. the same size and same > > > geometry), then you can use dd(1) for duplication, like > > > this: > > > > > > # dd if=/dev/ad0 of=/dev/ad1 bs=64k conv=noerror,sync > > > > > > The "noerror,sync" part is important so the dd command will > > > not stop when it hits any bad spots on the source drive and > > > instead will fill the blocks with zeroes on the destination > > > drive. Since it's only the swap partition, you shouldn't > > > lose any data. > > > > I would like to point out that the conclusion you're drawing in the last > > sentence is invalid IMHO. > > I'm afraid I don't agree. > > > "indefinite wait buffer" messages at > > apparently random block numbers just indicate that the pager was unable > > to access the swap area (in its entirety!) when it wanted to. It means > > that the disk drive was either dead at that point in time or busy trying > > to deal with a bad sector. > > > > This sector could have been anywhere on the disk. It just kept the disk > > drive busy for long enough that the pager started to complain. > > The OP specifically said that the swap_pager messages were > the only kernel messages that he got. That indicates that > only the swap partition is affected, because otherwise > there would have been other kernel messages indicating > I/O errors from one of the filesystems on that disk. Your assumption here is that the filesystem code would become impatient, too. This in not the case. The swap pager has a timeout built in (20 seconds IIRC) after which it prints a warning message and continues waiting, but there is nothing like this in the filesystem code. If the disk drive is dead or busy trying to deal with a bad sector in a filesystem the kernel will wait silently and indefinitely until either the disk drive succeeds in recovering the sector, or it fails to do so. In the latter case the kernel would log an I/O error. But only when it hears back from the disk drive and not any earlier, in contrast to the swap pager. That's why you often see only swap pager messages in case of a dying disk drive. I checked the kernel sources, but of course I could have missed the relevant lines. In this case I would appreciate a pointer to the place at which the filesystem code generates a warning message comparable to that from the swap pager. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-stable@FreeBSD.ORG Tue May 3 09:47:06 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ACF416A4CE; Tue, 3 May 2005 09:47:06 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE2B143D6A; Tue, 3 May 2005 09:47:03 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 48AE41F375; Tue, 3 May 2005 11:47:00 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 326C2615A; Tue, 3 May 2005 11:47:00 +0200 (CEST) Date: Tue, 3 May 2005 11:47:00 +0200 From: Marc Olzheim To: Brian Fundakowski Feldman Message-ID: <20050503094700.GA65878@stack.nl> References: <20050420173859.GA99695@stack.nl> <20050426140701.GB5789@green.homeunix.org> <20050426151751.GB68038@stack.nl> <20050426155043.GC5789@green.homeunix.org> <20050426160609.GA68511@stack.nl> <20050426162549.GD5789@green.homeunix.org> <20050426164346.GA68763@stack.nl> <20050426193602.GE5789@green.homeunix.org> <20050427081746.GA66441@stack.nl> <20050427160857.GF5789@green.homeunix.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20050427160857.GF5789@green.homeunix.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: Marc Olzheim cc: freebsd-stable@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 09:47:06 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 27, 2005 at 12:08:57PM -0400, Brian Fundakowski Feldman wrote: > Alright, this will do synchronous, instead of short, writes (also, > of course, not deadlock the system) if you are trying to use an > excessively large buffer size. >=20 > > Will this be incorporated in time for 5.4 ? Marc --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCd0iUezjnobFOgrERAhVUAKC/0JqP8tlri8o3nfPUoR5IelrcHACg1BW+ MFN6mP3tMYdJrn3e585Un6o= =yCA6 -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-stable@FreeBSD.ORG Tue May 3 11:00:06 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7017216A4CE; Tue, 3 May 2005 11:00:06 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C826043D55; Tue, 3 May 2005 11:00:05 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DSv8D-000EwW-37; Tue, 03 May 2005 14:00:01 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Ian Dowse In-Reply-To: Message from Ian Dowse <200505021708.aa58927@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 03 May 2005 14:00:00 +0300 From: Danny Braniss Message-ID: cc: stable@freebsd.org cc: current@freebsd.org Subject: Re: MNT_USER? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 11:00:06 -0000 > In message , Danny Braniss writes: > > > >after doing a mount_nfs as root (from the console or via su), statfs reports > >that MNT_USER flags is set! this is also true with 5.4. > > It's a bug in the statfs reporting for NFS filesystems. It should > be fixed now in -CURRENT (revision 1.174 of sys/nfsclient/nfs_vfsops.c). > I'll merge this to -STABLE in a week or so. > > Ian good, it did indeed fix the problem, and also a previous one that turned on the MNT_NOEXEC. BTW, this, the MNT_NOEXEC, uncovered, IMHO, a bug in libexec/rtld-elf/rtld.c where it's now checking for MNT_NOEXEC, but only if LD_LIBRARY_PATH is set! danny From owner-freebsd-stable@FreeBSD.ORG Tue May 3 11:10:33 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B7EA16A4CE; Tue, 3 May 2005 11:10:33 +0000 (GMT) Received: from pd4mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A428043D6B; Tue, 3 May 2005 11:10:32 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mr5so.prod.shaw.ca (pd4mr5so-qfe3.prod.shaw.ca [10.0.141.50])2004)) with ESMTP id <0IFW0046KV1E5SE0@l-daemon>; Tue, 03 May 2005 05:10:26 -0600 (MDT) Received: from pn2ml5so.prod.shaw.ca ([10.0.121.149]) by pd4mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IFW00MRQV1EG1J0@pd4mr5so.prod.shaw.ca>; Tue, 03 May 2005 05:10:26 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IFW00B0EV1DSS@l-daemon>; Tue, 03 May 2005 05:10:26 -0600 (MDT) Date: Tue, 03 May 2005 04:10:18 -0700 From: Colin Percival In-reply-to: To: Danny Braniss Message-id: <42775C1A.2080400@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 References: User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) cc: Ian Dowse cc: stable@freebsd.org cc: current@freebsd.org Subject: Re: MNT_USER? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 11:10:33 -0000 Danny Braniss wrote: > BTW, this, the MNT_NOEXEC, uncovered, IMHO, a bug in libexec/rtld-elf/rtld.c > where it's now checking for MNT_NOEXEC, but only if LD_LIBRARY_PATH is set! This is not a bug. Checking for MNT_NOEXEC adds a cost in performance, and it is not necessary if LD_LIBRARY_PATH, LD_PRELOAD, and LD_LIBMAP* are not set -- based on the assumption, that is, that no (sane) sysadmin would ever put a MNT_NOEXEC-mounted filesystem into the default library path. I agree that it's a bit counter-intuitive, but it's really just a case of saving time by not checking for something which should Never Happen. :-) Colin Percival PS. Bravo to Ian for tracking down the bug in NFS -- I spent a while looking for this, but got hopelessly lost. From owner-freebsd-stable@FreeBSD.ORG Tue May 3 13:21:57 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C5DF16A4CE for ; Tue, 3 May 2005 13:21:57 +0000 (GMT) Received: from gwmail1.grupos.com.br (gwmail1.grupos.com.br [66.90.64.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 155B143D60 for ; Tue, 3 May 2005 13:21:57 +0000 (GMT) (envelope-from marcus@corp.grupos.com.br) Received: from corp.grupos.com.br (unknown [150.162.166.55]) by gwmail1.grupos.com.br (Postfix) with ESMTP id 3B8BB3D298 for ; Tue, 3 May 2005 10:21:56 -0300 (BRT) Received: from [150.162.166.51] (unknown [150.162.166.51]) by corp.grupos.com.br (Postfix) with ESMTP id 30F7F5566 for ; Tue, 3 May 2005 10:21:41 -0300 (BRT) Message-ID: <42777AE4.4000900@corp.grupos.com.br> Date: Tue, 03 May 2005 10:21:40 -0300 From: Marcus Grando User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: panic on RELENG_5_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 13:21:57 -0000 Hi, Panic on RELENG_5_4 (cvsup yesterday). Waiting 5 seconds for SCSI devices to settle panic: mutex Giant not owned at /usr/src/cam/cam_xpt.c:4825 cpuid = 0 KDB: enter: panic [thread pid 35 tid 100031 ] Stopped at kdb_enter+0x2b: nop db> where Tracing pid 35 tid 100031 td 0xc22fb180 kdb_enter(c06e73f5) at kdb_enter+0x2b panic(c06e68be,c06f7be6,c06c08da,12d9,c2608800) at panic+0x127 _mtx_assert(c074c660,1,c06c08da,12d9) at _mtx_assert+0x5c xpt_done(c2608800,c23b6138,c23af000,c23af000,e4df8c54) at xpt_done+0x1d amr_cam_complete_extcdb(c23b6138)at amr_cam_complete_extcdb+0c3 amr_complete(c23af000,0,54e3,0,d79200) at amr_complete+0x5e amr_done(c23af000,c23af94c,0,c06dbc1d,1ae) at amr_done+0xb2 amr_pci_intr(c23af000) at amr_pci_intr+0x26 ithread_loop(c2306a00,e4df8d48,c2306a00,c0534f64,0) at ithread_loop+0x124 fork_exit(c0534f64,c2306a00,e4df8d48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4df8d7c, ebp = 0 --- db> I need more information, please ask. Regards -- Marcus Grando Grupos Internet S/A marcus(at)corp.grupos.com.br From owner-freebsd-stable@FreeBSD.ORG Tue May 3 13:59:10 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id BA9B216A4CE; Tue, 3 May 2005 13:59:09 +0000 (GMT) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.3/8.13.1) with ESMTP id j43Dx68O082029; Tue, 3 May 2005 09:59:06 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.3/8.13.1/Submit) id j43Dx59F082028; Tue, 3 May 2005 09:59:05 -0400 (EDT) (envelope-from green) Date: Tue, 3 May 2005 09:59:05 -0400 From: Brian Fundakowski Feldman To: Marc Olzheim Message-ID: <20050503135905.GA77223@green.homeunix.org> References: <20050426140701.GB5789@green.homeunix.org> <20050426151751.GB68038@stack.nl> <20050426155043.GC5789@green.homeunix.org> <20050426160609.GA68511@stack.nl> <20050426162549.GD5789@green.homeunix.org> <20050426164346.GA68763@stack.nl> <20050426193602.GE5789@green.homeunix.org> <20050427081746.GA66441@stack.nl> <20050427160857.GF5789@green.homeunix.org> <20050503094700.GA65878@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503094700.GA65878@stack.nl> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: NFS client/buffer cache deadlock X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 13:59:10 -0000 On Tue, May 03, 2005 at 11:47:00AM +0200, Marc Olzheim wrote: > On Wed, Apr 27, 2005 at 12:08:57PM -0400, Brian Fundakowski Feldman wrote: > > Alright, this will do synchronous, instead of short, writes (also, > > of course, not deadlock the system) if you are trying to use an > > excessively large buffer size. > > > > > > > > Will this be incorporated in time for 5.4 ? It really needs someone else to review the code changes more than just conceptually to make this kind of an adjustment before release. It is not truly an optimal solution, as fully synchronous writes are not necessary; just limiting the "write window" size and requiring posted transactions to complete before queueing up more is. Doing that is more error-prone, however, and would I think complicate things just to optimize the speed of a rare case. Still, there are probably a few who would object, in which case they should do the work of optimizing that side case ;) There's still missing an actual mount_nfs(8) configuration flag and documentation, but those things are trivial. (Forwarded on to -current as well, for additional eyes/testers.) -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-stable@FreeBSD.ORG Tue May 3 14:43:21 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2D8616A4CE for ; Tue, 3 May 2005 14:43:21 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14C5A43D53 for ; Tue, 3 May 2005 14:43:21 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailhost.stack.nl (Postfix) with ESMTP id E312E1F3ED for ; Tue, 3 May 2005 16:43:13 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 333) id D8EA222899; Tue, 3 May 2005 16:43:13 +0200 (CEST) Date: Tue, 3 May 2005 16:43:13 +0200 From: Marc Olzheim To: freebsd-stable@freebsd.org Message-ID: <20050503144313.GA14948@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FL5UXtIhxfXey3p5" Content-Disposition: inline X-Operating-System: FreeBSD snail.stack.nl 5.3-RELEASE-p9 FreeBSD 5.3-RELEASE-p9 X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Subject: Instant reboot FreeBSD 5.4-STABLE amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 14:43:21 -0000 --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD 5.4-STABLE #12: Mon May 2 19:23:22 CEST 2005 root@hammer.stack.nl:= /usr/obj/usr/src/sys/HAMMER hammer:~/src/hak/fpu>gdb ./fpu5th=20 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... (gdb) break floor Function "floor" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (floor) pending. (gdb) r Starting program: /vwww.mnt/sources/srcimport/marcolz/hak/fpu/fpu5th=20 Breakpoint 2 at 0x80063fdf0 Pending breakpoint "floor" resolved load: 0.08 cmd: fpu5th 917 [running] 1.69u 0.01s 4% 1192k Program received signal SIGINFO, Information request. [Switching to Thread 1 (LWP 100167)] 0x000000080076558c in pthread_testcancel () from /usr/lib/libpthread.so.1 (gdb) disass floorl No symbol "floorl" in current context. (gdb) disass floorf Dump of assembler code for function floorf: 0x000000080063fd40 : movss %xmm0,0xfffffffffffffffc(%rsp) 0x000000080063fd46 : mov 0xfffffffffffffffc(%rsp),%edx 0x000000080063fd4a : mov %edx,%eax 0x000000080063fd4c : sar $0x17,%eax 0x000000080063fd4f : and $0xff,%eax 0x000000080063fd54 : lea 0xffffffffffffff81(%rax),%ecx 0x000000080063fd57 : cmp $0x16,%ecx 0x000000080063fd5a : jg 0x80063fda1 0x000000080063fd5c : test %ecx,%ecx 0x000000080063fd5e : js 0x80063fdb1 0x000000080063fd60 : mov $0x7fffff,%esi 0x000000080063fd65 : movaps %xmm0,%xmm1 0x000000080063fd68 : sar %cl,%esi 0x000000080063fd6a : test %edx,%esi 0x000000080063fd6c : je 0x80063fd9d 0x000000080063fd6e : addss 3226(%rip),%xmm0 # 0x800640a1= 0 <_fini+152> 0x000000080063fd76 : ucomiss 3223(%rip),%xmm0 # 0x800640a= 14 <_fini+156> 0x000000080063fd7d : jbe 0x80063fd90 0x000000080063fd7f : test %edx,%edx 0x000000080063fd81 : js 0x80063fdd9 ---Type to continue, or q to quit--- 0x000000080063fd83 : mov %esi,%eax 0x000000080063fd85 : not %eax 0x000000080063fd87 : and %eax,%edx 0x000000080063fd89 : data16 0x000000080063fd8a : data16 0x000000080063fd8b : data16 0x000000080063fd8c : nop =20 0x000000080063fd8d : data16 0x000000080063fd8e : data16 0x000000080063fd8f : nop =20 0x000000080063fd90 : mov %edx,0xfffffffffffffffc(%rsp) 0x000000080063fd94 : movss 0xfffffffffffffffc(%rsp),%xmm0 0x000000080063fd9a : movaps %xmm0,%xmm1 0x000000080063fd9d : movaps %xmm1,%xmm0 0x000000080063fda0 : retq =20 0x000000080063fda1 : add $0xffffffffffffff80,%ecx 0x000000080063fda4 : movaps %xmm0,%xmm1 0x000000080063fda7 : jne 0x80063fd9d 0x000000080063fda9 : addss %xmm0,%xmm1 0x000000080063fdad : movaps %xmm1,%xmm0 0x000000080063fdb0 : retq =20 0x000000080063fdb1 : addss 3159(%rip),%xmm0 # 0x= 800640a10 <_fini+152> ---Type to continue, or q to quit--- 0x000000080063fdb9 : ucomiss 3156(%rip),%xmm0 # 0= x800640a14 <_fini+156> 0x000000080063fdc0 : jbe 0x80063fd90 0x000000080063fdc2 : test %edx,%edx 0x000000080063fdc4 : js 0x80063fdca 0x000000080063fdc6 : xor %edx,%edx 0x000000080063fdc8 : jmp 0x80063fd90 0x000000080063fdca : test $0x7fffffff,%edx 0x000000080063fdd0 : je 0x80063fd90 0x000000080063fdd2 : mov $0xbf800000,%edx 0x000000080063fdd7 : jmp 0x80063fd90 0x000000080063fdd9 : mov $0x800000,%eax 0x000000080063fdde : sar %cl,%eax 0x000000080063fde0 : add %eax,%edx 0x000000080063fde2 : jmp 0x80063fd83 0x000000080063fde4 : nop =20 0x000000080063fde5 : nop =20 0x000000080063fde6 : nop =20 0x000000080063fde7 : nop =20 0x000000080063fde8 : nop =20 0x000000080063fde9 : nop =20 0x000000080063fdea : nop =20 0x000000080063fdeb : nop =20 ---Type to continue, or q to quit--- 0x000000080063fdec : nop =20 0x000000080063fded : nop =20 0x000000080063fdee : nop =20 0x000000080063fdef : nop =20 End of assembler dump. (gdb) q The program is running. Exit anyway? (y or n) y *reboot, no dump* :-(( I tried debugging the program I just mailed to threads@ Marc --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCd44BezjnobFOgrERAmp1AJ9AQ8Kk/yHA36jxTtsV+HOxTHzYywCeOFmm x6Nezid2eAQ7vw69G12VO8U= =4kN3 -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From owner-freebsd-stable@FreeBSD.ORG Tue May 3 14:48:11 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B165D16A4CE for ; Tue, 3 May 2005 14:48:11 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5427D43D4C for ; Tue, 3 May 2005 14:48:11 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailhost.stack.nl (Postfix) with ESMTP id 613531F030 for ; Tue, 3 May 2005 16:48:04 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 333) id 5446F22899; Tue, 3 May 2005 16:48:04 +0200 (CEST) Date: Tue, 3 May 2005 16:48:04 +0200 From: Marc Olzheim To: freebsd-stable@freebsd.org Message-ID: <20050503144804.GB14948@stack.nl> References: <20050503144313.GA14948@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline In-Reply-To: <20050503144313.GA14948@stack.nl> X-Operating-System: FreeBSD snail.stack.nl 5.3-RELEASE-p9 FreeBSD 5.3-RELEASE-p9 X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Subject: Re: Instant reboot FreeBSD 5.4-STABLE amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 14:48:11 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 03, 2005 at 04:43:13PM +0200, Marc Olzheim wrote: > FreeBSD 5.4-STABLE #12: Mon May 2 19:23:22 CEST 2005 root@hammer.stack.n= l:/usr/obj/usr/src/sys/HAMMER >=20 Doing exactly the same on i386 SMP results in a hanging gdb and the process exiting with signal 8. blackmetal:~#ps uaxwwwwwlp 759 =20 USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND UID= PPID CPU PRI NI MWCHAN marcolz 759 0.0 0.1 5976 5440 p0 I+ 4:45PM 0:00.07 gdb ./fpu5t= h 104 650 0 8 0 wait =20 blackmetal:~# Marc --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCd48kezjnobFOgrERArqPAJ9v4s4opnUnBNOglqckYN5h/GXzogCfZmc4 5UaLbvuFm53hvmC02TSMyOc= =p4+D -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-freebsd-stable@FreeBSD.ORG Tue May 3 15:00:22 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20A9516A4D0; Tue, 3 May 2005 15:00:22 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 949E943D62; Tue, 3 May 2005 15:00:21 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailhost.stack.nl (Postfix) with ESMTP id 1CB761F3F2; Tue, 3 May 2005 17:00:15 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 333) id 0F9EE22899; Tue, 3 May 2005 17:00:15 +0200 (CEST) Date: Tue, 3 May 2005 17:00:14 +0200 From: Marc Olzheim To: bug-followup@FreeBSD.org, rwatson@freebsd.org Message-ID: <20050503150014.GG17096@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i cc: freebsd-stable@freebsd.org Subject: Re: kern/78824: race condition close()ing and read()ing the same socketpair on SMP. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 15:00:22 -0000 Is this going to be fixed before 5.4 ? It still breaks on today's 5.4-STABLE. Marc From owner-freebsd-stable@FreeBSD.ORG Tue May 3 15:04:15 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7062916A4CE for ; Tue, 3 May 2005 15:04:15 +0000 (GMT) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FD1143D75 for ; Tue, 3 May 2005 15:04:14 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 0B4AA64DBAF; Tue, 3 May 2005 12:04:08 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 45762-07; Tue, 3 May 2005 15:04:07 +0000 (GMT) Received: from ganymede.hub.org (blk-222-81-172.eastlink.ca [24.222.81.172]) by hub.org (Postfix) with ESMTP id 77C2A64DB2B; Tue, 3 May 2005 12:04:07 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 1C77337A81; Tue, 3 May 2005 12:04:06 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 1926433FAA; Tue, 3 May 2005 12:04:06 -0300 (ADT) Date: Tue, 3 May 2005 12:04:06 -0300 (ADT) From: "Marc G. Fournier" To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <86psw84zbi.fsf@xps.des.no> Message-ID: <20050503114016.U53065@ganymede.hub.org> References: <426E5713.3010906@eurocom.od.ua> <747dc8f30504260812ee3c47e@mail.gmail.com> <426E5EA5.8000703@eurocom.od.ua> <426F3AFA.9020900@konvergencia.hu> <426F5A6E.4050208@eurocom.od.ua> <86acndmyky.fsf@xps.des.no> <20050502180152.I53065@ganymede.hub.org> <86psw84zbi.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-362608285-1115132646=:53065" X-Virus-Scanned: by amavisd-new at hub.org cc: Alexander Rusinov cc: Richard Coleman cc: freebsd-stable@freebsd.org Subject: Re: PostgreSQL in FreeBSD jails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 15:04:15 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-362608285-1115132646=:53065 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 3 May 2005, [iso-8859-1] Dag-Erling Sm=F8rgrav wrote: > PostgreSQL has always had this problem, both on 4.x and 5.x. A hack was= =20 > put in place last November to work around it, but it still exists, and=20 > while it may now be possible (with 8.0) for multiple postmasters to run= =20 > on the same machine 'k, I've been doing multiple since 7.2 on the same machine, all on the=20 same port, all different IPs, all on 4.x servers ... have never had an=20 issue with crashes (its pretty much my most stable 4.x server) ... In fact: # ps aux | grep postmaster | egrep -v "postmaster:" | sort +1 -n scrappy 36569 0.0 0.0 14552 600 ?? IsJ 19Apr05 0:21.48 /usr/local/p= gsql/bin/postmaster -D /usr/local/pgsql/data -S (postgres) scrappy 36675 0.0 0.0 258184 1052 ?? SsJ 19Apr05 14:10.24 /usr/local/= bin/postmaster -D /usr/local/pgsql/data -S (postgres) scrappy 36865 0.0 0.0 16556 836 ?? IsJ 19Apr05 0:14.17 /usr/local/b= in/postmaster -D /usr/local/pgsql/data -S (postgres) pgsql 37518 0.0 0.0 16400 396 ?? IsJ 19Apr05 0:04.02 /usr/local/b= in/postmaster (postgres) pgsql 37815 0.0 0.0 8144 436 p9- IJ 19Apr05 0:14.62 /usr/local/b= in/postmaster (postgres) pgsql 37962 0.0 0.0 8680 560 ?? IsJ 19Apr05 0:08.72 /usr/local/b= in/postmaster (postgres) pgsql 38168 0.0 0.0 16400 452 ?? IsJ 19Apr05 0:37.69 /usr/local/b= in/postmaster (postgres) pgsql 38316 0.0 0.0 7144 464 ?? IsJ 19Apr05 0:04.08 /usr/local/b= in/postmaster (postgres) pgsql 38458 0.0 0.0 7208 380 ?? IsJ 19Apr05 0:04.01 /usr/local/b= in/postmaster (postgres) pgsql 38596 0.0 0.0 6952 452 ?? IsJ 19Apr05 0:03.90 /usr/local/b= in/postmaster (postgres) scrappy 38717 0.0 0.0 6952 436 ?? IsJ 19Apr05 0:03.98 /usr/local/b= in/postmaster (postgres) pgsql 38868 0.0 0.0 8224 552 ?? SsJ 19Apr05 0:03.39 /usr/local/b= in/postmaster -D /usr/local/pgsql/data (postgres) pgsql 38993 0.0 0.0 7912 584 ?? IsJ 19Apr05 0:06.41 /usr/local/b= in/postmaster (postgres) pgsql 39126 0.0 0.0 7480 400 ?? IsJ 19Apr05 0:01.80 /usr/local/b= in/postmaster -D /usr/local/pgsql/data (postgres) pgsql 87544 0.0 0.1 7948 3528 ?? IsJ Sun08PM 0:00.78 /usr/local/b= in/postmaster -D /usr/local/pgsql/data (postgres) # ipcs -a | fgrep -f /tmp/pids | sort +10 -n m 327683 5432003 --rw------- scrappy 1001 scrappy 1001 7 = 10256384 36569 38717 8:40:46 11:51:28 8:37:57 m 131076 5432004 --rw------- scrappy 1001 scrappy 1001 100 = 257957888 36675 38717 8:40:46 11:54:16 8:38:04 m 10092549 5432005 --rw------- scrappy 1001 scrappy 1001 1= 2 10362880 36865 38717 8:40:46 11:29:20 8:38:25 m 131080 5432007 --rw------- pgsql pgsql pgsql pgsql 1 = 10436608 37518 39126 8:41:20 11:53:08 8:39:18 m 131081 5432008 --rw------- pgsql pgsql pgsql pgsql 6 = 2449408 37815 39126 8:41:20 11:52:32 8:39:43 m 393226 5432009 --rw------- pgsql pgsql pgsql pgsql 9 = 2596864 37962 39126 8:41:20 11:50:25 8:39:55 m 131083 5432010 --rw------- pgsql pgsql pgsql pgsql 1 = 10436608 38168 39126 8:41:20 11:52:15 8:40:06 m 1048588 5432011 --rw------- pgsql pgsql pgsql pgsql 1= 1024000 38316 39126 8:41:20 11:51:53 8:40:19 m 131085 5432012 --rw------- pgsql pgsql pgsql pgsql 1 = 1024000 38458 39126 8:41:20 11:50:28 8:40:29 m 131086 5432013 --rw------- pgsql pgsql pgsql pgsql 1 = 761856 38596 39126 8:41:20 11:53:02 8:40:38 m 131087 5432014 --rw------- scrappy 1001 scrappy 1001 1 = 761856 38717 38717 8:40:46 11:50:42 8:40:46 m 131088 5432015 --rw------- pgsql pgsql pgsql pgsql 2 = 811008 38868 39126 8:41:20 1:59:39 8:40:58 m 1507345 5432016 --rw------- pgsql pgsql pgsql pgsql 1= 761856 38993 39126 8:41:20 11:50:37 8:41:07 m 1310738 5432017 --rw------- pgsql pgsql pgsql pgsql 2= 811008 39126 39126 8:41:20 0:59:01 8:41:20 m 196615 5432001 --rw------- pgsql pgsql pgsql pgsql 11 = 1548288 87544 8754420:32:30 11:50:56 20:32:30 So, unless I'm missing something here, each postmaster is acquiring its=20 own ID, and the above servers consist of the following versions (all of=20 which are built from ports): 1 postgresql-7.2.4_2 1 postgresql-7.4.1 1 postgresql-7.4.1_1 1 postgresql-7.4.2 2 postgresql-7.4.5 4 postgresql-7.4.6 1 postgresql-devel-8.0.0,1 1 postgresql-server-7.4.7 1 postgresql-server-7.4.7_3 1 postgresql-server-8.0.0 1 postgresql-server-8.0.1_3 So, unless I'm missing something, 4.x did allow for running multiple=20 PostgreSQL servers, on the same machine, in multiple jails, each with=20 their own distinct shared memory segment ... or am I mis-reading the=20 above? > it is also still possible for malicious code in one jail to crash > postmasters in other jails. That one I can agree with, which is why all our database servers are on a= =20 seperate machine that 'clients' don't have access to ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 --0-362608285-1115132646=:53065-- From owner-freebsd-stable@FreeBSD.ORG Tue May 3 15:47:42 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 422A616A4CE; Tue, 3 May 2005 15:47:42 +0000 (GMT) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 821CD43D6D; Tue, 3 May 2005 15:47:39 +0000 (GMT) (envelope-from ath@niksun.com) Received: from stiegl.mj.niksun.com (stiegl.mj.niksun.com [10.70.0.231]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j43FmSvw091231; Tue, 3 May 2005 11:48:28 -0400 (EDT) (envelope-from ath@niksun.com) Received: from stiegl.mj.niksun.com (localhost [127.0.0.1]) by stiegl.mj.niksun.com (Postfix) with ESMTP id 0888D54DE; Tue, 3 May 2005 11:47:33 -0400 (EDT) Date: Tue, 3 May 2005 11:47:32 -0400 From: Andrew Heybey To: freebsd-stable@freebsd.org Message-ID: <20050503114732.65bce180@stiegl.mj.niksun.com> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd4.11) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on anuket.mj.niksun.com X-Virus-Status: Clean cc: sos@freebsd.org Subject: ATA mkIII suspend problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 15:47:42 -0000 I just tried RELENG_5 as of last week and the latest (April 13) ATA mkIII patches from http://people.freebsd.org/~sos/ATA/ on my laptop. Unfortunately, it breaks suspend-to-RAM (S3). History: I first tried RELENG_5 on the laptop (a Toshiba Tecra M2V) in January and suspend did not work (the laptop hung after reinitializing the ATA controller). Then I tried the first release of ATA mkIII. That first version of the new ATA code made suspend work, and I was happy. Last week, I tried upgrading to the latest RELENG_5 and the newest ATA mkIII code, and now after suspending the kernel panics when reiniting the ATA device(s) in ata-all.c:ata_reinit(), about line 217: /* reinit the children and delete any that fails */ if (!device_get_children(dev, &children, &nchildren)) { mtx_lock(&Giant); /* newbus suckage it needs Giant */ for (i = 0; i < nchildren; i++) { if (children[i] && device_is_attached(children[i])) if (ATA_REINIT(children[i])) { if (ch->running->dev == children[i]) { ^^^^^^^^^^^^^^^^ device_printf(ch->running->dev, "FAILURE - device detached\n"); ch->running->dev = NULL; ch->running = NULL; } device_delete_child(dev, children[i]); } } free(children, M_TEMP); mtx_unlock(&Giant); /* newbus suckage dealt with, release Giant */ } The problem is that ch->running is NULL at this point. Any suggestions on how to further debug or fix? thanks, andrew From owner-freebsd-stable@FreeBSD.ORG Tue May 3 15:54:21 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13BC116A4D0 for ; Tue, 3 May 2005 15:54:21 +0000 (GMT) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9998F43D2D for ; Tue, 3 May 2005 15:54:19 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.50 (FreeBSD)) id 1DSzis-00082B-Q1 for freebsd-stable@freebsd.org; Tue, 03 May 2005 16:54:10 +0100 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.50 (FreeBSD)) id 1DSzis-000HlG-Pi for freebsd-stable@freebsd.org; Tue, 03 May 2005 16:54:10 +0100 To: freebsd-stable@freebsd.org Message-Id: From: Pete French Date: Tue, 03 May 2005 16:54:10 +0100 Subject: RC4 will not install using FTP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 15:54:21 -0000 Just been trying to install a new machine with 5.4-RC4. I normally do this using the bootonly image and FTP. But doing an FTP install always gives me the error "/: write failed, filesystem full" when it fetches the first chunk and tries to write it out. I get exactly the same problem doing an FTP install from the full disc1.iso, so it isnt a problem wiuth the boootonly iso image. Installing from the full CD works fine, however. Included below is the dmesg in case my hardware has something to dow ith this. -pcf. Copyright (c) 1992-2005 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 5.4-RC4 #0: Mon May 2 00:08:36 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2392.04-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 536301568 (511 MB) avail memory = 515141632 (491 MB) ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: mem 0xee000000-0xefffffff at device 1.0 on pci0 pci1: on pcib1 pcib2: at device 2.0 on pci0 pci2: on pcib2 pci2: at device 28.0 (no driver attached) pcib3: at device 29.0 on pci2 pci3: on pcib3 mpt0: port 0xec00-0xecff mem 0xfe3c0000-0xfe3dffff,0xfe3e0000-0xfe3fffff irq 25 at device 12.0 on pci3 mpt1: port 0xe800-0xe8ff mem 0xfe380000-0xfe39ffff,0xfe3a0000-0xfe3bffff irq 26 at device 12.1 on pci3 em0: port 0xe4c0-0xe4ff mem 0xfe360000-0xfe37ffff irq 24 at device 14.0 on pci3 em0: Ethernet address: 00:0b:db:c6:06:68 em0: Speed:N/A Duplex:N/A pci2: at device 30.0 (no driver attached) pcib4: at device 31.0 on pci2 pci4: on pcib4 uhci0: port 0xff80-0xff9f irq 16 at device 29.0 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xff60-0xff7f irq 19 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xff40-0xff5f irq 18 at device 29.2 on pci0 usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib5: at device 30.0 on pci0 pci5: on pcib5 pcib6: at device 13.0 on pci5 pci6: on pcib6 pci6: at device 0.0 (no driver attached) pci6: at device 4.0 (no driver attached) pci6: at device 8.0 (no driver attached) pci6: at device 12.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: port 0x778-0x77f,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xce000-0xcffff,0xcc800-0xcdfff,0xc8800-0xcc7ff,0xc0000-0xc87ff on isa0 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2392044020 Hz quality 800 Timecounters tick every 10.000 msec acd0: CDRW at ata1-master PIO4 Waiting 15 seconds for SCSI devices to settle da0 at mpt1 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da0: 34732MB (71132959 512 byte sectors: 255H 63S/T 4427C) Mounting root from ufs:/dev/da0s2a em0: Link is up 100 Mbps Full Duplex From owner-freebsd-stable@FreeBSD.ORG Tue May 3 15:56:18 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC58316A4CE; Tue, 3 May 2005 15:56:18 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08D4943D70; Tue, 3 May 2005 15:56:18 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j43FrnHM004763; Tue, 3 May 2005 17:53:49 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <42779EA1.4040100@DeepCore.dk> Date: Tue, 03 May 2005 17:54:09 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 1.0 (X11/20050116) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Heybey References: <20050503114732.65bce180@stiegl.mj.niksun.com> In-Reply-To: <20050503114732.65bce180@stiegl.mj.niksun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.12 cc: freebsd-stable@FreeBSD.ORG cc: sos@FreeBSD.ORG Subject: Re: ATA mkIII suspend problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 15:56:18 -0000 Andrew Heybey wrote: > I just tried RELENG_5 as of last week and the latest (April 13) ATA > mkIII patches from http://people.freebsd.org/~sos/ATA/ on my laptop.=20 > Unfortunately, it breaks suspend-to-RAM (S3). >=20 > History: >=20 > I first tried RELENG_5 on the laptop (a Toshiba Tecra M2V) in January > and suspend did not work (the laptop hung after reinitializing the ATA > controller). Then I tried the first release of ATA mkIII. That first > version of the new ATA code made suspend work, and I was happy. >=20 > Last week, I tried upgrading to the latest RELENG_5 and the newest ATA > mkIII code, and now after suspending the kernel panics when reiniting > the ATA device(s) in ata-all.c:ata_reinit(), about line 217: >=20 > /* reinit the children and delete any that fails */ > if (!device_get_children(dev, &children, &nchildren)) { > mtx_lock(&Giant); /* newbus suckage it needs Giant */ > for (i =3D 0; i < nchildren; i++) { > if (children[i] && device_is_attached(children[i])) > if (ATA_REINIT(children[i])) { > if (ch->running->dev =3D=3D children[i]) { > ^^^^^^^^^^^^^^^^ > device_printf(ch->running->dev, > "FAILURE - device detached\n"); > ch->running->dev =3D NULL; > ch->running =3D NULL; > } > device_delete_child(dev, children[i]); > } > } > free(children, M_TEMP); > mtx_unlock(&Giant); /* newbus suckage dealt with, release Giant */= > } >=20 > The problem is that ch->running is NULL at this point. >=20 > Any suggestions on how to further debug or fix? Thats been fixed since in -current just replace the line with: if (ch->running && ch->running->dev =3D=3D children[i]) { --=20 -S=F8ren From owner-freebsd-stable@FreeBSD.ORG Tue May 3 16:10:01 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D832816A4CF for ; Tue, 3 May 2005 16:10:01 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DFAB43D54 for ; Tue, 3 May 2005 16:10:01 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j43GDDa9056474; Tue, 3 May 2005 10:13:14 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4277A1FE.2080507@samsco.org> Date: Tue, 03 May 2005 10:08:30 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcus Grando References: <42777AE4.4000900@corp.grupos.com.br> In-Reply-To: <42777AE4.4000900@corp.grupos.com.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: "freebsd-stable@freebsd.org" Subject: Re: panic on RELENG_5_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 16:10:02 -0000 Marcus Grando wrote: > Hi, > > Panic on RELENG_5_4 (cvsup yesterday). > > Waiting 5 seconds for SCSI devices to settle > panic: mutex Giant not owned at /usr/src/cam/cam_xpt.c:4825 > cpuid = 0 > KDB: enter: panic > [thread pid 35 tid 100031 ] > Stopped at kdb_enter+0x2b: nop > db> where > Tracing pid 35 tid 100031 td 0xc22fb180 > kdb_enter(c06e73f5) at kdb_enter+0x2b > panic(c06e68be,c06f7be6,c06c08da,12d9,c2608800) at panic+0x127 > _mtx_assert(c074c660,1,c06c08da,12d9) at _mtx_assert+0x5c > xpt_done(c2608800,c23b6138,c23af000,c23af000,e4df8c54) at xpt_done+0x1d > amr_cam_complete_extcdb(c23b6138)at amr_cam_complete_extcdb+0c3 > amr_complete(c23af000,0,54e3,0,d79200) at amr_complete+0x5e > amr_done(c23af000,c23af94c,0,c06dbc1d,1ae) at amr_done+0xb2 > amr_pci_intr(c23af000) at amr_pci_intr+0x26 > ithread_loop(c2306a00,e4df8d48,c2306a00,c0534f64,0) at ithread_loop+0x124 > fork_exit(c0534f64,c2306a00,e4df8d48) at fork_exit+0xa4 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe4df8d7c, ebp = 0 --- > db> > > I need more information, please ask. > > Regards > I'll look at this, thanks. Scott From owner-freebsd-stable@FreeBSD.ORG Tue May 3 16:40:41 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C6A216A4CE; Tue, 3 May 2005 16:40:41 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C75D043D79; Tue, 3 May 2005 16:40:40 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id C066746B33; Tue, 3 May 2005 12:40:36 -0400 (EDT) Date: Tue, 3 May 2005 17:43:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jonathan Noack In-Reply-To: <42768DC3.5070100@alumni.rice.edu> Message-ID: <20050503173943.T35071@fledge.watson.org> References: <427396DA.60302@samsco.org> <42768DC3.5070100@alumni.rice.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Chris cc: stable@freebsd.org cc: developers@freebsd.org cc: Claus Guttesen Subject: Re: FreeBSD 5.4 release status X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 16:40:41 -0000 On Mon, 2 May 2005, Jonathan Noack wrote: >> Hi I am abit confused here, have seen a post from someone using >> 5.4-STABLE how is that possible if 5.4 isnt RELEASE yet, and good news >> on the bug fix. > > When RELENG_5_4 was branched, RELENG_5 went from 5.4-PRERELEASE to > 5.4-STABLE to reflect that it is once again open for less-restricted > development. As 5.4 will be released via the RELENG_5_4 branch, it is > normal and expected to have 5.4-STABLE around before 5.4-RELEASE. Casey Schaufler (ex-SGI, previously ex-Sun) gave a great talk at a workshop I was at recently relating to closed and open source release processes. One thing he pointed out that I found quite insightful is that what a development organization does is release source code and a build environment. Specifically, they release it to the release engineers, who then release a product, and may iterate some on the source product before turning it into the product. We represent that in the FreeBSD world through a notion of release engineering branches: when the developer team is ready to generate a source product, we generate a branch. It's done with the help of the release engineering team, but at some point the correlation between the source development branch and the releasee engineering branch becomes lower and they are essentially independent. Casey was careful to point out that what a release engineering team releases may be quite different from the development organization's product -- it may have custom patches, custom build changes, documentation (release notes), logos, and who knows what else. While there's overlap in these processes, and there's no cut and dry hand-off as a result of some iteration on the release process, I think this is a useful world view, and it explains why branches become -STABLE, etc. The development organization, once its cut its source release to the release engineering team, goes back to doing what it does: building software for its next release. We used to make the handoff synchronous, and we found that caused a lot of heartache. The loosely synchronous model we have now (where people are a bit restrained) appears to work better. Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Tue May 3 17:29:42 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83BC116A4CE for ; Tue, 3 May 2005 17:29:42 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C35B43D8E for ; Tue, 3 May 2005 17:29:39 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j43HWhuU056786; Tue, 3 May 2005 11:32:44 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4277B4A0.9060601@samsco.org> Date: Tue, 03 May 2005 11:28:00 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcus Grando References: <42777AE4.4000900@corp.grupos.com.br> In-Reply-To: <42777AE4.4000900@corp.grupos.com.br> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: "freebsd-stable@freebsd.org" Subject: Re: panic on RELENG_5_4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 17:29:42 -0000 Marcus Grando wrote: > Hi, > > Panic on RELENG_5_4 (cvsup yesterday). > > Waiting 5 seconds for SCSI devices to settle > panic: mutex Giant not owned at /usr/src/cam/cam_xpt.c:4825 > cpuid = 0 > KDB: enter: panic > [thread pid 35 tid 100031 ] > Stopped at kdb_enter+0x2b: nop > db> where > Tracing pid 35 tid 100031 td 0xc22fb180 > kdb_enter(c06e73f5) at kdb_enter+0x2b > panic(c06e68be,c06f7be6,c06c08da,12d9,c2608800) at panic+0x127 > _mtx_assert(c074c660,1,c06c08da,12d9) at _mtx_assert+0x5c > xpt_done(c2608800,c23b6138,c23af000,c23af000,e4df8c54) at xpt_done+0x1d > amr_cam_complete_extcdb(c23b6138)at amr_cam_complete_extcdb+0c3 > amr_complete(c23af000,0,54e3,0,d79200) at amr_complete+0x5e > amr_done(c23af000,c23af94c,0,c06dbc1d,1ae) at amr_done+0xb2 > amr_pci_intr(c23af000) at amr_pci_intr+0x26 > ithread_loop(c2306a00,e4df8d48,c2306a00,c0534f64,0) at ithread_loop+0x124 > fork_exit(c0534f64,c2306a00,e4df8d48) at fork_exit+0xa4 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe4df8d7c, ebp = 0 --- > db> > > I need more information, please ask. > > Regards > Could you try the patch at http://people.freebsd.org/~scottl/amr_cam.5.4.diff I'll make sure to get it into the release if it works. It looks like I had wanted to fix this exact problem in 6-current several months ago, but chose to fix xpt_done() instead (something that I don't want to merge back to 5-stable right now). Scott From owner-freebsd-stable@FreeBSD.ORG Tue May 3 17:57:56 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5972D16A4CE for ; Tue, 3 May 2005 17:57:56 +0000 (GMT) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2B1F43D5A for ; Tue, 3 May 2005 17:57:55 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.buffalo.edu [128.205.32.4]) by opus.cse.buffalo.edu (8.13.3/8.12.10) with ESMTP id j43HvpLe099915; Tue, 3 May 2005 13:57:51 -0400 (EDT) From: Ken Smith To: Pete French In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-CCtUUaL8pnBBmU00WWJe" Organization: U. Buffalo CSE Department Date: Tue, 03 May 2005 13:57:50 -0400 Message-Id: <1115143070.2859.37.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port cc: freebsd-stable@freebsd.org Subject: Re: RC4 will not install using FTP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 17:57:56 -0000 --=-CCtUUaL8pnBBmU00WWJe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-05-03 at 16:54 +0100, Pete French wrote: > Just been trying to install a new machine with 5.4-RC4. I normally > do this using the bootonly image and FTP. But doing an FTP install > always gives me the error "/: write failed, filesystem full" when > it fetches the first chunk and tries to write it out. >=20 > I get exactly the same problem doing an FTP install from the full > disc1.iso, so it isnt a problem wiuth the boootonly iso image. >=20 > Installing from the full CD works fine, however. Included below is > the dmesg in case my hardware has something to dow ith this. I haven't been able to reproduce this yet. I've successfully done an FTP install both from an initial floppy boot and from an initial disc1 CD boot. So it's not a "totally generic" problem, it might have something to do with the pathway you are following through sysinstall. Was this a brand new install or were you installing over top of a pre-existing install? If the latter did you recycle the existing disk partitions or have it wipe out everything and re-do them from scratch? Thanks. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-CCtUUaL8pnBBmU00WWJe Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCd7ue/G14VSmup/YRAlpFAKCOOhLE69F1c2RFj6L82AGvRPmnMgCeIf6J 7btF6xoaP4MbWfz2PSHpafk= =GvnL -----END PGP SIGNATURE----- --=-CCtUUaL8pnBBmU00WWJe-- From owner-freebsd-stable@FreeBSD.ORG Tue May 3 18:34:05 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 490D116A4CE for ; Tue, 3 May 2005 18:34:05 +0000 (GMT) Received: from merlin.alerce.com (w094.z064001164.sjc-ca.dsl.cnc.net [64.1.164.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FD8343D76 for ; Tue, 3 May 2005 18:34:04 +0000 (GMT) (envelope-from hartzell@kestrel.alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id EEE94215D; Tue, 3 May 2005 11:33:22 -0700 (PDT) Received: from satchel.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by merlin.alerce.com (Postfix) with ESMTP id 9A1472151; Tue, 3 May 2005 11:33:22 -0700 (PDT) Received: from satchel.alerce.com (localhost [127.0.0.1]) by satchel.alerce.com (8.13.1/8.13.1) with ESMTP id j43IY8qm006755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 May 2005 11:34:09 -0700 (PDT) (envelope-from hartzell@satchel.alerce.com) Received: (from hartzell@localhost) by satchel.alerce.com (8.13.1/8.13.1/Submit) id j43IY7h2006751; Tue, 3 May 2005 11:34:07 -0700 (PDT) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <17015.50206.651588.618737@satchel.alerce.com> Date: Tue, 3 May 2005 11:34:06 -0700 To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: References: X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid X-Virus-Scanned: ClamAV using ClamSMTP cc: "stable@freebsd.org" Subject: Re: gmirror oddities X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2005 18:34:05 -0000 Eirik =D8verby writes: > Hi! >=20 > I've been using gmirror for a while to safeguard my system disks. I = have > taken the slice-based mirror approach, where I use, say, ad0s1 and a= d2s1 as > providers. > On one of my servers, this seems to be impossible. I create the mirr= or using > ad2s1 first (to keep my system running while I do some of the work),= and > then I re-initialize ad0s1 (making it exactly the size of ad2s1) bef= ore > using gmirror insert to add it to the mirror. > However, at this point - when doing a gmirror list - it turns out th= at it > never added ad0s1 as a provider, but ad0 itself! As a result, I now = have a > load of slices (ad0a, ad0b, ad0d, ad0e, ad0f) instead of having the = same > structure as I have on ad2s1. It's just like ad2s1, just without the= "s1" > part. >=20 > I've tried "dd if=3D/dev/zero of=3D/dev/ad0 bs=3D65536" a couple of = times, in case > some old provider metadata was stored there. I also have exactly the= same > setup in another server, the only difference being that it behaves a= s > expected.. >=20 > Am I doing something blatantly wrong here? This IS supposed to work,= right? > I've even found a very nice description of how to do it at > http://people.freebsd.org/~rse/mirror/ > confirming that what I'm doing is right. >=20 > I'm on 5.4-PRERELEASE, but this problem has been there since 5.3-p2 = or > something, which was when I first tried this. I bet you're getting bitten by a problem that bit me. It's described in the fine print in http://people.freebsd.org/~rse/mirror/. Gmirror saves it's metadata on the last sector of its disk space. Since the slice (adXs1) and the disk device (adX) end at the same place on the disk, gmirror gets confused. It tastes devices in a particular order, apparently devices first, then slices. It finds the metadata when it tastes adX and goes ahead and uses it, even though it should be associating it w/ adXsY. Hilarity ensues.... The fix is described in the fourth comment block of Ralf's doc, either make the slice a sector smaller than the disk device or hardcode the provider name. I've been using the hardcoding approach, and it seems to work for me. g. From owner-freebsd-stable@FreeBSD.ORG Tue May 3 18:54:57 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED6AC16A503 for ; Tue, 3 May 2005 18:54:57 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C605943D3F for ; Tue, 3 May 2005 18:54:57 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id A94AE72DD4; Tue, 3 May 2005 11:54:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id A35AB72DCB for ; Tue, 3 May 2005 11:54:52 -0700 (PDT) Date: Tue, 3 May 2005 11:54:52 -0700 (PDT) From: Doug White To: stable@freebsd.org Message-ID: <20050503115344.S26250@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Experimental ttwwakeup() panic patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 18:54:58 -0000 Hey folks, I've taken a crack at working around the ttwwakeup() panic thats been reported now and again. My early analysis, based on debugging output from rwatson, is that a defunct struct tty gets reused without cleaning out the associated (stale) knote structures, and the ttwwakeup() at the end of sioopen() jumps off into space when it finds them. This patch is against RELENG_5 but the logic should apply to -CURRENT, although the patch likely won't as ttymalloc() is organized differently there. I did some basic testing on my UP box and didn't see any abberant behavior afterwards. However I can't reproduce the panic in question, so if you're good at triggering the panic give this a spin. http://people.freebsd.org/~dwhite/tty.c.20050503.patch -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Tue May 3 19:27:55 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6777E16A4CF for ; Tue, 3 May 2005 19:27:55 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E682643D48 for ; Tue, 3 May 2005 19:27:54 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from ranger.anduin.net ([81.0.162.52] helo=[192.168.1.110]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DT33d-0008OC-7h; Tue, 03 May 2005 21:27:49 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 03 May 2005 21:26:43 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: Message-ID: In-Reply-To: <17015.50206.651588.618737@satchel.alerce.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable cc: "stable@freebsd.org" Subject: Re: gmirror oddities X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 19:27:55 -0000 On 03-05-05 20:34, "George Hartzell" wrote: >=20 > Eirik =D8verby writes: >> Hi! >>=20 >> I've been using gmirror for a while to safeguard my system disks. I have >> taken the slice-based mirror approach, where I use, say, ad0s1 and ad2s1= as >> providers. >> On one of my servers, this seems to be impossible. I create the mirror u= sing >> ad2s1 first (to keep my system running while I do some of the work), and >> then I re-initialize ad0s1 (making it exactly the size of ad2s1) before >> using gmirror insert to add it to the mirror. >> However, at this point - when doing a gmirror list - it turns out that i= t >> never added ad0s1 as a provider, but ad0 itself! As a result, I now have= a >> load of slices (ad0a, ad0b, ad0d, ad0e, ad0f) instead of having the same >> structure as I have on ad2s1. It's just like ad2s1, just without the "s1= " >> part. >>=20 >> I've tried "dd if=3D/dev/zero of=3D/dev/ad0 bs=3D65536" a couple of times, in = case >> some old provider metadata was stored there. I also have exactly the sam= e >> setup in another server, the only difference being that it behaves as >> expected.. >>=20 >> Am I doing something blatantly wrong here? This IS supposed to work, rig= ht? >> I've even found a very nice description of how to do it at >> http://people.freebsd.org/~rse/mirror/ >> confirming that what I'm doing is right. >>=20 >> I'm on 5.4-PRERELEASE, but this problem has been there since 5.3-p2 or >> something, which was when I first tried this. >=20 > I bet you're getting bitten by a problem that bit me. It's described > in the fine print in http://people.freebsd.org/~rse/mirror/. >=20 > Gmirror saves it's metadata on the last sector of its disk space. > Since the slice (adXs1) and the disk device (adX) end at the same > place on the disk, gmirror gets confused. It tastes devices in a > particular order, apparently devices first, then slices. It finds the > metadata when it tastes adX and goes ahead and uses it, even though it > should be associating it w/ adXsY. Hilarity ensues.... >=20 > The fix is described in the fourth comment block of Ralf's doc, either > make the slice a sector smaller than the disk device or hardcode the > provider name. I've been using the hardcoding approach, and it seems > to work for me. Same here, tried that immediately after my last post. Apologies for the noise ;) /Eirik From owner-freebsd-stable@FreeBSD.ORG Tue May 3 19:38:18 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE49A16A4CE for ; Tue, 3 May 2005 19:38:18 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AB2043D66 for ; Tue, 3 May 2005 19:38:18 +0000 (GMT) (envelope-from craig@feniz.gank.org) Received: by ion.gank.org (mail, from userid 1001) id D71912A9F9; Tue, 3 May 2005 14:38:11 -0500 (CDT) Date: Tue, 3 May 2005 14:38:08 -0500 From: Craig Boston To: hartzell@alerce.com Message-ID: <20050503193807.GA6314@nowhere> Mail-Followup-To: Craig Boston , hartzell@alerce.com, Eirik ?verby , "stable@freebsd.org" References: <17015.50206.651588.618737@satchel.alerce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17015.50206.651588.618737@satchel.alerce.com> User-Agent: Mutt/1.4.2.1i cc: "stable@freebsd.org" cc: Eirik ?verby Subject: Re: gmirror oddities X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 19:38:18 -0000 On Tue, May 03, 2005 at 11:34:06AM -0700, George Hartzell wrote: > The fix is described in the fourth comment block of Ralf's doc, either > make the slice a sector smaller than the disk device or hardcode the > provider name. I've been using the hardcoding approach, and it seems > to work for me. I'm sorry that I don't remember who said it (I'll do some googling and follow up if I can find the reference), but one time this came up someone posted a very good idea which IMHO is a good enough solution to make the default. That is, instead of hardcoding the provider name, put the provider *size* into the metadata. In theory, that would give the geom classes enough information to deduce which provider to attach to in all normal cases. The only catch is if the size changes somehow after it's been labeled, but that is usually the sign of something else wrong that will eventually bite you. It could simply revert back to the current behavior in that case. Craig From owner-freebsd-stable@FreeBSD.ORG Tue May 3 19:48:56 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBDB116A4CE for ; Tue, 3 May 2005 19:48:56 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9701843D70 for ; Tue, 3 May 2005 19:48:56 +0000 (GMT) (envelope-from craig@feniz.gank.org) Received: by ion.gank.org (mail, from userid 1001) id CC0FE2D00A; Tue, 3 May 2005 14:48:51 -0500 (CDT) Date: Tue, 3 May 2005 14:48:37 -0500 From: Craig Boston To: "stable@freebsd.org" Message-ID: <20050503194837.GB6314@nowhere> Mail-Followup-To: Craig Boston , "stable@freebsd.org" References: <17015.50206.651588.618737@satchel.alerce.com> <20050503193807.GA6314@nowhere> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050503193807.GA6314@nowhere> User-Agent: Mutt/1.4.2.1i Subject: Re: gmirror oddities X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 19:48:56 -0000 On Tue, May 03, 2005 at 02:38:08PM -0500, Craig Boston wrote: > I'm sorry that I don't remember who said it (I'll do some googling and > follow up if I can find the reference), but one time this came up > someone posted a very good idea which IMHO is a good enough solution to > make the default. That is, instead of hardcoding the provider name, put > the provider *size* into the metadata. Aha, it was in fact PJD: http://lists.freebsd.org/pipermail/freebsd-geom/2005-February/000528.html From owner-freebsd-stable@FreeBSD.ORG Tue May 3 20:51:33 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75C5916A4CE for ; Tue, 3 May 2005 20:51:33 +0000 (GMT) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id D787843D62 for ; Tue, 3 May 2005 20:51:30 +0000 (GMT) (envelope-from des@des.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFX00AZKLO2WD30@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 03 May 2005 22:45:38 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IFX001GZLZ5IZR0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Tue, 03 May 2005 22:52:17 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id E425E45165; Tue, 03 May 2005 22:51:24 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 4853C45131; Tue, 03 May 2005 22:51:19 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 3374833C39; Tue, 03 May 2005 22:51:19 +0200 (CEST) Date: Tue, 03 May 2005 22:51:19 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050503114016.U53065@ganymede.hub.org> To: "Marc G. Fournier" Message-id: <86wtqg2fug.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <426E5713.3010906@eurocom.od.ua> <747dc8f30504260812ee3c47e@mail.gmail.com> <426E5EA5.8000703@eurocom.od.ua> <426F3AFA.9020900@konvergencia.hu> <426F5A6E.4050208@eurocom.od.ua> <86acndmyky.fsf@xps.des.no> <4276910A.3040100@criticalmagic.com> <20050502180152.I53065@ganymede.hub.org> <86psw84zbi.fsf@xps.des.no> <20050503114016.U53065@ganymede.hub.org> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: cc: Alexander Rusinov cc: Richard Coleman cc: freebsd-stable@freebsd.org Subject: Re: PostgreSQL in FreeBSD jails X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 20:51:33 -0000 "Marc G. Fournier" writes: > 'k, I've been doing multiple since 7.2 on the same machine, all on the > same port, all different IPs, all on 4.x servers ... have never had an > issue with crashes (its pretty much my most stable 4.x server) ... It was never possible. 8.0 has a hack to detect and avoid shared memory collisions, but I think it will still have problems with semaphores. I have no idea why it works (or seems to work) for you; it never did for anyone else. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-stable@FreeBSD.ORG Tue May 3 22:16:46 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0EF1516A4CF for ; Tue, 3 May 2005 22:16:46 +0000 (GMT) Received: from smtp-one-2.wash.one.se (smtp-one-2.one.se [213.80.101.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED83843D1D for ; Tue, 3 May 2005 22:16:44 +0000 (GMT) (envelope-from carl@thegoodone.mine.nu) Received: from localhost (smtp-one-2.local [127.0.0.1]) by re-injector2.wash.one.se (Postfix) with ESMTP id 4BF7A66C8A1; Tue, 3 May 2005 22:16:17 +0000 (GMT) Received: from smtp-one-2.wash.one.se ([127.0.0.1]) by localhost (smtp-one-2.wash.one.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31360-04; Tue, 3 May 2005 22:16:15 +0000 (GMT) Received: from thegoodone.mine.nu (81-170-146-19.bahnhofbredband.net [81.170.146.19]) by smtp-one-2.wash.one.se (Postfix) with ESMTP id B356366C88F; Tue, 3 May 2005 22:16:14 +0000 (GMT) Message-ID: <4277F82B.7060706@thegoodone.mine.nu> Date: Wed, 04 May 2005 00:16:11 +0200 From: Carl Gustavsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Darren Pilgrim References: <000001c54f8b$40b43ed0$9afb40d8@Sonomago> In-Reply-To: <000001c54f8b$40b43ed0$9afb40d8@Sonomago> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0518-1, 2005-05-02), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: by amavisd-new at one.se (smtp-one-2) X-Spam-Status: No, hits=0.585 tagged_above=-999 required=7 tests=AWL, BAYES_00, J_CHICKENPOX_21, OACYS_CONS_6, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL, SARE_BAYES_6x6, TW_XD X-Spam-Level: cc: freebsd-stable@freebsd.org Subject: Re: ndis with Intel 2915 wireless, getting "NDIS ERROR" messagesand deattach on boot X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 03 May 2005 22:16:46 -0000 Darren Pilgrim wrote: >>From: Darren Pilgrim >>From: Carl Gustavsson >> >> >>>Have you tested the iwi-driver? >>>See: http://damien.bergamini.free.fr/ipw/iwi-freebsd.html >>> >>> >>I haven't yet. Reading that page has brought up another questions. On >> >> >the > > >>page it says 5-STABLE doesn't support WPA. My wireless network uses WPA. >>Is this still the case? I know -stable is -stable, but WPA something of a >>show-stopper, if you ask me. >> >>Fortunately, my neighborhood is a well-covered sea of open "linksys" and >>"NETGEAR" APs in default configuration with to test the driver. >> >> > >I'm using driver version 1.3.4 and firmware version 2.2. The driver appears >to attach just fine: > >iwi0: mem 0xdfcfd000-0xdfcfdfff irq >5 at device 3.0 on pci3 >iwi0: Ethernet address: 00:0e:35:f6:d6:5c >iwi0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps >iwi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps >iwi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps >36Mbps 48Mbps 54Mbps > >However, when I attempt to associate and get an IP address, I get "iwi0: >fatal error" when running dhclient. Setting debug.iwi=10 and >debug.ieee80211=10, I get the following debug output when I run the firmware >download and dhclient commands: > ># iwicontrol iwi0 -d /root/if_iwi/firmware-2.2 -m bss >Firmware cached: boot 6464, ucode 16326, main 166952 > ># dhclient iwi0 >INTR!0x01000000 >INTR!0x01000000 >Setting MAC address to 00:0e:35:f6:d6:5c >TX!CMD!11!6 >INTR!0x00000800 >Configuring adapter >TX!CMD!6!20 >INTR!0x00000800 >Setting power mode to 0 >TX!CMD!17!4 >INTR!0x00000800 >Setting RTS threshold to 2312 >TX!CMD!15!4 >INTR!0x00000800 >Setting .11bg supported rates (12) >TX!CMD!22!16 >INTR!0x00000800 >Setting .11a supported rates (8) >TX!CMD!22!16 >INTR!0x00000800 >Setting initialization vector to 693451133 >TX!CMD!34!4 >INTR!0x00000800 >Enabling adapter >TX!CMD!2!0 >INTR!0x00000800 >ieee80211_next_scan: chan 56->60 >Start scanning >TX!CMD!20!60 >INTR!0x00000800 >INTR!0x00000002 >Notification (20) >INTR!0x00000002 >Scan channel (36) >INTR!0x00000002 >Scan channel (40) >INTR!0x00000002 >Scan channel (44) >INTR!0x00000002 >Scan channel (48) >INTR!0x00000002 >RX!DATA!68!52!58 >ieee80211_recv_mgmt: new probe response on chan 52 (bss chan 52) "191" from >00:0c:db:81:5e:a8 >ieee80211_recv_mgmt: caps 0x401 bintval 100 erp 0x0 >ieee80211_recv_mgmt: country info 55 53 20 24 04 11 34 04 17 95 05 1e >INTR!0x00000002 >Notification (25) >Scan channel (52) >INTR!0x00000002 >RX!DATA!68!56!50 >ieee80211_recv_mgmt: new probe response on chan 56 (bss chan 56) "191" from >00:0c:db:81:5e:4a >ieee80211_recv_mgmt: caps 0x401 bintval 100 erp 0x0 >ieee80211_recv_mgmt: country info 55 53 20 24 04 11 34 04 17 95 05 1e >INTR!0x00000002 >Notification (25) >Scan channel (56) >INTR!0x00000002 >Scan channel (60) >INTR!0x00000002 >Scan channel (64) >INTR!0x00000002 >Scan channel (149) >INTR!0x00000002 >Scan channel (153) >INTR!0x00000002 >Scan channel (157) >INTR!0x40000000 >iwi0: fatal error > >At which point dhclient stalls for several seconds before switching to its >background mode. `ifconfig iwi0` then shows "status: no carrier" and no IP >address assignment. > > >_______________________________________________ >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" > > I use static IP:s in my wireless network and it works pretty fine (a 2200BG-card). Gets some "iwi0: fatal error" but it works though. I don't know how to solve your problem. From owner-freebsd-stable@FreeBSD.ORG Wed May 4 07:09:39 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6677416A4CE; Wed, 4 May 2005 07:09:39 +0000 (GMT) Received: from 62-15-215-178.inversas.jazztel.es (62-15-215-178.inversas.jazztel.es [62.15.215.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id E535843D2F; Wed, 4 May 2005 07:09:37 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j4479UBu006180; Wed, 4 May 2005 09:09:30 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j4479TBj001081; Wed, 4 May 2005 09:09:29 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: stable@freebsd.org Date: Wed, 4 May 2005 09:09:28 +0200 User-Agent: KMail/1.8 References: <200504281542.43241.josemi@redesjm.local> In-Reply-To: <200504281542.43241.josemi@redesjm.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200505040909.29085.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.155; host: antares.redesjm.local) cc: re@freebsd.org Subject: Re: MFC pxe fixes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 07:09:39 -0000 El Jueves, 28 de Abril de 2005 15:42, Jose M Rodriguez escribi=F3: > Hi, > > I note that the long standing bug that prevents do a nfsroot mount > after operate pxeloader in tftp mode is recent solved in -CURRENT > pxe.c > > I think this can be missed for 5.4 REL, but I'll be glad to see this > MFC as time permitting. > I pointing to changes in revs 1.21 and 1.22 of=20 src/sys/boot/i386/libi386/pxe.c In special, rev 1.21, from kan, 7 weeks ago. I can't see this breaking any ABI, but making things work as documented. =20 Tested on RELENG_5_4 as attached patch =2D- josemi =2D-- pxe.diff begins here --- Index: pxe.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/cvs/freebsd/src/sys/boot/i386/libi386/pxe.c,v retrieving revision 1.20 diff -u -r1.20 pxe.c =2D-- pxe.c 25 Aug 2003 23:28:31 -0000 1.20 +++ pxe.c 28 Apr 2005 17:49:35 -0000 @@ -27,7 +27,7 @@ */ =20 #include =2D__FBSDID("$FreeBSD: src/sys/boot/i386/libi386/pxe.c,v 1.20 2003/08/25=20 23:28:31 obrien Exp $"); +__FBSDID("$FreeBSD: src/sys/boot/i386/libi386/pxe.c,v 1.22 2005/04/17=20 21:38:22 wollman Exp $"); =20 #include #include @@ -308,6 +308,7 @@ } setenv("boot.nfsroot.server", inet_ntoa(rootip), 1); setenv("boot.nfsroot.path", rootpath, 1); + setenv("dhcp.host-name", hostname, 1); } } pxe_opens++; @@ -413,6 +414,22 @@ /* structure truncated here */ }; extern struct nfs_iodesc nfs_root_node; +extern int rpc_port; + +static void +pxe_rpcmountcall() +{ + struct iodesc *d; + int error; + + if (!(d =3D socktodesc(pxe_sock))) + return; + d->myport =3D htons(--rpc_port); + d->destip =3D rootip; + if ((error =3D nfs_getrootfh(d, rootpath, nfs_root_node.fh)) !=3D 0)=20 + printf("NFS MOUNT RPC error: %d\n", error); + nfs_root_node.iodesc =3D d; +} =20 static void pxe_setnfshandle(char *rootpath) @@ -421,6 +438,14 @@ u_char *fh; char buf[2 * NFS_FHSIZE + 3], *cp; =20 + /* + * If NFS files were never opened, we need to do mount call + * ourselves. Use nfs_root_node.iodesc as flag indicating + * previous NFS usage. + */ + if (nfs_root_node.iodesc =3D=3D NULL) + pxe_rpcmountcall(); + fh =3D &nfs_root_node.fh[0]; buf[0] =3D 'X'; cp =3D &buf[1]; =2D-- pxe.diff ends here --- From owner-freebsd-stable@FreeBSD.ORG Wed May 4 07:37:11 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FC6716A4CF; Wed, 4 May 2005 07:37:11 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D499F43D6E; Wed, 4 May 2005 07:37:10 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DTEQp-000H0L-E5; Wed, 04 May 2005 10:36:31 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Jose M Rodriguez In-Reply-To: Message from Jose M Rodriguez <200505040909.29085.josemi@redesjm.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 May 2005 10:36:31 +0300 From: Danny Braniss Message-ID: cc: stable@freebsd.org cc: re@freebsd.org Subject: Re: MFC pxe fixes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 07:37:11 -0000 sorry if this looks like im highjacking hte thread, but i've submitted a PR http://www.freebsd.org/cgi/query-pr.cgi?pr=61239 which among other things, places ALL the dhcp variables in the environment. danny From owner-freebsd-stable@FreeBSD.ORG Wed May 4 08:31:27 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 813C516A4CE for ; Wed, 4 May 2005 08:31:27 +0000 (GMT) Received: from 62-15-215-178.inversas.jazztel.es (62-15-215-178.inversas.jazztel.es [62.15.215.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 403AD43D76 for ; Wed, 4 May 2005 08:31:26 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) j448UXiH006481; Wed, 4 May 2005 10:30:33 +0200 (CEST) (envelope-from josemi@redesjm.local) Received: from localhost (localhost [[UNIX: localhost]]) by redesjm.local (8.13.3/8.13.3/Submit) id j448UXLq067068; Wed, 4 May 2005 10:30:33 +0200 (CEST) (envelope-from josemi@redesjm.local) From: Jose M Rodriguez To: Danny Braniss Date: Wed, 4 May 2005 10:30:31 +0200 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200505041030.32548.josemi@redesjm.local> X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.30.0.7; VDF: 6.30.0.155; host: antares.redesjm.local) cc: stable@freebsd.org cc: Jose M Rodriguez Subject: Re: MFC pxe fixes X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 08:31:27 -0000 El Mi=E9rcoles, 4 de Mayo de 2005 09:36, Danny Braniss escribi=F3: > sorry if this looks like im highjacking hte thread, but i've > submitted a PR http://www.freebsd.org/cgi/query-pr.cgi?pr=3D61239 > which among other things, places ALL the dhcp variables in the > environment. > > danny I can't see how this will be on FreeBSD-5.4 or -stable. If you're interested on this, open a thread on current. This is about making pxeboot compiled with LOADER_TFTP_SUPPORT defined=20 works as documented. Also, point that your workplan makes a second bootp transaction needed. Try make the bootp/dhcp packet parser independent of bootp.c (At last,=20 exportable), so we can parse the 'bootplayer' binary packet pxe=20 allready have. ALso, I'm not sure we can redefine CLASSID without breaking PXE (not=20 dhcp) compatibility. Remember that the PXE bios has allready do the bootp/dhcp transaction=20 for us, and the correct path is only parse the 'bootplayer' (really a=20 bootp/dhcp packet in binary form) than we get from the bios. =2D- josemi =2D- josemi From owner-freebsd-stable@FreeBSD.ORG Wed May 4 11:30:16 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B428C16A4CE for ; Wed, 4 May 2005 11:30:16 +0000 (GMT) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B46343D53 for ; Wed, 4 May 2005 11:30:16 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTI4E-000IZD-Cq; Wed, 04 May 2005 12:29:26 +0100 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.50 (FreeBSD)) id 1DTI44-000JGK-3F; Wed, 04 May 2005 12:29:16 +0100 To: kensmith@cse.Buffalo.EDU, petefrench@ticketswitch.com In-Reply-To: <1115143070.2859.37.camel@opus.cse.buffalo.edu> Message-Id: From: Pete French Date: Wed, 04 May 2005 12:29:16 +0100 cc: freebsd-stable@freebsd.org Subject: Re: RC4 will not install using FTP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 11:30:16 -0000 > I haven't been able to reproduce this yet. I've successfully done an > FTP install both from an initial floppy boot and from an initial disc1 > CD boot. So it's not a "totally generic" problem, it might have > something to do with the pathway you are following through sysinstall. Possibly. I had to take a slightly odd path through sysinstall, as I'll explain below. > Was this a brand new install or were you installing over top of a > pre-existing install? If the latter did you recycle the existing disk > partitions or have it wipe out everything and re-do them from scratch? Old install, I kept the slice layout, but wiped all the partitions and created new (different) ones. Other proble was that the first time through sysinstall it cannot resolve any named from the nameserver. I then hitt Ctrl-C, go back to the start and type all the same details in again. The second time round it works fine. I dont know if that is likely to affect the install at all ? Could it be having problems due to having the original partitions already mounted from the first attempt maybe ? I can't explain why I have to go through the networking part twice either. I also note that even now I have the machine installed, em0 has trouble coming up when I reboot the machine - I get 'host unreachable' errors on boot, but then a bit later it seems to sort itself out fine. -pcf. From owner-freebsd-stable@FreeBSD.ORG Wed May 4 12:19:58 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80B6F16A4CE for ; Wed, 4 May 2005 12:19:58 +0000 (GMT) Received: from mrelay3.uni-hannover.de (mrelay3.uni-hannover.de [130.75.2.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EEE043D62 for ; Wed, 4 May 2005 12:19:57 +0000 (GMT) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2])j44CJH9e013038 for ; Wed, 4 May 2005 14:19:18 +0200 (MEST) Received: by www.pmp.uni-hannover.de (Postfix, from userid 846) id 5B08E16C; Wed, 4 May 2005 14:19:13 +0200 (CEST) Date: Wed, 4 May 2005 14:19:13 +0200 From: Gerrit =?iso-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-ID: <20050504121913.GA55308@pmp.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.2.2 (mrelay3.uni-hannover.de [130.75.2.41]); Wed, 04 May 2005 14:19:18 +0200 (MEST) X-Scanned-By: MIMEDefang 2.42 Subject: Trek Technology Thumbdrive 16MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 12:19:58 -0000 Hi folks, has anyone used the subject successfully with -stable? umass(4) mentions the 8MB version, so I thought 16MB should actually work, too. However, when I plug the device in, I just get ugen0: Trek Technology ThumbDrive, rev 1.10/1.00, addr 2 and no umass device. usbdevs shows port 3 addr 2: full speed, power 40 mA, config 1, ThumbDrive(0x1111), Trek Technology(0x0a16), rev 1.00, device ugen0 Any hints how to make this work? cu Gerrit -- From owner-freebsd-stable@FreeBSD.ORG Wed May 4 14:24:16 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3616816A4CE for ; Wed, 4 May 2005 14:24:16 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FB9743D45 for ; Wed, 4 May 2005 14:24:15 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 82A4E1F04F; Wed, 4 May 2005 16:23:51 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 5EAD86393; Wed, 4 May 2005 16:23:51 +0200 (CEST) Date: Wed, 4 May 2005 16:23:51 +0200 From: Marc Olzheim To: Gerrit =?iso-8859-1?Q?K=FChn?= Message-ID: <20050504142351.GA75110@stack.nl> References: <20050504121913.GA55308@pmp.uni-hannover.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <20050504121913.GA55308@pmp.uni-hannover.de> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: freebsd-stable@freebsd.org Subject: Re: Trek Technology Thumbdrive 16MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 14:24:16 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 04, 2005 at 02:19:13PM +0200, Gerrit Khn wrote: > Hi folks, >=20 > has anyone used the subject successfully with -stable? > umass(4) mentions the 8MB version, so I thought 16MB should actually work, > too. However, when I plug the device in, I just get >=20 > ugen0: Trek Technology ThumbDrive, rev 1.10/1.00, addr 2 >=20 > and no umass device. >=20 > usbdevs shows >=20 > port 3 addr 2: full speed, power 40 mA, config 1, ThumbDrive(0x1111), Trek > Technology(0x0a16), rev 1.00, device ugen0 >=20 >=20 > Any hints how to make this work? You _do_ have scsi disk support (device da) enabled in your kernel ? Marc --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCeNr3ezjnobFOgrERAjYiAKCBR1yiLQ+K5FB3uWUDGP4hfMKZmQCfcczw keidkfHsE8wySbLKsl2X8as= =TwBS -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-stable@FreeBSD.ORG Wed May 4 14:27:09 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C56A216A4CE for ; Wed, 4 May 2005 14:27:09 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 873A243D39 for ; Wed, 4 May 2005 14:27:09 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 1DCDC1F04F; Wed, 4 May 2005 16:26:49 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 0B7E76393; Wed, 4 May 2005 16:26:49 +0200 (CEST) Date: Wed, 4 May 2005 16:26:48 +0200 From: Marc Olzheim To: Gerrit =?iso-8859-1?Q?K=FChn?= Message-ID: <20050504142648.GB75110@stack.nl> References: <20050504121913.GA55308@pmp.uni-hannover.de> <20050504142351.GA75110@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Bn2rw/3z4jIqBvZU" Content-Disposition: inline In-Reply-To: <20050504142351.GA75110@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: freebsd-stable@freebsd.org Subject: Re: Trek Technology Thumbdrive 16MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 14:27:09 -0000 --Bn2rw/3z4jIqBvZU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 04, 2005 at 04:23:51PM +0200, Marc Olzheim wrote: > > Any hints how to make this work? >=20 > You _do_ have scsi disk support (device da) enabled in your kernel ? And loaded the umass module or have it in your kernel, for that matter ? Marc --Bn2rw/3z4jIqBvZU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCeNuoezjnobFOgrERAg1SAJ4kQB0jOHWYUpMNyDO3vit6NauSvQCeOPDg ZAGxhCODm9oWzNfEIT7r3lA= =4YKS -----END PGP SIGNATURE----- --Bn2rw/3z4jIqBvZU-- From owner-freebsd-stable@FreeBSD.ORG Wed May 4 15:20:42 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE58616A4CE for ; Wed, 4 May 2005 15:20:42 +0000 (GMT) Received: from mrelay3.uni-hannover.de (mrelay3.uni-hannover.de [130.75.2.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EBA443D67 for ; Wed, 4 May 2005 15:20:41 +0000 (GMT) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2])j44FJ79e023331; Wed, 4 May 2005 17:19:07 +0200 (MEST) Received: by www.pmp.uni-hannover.de (Postfix, from userid 846) id 0B72959B; Wed, 4 May 2005 17:19:02 +0200 (CEST) Date: Wed, 4 May 2005 17:19:02 +0200 From: Gerrit =?iso-8859-1?Q?K=FChn?= To: Marc Olzheim Message-ID: <20050504151901.GC56137@pmp.uni-hannover.de> References: <20050504121913.GA55308@pmp.uni-hannover.de> <20050504142351.GA75110@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050504142351.GA75110@stack.nl> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.2.2 (mrelay3.uni-hannover.de [130.75.2.41]); Wed, 04 May 2005 17:19:07 +0200 (MEST) X-Scanned-By: MIMEDefang 2.42 cc: freebsd-stable@freebsd.org Subject: Re: Trek Technology Thumbdrive 16MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 15:20:42 -0000 On Wed, May 04, 2005 at 04:23:51PM +0200, Marc Olzheim wrote: > > ugen0: Trek Technology ThumbDrive, rev 1.10/1.00, addr 2 > > and no umass device. > > Any hints how to make this work? > You _do_ have scsi disk support (device da) enabled in your kernel ? Yes, I do. I have two SCSI-Controllers in this system (CDRW, MOD) and various working umass-devices. cu Gerrit -- From owner-freebsd-stable@FreeBSD.ORG Wed May 4 15:28:14 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B3EE816A4CE for ; Wed, 4 May 2005 15:28:14 +0000 (GMT) Received: from mrelay3.uni-hannover.de (mrelay3.uni-hannover.de [130.75.2.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12B1943D45 for ; Wed, 4 May 2005 15:28:14 +0000 (GMT) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2])j44FPc9e023607; Wed, 4 May 2005 17:25:39 +0200 (MEST) Received: by www.pmp.uni-hannover.de (Postfix, from userid 846) id E47A0105; Wed, 4 May 2005 17:25:33 +0200 (CEST) Date: Wed, 4 May 2005 17:25:33 +0200 From: Gerrit =?iso-8859-1?Q?K=FChn?= To: Marc Olzheim Message-ID: <20050504152533.GD56137@pmp.uni-hannover.de> References: <20050504121913.GA55308@pmp.uni-hannover.de> <20050504142351.GA75110@stack.nl> <20050504142648.GB75110@stack.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050504142648.GB75110@stack.nl> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.2.2 (mrelay3.uni-hannover.de [130.75.2.41]); Wed, 04 May 2005 17:25:39 +0200 (MEST) X-Scanned-By: MIMEDefang 2.42 cc: freebsd-stable@freebsd.org Subject: Re: Trek Technology Thumbdrive 16MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 15:28:14 -0000 On Wed, May 04, 2005 at 04:26:48PM +0200, Marc Olzheim wrote: > > You _do_ have scsi disk support (device da) enabled in your kernel ? > And loaded the umass module or have it in your kernel, for that matter ? Yes, of course. As I said before: I have working externel USB-HD, a working USB-MP3-Player and so on. Just the Thumbdrive doesn't do anything here. Meanwhile I browsed the sourcecode a little bit. I found that usbdevs has product TREK THUMBDRIVE 0x1111 ThumbDrive product TREK THUMBDRIVE_8MB 0x9988 ThumbDrive_8MB The first one should apply to my drive. However, umass.c only has { USB_VENDOR_TREK, USB_PRODUCT_TREK_THUMBDRIVE_8MB, RID_WILDCARD, UMASS_PROTO_ATAPI | UMASS_PROTO_BBB, IGNORE_RESIDUE }, I don't know if an entry for USB_PRODUCT_TREK_THUMBDRIVE would be needed in this place, but I just decided to try out and copied (and renamed) the above entry for this purpose. Cannot tell if it's working though, since the system is still compiling (I took the chance to upgrade world, too, and the system is just a 933MHz P3). cu Gerrit -- From owner-freebsd-stable@FreeBSD.ORG Wed May 4 15:42:49 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFC3B16A4CF for ; Wed, 4 May 2005 15:42:49 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6448143D39 for ; Wed, 4 May 2005 15:42:46 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j44FSv0e062348; Wed, 4 May 2005 10:28:57 -0500 (CDT) (envelope-from dan) Date: Wed, 4 May 2005 10:28:57 -0500 From: Dan Nelson To: Gerrit =?utf-8?B?S8O8aG4=?= Message-ID: <20050504152857.GC49336@dan.emsphone.com> References: <20050504121913.GA55308@pmp.uni-hannover.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050504121913.GA55308@pmp.uni-hannover.de> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-stable@freebsd.org Subject: Re: Trek Technology Thumbdrive 16MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 15:42:49 -0000 In the last episode (May 04), Gerrit Khn said: > has anyone used the subject successfully with -stable? umass(4) > mentions the 8MB version, so I thought 16MB should actually work, > too. However, when I plug the device in, I just get > > ugen0: Trek Technology ThumbDrive, rev 1.10/1.00, addr 2 > > and no umass device. > > usbdevs shows > > port 3 addr 2: full speed, power 40 mA, config 1, ThumbDrive(0x1111), Trek Technology(0x0a16), rev 1.00, device ugen0 umass only attaches to devices it recognizes. There are entries for both the thumbdrive and thumbdrive_8mb in usbdevs, but only the 8mb version is in umass.c. Try copying the entry and changing USB_PRODUCT_TREK_THUMBDRIVE_8MB to USB_PRODUCT_TREK_THUMBDRIVE, and see if that works. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Wed May 4 16:41:35 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5848516A4CE for ; Wed, 4 May 2005 16:41:35 +0000 (GMT) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id BACC643D78 for ; Wed, 4 May 2005 16:41:33 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy-128.york.ac.uk [144.32.128.165]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with ESMTP id j44GYjwd026263; Wed, 4 May 2005 17:34:45 +0100 (BST) Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.3/8.13.1) with ESMTP id j44GYjMd049781; Wed, 4 May 2005 17:34:45 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.3/8.13.1/Submit) id j44GYinE049780; Wed, 4 May 2005 17:34:44 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Pete French In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 04 May 2005 17:34:43 +0100 Message-Id: <1115224483.49427.9.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk cc: kensmith@cse.Buffalo.EDU cc: freebsd-stable@freebsd.org Subject: Re: RC4 will not install using FTP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 16:41:35 -0000 On Wed, 2005-05-04 at 12:29 +0100, Pete French wrote: > > I haven't been able to reproduce this yet. I've successfully done an > > FTP install both from an initial floppy boot and from an initial disc1 > > CD boot. So it's not a "totally generic" problem, it might have > > something to do with the pathway you are following through sysinstall. > > Possibly. I had to take a slightly odd path through sysinstall, as I'll > explain below. > > > Was this a brand new install or were you installing over top of a > > pre-existing install? If the latter did you recycle the existing disk > > partitions or have it wipe out everything and re-do them from scratch? > > Old install, I kept the slice layout, but wiped all the partitions and > created new (different) ones. > > Other proble was that the first time through sysinstall it cannot resolve any > named from the nameserver. I then hitt Ctrl-C, go back to the start and > type all the same details in again. The second time round it works fine. > > I dont know if that is likely to affect the install at all ? Could it > be having problems due to having the original partitions already mounted > from the first attempt maybe ? Bingo! Restarting sysinstall always causes this problem. It's a well known problem with several open PRs (see for example bin/38854, bin/42162 and bin/45565 - all dating back to 2002). It's 100% recreateable by restarting sysinstall realatively early in the install procedure, and I've never had it happen without doing so. It's one of these bugs that I keep tripping up on and was always planning to sit down, set up a PXE boot environment and sort it and other sysinstall problems, but can always seem to find other things to do :( Gavin From owner-freebsd-stable@FreeBSD.ORG Wed May 4 17:03:08 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C21C16A4CE for ; Wed, 4 May 2005 17:03:08 +0000 (GMT) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AF7043D49 for ; Wed, 4 May 2005 17:03:08 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTNGU-000NUP-4w; Wed, 04 May 2005 18:02:26 +0100 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.50 (FreeBSD)) id 1DTNGT-000FJS-UG; Wed, 04 May 2005 18:02:25 +0100 To: gavin.atkinson@ury.york.ac.uk, petefrench@ticketswitch.com In-Reply-To: <1115224483.49427.9.camel@buffy.york.ac.uk> Message-Id: From: Pete French Date: Wed, 04 May 2005 18:02:25 +0100 cc: kensmith@cse.Buffalo.EDU cc: freebsd-stable@freebsd.org Subject: Re: RC4 will not install using FTP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 17:03:08 -0000 > Bingo! Restarting sysinstall always causes this problem. It's a well > known problem with several open PRs (see for example bin/38854, > bin/42162 and bin/45565 - all dating back to 2002). It's 100% > recreateable by restarting sysinstall realatively early in the install > procedure, and I've never had it happen without doing so. Ahhh.... O.K. so not just a problem with RC4 then. Thats good. Though now I am wondering how to make that interface come up without going back round again. Hmmm.... -pete. From owner-freebsd-stable@FreeBSD.ORG Wed May 4 19:01:54 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F7B316A4CE for ; Wed, 4 May 2005 19:01:54 +0000 (GMT) Received: from ganymede.hub.org (blk-222-81-172.eastlink.ca [24.222.81.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51CF643D3F for ; Wed, 4 May 2005 19:01:54 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 889A53865A; Wed, 4 May 2005 16:01:27 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 878F2370B3 for ; Wed, 4 May 2005 16:01:27 -0300 (ADT) Date: Wed, 4 May 2005 16:01:27 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-stable@freebsd.org Message-ID: <20050504160004.B53065@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: twa0: INFO: (0x04: 0x000c): Background initialize started: unit=0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 19:01:54 -0000 Running FreeBSD 4.11-STABLE ... Has anyone seen this before? Only reference on the 'net I can find seems to be similar issue on a Dragonfly system: http://leaf.dragonflybsd.org/mailarchive/bugs/2004-09/msg00176.html Mine is a 9500-4LP controller ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-stable@FreeBSD.ORG Wed May 4 19:33:28 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03F6816A4CE for ; Wed, 4 May 2005 19:33:28 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id A368343D2D for ; Wed, 4 May 2005 19:33:27 +0000 (GMT) (envelope-from hayarms@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so706025nzf for ; Wed, 04 May 2005 12:32:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=d0fddcDBpZchAJLqyyLTgfuP5WtUFDNOJCISInJm7RDy4ejqopE+MomtlDEaWNUuxKb1q6+vBatThqKfxoxUu38qI5DJqGvf9fl5sWstpDT37e7m6S0SeYiNbKETeWfD3guwXRNSYNieO5biARdCnpVPO1XBEQBxCxTriDnPTHM= Received: by 10.36.56.19 with SMTP id e19mr190996nza; Wed, 04 May 2005 12:26:11 -0700 (PDT) Received: by 10.36.4.13 with HTTP; Wed, 4 May 2005 12:26:11 -0700 (PDT) Message-ID: <63f52968050504122644fa1aef@mail.gmail.com> Date: Wed, 4 May 2005 21:26:11 +0200 From: Marcello Maggioni To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: "Giving up on 2 buffers" message when rebooting while ext2fs mounted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Marcello Maggioni List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2005 19:33:28 -0000 Hi all, I've just installed my FreeBSD system and upgraded it to the lastest -STABLE with buildworld . I have an EXT3 partition on my second harddrive that I mount read-only with the command : mount -o ro -t ext2fs /dev/ad1s1 /mount_point The problem is that if I reboot without umounting that filesystem I get this message on reboot : syncing disks, buffers remaining... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 giving up on 2 buffers After the reboot the file systems are considered "unclean" and checked with fsck. If I umount the ext3 filesystem before rebooting I get the "No busy buffers" message and all is fine . What is causing this? Thanks Marcello From owner-freebsd-stable@FreeBSD.ORG Wed May 4 19:45:18 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 974F716A4CE for ; Wed, 4 May 2005 19:45:18 +0000 (GMT) Received: from mxsf01.cluster1.charter.net (mxsf01.cluster1.charter.net [209.225.28.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33F2143D58 for ; Wed, 4 May 2005 19:45:18 +0000 (GMT) (envelope-from yocumjt@charter.net) Received: from mxip11.cluster1.charter.net (mxip11a.cluster1.charter.net [209.225.28.141])j44JiWQK004392 for ; Wed, 4 May 2005 15:44:32 -0400 Received: from 66-189-205-245.dhcp.ykma.wa.charter.com (HELO [127.0.0.1]) (66.189.205.245) by mxip11.cluster1.charter.net with ESMTP; 04 May 2005 15:44:32 -0400 X-Ironport-AV: i="3.92,154,1112587200"; d="scan'208"; a="1071225409:sNHT12891684" Message-ID: <4279261E.6050502@charter.net> Date: Wed, 04 May 2005 12:44:30 -0700 From: "John T. Yocum" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0518-2, 05/04/2005), Outbound message X-Antivirus-Status: Clean Subject: kernel/dmesg misreporting clock speed of CPU X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 19:45:18 -0000 Hello, Just an update to my previous post about the clock speed being misreported. As of RC4, the clockspeed appears to be reported correctly. Thanks, John From owner-freebsd-stable@FreeBSD.ORG Wed May 4 22:26:25 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C874D16A4CE for ; Wed, 4 May 2005 22:26:25 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73BE043D75 for ; Wed, 4 May 2005 22:26:25 +0000 (GMT) (envelope-from hayarms@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so12500nzf for ; Wed, 04 May 2005 15:25:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=LDZv3SfyBq/wFKzrEBW+P+Fx3YERMgf6GEnc52EVIB735wzaLogBpbeYNdfq5uEDagyjulTAimMXUZORhd9NDX54zQZhGEpPE1bxGIOjJ3IYOg7kn8KPtfd39h4T0adSWOzDZiZSpj/c30rDsXH/TU+OAsTD/kPFOVhQWqIghqY= Received: by 10.36.61.11 with SMTP id j11mr205632nza; Wed, 04 May 2005 13:39:07 -0700 (PDT) Received: by 10.36.4.13 with HTTP; Wed, 4 May 2005 13:39:07 -0700 (PDT) Message-ID: <63f5296805050413393c4b6c54@mail.gmail.com> Date: Wed, 4 May 2005 22:39:07 +0200 From: Marcello Maggioni To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Giving up on 2 buffers with ext2fs mounted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Marcello Maggioni List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2005 22:26:25 -0000 Hi all, I've just installed my FreeBSD system and upgraded it to the lastest -STABLE with buildworld . I have an EXT3 partition on my second harddrive that I mount read-only with the command : mount -o ro -t ext2fs /dev/ad1s1 /mount_point The problem is that if I reboot without umounting that filesystem I get this message on reboot : syncing disks, buffers remaining... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 giving up on 2 buffers After the reboot the file systems are considered "unclean" and checked with fsck. If I umount the ext3 filesystem before rebooting I get the "No busy buffers" message and all is fine . What is causing this? Thanks Marcello From owner-freebsd-stable@FreeBSD.ORG Wed May 4 23:04:54 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FF8616A4CE for ; Wed, 4 May 2005 23:04:54 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 239DB43D60 for ; Wed, 4 May 2005 23:04:54 +0000 (GMT) (envelope-from christopher.hodgins@gmail.com) Received: by wproxy.gmail.com with SMTP id 57so293285wri for ; Wed, 04 May 2005 16:04:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WoF6rkULNrgfT2OXp92W0kvUZ/yXbACBCjqGGrGCJX4b7UYAf8L087a883846qJNfYfPEp3z1XzKc47+8N94/Bb927m8uQMg9v5ATnbZVv5uBVHIgP7QWGADeCFP04PVwRReAMyd1hPU8abmT6UrytTxOBIY04FhANyFwh6PqyM= Received: by 10.54.127.15 with SMTP id z15mr608128wrc; Wed, 04 May 2005 15:37:27 -0700 (PDT) Received: by 10.54.82.6 with HTTP; Wed, 4 May 2005 15:37:27 -0700 (PDT) Message-ID: <63c3899e05050415373efba614@mail.gmail.com> Date: Wed, 4 May 2005 23:37:27 +0100 From: Chris Hodgins To: Pete French In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1115224483.49427.9.camel@buffy.york.ac.uk> cc: kensmith@cse.buffalo.edu cc: freebsd-stable@freebsd.org Subject: Re: RC4 will not install using FTP X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Chris Hodgins List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2005 23:04:54 -0000 On 5/4/05, Pete French wrote: > > Bingo! Restarting sysinstall always causes this problem. It's a well > > known problem with several open PRs (see for example bin/38854, > > bin/42162 and bin/45565 - all dating back to 2002). It's 100% > > recreateable by restarting sysinstall realatively early in the install > > procedure, and I've never had it happen without doing so. >=20 > Ahhh.... O.K. so not just a problem with RC4 then. Thats good. > Though now I am wondering how to make that interface come up without > going back round again. Hmmm.... >=20 > -pete. You can launch a shell from the Fixit menu. You can then go in and check your interfaces and make sure your routing table is not messed up. HTH Chris From owner-freebsd-stable@FreeBSD.ORG Wed May 4 23:08:02 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15FF216A4CE for ; Wed, 4 May 2005 23:08:02 +0000 (GMT) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BB2A43D62 for ; Wed, 4 May 2005 23:08:01 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from drjekyll.mkbuelow.net (p54AACF9E.dip.t-dialin.net [84.170.207.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 03DB32E06B; Thu, 5 May 2005 00:39:53 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j44MemeC026949; Thu, 5 May 2005 00:40:48 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Received: (from mkb@localhost) by drjekyll.mkbuelow.net (8.13.3/8.13.3/Submit) id j44MelJK026948; Thu, 5 May 2005 00:40:47 +0200 (CEST) (envelope-from mkb) Date: Thu, 5 May 2005 00:40:47 +0200 From: Matthias Buelow To: Marcello Maggioni Message-ID: <20050504224047.GA25749@drjekyll.mkbuelow.net> References: <63f5296805050413393c4b6c54@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <63f5296805050413393c4b6c54@mail.gmail.com> User-Agent: Mutt/1.4.2.1i cc: freebsd-stable@freebsd.org Subject: Re: Giving up on 2 buffers with ext2fs mounted X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 04 May 2005 23:08:02 -0000 Marcello Maggioni wrote: >The problem is that if I reboot without umounting that filesystem I >get this message on reboot : >syncing disks, buffers remaining... 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 >giving up on 2 buffers http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/56675 mkb. From owner-freebsd-stable@FreeBSD.ORG Thu May 5 03:55:51 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC89716A4CE for ; Thu, 5 May 2005 03:55:51 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8471C43D45 for ; Thu, 5 May 2005 03:55:51 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id D265172DD4; Wed, 4 May 2005 20:54:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CDBBB72DCB for ; Wed, 4 May 2005 20:54:23 -0700 (PDT) Date: Wed, 4 May 2005 20:54:23 -0700 (PDT) From: Doug White To: stable@freebsd.org In-Reply-To: <20050503115344.S26250@carver.gumbysoft.com> Message-ID: <20050504205315.K40602@carver.gumbysoft.com> References: <20050503115344.S26250@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Experimental ttwwakeup() panic patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 03:55:51 -0000 On Tue, 3 May 2005, Doug White wrote: > Hey folks, > > I've taken a crack at working around the ttwwakeup() panic thats been > reported now and again. My early analysis, based on debugging output from > rwatson, is that a defunct struct tty gets reused without cleaning out the > associated (stale) knote structures, and the ttwwakeup() at the end of > sioopen() jumps off into space when it finds them. > > This patch is against RELENG_5 but the logic should apply to -CURRENT, > although the patch likely won't as ttymalloc() is organized differently > there. > > I did some basic testing on my UP box and didn't see any abberant behavior > afterwards. However I can't reproduce the panic in question, so if you're > good at triggering the panic give this a spin. > > http://people.freebsd.org/~dwhite/tty.c.20050503.patch This patch has been committed and exists as rev 1.228.2.4 of src/sys/kern/tty.c. Please let me know if this fixes the panic for you, or causes new problems :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Thu May 5 05:31:13 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F9AE16A719 for ; Thu, 5 May 2005 05:31:13 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CC5A43D93 for ; Thu, 5 May 2005 05:31:13 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j455VCW2006620 for ; Wed, 4 May 2005 22:31:12 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j455VC8t006619 for stable@freebsd.org; Wed, 4 May 2005 22:31:12 -0700 Date: Wed, 4 May 2005 22:31:12 -0700 From: Brooks Davis To: stable@freebsd.org Message-ID: <20050505053112.GA4455@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Subject: calling fpa and fea users X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 05:31:13 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm writing this message to attempt to determine if anyone is actually using either of these drivers. Please write if you are both: - Using these drivers to connect to a real, production FDDI network - Are running FreeBSD 5.3+ or will be in the near future Please DO NOT write if: - Your production system will never be upgraded - Your network is a toy (with possible exception of real museums) Every time I look at these drivers, their massive collection of "portability" ifdefs makes it quite difficult to decipher the code. Virtually all changes to these drivers in the last eight years have been mechanical API updates. During this time, FDDI has become totally obsolete. Unless someone is running these drivers for real on a modern version of FreeBSD I would like to remove them from 6.0 and stop wasting my time on them. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCea+fXY6L6fI4GtQRAmOWAJ47MgSFVvyYgSGzg/Wox9dE0lXQ6QCfa9nn R0H+v5Va0RzcOZFMVXtwZ3E= =kMnn -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-stable@FreeBSD.ORG Thu May 5 06:21:48 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8F9F16A4CE for ; Thu, 5 May 2005 06:21:48 +0000 (GMT) Received: from mrelay3.uni-hannover.de (mrelay3.uni-hannover.de [130.75.2.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98D1043DA7 for ; Thu, 5 May 2005 06:21:47 +0000 (GMT) (envelope-from gerrit@pmp.uni-hannover.de) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2])j456Ld9e014212; Thu, 5 May 2005 08:21:40 +0200 (MEST) Received: by www.pmp.uni-hannover.de (Postfix, from userid 846) id D4B8216C; Thu, 5 May 2005 08:21:34 +0200 (CEST) Date: Thu, 5 May 2005 08:21:34 +0200 From: Gerrit =?iso-8859-1?Q?K=FChn?= To: Dan Nelson Message-ID: <20050505062134.GA62781@pmp.uni-hannover.de> References: <20050504121913.GA55308@pmp.uni-hannover.de> <20050504152857.GC49336@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050504152857.GC49336@dan.emsphone.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.2.2 (mrelay3.uni-hannover.de [130.75.2.41]); Thu, 05 May 2005 08:21:40 +0200 (MEST) X-Scanned-By: MIMEDefang 2.42 cc: freebsd-stable@freebsd.org Subject: Re: Trek Technology Thumbdrive 16MB X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 06:21:48 -0000 On Wed, May 04, 2005 at 10:28:57AM -0500, Dan Nelson wrote: > In the last episode (May 04), Gerrit Khn said: > > port 3 addr 2: full speed, power 40 mA, config 1, ThumbDrive(0x1111), Trek Technology(0x0a16), rev 1.00, device ugen0 > umass only attaches to devices it recognizes. There are entries for > both the thumbdrive and thumbdrive_8mb in usbdevs, but only the 8mb > version is in umass.c. Try copying the entry and changing > USB_PRODUCT_TREK_THUMBDRIVE_8MB to USB_PRODUCT_TREK_THUMBDRIVE, and see > if that works. I thought of that yesterday, too. New world and kernel are ready meanwhile (I did an complete update along with that), but I didn't have the time to install, reboot and try out so far. I'll do that later today and report here whether it works. Thanks for the hint. cu Gerrit -- From owner-freebsd-stable@FreeBSD.ORG Thu May 5 08:12:45 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6FF4016A4E8 for ; Thu, 5 May 2005 08:12:45 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6F3343D73 for ; Thu, 5 May 2005 08:12:44 +0000 (GMT) (envelope-from rink@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mailhost.stack.nl (Postfix) with ESMTP id B72A11F0F0; Thu, 5 May 2005 10:12:43 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1796) id A660F22899; Thu, 5 May 2005 10:12:43 +0200 (CEST) Date: Thu, 5 May 2005 10:12:43 +0200 From: Rink Springer To: Brooks Davis Message-ID: <20050505081243.GB58471@stack.nl> References: <20050505053112.GA4455@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z6Eq5LdranGa6ru8" Content-Disposition: inline In-Reply-To: <20050505053112.GA4455@odin.ac.hmc.edu> X-Editor: Vim http://www.vim.org/ X-Info: http://rink.nu/ X-Operating-System: FreeBSD 5.3-RELEASE-p9 i386 User-Agent: Mutt/1.5.9i cc: stable@freebsd.org Subject: Re: calling fpa and fea users X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 08:12:45 -0000 --z6Eq5LdranGa6ru8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Brooks, > - Using these drivers to connect to a real, production FDDI network > - Are running FreeBSD 5.3+ or will be in the near future Well, I use fpa(4) as a crosslink between my two boxes. Not really production-wise, but I do enjoy the fact that they can be dual-attached. Which is why I would't enjoy them being removed. > Every time I look at these drivers, their massive collection of > "portability" ifdefs makes it quite difficult to decipher the code. > Virtually all changes to these drivers in the last eight years have > been mechanical API updates. During this time, FDDI has become totally > obsolete. Unless someone is running these drivers for real on a modern > version of FreeBSD I would like to remove them from 6.0 and stop wasting > my time on them. If you could tell me where to begin, I'd like to try to make them more readible / maintainable. I've done some poking around (fpa(4) doesn't always attach correctly for me, due to some DMA issues) but without the proper data sheets, I guess it'll be hard to figure out where the problem lies. If anyone has data sheets for these cards, I'd be willing to bring them to a more maintainable level. I agree the code is a bit hard to decipher due to all the #ifdef's, I could work on getting rid of these alltogether. However, in order to fix the attachment problem (fpa0: Initialization failure, which I always get on some machines) I figure I'd need more detailed information. Perhaps someone can help me out on that? --=20 Rink P.W. Springer - http://rink.nu "God, root, what is difference?" - Pitr, Userfriendly --z6Eq5LdranGa6ru8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCedV7b3O60uztv/8RAg/5AKCAAaMjCAfmgiQtGWMoR6l0OAgsOwCZAS9e mw9o/fXJEDSQGyby+4KylWw= =3KBG -----END PGP SIGNATURE----- --z6Eq5LdranGa6ru8-- From owner-freebsd-stable@FreeBSD.ORG Thu May 5 12:07:55 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 179A616A4CF for ; Thu, 5 May 2005 12:07:55 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AA6343D6A for ; Thu, 5 May 2005 12:07:54 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from ranger.anduin.net ([81.0.162.52] helo=[192.168.1.110]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DTf8z-000GtJ-33 for stable@freebsd.org; Thu, 05 May 2005 14:07:53 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 05 May 2005 14:06:48 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: "stable@freebsd.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 12:07:55 -0000 Hi all, I'm struggling with some hosting environments where I am managing a large number of jails (>100) spread over about a dozen servers. I am starting to see disk space as a real problem, especially given that each physical box needs to be autonomous - i.e. I can't rely on any external storage, and I am limited to 1U and 2U servers. The solution, or at least parts of it, would be to have certain parts of the jail filesystems mounted in via nullfs (acceptable solution) or unionfs (ideal solution). However, ever since FreeBSD 4.10 this has been a major problem, as both filesystems started exhibiting major stability and data integrity issues. Before I start playing with this again, I'd like to know if any work has been done on either of these in 5.x. Specifically, I'm currently running 5.3-p6 or newer on all the systems, and as of yesterday I've been using 5.4-prerelease (cvsup) on a couple of test systems. What can I expect to see when trying nullfs and/or unionfs today? Has anything changed? Do I have even a remote chance of making it work - and if it doesn't work, what are my chances of anyone having time or energy to look into it? I'm an admin only, no coder, otherwise I'd be happy to look into it myself. Thanks, /Eirik From owner-freebsd-stable@FreeBSD.ORG Thu May 5 12:12:26 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5401816A4CE for ; Thu, 5 May 2005 12:12:26 +0000 (GMT) Received: from mail.praemunio.com (mail.praemunio.com [66.179.47.216]) by mx1.FreeBSD.org (Postfix) with SMTP id CA39A43D91 for ; Thu, 5 May 2005 12:12:25 +0000 (GMT) (envelope-from frank@knobbe.us) Received: from localhost (HELO mail.knobbe.us) by localhost with SMTP; 5 May 2005 07:12:24 -0500 Received: from localhost by localhost with SMTP; 5 May 2005 07:12:23 -0500 From: Frank Knobbe To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ylhXghT2SK5SzEzh0S/q" Date: Thu, 05 May 2005 07:12:21 -0500 Message-Id: <1115295141.87850.17.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port cc: "stable@freebsd.org" Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 12:12:26 -0000 --=-ylhXghT2SK5SzEzh0S/q Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2005-05-05 at 14:06 +0200, Eirik =3D?ISO-8859-1?B?2A=3D=3D?=3Dverby wrote: > [...] The solution, or at least parts of it, would be to have certain par= ts of the > jail filesystems mounted in via nullfs (acceptable solution) or unionfs > (ideal solution). However, ever since FreeBSD 4.10 this has been a major > problem, as both filesystems started exhibiting major stability and data > integrity issues.=20 > [...] > What can I expect to see when trying nullfs and/or unionfs today? Has > anything changed? Don't know if anything has changed, but I'm using nullfs to mount the ports directory of the host into jails. No ill effects. Works great, both under 4.10 and 5.3. (Back when I toyed with unionfs, I found that to be a bit unstable. But nullfs appears pretty solid) Regards, Frank --=-ylhXghT2SK5SzEzh0S/q Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCeg2lwBQKb2zelzoRAr/EAKD1UHjMBsCqhCaEPTd4xhXc89QsOACbBoyS SIdk1f5XpowWCrci+dGtzbc= =dYdD -----END PGP SIGNATURE----- --=-ylhXghT2SK5SzEzh0S/q-- From owner-freebsd-stable@FreeBSD.ORG Thu May 5 12:15:58 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D138916A4CE for ; Thu, 5 May 2005 12:15:58 +0000 (GMT) Received: from osiris.itlegion.ru (osiris.itlegion.ru [84.21.226.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACA0743DA7 for ; Thu, 5 May 2005 12:15:56 +0000 (GMT) (envelope-from matrix@itlegion.ru) Received: from artem ([192.168.0.12]) by osiris.itlegion.ru (8.13.1/8.13.1) with SMTP id j45CFKr6087254; Thu, 5 May 2005 16:15:20 +0400 (MSD) (envelope-from matrix@itlegion.ru) X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 73405, updated: 4.05.2005] Message-ID: <029701c5516c$4fe12480$0c00a8c0@artem> From: "Artem Kuchin" To: "Eirik Ø verby" , References: Date: Thu, 5 May 2005 16:16:47 +0400 Organization: IT Legion MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 12:15:58 -0000 Eirik Ø verby wrote: > Before I start playing with this again, I'd like to know if any work > has been done on either of these in 5.x. Specifically, I'm currently > running > 5.3-p6 or newer on all the systems, and as of yesterday I've been > using > 5.4-prerelease (cvsup) on a couple of test systems. Hi. I am running on 5.3-STABLE since december 2004. We run 14 jails and use nullfs for some shared parts. Everything is just fine. I tryed unionfs, it worked stable but i didn't do what i wanted it to do or probably i didn't get its usage right :) -- Regards, Artem Kuchin IT Legion Ltd. Moscow, Russia www.itlegion.ru matrix@itlegion.ru +7 095 232-0338 From owner-freebsd-stable@FreeBSD.ORG Thu May 5 14:43:41 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 336D716A4CE for ; Thu, 5 May 2005 14:43:41 +0000 (GMT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 38A5A43D5C for ; Thu, 5 May 2005 14:43:40 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 05 May 2005 14:43:34 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp027) with SMTP; 05 May 2005 16:43:34 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-stable@freebsd.org Date: Thu, 5 May 2005 16:43:23 +0200 User-Agent: KMail/1.8 References: In-Reply-To: X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3969337.tSrNxGHgxe"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505051643.33318@harrymail> X-Y-GMX-Trusted: 0 cc: Eirik =?iso-8859-1?q?=D8verby?= Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 14:43:41 -0000 --nextPart3969337.tSrNxGHgxe Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Donnerstag, 5. Mai 2005 14:06 schrieb Eirik =D8verby: > Hi all, > > I'm struggling with some hosting environments where I am managing a > large number of jails (>100) spread over about a dozen servers. I am > starting to see disk space as a real problem, especially given that each > physical box needs to be autonomous - i.e. I can't rely on any external > storage, and I am limited to 1U and 2U servers. > > The solution, or at least parts of it, would be to have certain parts of > the jail filesystems mounted in via nullfs (acceptable solution) or > unionfs (ideal solution). However, ever since FreeBSD 4.10 this has been > a major problem, as both filesystems started exhibiting major stability > and data integrity issues. > > Before I start playing with this again, I'd like to know if any work has > been done on either of these in 5.x. Specifically, I'm currently running > 5.3-p6 or newer on all the systems, and as of yesterday I've been using > 5.4-prerelease (cvsup) on a couple of test systems. > > What can I expect to see when trying nullfs and/or unionfs today? Has > anything changed? Do I have even a remote chance of making it work - and > if it doesn't work, what are my chances of anyone having time or energy > to look into it? I'm an admin only, no coder, otherwise I'd be happy to > look into it myself. Nullfs is as far as I can tell stable on 5.4 but the performance problem together with jails is not solved in 5.4, only in 6. And like Jeff said, it's not sure that it gets MFCd since lot of VFS changes are requred. =2DHarry > > Thanks, > /Eirik > > > _______________________________________________ > 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" --nextPart3969337.tSrNxGHgxe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCejEVBylq0S4AzzwRAlR1AJ9UCdeK5PjbtzLXAnDcxYI8UYnQegCeOxuP 1g7huuESbsELrjL6sYyI4Js= =WVji -----END PGP SIGNATURE----- --nextPart3969337.tSrNxGHgxe-- From owner-freebsd-stable@FreeBSD.ORG Thu May 5 14:59:56 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1D1016A4CE for ; Thu, 5 May 2005 14:59:56 +0000 (GMT) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84E5D43D49 for ; Thu, 5 May 2005 14:59:56 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 5013D64DE03; Thu, 5 May 2005 11:59:54 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 78110-03; Thu, 5 May 2005 14:59:53 +0000 (GMT) Received: from ganymede.hub.org (blk-222-81-172.eastlink.ca [24.222.81.172]) by hub.org (Postfix) with ESMTP id E65ED64DDFC; Thu, 5 May 2005 11:59:53 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 6086235778; Thu, 5 May 2005 11:59:52 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 5F54133E52; Thu, 5 May 2005 11:59:52 -0300 (ADT) Date: Thu, 5 May 2005 11:59:52 -0300 (ADT) From: "Marc G. Fournier" To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: Message-ID: <20050505115903.K42300@ganymede.hub.org> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-753026097-1115305192=:42300" X-Virus-Scanned: by amavisd-new at hub.org cc: "stable@freebsd.org" Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 14:59:56 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-753026097-1115305192=:42300 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 5 May 2005, Eirik [ISO-8859-1] =D8verby wrote: > The solution, or at least parts of it, would be to have certain parts of= =20 > the jail filesystems mounted in via nullfs (acceptable solution) or=20 > unionfs (ideal solution). However, ever since FreeBSD 4.10 this has been= =20 > a major problem, as both filesystems started exhibiting major stability= =20 > and data integrity issues. I'm running 4.11 with ~90 mount/jails running on two of our servers ...=20 haven't noticed any stability problems ... what are you seeing? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 --0-753026097-1115305192=:42300-- From owner-freebsd-stable@FreeBSD.ORG Thu May 5 18:09:38 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 34BAE16A4E0 for ; Thu, 5 May 2005 18:09:38 +0000 (GMT) Received: from merlin.alerce.com (w094.z064001164.sjc-ca.dsl.cnc.net [64.1.164.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EB5C43D77 for ; Thu, 5 May 2005 18:09:37 +0000 (GMT) (envelope-from hartzell@kestrel.alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 06F9E21AF; Thu, 5 May 2005 11:08:55 -0700 (PDT) Received: from satchel.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by merlin.alerce.com (Postfix) with ESMTP id B314B214F; Thu, 5 May 2005 11:08:55 -0700 (PDT) Received: from satchel.alerce.com (localhost [127.0.0.1]) by satchel.alerce.com (8.13.1/8.13.1) with ESMTP id j45I9hNf009773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 May 2005 11:09:44 -0700 (PDT) (envelope-from hartzell@satchel.alerce.com) Received: (from hartzell@localhost) by satchel.alerce.com (8.13.1/8.13.1/Submit) id j45I9gTa009770; Thu, 5 May 2005 11:09:42 -0700 (PDT) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <17018.24934.201800.345415@satchel.alerce.com> Date: Thu, 5 May 2005 11:09:42 -0700 To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: References: X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid X-Virus-Scanned: ClamAV using ClamSMTP cc: "stable@freebsd.org" Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2005 18:09:38 -0000 Eirik =D8verby writes: > [...] > What can I expect to see when trying nullfs and/or unionfs today? Ha= s > anything changed? Do I have even a remote chance of making it work -= and if > it doesn't work, what are my chances of anyone having time or energy= to look > into it? I'm an admin only, no coder, otherwise I'd be happy to look= into it > myself. I'm using unionfs to mount a copy of my ports tree into a jail on a fairly currently patched 5.3 system. It works beautifully except that it sometimes can't be unmounted as the machine shuts down, leading to an fsck. I've been trying to characterize it. Seems like I can mount it, start a jail, stop the jail, and unmount it just fine. However if I do anything in the jail's ports tree, then it won't unmount. Last experiment I did was to log into the jail and do a couple of 'syncs', then log out, shut the jail down and unmount it. That worked that one time. Not enough to file a bug yet, but the anecdote might be useful. g. From owner-freebsd-stable@FreeBSD.ORG Thu May 5 19:08:27 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB5BD16A4CE for ; Thu, 5 May 2005 19:08:27 +0000 (GMT) Received: from pandora.afflictions.org (asylum.afflictions.org [64.7.134.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD6D743D92 for ; Thu, 5 May 2005 19:08:27 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from localhost (localhost [127.0.0.1]) by pandora.afflictions.org (Postfix) with ESMTP id 6A7EA78C70 for ; Thu, 5 May 2005 15:10:43 -0400 (EDT) Received: from pandora.afflictions.org ([127.0.0.1]) by localhost (pandora.afflictions.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66726-04 for ; Thu, 5 May 2005 15:10:40 -0400 (EDT) Received: from dementia.afflictions.org (unknown [172.19.206.152]) by pandora.afflictions.org (Postfix) with ESMTP id DE34678C64 for ; Thu, 5 May 2005 15:10:39 -0400 (EDT) Received: by dementia.afflictions.org (Postfix, from userid 1001) id 60DE833C30; Thu, 5 May 2005 15:08:13 -0400 (EDT) Date: Thu, 5 May 2005 15:08:13 -0400 From: Damian Gerow To: stable@freebsd.org Message-ID: <20050505190812.GB15724@afflictions.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-GPG-Fingerprint: B3D7 D901 A53A 1A99 BFD6 E6DF 9F3B 742B C288 9CC9 User-Agent: Mutt/1.5.9i X-Virus-Scanned: amavisd-new at pandora.afflictions.org Subject: examples/etc/make.conf: nocona? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 19:08:28 -0000 When looking through the example make.conf, I saw that 'nocona' is listed under "AMD CPUs" (under "Intel x86 architecture") as well as under "AMD64 architecture". I can understand listing nocona under AMD64 architecture, but isn't it an Intel CPU? Am I missing something in thinking it should be listed under "Intel CPUs"? From owner-freebsd-stable@FreeBSD.ORG Thu May 5 19:34:09 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D209E16A4CE for ; Thu, 5 May 2005 19:34:09 +0000 (GMT) Received: from veldy.net (fuggle.veldy.net [209.240.64.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AF7B43D78 for ; Thu, 5 May 2005 19:34:09 +0000 (GMT) (envelope-from veldy@veldy.net) Received: from localhost (localhost.veldy.net [127.0.0.1]) by veldy.net (Postfix) with ESMTP id 739046B for ; Thu, 5 May 2005 14:33:44 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle.veldy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42499-05 for ; Thu, 5 May 2005 14:33:36 -0500 (CDT) Received: from [127.0.0.1] (cascade.veldy.net [192.168.1.1]) by veldy.net (Postfix) with ESMTP id 5D75D1F for ; Thu, 5 May 2005 14:33:36 -0500 (CDT) Message-ID: <427A7494.8060508@veldy.net> Date: Thu, 05 May 2005 14:31:32 -0500 From: "Thomas T. Veldhouse" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary="------------070402070808000805040102" X-Virus-Scanned: by amavisd-new at veldy.net Subject: [Fwd: Cron /usr/libexec/save-entropy] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 19:34:10 -0000 This is a multi-part message in MIME format. --------------070402070808000805040102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Can anybody indicate to me what is causing the attached email and how to fix it? I upgraded to the 5.4-STABLE as of yesterday and I am now getting the attached email several time a day. Is this simply a script error? Thanks, Tom Veldhouse --------------070402070808000805040102 Content-Type: message/rfc822; name="Cron /usr/libexec/save-entropy" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Cron /usr/libexec/save-entropy" Return-Path: X-Original-To: veldy@veldy.net Delivered-To: veldy@veldy.net Received: from localhost (localhost.veldy.net [127.0.0.1]) by veldy.net (Postfix) with ESMTP id ACA5A6C for ; Thu, 5 May 2005 14:23:00 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle.veldy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42482-02 for ; Thu, 5 May 2005 14:22:53 -0500 (CDT) Received: from ekg.veldy.net (ekg.veldy.net [192.168.1.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by veldy.net (Postfix) with ESMTP id EB2061F for ; Thu, 5 May 2005 14:22:52 -0500 (CDT) Received: from ekg.veldy.net (localhost.veldy.net [127.0.0.1]) by ekg.veldy.net (8.13.3/8.13.1) with ESMTP id j45EM0Wn023202 for ; Thu, 5 May 2005 09:22:00 -0500 (CDT) (envelope-from operator@ekg.veldy.net) Received: (from operator@localhost) by ekg.veldy.net (8.13.3/8.13.1/Submit) id j45EM0kH023191; Thu, 5 May 2005 09:22:00 -0500 (CDT) (envelope-from operator) Date: Thu, 5 May 2005 09:22:00 -0500 (CDT) Message-Id: <200505051422.j45EM0kH023191@ekg.veldy.net> From: operator@ekg.veldy.net (Cron Daemon) To: operator@ekg.veldy.net Subject: Cron /usr/libexec/save-entropy X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Cron-Env: X-Virus-Scanned: by amavisd-new at veldy.net X-DSPAM-Factors: 27, Received*operator, 0.00020, not+found, 0.00600, Received*ekg.veldy.net, 0.00600, Received*ekg.veldy.net, 0.00600, X-Cron-Env*bin, 0.00600, X-Cron-Env*bin, 0.00600, X-Cron-Env*usr, 0.00600, X-Cron-Env*usr, 0.00600, X-Cron-Env*sbin, 0.00600, X-Cron-Env*sbin, 0.00600, X-Cron-Env*operator, 0.00600, X-Cron-Env*operator, 0.00600, From*Cron+Daemon, 0.00600, X-Cron-Env*PATH+etc, 0.00600, Subject*Cron+operator, 0.00600, X-Cron-Env*bin+sh, 0.00600, Subject*save+entropy, 0.00600, X-Cron-Env*bin+usr, 0.00600, To*ekg+veldy, 0.00600, X-Cron-Env*bin+sbin, 0.00600, X-Cron-Env*usr+bin, 0.00600, Return-Path*ekg+veldy, 0.00600, Subject*ekg+usr, 0.00600, Subject*libexec+save, 0.00600, From*ekg+veldy, 0.00600, Message-Id*ekg+veldy, 0.00600, From*operator+ekg, 0.00600 X-DSPAM-Result: Whitelisted X-DSPAM-Confidence: 0.9941 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: !DSPAM:427a7295425457150559098! X: not found --------------070402070808000805040102-- From owner-freebsd-stable@FreeBSD.ORG Thu May 5 23:04:12 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90DB616A4CE for ; Thu, 5 May 2005 23:04:12 +0000 (GMT) Received: from orchid.homeunix.org (awv212.neoplus.adsl.tpnet.pl [83.27.81.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D9DB43D92 for ; Thu, 5 May 2005 23:04:11 +0000 (GMT) (envelope-from freebsd@orchid.homeunix.org) Received: from [192.168.1.66] (blackacidevil.orchid.homeunix.org [192.168.1.66]) (authenticated bits=0) by orchid.homeunix.org (8.13.1/8.13.1) with ESMTP id j45N3kKm020284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 May 2005 01:04:07 +0200 (CEST) (envelope-from freebsd@orchid.homeunix.org) Message-ID: <427AA656.4040305@orchid.homeunix.org> Date: Fri, 06 May 2005 01:03:50 +0200 From: Karol Kwiatkowski User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050326) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomas T. Veldhouse" References: <427A7494.8060508@veldy.net> In-Reply-To: <427A7494.8060508@veldy.net> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.84/871/Thu May 5 15:50:45 2005 on orchid.homeunix.org X-Virus-Status: Clean cc: freebsd-stable@freebsd.org Subject: Re: [Fwd: Cron /usr/libexec/save-entropy] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd@orchid.homeunix.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2005 23:04:12 -0000 Thomas T. Veldhouse wrote: > Can anybody indicate to me what is causing the attached email and how to > fix it? I upgraded to the 5.4-STABLE as of yesterday and I am now > getting the attached email several time a day. Is this simply a script > error? [snip] > Cron /usr/libexec/save-entropy > X: not found I'm not using 5.4 but I would look in the save-entropy script for a line that starts with 'X '. Also, looking at the source, have a look at /etc/rc.conf and/or /etc/defaults/rc.conf as they are read at the beginning of that script. Actually, I can reproduce such message by adding line with 'X ' at the beginning in /etc/rc.conf. Regards, Karol -- Karol Kwiatkowski From owner-freebsd-stable@FreeBSD.ORG Thu May 5 23:30:03 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77FCF16A4CE for ; Thu, 5 May 2005 23:30:03 +0000 (GMT) Received: from veldy.net (fuggle.veldy.net [209.240.64.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4114443D64 for ; Thu, 5 May 2005 23:30:03 +0000 (GMT) (envelope-from veldy@veldy.net) Received: from localhost (localhost.veldy.net [127.0.0.1]) by veldy.net (Postfix) with ESMTP id 47E866B for ; Thu, 5 May 2005 18:30:02 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle.veldy.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44044-02 for ; Thu, 5 May 2005 18:29:53 -0500 (CDT) Received: from [127.0.0.1] (cascade.veldy.net [192.168.1.1]) by veldy.net (Postfix) with ESMTP id A85AF28 for ; Thu, 5 May 2005 18:29:53 -0500 (CDT) Message-ID: <427AABF7.6060807@veldy.net> Date: Thu, 05 May 2005 18:27:51 -0500 From: "Thomas T. Veldhouse" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <427A7494.8060508@veldy.net> <427AA656.4040305@orchid.homeunix.org> In-Reply-To: <427AA656.4040305@orchid.homeunix.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at veldy.net Subject: Re: [Fwd: Cron /usr/libexec/save-entropy] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 23:30:03 -0000 Karol Kwiatkowski wrote: >I'm not using 5.4 but I would look in the save-entropy script for a >line that starts with 'X '. Also, looking at the source, have a look >at /etc/rc.conf and/or /etc/defaults/rc.conf as they are read at the >beginning of that script. > >Actually, I can reproduce such message by adding line with 'X ' at the > beginning in /etc/rc.conf > > Thanks ... that was the tip I needed. I had the following in my /etc/rc.conf file: xfs_enable="NO" X font server I was missing the comment hash. Tom Veldhouse From owner-freebsd-stable@FreeBSD.ORG Thu May 5 23:49:51 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C3B8E16A4CE for ; Thu, 5 May 2005 23:49:51 +0000 (GMT) Received: from imo-d23.mx.aol.com (imo-d23.mx.aol.com [205.188.139.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B6A443D54 for ; Thu, 5 May 2005 23:49:51 +0000 (GMT) (envelope-from PATTISP71@aol.com) Received: from PATTISP71@aol.com by imo-d23.mx.aol.com (mail_out_v38_r1.7.) id n.1ff.1070081 (48600) for ; Thu, 5 May 2005 19:49:48 -0400 (EDT) From: PATTISP71@aol.com Message-ID: <1ff.1070081.2fac0b1c@aol.com> Date: Thu, 5 May 2005 19:49:48 EDT To: freebsd-stable@freebsd.org MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5012 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: NEC 1300A DVD-R writing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 05 May 2005 23:49:51 -0000 Do you happen to still have the 1198_firmware_ND-1300A_WIN108.zip file? I have not been able to find this and I think this is what I need. I can burn Music files and CD to CD, but when I go to burn a DVD or movie file, it won't. I am grateful if you can help me! Thanks, Patti From owner-freebsd-stable@FreeBSD.ORG Fri May 6 00:26:13 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D27D16A4CF for ; Fri, 6 May 2005 00:26:13 +0000 (GMT) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0865943DAF for ; Fri, 6 May 2005 00:26:13 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.50 (FreeBSD)) id 1DTqfS-000J8Y-Uk; Fri, 06 May 2005 01:26:10 +0100 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.50 (FreeBSD)) id 1DTqfS-000LgT-W0; Fri, 06 May 2005 01:26:10 +0100 To: freebsd-stable@freebsd.org, PATTISP71@aol.com In-Reply-To: <1ff.1070081.2fac0b1c@aol.com> Message-Id: From: Pete French Date: Fri, 06 May 2005 01:26:10 +0100 Subject: Re: NEC 1300A DVD-R writing X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 00:26:13 -0000 > Do you happen to still have the 1198_firmware_ND-1300A_WIN108.zip file? I > have not been able to find this and I think this is what I need. not sure what your question is doing here, but the answer is probably: http://forum.rpc1.org/dl_firmware.php?download_id=1517 many firmwares for that drive up to 1.0C -pcf. From owner-freebsd-stable@FreeBSD.ORG Fri May 6 06:18:55 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0746F16A4CE for ; Fri, 6 May 2005 06:18:55 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9268743D8A for ; Fri, 6 May 2005 06:18:54 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DTwAl-000PKy-Ht; Fri, 06 May 2005 09:18:51 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: hartzell@alerce.com In-Reply-To: Message from George Hartzell <17018.24934.201800.345415@satchel.alerce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 06 May 2005 09:18:51 +0300 From: Danny Braniss Message-ID: cc: "stable@freebsd.org" cc: Eirik =?ISO-8859-1?B?2A==?=verby Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 06:18:55 -0000 > Eirik =D8verby writes: > > [...] > > What can I expect to see when trying nullfs and/or unionfs today? Ha= s > > anything changed? Do I have even a remote chance of making it work -= and if > > it doesn't work, what are my chances of anyone having time or energy= to look > > into it? I'm an admin only, no coder, otherwise I'd be happy to look= into it > > myself. > = > I'm using unionfs to mount a copy of my ports tree into a jail on a > fairly currently patched 5.3 system. It works beautifully except that > it sometimes can't be unmounted as the machine shuts down, leading to > an fsck. > = > I've been trying to characterize it. Seems like I can mount it, start > a jail, stop the jail, and unmount it just fine. However if I do > anything in the jail's ports tree, then it won't unmount. Last > experiment I did was to log into the jail and do a couple of 'syncs', > then log out, shut the jail down and unmount it. That worked that one > time. > = > Not enough to file a bug yet, but the anecdote might be useful. we use unionfs with our diskless, mounting the read-only root via nfs, th= en union /etc with a memory file system, the per host files (rc.conf, fstab = =2E..) get copied to it, so that after a reboot no need to fsck anything. works like a charm! a happy user of unionfs, danny From owner-freebsd-stable@FreeBSD.ORG Fri May 6 07:20:10 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3259016A4CE for ; Fri, 6 May 2005 07:20:10 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2B3943D5D for ; Fri, 6 May 2005 07:20:09 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DTx81-000BQG-8D; Fri, 06 May 2005 09:20:05 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 06 May 2005 09:19:59 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: Danny Braniss , Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable cc: "stable@freebsd.org" Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 07:20:10 -0000 On 06-05-05 08:18, "Danny Braniss" wrote: >> Eirik =D8verby writes: >>> [...] >>> What can I expect to see when trying nullfs and/or unionfs today? Has >>> anything changed? Do I have even a remote chance of making it work - an= d if >>> it doesn't work, what are my chances of anyone having time or energy to= look >>> into it? I'm an admin only, no coder, otherwise I'd be happy to look in= to it >>> myself. >>=20 >> I'm using unionfs to mount a copy of my ports tree into a jail on a >> fairly currently patched 5.3 system. It works beautifully except that >> it sometimes can't be unmounted as the machine shuts down, leading to >> an fsck. >>=20 >> I've been trying to characterize it. Seems like I can mount it, start >> a jail, stop the jail, and unmount it just fine. However if I do >> anything in the jail's ports tree, then it won't unmount. Last >> experiment I did was to log into the jail and do a couple of 'syncs', >> then log out, shut the jail down and unmount it. That worked that one >> time. >>=20 >> Not enough to file a bug yet, but the anecdote might be useful. >=20 >=20 > we use unionfs with our diskless, mounting the read-only root via nfs, th= en > union /etc with a memory file system, the per host files (rc.conf, fstab = ...) > get copied to it, so that after a reboot no need to fsck anything. works > like a charm! Interesting approach. Is this with 4.x or 5.x? How do you union-mount /etc (mount command/fstab entry)? /Eirik >=20 > a happy user of unionfs, > danny >=20 >=20 >=20 From owner-freebsd-stable@FreeBSD.ORG Fri May 6 07:25:11 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EC2616A4CE for ; Fri, 6 May 2005 07:25:11 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D17E643D5A for ; Fri, 6 May 2005 07:25:10 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DTxCv-0000bq-1f; Fri, 06 May 2005 10:25:09 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: Message from Eirik =?ISO-8859-1?B?2A==?=verby Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 06 May 2005 10:25:08 +0300 From: Danny Braniss Message-ID: cc: stable@freebsd.org cc: hartzell@alerce.com Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 07:25:11 -0000 > Interesting approach. Is this with 4.x or 5.x? How do you union-mount /= etc > (mount command/fstab entry)? > = been doing it since 4.x (i think x < 9) in initdiskless (5.x) we have: if [ -e /conf/union ]; then kldload unionfs mount_md 4096 /conf/etc chmod 755 /conf/etc mount_unionfs /conf/etc /etc ls -R /etc > /dev/null touch /etc/.sentinel md_created_etc=3Dcreated fi danny From owner-freebsd-stable@FreeBSD.ORG Fri May 6 10:44:29 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6648916A4CE for ; Fri, 6 May 2005 10:44:29 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 253C743D7F for ; Fri, 6 May 2005 10:44:29 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DU0Jn-000Cs9-EL; Fri, 06 May 2005 12:44:28 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 06 May 2005 12:44:20 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: "Marc G. Fournier" Message-ID: In-Reply-To: <20050505115903.K42300@ganymede.hub.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable cc: "stable@freebsd.org" Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 10:44:29 -0000 On 05-05-05 16:59, "Marc G. Fournier" wrote: > On Thu, 5 May 2005, Eirik [ISO-8859-1] =D8verby wrote: >=20 >> The solution, or at least parts of it, would be to have certain parts of >> the jail filesystems mounted in via nullfs (acceptable solution) or >> unionfs (ideal solution). However, ever since FreeBSD 4.10 this has been >> a major problem, as both filesystems started exhibiting major stability >> and data integrity issues. >=20 > I'm running 4.11 with ~90 mount/jails running on two of our servers ... > haven't noticed any stability problems ... what are you seeing? I was seeing panics and deadlocks (hangs), seemingly unrelated to the level of disk activity, and sometimes I even had the suspicion that just having such a mountpoint, even though the jail wasn't started, could be enough to bring the system down. The problems appeared around 4.9/4.10. Even though I mounted these read-only, I still saw data going bad in directories that was null-mounted. This scared me away for a very long time ;) I'm just now picking up on the unionfs use, seems to do what I want, but I have no idea if it's stable or not. I suppose we'll be seeing that soon. /Eirik =20 > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.or= g) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 76156= 64 > _______________________________________________ > 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 Fri May 6 10:45:34 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B3FA16A4CE for ; Fri, 6 May 2005 10:45:34 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ED7443D7C for ; Fri, 6 May 2005 10:45:34 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DU0Kq-000Cud-Th; Fri, 06 May 2005 12:45:33 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 06 May 2005 12:45:23 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: Danny Braniss Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit cc: stable@freebsd.org Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 10:45:34 -0000 On 06-05-05 09:25, "Danny Braniss" wrote: > >> Interesting approach. Is this with 4.x or 5.x? How do you union-mount /etc >> (mount command/fstab entry)? >> > > been doing it since 4.x (i think x < 9) Any idea how unionfs will behave if stacked (more mounts on top of each other)? I was playing with the thought of having a "template" jail directory which I unionmount into my jails, then perhaps use your trick to union-mount a md device into certain points in the jail. Got a gut feeling about that? /Eirik > in initdiskless (5.x) we have: > > if [ -e /conf/union ]; then > kldload unionfs > mount_md 4096 /conf/etc > chmod 755 /conf/etc > mount_unionfs /conf/etc /etc > ls -R /etc > /dev/null > touch /etc/.sentinel > md_created_etc=created > fi > > danny > > > _______________________________________________ > 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 Fri May 6 11:14:46 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78F8716A51E for ; Fri, 6 May 2005 11:14:44 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 854ED43D6D for ; Fri, 6 May 2005 11:14:43 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1DU0n4-0004uf-0J; Fri, 06 May 2005 14:14:42 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: Message from Eirik =?ISO-8859-1?B?2A==?=verby Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 06 May 2005 14:14:41 +0300 From: Danny Braniss Message-ID: cc: stable@freebsd.org Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 11:14:46 -0000 > On 06-05-05 09:25, "Danny Braniss" wrote: > > > > >> Interesting approach. Is this with 4.x or 5.x? How do you union-mount /etc > >> (mount command/fstab entry)? > >> > > > > been doing it since 4.x (i think x < 9) > > Any idea how unionfs will behave if stacked (more mounts on top of each > other)? I was playing with the thought of having a "template" jail directory > which I unionmount into my jails, then perhaps use your trick to union-mount > a md device into certain points in the jail. Got a gut feeling about that? i have the feeling that that will get into trouble :-), but im no expert here. If what you mean is: mount_unionfs /md-0 /jail-0 and then mount_unionfs /md-1 /jail-0/xyz which is not strickly 'stacked', might work and should be easy to try out, but IMHO, breaks the KISS principle :-) and also, im not sure if: mkdir /jail-0/xyz mount_unionfs /md-1 /jail-0/xyz is the same as the above. danny From owner-freebsd-stable@FreeBSD.ORG Fri May 6 11:20:26 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D592316A4D0 for ; Fri, 6 May 2005 11:20:26 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67FA343D55 for ; Fri, 6 May 2005 11:20:26 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DU0sb-000Hth-6O; Fri, 06 May 2005 13:20:25 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 06 May 2005 13:20:19 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: Danny Braniss Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit cc: stable@freebsd.org Subject: Re: Current status of nullfs and/or unionfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 11:20:26 -0000 On 06-05-05 13:14, "Danny Braniss" wrote: >> On 06-05-05 09:25, "Danny Braniss" wrote: >> >>> >>>> Interesting approach. Is this with 4.x or 5.x? How do you union-mount /etc >>>> (mount command/fstab entry)? >>>> >>> >>> been doing it since 4.x (i think x < 9) >> >> Any idea how unionfs will behave if stacked (more mounts on top of each >> other)? I was playing with the thought of having a "template" jail directory >> which I unionmount into my jails, then perhaps use your trick to union-mount >> a md device into certain points in the jail. Got a gut feeling about that? > > i have the feeling that that will get into trouble :-), but im no expert > here. If what you mean is: > > mount_unionfs /md-0 /jail-0 > and then > mount_unionfs /md-1 /jail-0/xyz > > which is not strickly 'stacked', might work and should be easy to try out, but > IMHO, breaks the KISS principle :-) I was more thinking, like, mount_unionfs -b /jails/jail_template /jails/jail-0 mount_unionfs /md-0 /jails/jail-0/etc for example. I could also imagine stacking unionfs on top of nullfs, like mount_nullfs /cdrom/jail_template /jails/jail-0 mount_unionfs /md-0 /jails/jail-0 alternatively mount_unionfs /nfs-0 /jails/jail-0 Sounds weird, I know, but we could use it... > and also, im not sure if: > mkdir /jail-0/xyz > mount_unionfs /md-1 /jail-0/xyz > is the same as the above. > > danny > > > From owner-freebsd-stable@FreeBSD.ORG Fri May 6 11:52:20 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE1EF16A4D0 for ; Fri, 6 May 2005 11:52:20 +0000 (GMT) Received: from cl-mailhost.FernUni-Hagen.de (sycamore.fernuni-hagen.de [132.176.114.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EB8C43DA3 for ; Fri, 6 May 2005 11:52:20 +0000 (GMT) (envelope-from heinricf@mailstore.FernUni-Hagen.de) Received: from mailstore.fernuni-hagen.de ([132.176.114.185]) by cl-mailhost.FernUni-Hagen.de with esmtp (Exim 4.24) id 1DU1NT-00001T-F1 for stable@freebsd.org; Fri, 06 May 2005 13:52:19 +0200 Received: from jfh00.fernuni-hagen.de (account heinricf [132.176.7.6] verified) by mailstore.fernuni-hagen.de (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 10869008 for stable@freebsd.org; Fri, 06 May 2005 13:52:17 +0200 From: Fritz Heinrichmeyer Organization: Fernuni Hagen To: stable@freebsd.org Date: Fri, 6 May 2005 13:52:17 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200505061352.17269.Fritz.heinrichmeyer@fernuni-hagen.de> X-prewhitelist: your reply will pass through without greylisting Subject: recent fix of NTFS readdir function X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 11:52:20 -0000 Hello,=20 i also recognized this bug some time ago and circumvented it by using an=20 msdosfs partition. This should go in stable too. =2D-=20 Mit freundlichen Gr=FC=DFen =46ritz Heinrichmeyer FernUniversit=E4t, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 From owner-freebsd-stable@FreeBSD.ORG Fri May 6 11:57:43 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5D8416A4D0 for ; Fri, 6 May 2005 11:57:43 +0000 (GMT) Received: from mta1.netlife.no (banan.netlife.no [213.187.191.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3992443D55 for ; Fri, 6 May 2005 11:57:43 +0000 (GMT) (envelope-from erik@tefre.com) Received: from bavian.netlife.no (bavian.netlife.no [213.187.191.52]) by mta1.netlife.no (Postfix) with ESMTP id F00AF67852; Fri, 6 May 2005 13:57:42 +0200 (CEST) From: Erik Stian Tefre To: "Marc G. Fournier" In-Reply-To: <20050504160004.B53065@ganymede.hub.org> References: <20050504160004.B53065@ganymede.hub.org> Content-Type: text/plain Date: Fri, 06 May 2005 13:57:44 +0200 Message-Id: <1115380664.56321.171.camel@bavian.netlife.no> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org Subject: Re: twa0: INFO: (0x04: 0x000c): Background initialize started: unit=0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 11:57:44 -0000 I believe you should see this message only once after creating a new array/unit, given that you give the box enough uptime to finish the initialization. The following message confirms that the initialization is complete (it took 4.5 hours on my box with a 9500-8LP, which btw is running 5.3): twa0: INFO: (0x04: 0x0007): Background initialize done: unit=0 On Wed, 2005-05-04 at 16:01 -0300, Marc G. Fournier wrote: > Running FreeBSD 4.11-STABLE ... > > Has anyone seen this before? Only reference on the 'net I can find seems > to be similar issue on a Dragonfly system: > > http://leaf.dragonflybsd.org/mailarchive/bugs/2004-09/msg00176.html > > Mine is a 9500-4LP controller ... > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > _______________________________________________ > 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" -- Erik Stian Tefre From owner-freebsd-stable@FreeBSD.ORG Fri May 6 13:17:42 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADE5016A4D3 for ; Fri, 6 May 2005 13:17:42 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1A8543D93 for ; Fri, 6 May 2005 13:17:39 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1DU2aj-0003T8-7h for freebsd-stable@freebsd.org; Fri, 06 May 2005 15:10:05 +0200 Received: from kvip88.kvi.nl ([129.125.15.152]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 May 2005 15:10:05 +0200 Received: from A.S.Usov by kvip88.kvi.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 May 2005 15:10:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Alexander S. Usov" Date: Fri, 06 May 2005 15:08:39 +0200 Organization: KVI Lines: 31 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: kvip88.kvi.nl User-Agent: KNode/0.9.0 Sender: news Subject: kernel panics in recent RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 13:17:42 -0000 It look that something was broken in the last few days in RELENG_5 branch. I am getting reproducible panics by pressing almost any key while system is booting or is in shutdown. Once it is up -- it works mostly fine. Also I noted that the keyboard was not working on my laptop while in the booting phase -- so after I managed to get a second panic doing fsck, I was unable to do anything in single-user mode. The only working keys I found were ScrollLock/Pause and Ctrl-Alt-Del :) Howewer rebooting it with acpi turned off I managed to get it working. The overall impression is that something is wrong with syscons, so it causes system panics when key is pressed and nobody listens to the terminal. I am trying to check if this issue is present in RELENG_5_4, and could also try to get crash dump if somebody is interested in digging it. BTW, did somebody else had problems with ehci? I had a problems with processes trying to read/write msdos/ext2fs partitions from usb2 drive getting stuck in wdrain (if I didn't mispell it) state. However I am not absolutely sure here, and want to do some more testing. I suspect that the usb2ide bridge I have is somewhat too cheap and buggy, as I also saw similar kind of problems with windows (the lamp on the drive constantly lights, and after some time windows disconnects it), but freebsd seemed to trigger this problem very efficiently. -- Best regards, Alexander. From owner-freebsd-stable@FreeBSD.ORG Fri May 6 13:29:53 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42AA916A4D3 for ; Fri, 6 May 2005 13:29:53 +0000 (GMT) Received: from discordia.pl (discordia.pl [212.160.154.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5FA643D6E for ; Fri, 6 May 2005 13:29:52 +0000 (GMT) (envelope-from toread@discordia.pl) Received: from localhost (localhost.pl [127.0.0.1]) by discordia.pl (Postfix) with ESMTP id B797420B415 for ; Fri, 6 May 2005 15:29:48 +0200 (CEST) Received: from discordia.pl ([127.0.0.1]) by localhost (discordia.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00833-02 for ; Fri, 6 May 2005 15:29:35 +0200 (CEST) Received: by discordia.pl (Postfix, from userid 1001) id 3114E20B40F; Fri, 6 May 2005 15:29:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by discordia.pl (Postfix) with ESMTP id 0FB8C20B40C for ; Fri, 6 May 2005 15:29:35 +0200 (CEST) Date: Fri, 6 May 2005 15:29:34 +0200 (CEST) From: Piotr Gnyp To: stable@freebsd.org Message-ID: <20050506152346.E23993@discordia.pl> X-PGP-Key: http://discordia.pl/~toread/pub.txt Organization: The Golden Apple Corp MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at discordia.pl Subject: Kernel panic: kmem_map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 13:29:53 -0000 uname -v FreeBSD 5.3-RELEASE-p9 panic message: savecore: reboot after panic: kmem_malloc(45056): kmem _map too small: 334680064 total allocated when i try to do kgdb i get this: kgdb: cannot read PTD Panic after 31 days of uptime. I will gladly show more data if needed. -- "How fortunate the man with none." --Dead Can Dance From owner-freebsd-stable@FreeBSD.ORG Fri May 6 14:34:37 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB6AB16A4D3 for ; Fri, 6 May 2005 14:34:37 +0000 (GMT) Received: from smtp1.wanadoo.fr (smtp1.wanadoo.fr [193.252.22.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id BEFEF43D99 for ; Fri, 6 May 2005 14:34:36 +0000 (GMT) (envelope-from lists@nbux.com) Received: from me-wanadoo.net (unknown [127.0.0.1]) by mwinf0106.wanadoo.fr (SMTP Server) with ESMTP id 5031B1C0015C for ; Fri, 6 May 2005 16:34:35 +0200 (CEST) Received: from daneel.nbux.com (LNeuilly-152_22-15-131.w82-127.abo.wanadoo.fr [82.127.94.131]) by mwinf0106.wanadoo.fr (SMTP Server) with ESMTP id 32E701C00150 for ; Fri, 6 May 2005 16:34:35 +0200 (CEST) X-ME-UUID: 20050506143435208.32E701C00150@mwinf0106.wanadoo.fr Received: from webmail.nbux.com (daneel.nbux.com [192.168.42.2]) by daneel.nbux.com (Postfix) with ESMTP id 4629F7F494 for ; Fri, 6 May 2005 16:34:32 +0200 (CEST) Received: from 194.51.215.62 (SquirrelMail authenticated user lists) by webmail.nbux.com with HTTP; Fri, 6 May 2005 16:34:32 +0200 (CEST) Message-ID: <32899.194.51.215.62.1115390072.squirrel@webmail.nbux.com> Date: Fri, 6 May 2005 16:34:32 +0200 (CEST) From: "Christophe Yayon" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: yes Subject: pthreads and nagios issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 14:34:37 -0000 Hi all, i am upgrading our nagios 1.2 (on freebsd 5.3-release) to nagios 2.0 (currently last cvs after 2.0b3) on Freebsd-5.4RC3 and i saw a very strange thing. After few hours, nagios main process (nagios -d ...) use lot of cpu time and when i do a truss on the pid, i have a "kse_release" loop message. # top last pid: 75729; load averages: 1.81, 2.08, 2.03 63 processes: 2 running, 61 sleeping CPU states: 12.5% user, 0.0% nice, 16.0% system, 0.0% interrupt, 71.5% idle Mem: 36M Active, 1639M Inact, 219M Wired, 68M Cache, 112M Buf, 44M Free Swap: 5000M Total, 52K Used, 5000M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 40435 nagios 112 0 4688K 3544K CPU0 0 569:46 93.99% 93.99% nagios [...] # truss -p 40435 kse_release(0xbfbf9b70) ERR#22 "Invalid argument" kse_release(0xbfbf9b70) ERR#22 "Invalid argument" kse_release(0xbfbf9b70) ERR#22 "Invalid argument" [...] I know there is a pthread_acquire() issue with Nagios and FreeBSD threads, but is there any patch against this ? Thanks in advance... From owner-freebsd-stable@FreeBSD.ORG Fri May 6 14:45:36 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4852416A4D3 for ; Fri, 6 May 2005 14:45:36 +0000 (GMT) Received: from smtp14.wanadoo.fr (smtp14.wanadoo.fr [193.252.23.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9D2D43DA5 for ; Fri, 6 May 2005 14:45:35 +0000 (GMT) (envelope-from lists@nbux.com) Received: from me-wanadoo.net (unknown [127.0.0.1]) by mwinf1402.wanadoo.fr (SMTP Server) with ESMTP id D183970000B8 for ; Fri, 6 May 2005 16:45:34 +0200 (CEST) Received: from daneel.nbux.com (LNeuilly-152_22-15-131.w82-127.abo.wanadoo.fr [82.127.94.131]) by mwinf1402.wanadoo.fr (SMTP Server) with ESMTP id A1A877000098 for ; Fri, 6 May 2005 16:45:34 +0200 (CEST) X-ME-UUID: 20050506144534662.A1A877000098@mwinf1402.wanadoo.fr Received: from webmail.nbux.com (daneel.nbux.com [192.168.42.2]) by daneel.nbux.com (Postfix) with ESMTP id 93BC17F494 for ; Fri, 6 May 2005 16:45:31 +0200 (CEST) Received: from 194.51.215.62 (SquirrelMail authenticated user lists) by webmail.nbux.com with HTTP; Fri, 6 May 2005 16:45:31 +0200 (CEST) Message-ID: <34723.194.51.215.62.1115390731.squirrel@webmail.nbux.com> Date: Fri, 6 May 2005 16:45:31 +0200 (CEST) From: "Christophe Yayon" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: yes Subject: pthread and nagios issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 14:45:36 -0000 Hi all, i am upgrading our nagios 1.2 (on freebsd 5.3-release) to nagios 2.0 (currently last cvs after 2.0b3) on Freebsd-5.4RC3 and i saw a very strange thing. After few hours, nagios main process (nagios -d ...) use lot of cpu time and when i do a truss on the pid, i have a "kse_release" loop message. # top last pid: 75729; load averages: 1.81, 2.08, 2.03 63 processes: 2 running, 61 sleeping CPU states: 12.5% user, 0.0% nice, 16.0% system, 0.0% interrupt, 71.5% idle Mem: 36M Active, 1639M Inact, 219M Wired, 68M Cache, 112M Buf, 44M Free Swap: 5000M Total, 52K Used, 5000M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND 40435 nagios 112 0 4688K 3544K CPU0 0 569:46 93.99% 93.99% nagios [...] # truss -p 40435 kse_release(0xbfbf9b70) ERR#22 "Invalid argument" kse_release(0xbfbf9b70) ERR#22 "Invalid argument" kse_release(0xbfbf9b70) ERR#22 "Invalid argument" [...] I know there is a pthread_acquire() issue with Nagios and FreeBSD threads, but is there any patch against this ? Thanks in advance... From owner-freebsd-stable@FreeBSD.ORG Fri May 6 14:48:05 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3378016A4D3 for ; Fri, 6 May 2005 14:48:05 +0000 (GMT) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id E8A8A43D88 for ; Fri, 6 May 2005 14:48:04 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 6A9F664DACE; Fri, 6 May 2005 11:48:04 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 22841-06; Fri, 6 May 2005 14:47:58 +0000 (GMT) Received: from ganymede.hub.org (blk-222-81-172.eastlink.ca [24.222.81.172]) by hub.org (Postfix) with ESMTP id D0ACC64DAC7; Fri, 6 May 2005 11:48:03 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 132E23707C; Fri, 6 May 2005 11:48:03 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 123DF36B54; Fri, 6 May 2005 11:48:03 -0300 (ADT) Date: Fri, 6 May 2005 11:48:03 -0300 (ADT) From: "Marc G. Fournier" To: Erik Stian Tefre In-Reply-To: <1115380664.56321.171.camel@bavian.netlife.no> Message-ID: <20050506114651.Y42300@ganymede.hub.org> References: <20050504160004.B53065@ganymede.hub.org> <1115380664.56321.171.camel@bavian.netlife.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org cc: freebsd-stable@freebsd.org Subject: Re: twa0: INFO: (0x04: 0x000c): Background initialize started: unit=0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 14:48:05 -0000 yOn Fri, 6 May 2005, Erik Stian Tefre wrote: > I believe you should see this message only once after creating a new > array/unit, given that you give the box enough uptime to finish the > initialization. > The following message confirms that the initialization is complete (it > took 4.5 hours on my box with a 9500-8LP, which btw is running 5.3): > twa0: INFO: (0x04: 0x0007): Background initialize done: unit=0 'k, it *had* had 16 days of production uptime before the power outage :( I have seen the 'initalize done' though, so hopefully it doesn't happen again on Saturday when we replace the power strip ... > > On Wed, 2005-05-04 at 16:01 -0300, Marc G. Fournier wrote: >> Running FreeBSD 4.11-STABLE ... >> >> Has anyone seen this before? Only reference on the 'net I can find seems >> to be similar issue on a Dragonfly system: >> >> http://leaf.dragonflybsd.org/mailarchive/bugs/2004-09/msg00176.html >> >> Mine is a 9500-4LP controller ... >> >> ---- >> Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) >> Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 >> _______________________________________________ >> 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" > -- > Erik Stian Tefre > > > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-stable@FreeBSD.ORG Fri May 6 14:52:39 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C9D816A4D3; Fri, 6 May 2005 14:52:39 +0000 (GMT) Received: from hardy-5.tmseck.homedns.org (xdsl-81-173-230-171.netcologne.de [81.173.230.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E2D243D8F; Fri, 6 May 2005 14:52:38 +0000 (GMT) (envelope-from thomas@hardy-5.tmseck.homedns.org) Received: from hardy-5.tmseck.homedns.org (localhost [127.0.0.1]) j46Eqa5u017756; Fri, 6 May 2005 16:52:36 +0200 (CEST) (envelope-from thomas@hardy-5.tmseck.homedns.org) Received: (from thomas@localhost)j46EqZZu017755; Fri, 6 May 2005 16:52:35 +0200 (CEST) (envelope-from thomas) Date: Fri, 6 May 2005 16:52:35 +0200 (CEST) Message-Id: <200505061452.j46EqZZu017755@hardy-5.tmseck.homedns.org> From: tmseck-usenet@netcologne.de (Thomas-Martin Seck) To: freebsd-stable@freebsd.org In-Reply-To: X-Newsgroups: gmane.os.freebsd.stable cc: dwhite@freebsd.org cc: "Alexander S. Usov" Subject: Re: kernel panics in recent RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 14:52:39 -0000 * Alexander S. Usov : > It look that something was broken in the last few days in > RELENG_5 branch. I am getting reproducible panics by pressing > almost any key while system is booting or is in shutdown. > Once it is up -- it works mostly fine. > Also I noted that the keyboard was not working on my laptop > while in the booting phase -- so after I managed to get a second > panic doing fsck, I was unable to do anything in single-user mode. > The only working keys I found were ScrollLock/Pause and > Ctrl-Alt-Del :) Howewer rebooting it with acpi turned off I managed > to get it working. I can probably confirm this. When I boot a RELENG_5 kernel that uses version 1.228.2.4 (committed by dwhite, Cc'ed) of /sys/kern/tty.c, I do not get beyond init's "select shell" prompt. The keyboard attaches properly though and Ctrl-Alt-Del and Scroll Lock do still work, too. Reverting kern/tty.c to 1.228.2.3 does the trick for me. I do not get a panic, fortunately(?). From owner-freebsd-stable@FreeBSD.ORG Fri May 6 14:59:04 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47BDE16A4D3 for ; Fri, 6 May 2005 14:59:04 +0000 (GMT) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87C7943DB4 for ; Fri, 6 May 2005 14:59:03 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 6 May 2005 10:59:02 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id BD68A13641; Fri, 6 May 2005 10:59:02 -0400 (EDT) Date: Fri, 6 May 2005 10:59:02 -0400 From: Ed Maste To: Doug White Message-ID: <20050506145902.GA51724@sandvine.com> References: <20050503115344.S26250@carver.gumbysoft.com> <20050504205315.K40602@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050504205315.K40602@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 06 May 2005 14:59:02.0935 (UTC) FILETIME=[2443EA70:01C5524C] cc: stable@freebsd.org Subject: Re: Experimental ttwwakeup() panic patch X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 14:59:04 -0000 On Wed, May 04, 2005 at 08:54:23PM -0700, Doug White wrote: > > http://people.freebsd.org/~dwhite/tty.c.20050503.patch > > This patch has been committed and exists as rev 1.228.2.4 of > src/sys/kern/tty.c. Please let me know if this fixes the panic for you, > or causes new problems :) For what it's worth, I've come across a similar crash during a test that repeatedly ssh'd into the machine. This was while opening a pty, not using serial console. The symptoms seem similar; my tty struct has a struct knlist with a null struct mtx *. I haven't yet investigated in great detail or tried the patch. I just wanted to offer this as another data point. Although kgdb gets confused during the backtrace (frames 7 and 8) the tf_eip is a cmpxchg in knote(). #5 0xa0737d9e in trap (frame= {tf_fs = -940507112, tf_es = -1604648944, tf_ds = 16, tf_edi = -1539518464, tf_esi = -1554006784, tf_ebp = +-940488284, tf_isp = -940488336, tf_ebx = -1572873216, tf_edx = 0, tf_ecx = -1570261440, tf_eax = 4, tf_trapno = 12, +tf_err = 2, tf_eip = -1604905379, tf_cs = 8, tf_eflags = 66118, tf_esp = -1572873216, tf_ss = -1554006784}) at +/usr/src/sys/i386/i386/trap.c:436 #6 0xa0723d8a in calltrap () at /usr/src/sys/i386/i386/exception.s:202 #7 0xc7f10018 in ?? () #8 0xa05b0010 in power_profile_set_state (state=0) at /usr/src/sys/kern/subr_power.c:110 #9 0xa05c942c in ttwakeup (tp=0xa23fdc00) at /usr/src/sys/kern/tty.c:2370 #10 0xa05c7d71 in ttymodem (tp=0xa23fdc00, flag=0) at /usr/src/sys/kern/tty.c:1625 #11 0xa05cc3cd in ptcopen (dev=0xa35fbd00, flag=3, devtype=8192, td=0x0) at linedisc.h:136 #12 0xa054d06c in spec_open (ap=0xc7f14a70) at /usr/src/sys/fs/specfs/spec_vnops.c:207 #13 0xa054cd44 in spec_vnoperate (ap=0x0) at /usr/src/sys/fs/specfs/spec_vnops.c:118 #14 0xa0601bad in vn_open_cred (ndp=0xc7f14bd8, flagp=0xc7f14cd8, cmode=0, cred=0xa315c500, fdidx=0) at vnode_if.h:228 #15 0xa060175f in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0) at /usr/src/sys/kern/vfs_vnops.c:91 #16 0xa05fa8cd in kern_open (td=0xa267b640, path=0x0, pathseg=UIO_USERSPACE, flags=3, mode=0) at /usr/src/sys/kern/vfs_syscalls.c:957 #17 0xa05fa7c1 in open (td=0x0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:926 #18 0xa07388db in syscall (frame= {tf_fs = 134676527, tf_es = 47, tf_ds = -1614872529, tf_edi = -1, tf_esi = 134724008, tf_ebp = -1614815016, tf_isp += -940487308, tf_ebx = 1745724064, tf_edx = 1745720517, tf_ecx = 1748412300, tf_eax = 5, tf_trapno = 12, tf_err = 2, +tf_eip = 1747892523, tf_cs = 31, tf_eflags = 514, tf_esp = -1614815108, tf_ss = 47}) at +/usr/src/sys/i386/i386/trap.c:1021 #19 0xa0723ddf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:263 -- Ed Maste Sandvine Inc. From owner-freebsd-stable@FreeBSD.ORG Fri May 6 15:00:04 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64EE316A4D3 for ; Fri, 6 May 2005 15:00:04 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1846443D94 for ; Fri, 6 May 2005 15:00:04 +0000 (GMT) (envelope-from bjmccann@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so514585nzo for ; Fri, 06 May 2005 08:00:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pDW3Sxz9nWFB/Q6PpJJcItiujFo/FJ03GBfCKzAS5VL7A9T4yYLxWQwqTAjFPWcmdLlOtYu3zxqeBZ2wKwXqEWXIxeu+Ivt1t3wrnwf7ga6qc3Fl6qYaUPInBQTKn8xGB8mg0z6Nn8v8phcY2AR2elF+5rh00+TsEy9RpAaVcGk= Received: by 10.36.37.10 with SMTP id k10mr604407nzk; Fri, 06 May 2005 08:00:03 -0700 (PDT) Received: by 10.36.47.11 with HTTP; Fri, 6 May 2005 08:00:03 -0700 (PDT) Message-ID: <2b5f066d05050608004d0b10fa@mail.gmail.com> Date: Fri, 6 May 2005 11:00:03 -0400 From: Brian McCann To: Christophe Yayon In-Reply-To: <32899.194.51.215.62.1115390072.squirrel@webmail.nbux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <32899.194.51.215.62.1115390072.squirrel@webmail.nbux.com> cc: freebsd-stable@freebsd.org Subject: Re: pthreads and nagios issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Brian McCann List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 15:00:04 -0000 On 5/6/05, Christophe Yayon wrote: > Hi all, >=20 > i am upgrading our nagios 1.2 (on freebsd 5.3-release) to nagios 2.0 > (currently last cvs after 2.0b3) on Freebsd-5.4RC3 and i saw a very > strange thing. >=20 > After few hours, nagios main process (nagios -d ...) use lot of cpu time > and when i do a truss on the pid, i have a "kse_release" loop message. >=20 > # top > last pid: 75729; load averages: 1.81, 2.08, 2.03 > 63 processes: 2 running, 61 sleeping > CPU states: 12.5% user, 0.0% nice, 16.0% system, 0.0% interrupt, 71.5% = idle > Mem: 36M Active, 1639M Inact, 219M Wired, 68M Cache, 112M Buf, 44M Free > Swap: 5000M Total, 52K Used, 5000M Free >=20 > PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU COMMAND > 40435 nagios 112 0 4688K 3544K CPU0 0 569:46 93.99% 93.99% nagio= s > [...] >=20 > # truss -p 40435 > kse_release(0xbfbf9b70) ERR#22 "Invalid argument= " > kse_release(0xbfbf9b70) ERR#22 "Invalid argument= " > kse_release(0xbfbf9b70) ERR#22 "Invalid argument= " > [...] >=20 > I know there is a pthread_acquire() issue with Nagios and FreeBSD > threads, but is there any patch against this ? >=20 > Thanks in advance... >=20 > _______________________________________________ > 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" >=20 I've got the same issues, as do some people on the nagios-users list.=20 If there is a patch available, the Nagios team still isn't aware of it yet as that is one of the reasons 2.0 is still in beta. --=20 _-=3D-_-=3D-_-=3D-_-=3D-_-=3D-_-=3D-_-=3D-_-=3D-_-=3D-_-=3D-_-=3D-_ Brian McCann Systems & Network Administrator, K12USA "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" From owner-freebsd-stable@FreeBSD.ORG Fri May 6 15:01:25 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50CB816A4D3 for ; Fri, 6 May 2005 15:01:25 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EC9E43DA0 for ; Fri, 6 May 2005 15:01:24 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DU4CW-0004lH-VP for freebsd-stable@freebsd.org; Fri, 06 May 2005 16:53:14 +0200 Received: from kvip88.kvi.nl ([129.125.15.152]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 May 2005 16:53:12 +0200 Received: from A.S.Usov by kvip88.kvi.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 May 2005 16:53:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Alexander S. Usov" Date: Fri, 06 May 2005 16:59:50 +0200 Organization: KVI Lines: 242 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nextPart1259855.P4Rh2qPZoV" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: kvip88.kvi.nl User-Agent: KNode/0.9.0 Sender: news Subject: Re: kernel panics in recent RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 15:01:25 -0000 --nextPart1259855.P4Rh2qPZoV Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8Bit So this panic also exists in RELENG_5_4, and I have managed to get a dump of it. First a few words about the system: uname -a: FreeBSD kvip88.kvi.nl 5.4-RELEASE FreeBSD 5.4-RELEASE #1: Fri May 6 16:03:32 CEST 2005 I did a fresh cvsup/buildworld/buildkernel today. Kernel config is attached below. Panic is 100% reproducible by just pressing any key during boot, and even sometimes on the live system (it happened only once for me, when I pressed a key on vty0, which has no getty running). This specific dump was taken at the very early stage of the boot sequence, just after attaching swap space. Unfortunately unlike in the examples from developers handbook I can't get a panic message back from a dump (is it because I compiled a debugger into the kernel and called panic from there manually?), but stack trace starting from entry 24 corresponds to the one I saw there. PS. Why doadump() refuses to write a 511Mb big dump into 512Mb swap partition? PPS. Do I really need a "option KDB/DDB" in the kernel to get dumps? -- Best regards, Alexander. --nextPart1259855.P4Rh2qPZoV Content-Type: text/plain; name="KVIP88" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="KVIP88" machine i386 cpu I686_CPU options CPU_SUSP_HLT options INCLUDE_CONFIG_FILE ident KVIP88 makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols options KDB options KDB_TRACE options DDB #options PREEMPTION # allows kernel threads preemtion options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem #options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=150 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Add character code conversion support with LIBICONV. options CD9660_ICONV options MSDOSFS_ICONV options LIBICONV # Additionall network options options ALTQ options ALTQ_CBQ # Class Bases Queueing options ALTQ_PRIQ # Priority Queueing options IPDIVERT # divert sockets options IPFIREWALL_DEFAULT_TO_ACCEPT # allow everything by default options FAST_IPSEC # new IPsec (cannot define w/ IPSEC) #options IPSEC # IP security #options IPSEC_ESP # IP security (crypto; define w/ IPSEC) # Bus support. Do not remove isa, even if you have no isa slots device isa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering device atapicam # emulate ATAPI devices as SCSI ditto via CAM # needs CAM to be present (scbus & pass) # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device cd # CD device pass # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_ALT_MOUSE_IMAGE options SC_PIXEL_MODE options VESA device agp # support several AGP chipsets device radeondrm device mgadrm # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm #device cpufreq # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # PCI Ethernet NICs that use the common MII bus controller code. device miibus # MII bus support device bfe # Broadcom BCM440x 10/100 Ethernet device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface #device ehci # EHCI PCI->USB interface device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # FireWire support #device firewire # FireWire bus code #device sbp # SCSI over FireWire (Requires scbus and da) #device fwe # Ethernet over FireWire (non-standard!) # Sound support device sound # The generic sound driver. device snd_ich # Intel ICH PCI and some more audio controllers # embedded in a chipset. # Crypto subsystem device crypto # core crypto support --nextPart1259855.P4Rh2qPZoV Content-Type: text/plain; name="dump.txt" Content-Transfer-Encoding: 8Bit Content-Disposition: attachment; filename="dump.txt" dump.txt usov@kvip88:/sys/i386/compile/KVIP88/ > sd kgdb kernel.debug /var/crash/vmcore.1 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc0515fb9 in boot (howto=260) at ../../../kern/kern_shutdown.c:410 #2 0xc0516679 in panic (fmt=0xc06a2937 "from debugger") at ../../../kern/kern_shutdown.c:566 #3 0xc044779d in db_panic (addr=-1067107782, have_addr=0, count=-1, modif=0xd41dda9c "") at ../../../ddb/db_command.c:435 #4 0xc0447b99 in db_command_loop () at ../../../ddb/db_command.c:349 #5 0xc0449854 in db_trap (type=12, code=0) at ../../../ddb/db_main.c:221 #6 0xc05312aa in kdb_trap (type=0, code=0, tf=0xd41ddc44) at ../../../kern/subr_kdb.c:468 #7 0xc066e29a in trap_fatal (frame=0xd41ddc44, eva=20) at ../../../i386/i386/trap.c:812 #8 0xc066e564 in trap_pfault (frame=0xd41ddc44, usermode=0, eva=20) at ../../../i386/i386/trap.c:735 #9 0xc066e980 in trap (frame= {tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1066188128, tf_esi = 32, tf_ebp = -736240480, tf_isp = -736240528, tf_ebx = -1045637120, tf_edx = 0, tf_ecx = -1066201856, tf_eax = 32, tf_trapno = 12, tf_err = 0, tf_eip = -1067107782, tf_cs = 8, tf_eflags = 66050, tf_esp = 32, tf_ss = -1045637120}) at ../../../i386/i386/trap.c:425 #10 0xc065d23a in calltrap () at ../../../i386/i386/exception.s:140 #11 0x00000018 in ?? () #12 0x00000010 in ?? () #13 0x00000010 in ?? () #14 0xc07342a0 in sc_devclass () #15 0x00000020 in ?? () #16 0xd41ddca0 in ?? () #17 0xd41ddc70 in ?? () #18 0xc1acd800 in ?? () #19 0x00000000 in ?? () #20 0xc0730d00 in kernel_console_ts () #21 0x00000020 in ?? () #22 0x0000000c in ?? () ---Type to continue, or q to quit--- #23 0x00000000 in ?? () #24 0xc0653a3a in sckbdevent (thiskbd=0xc071e0c0, event=0, arg=0xc07342a0) at linedisc.h:122 #25 0xc0644d16 in atkbd_intr (kbd=0xc071e0c0, arg=0x0) at ../../../dev/kbd/atkbd.c:461 #26 0xc0678c11 in atkbd_isa_intr (arg=0x0) at ../../../isa/atkbd_isa.c:177 #27 0xc04fd99d in ithread_loop (arg=0xc197bc80) at ../../../kern/kern_intr.c:547 #28 0xc04fc9d8 in fork_exit (callout=0xc04fd8e6 , arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:791 #29 0xc065d29c in fork_trampoline () at ../../../i386/i386/exception.s:209 (kgdb) --nextPart1259855.P4Rh2qPZoV-- From owner-freebsd-stable@FreeBSD.ORG Fri May 6 15:03:01 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 857E016A4D4 for ; Fri, 6 May 2005 15:03:01 +0000 (GMT) Received: from alogis.com (firewall2.alogis.com [62.8.223.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3820243D1F for ; Fri, 6 May 2005 15:03:00 +0000 (GMT) (envelope-from hk@alogis.com) Received: from alogis.com (localhost [127.0.0.1]) by alogis.com (8.13.1/8.13.1) with ESMTP id j46F2wFC051002 for ; Fri, 6 May 2005 17:02:58 +0200 (CEST) (envelope-from hk@alogis.com) Received: (from hk@localhost) by alogis.com (8.13.1/8.13.1/Submit) id j46F2wik051001 for stable@freebsd.org; Fri, 6 May 2005 17:02:58 +0200 (CEST) (envelope-from hk) Date: Fri, 6 May 2005 17:02:58 +0200 From: Holger Kipp To: stable@freebsd.org Message-ID: <20050506150258.GA50457@intserv.int1.b.intern> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Soundchip C-Media CMI9761 supported? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 15:03:01 -0000 Hi, I can get an ASrock K7Upgrade board with VIA KT880 and 5.1 sound C-Media CMI9761. Is this soundchip supported (at least for the usual stereo sound) under 5.4-STABLE? I couldn't find any information about this. Regards, Holger Kipp From owner-freebsd-stable@FreeBSD.ORG Fri May 6 15:07:35 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7688616A552 for ; Fri, 6 May 2005 15:07:35 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 343F643D75 for ; Fri, 6 May 2005 15:07:35 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DU4J2-00067Z-Tb for freebsd-stable@freebsd.org; Fri, 06 May 2005 16:59:56 +0200 Received: from kvip88.kvi.nl ([129.125.15.152]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 May 2005 16:59:56 +0200 Received: from A.S.Usov by kvip88.kvi.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 May 2005 16:59:56 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Alexander S. Usov" Date: Fri, 06 May 2005 17:05:47 +0200 Organization: KVI Lines: 32 Message-ID: References: <200505061452.j46EqZZu017755@hardy-5.tmseck.homedns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: kvip88.kvi.nl User-Agent: KNode/0.9.0 Sender: news Subject: Re: kernel panics in recent RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 15:07:35 -0000 Thomas-Martin Seck wrote: > * Alexander S. Usov : > >> It look that something was broken in the last few days in >> RELENG_5 branch. I am getting reproducible panics by pressing >> almost any key while system is booting or is in shutdown. >> Once it is up -- it works mostly fine. >> Also I noted that the keyboard was not working on my laptop >> while in the booting phase -- so after I managed to get a second >> panic doing fsck, I was unable to do anything in single-user mode. >> The only working keys I found were ScrollLock/Pause and >> Ctrl-Alt-Del :) Howewer rebooting it with acpi turned off I managed >> to get it working. > > I can probably confirm this. When I boot a RELENG_5 kernel that uses > version 1.228.2.4 (committed by dwhite, Cc'ed) of /sys/kern/tty.c, I do > not get beyond init's "select shell" prompt. The keyboard attaches > properly though and Ctrl-Alt-Del and Scroll Lock do still work, too. I my case I got it working by booting with ACPI off. > Reverting kern/tty.c to 1.228.2.3 does the trick for me. > > I do not get a panic, fortunately(?). I am getting panic by pressing a key when nobody listens the terminal. I have just submitted a trace. -- Best regards, Alexander. From owner-freebsd-stable@FreeBSD.ORG Fri May 6 15:37:20 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AE6316A4D5 for ; Fri, 6 May 2005 15:37:20 +0000 (GMT) Received: from opus.cse.buffalo.edu (opus.cse.Buffalo.EDU [128.205.32.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F0FE43D99 for ; Fri, 6 May 2005 15:37:20 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from opus.cse.buffalo.edu (opus.cse.buffalo.edu [128.205.32.4]) by opus.cse.buffalo.edu (8.13.3/8.12.10) with ESMTP id j46FbJHN001166 for ; Fri, 6 May 2005 11:37:19 -0400 (EDT) From: Ken Smith To: freebsd-stable@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TI0eMBdQh694RMvBmP6p" Organization: U. Buffalo CSE Department Date: Fri, 06 May 2005 11:37:19 -0400 Message-Id: <1115393839.747.23.camel@opus.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Subject: HEADS-UP: Problem with RELENG_5{_4} X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 15:37:20 -0000 --=-TI0eMBdQh694RMvBmP6p Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Looks like there are problems with the recent patch to fix tty panics. It seems to cause loss of keyboard input during the boot-up phase, including the point where it asks for what shell to use if you try booting to single-user. We'll fix it asap, but in the meantime be very careful with RELENG_5 and RELENG_5_4 machines. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-TI0eMBdQh694RMvBmP6p Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCe48v/G14VSmup/YRAnQJAJsGq+yKAJDV41W/BnOsTubZvGYJngCcCl9/ iRbsOWKtxjfe3BPIMF0E0to= =197M -----END PGP SIGNATURE----- --=-TI0eMBdQh694RMvBmP6p-- From owner-freebsd-stable@FreeBSD.ORG Fri May 6 15:50:25 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BEBF16A4D4; Fri, 6 May 2005 15:50:25 +0000 (GMT) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id B818843D9A; Fri, 6 May 2005 15:50:24 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix3-1.free.fr (Postfix) with ESMTP id A7A2B173527; Fri, 6 May 2005 17:50:23 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.0/8.13.0) with ESMTP id j46FoIxJ025927; Fri, 6 May 2005 17:50:20 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Date: Fri, 6 May 2005 17:50:10 +0200 User-Agent: KMail/1.8 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200505061750.11793.thierry@herbelot.com> Subject: loss of keyboard in single-user mode in RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: thierry@herbelot.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 15:50:25 -0000 Hello, I have rebuilt the world and kernel this morning. After rebooting with the new kernel, I have selected Single user in the loader boot menu, but the keyboard is not active. The machine is an Asus A7V333 machine, running with ACPI. The new kernel does not boot without ACPI (it goes directly to a page fault after prompting for a /bin/sh shell). Interesting files : - truncated verbose boot dmesg with the working kernel : http://herbelot.tfh.free.fr/Diversion/div.dmesg-verb.good - truncated verbose boot dmesg of the non-working kernel : http://herbelot.tfh.free.fr/Diversion/div.dmesg-verb.bug - non-truncated non-verbose boot dmesg of the working kernel : http://herbelot.tfh.free.fr/Diversion/div.dmesg.good2 - ident strings of the working kernel : http://herbelot.tfh.free.fr/Diversion/div.kern.ident.good - ident strings of the non-working kernel : http://herbelot.tfh.free.fr/Diversion/div.kern.ident.bug - ident strings of the modified sources between the two kernels : http://herbelot.tfh.free.fr/Diversion/div.kern.ident.diff² - kernel config file : http://herbelot.tfh.free.fr/Diversion/DIVERSION For now, the machine runs with the old kernel and the new world TfH From owner-freebsd-stable@FreeBSD.ORG Fri May 6 16:02:43 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D3EF16A4D4; Fri, 6 May 2005 16:02:43 +0000 (GMT) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DDDF43D94; Fri, 6 May 2005 16:02:43 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1DU5Hl-00085T-00; Fri, 06 May 2005 18:02:41 +0200 Date: Fri, 6 May 2005 18:02:40 +0200 To: Thierry Herbelot Message-ID: <20050506160240.GH21800@poupinou.org> References: <200505061750.11793.thierry@herbelot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200505061750.11793.thierry@herbelot.com> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot cc: freebsd-current@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: loss of keyboard in single-user mode in RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 16:02:43 -0000 On Fri, May 06, 2005 at 05:50:10PM +0200, Thierry Herbelot wrote: > - ident strings of the modified sources between the two kernels : > http://herbelot.tfh.free.fr/Diversion/div.kern.ident.diff² I can't get that one. Could you please rename it? -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-stable@FreeBSD.ORG Fri May 6 16:20:18 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88FBA16A4D4 for ; Fri, 6 May 2005 16:20:18 +0000 (GMT) Received: from mail.starlofashions.com (mail.starlofashions.com [12.44.50.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF6B543DA1 for ; Fri, 6 May 2005 16:20:17 +0000 (GMT) (envelope-from scottro@nyc.rr.com) Received: from uws1.starlofashions.com ([192.168.8.230]) by mail.starlofashions.com (8.9.3/8.9.3) with SMTP id MAA23760 for ; Fri, 6 May 2005 12:20:16 -0400 Received: by uws1.starlofashions.com (sSMTP sendmail emulation); Fri, 6 May 2005 12:20:16 -0400 Date: Fri, 6 May 2005 12:20:16 -0400 From: Scott Robbins To: freebsd-stable@freebsd.org Message-ID: <20050506162016.GA16808@uws1.starlofashions.com> Mail-Followup-To: freebsd-stable@freebsd.org References: <200505061452.j46EqZZu017755@hardy-5.tmseck.homedns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Subject: Re: kernel panics in recent RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 16:20:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, May 06, 2005 at 05:05:47PM +0200, Alexander S. Usov wrote: > Thomas-Martin Seck wrote: > > > * Alexander S. Usov : > > > >> It look that something was broken in the last few days in > >> RELENG_5 branch. I am getting reproducible panics by pressing > >> almost any key while system is booting or is in shutdown. > >> Once it is up -- it works mostly fine. > >> Also I noted that the keyboard was not working on my laptop > >> while in the booting phase -- so after I managed to get a second > >> panic doing fsck, I was unable to do anything in single-user mode. > >> The only working keys I found were ScrollLock/Pause and > >> Ctrl-Alt-Del :) Howewer rebooting it with acpi turned off I managed > >> to get it working. I can confirm this part. A moderately vanilla Gateway machine, when upgraded this morning, would not respond in single user mode. It did respond to ctl+alt+del, I rebooted into normal mode to finish with installworld and mergemaster. I tried again rebooting into single user mode with the same result, no keyboard response save for ctl+alt+del. (No RAID, no SCSI, just a workstation. I can post my kernel config if it will help, but the only things that are even a bit out of the ordinary are that I have SCHED_ULE and PREEMPTION.) - -- Scott Robbins GPG KeyID EB3467D6 ( 1B848 077D 66F6 9DB0 FDC2 A409 FA54 D575 EB34 67D6) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Maggie Walsh: We use the latest in scientific technology and state-of-the-art weaponry, and you, if I understand correctly, poke them with a sharp stick. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCe5lA+lTVdes0Z9YRAqfFAKC6fdiD1pPQ2An55pSuqtvOaPIixgCgkvUC nnD/1XEKjNQRwgLvIWB4BdY= =DzyL -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri May 6 16:25:05 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D52DA16A4D4; Fri, 6 May 2005 16:25:05 +0000 (GMT) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A0CF43D2F; Fri, 6 May 2005 16:25:05 +0000 (GMT) (envelope-from thierry@herbelot.com) Received: from herbelot.dyndns.org (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by postfix4-2.free.fr (Postfix) with ESMTP id E49C5319296; Fri, 6 May 2005 18:25:04 +0200 (CEST) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by herbelot.dyndns.org (8.13.0/8.13.0) with ESMTP id j46GOQbx002571; Fri, 6 May 2005 18:24:28 +0200 (CEST) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Fri, 6 May 2005 18:24:18 +0200 User-Agent: KMail/1.8 References: <200505061750.11793.thierry@herbelot.com> <20050506160240.GH21800@poupinou.org> In-Reply-To: <20050506160240.GH21800@poupinou.org> X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200505061824.19708.thierry@herbelot.com> cc: Bruno Ducrot cc: freebsd-stable@freebsd.org Subject: Re: loss of keyboard in single-user mode in RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: thierry@herbelot.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 16:25:06 -0000 Le Friday 6 May 2005 18:02, Bruno Ducrot a écrit : > On Fri, May 06, 2005 at 05:50:10PM +0200, Thierry Herbelot wrote: > > - ident strings of the modified sources between the two kernels : > > http://herbelot.tfh.free.fr/Diversion/div.kern.ident.diff² > > I can't get that one. Could you please rename it? of course : http://herbelot.tfh.free.fr/Diversion/div.kern.ident.diff if you can think of any other info to submit ... TfH From owner-freebsd-stable@FreeBSD.ORG Fri May 6 16:45:56 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DBA616A4D4 for ; Fri, 6 May 2005 16:45:56 +0000 (GMT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 852C343D60 for ; Fri, 6 May 2005 16:45:55 +0000 (GMT) (envelope-from "cyb."@gmx.net) Received: (qmail invoked by alias); 06 May 2005 16:45:54 -0000 Received: from pD9E28D01.dip0.t-ipconnect.de (EHLO localhost.localdomain) [217.226.141.1] by mail.gmx.net (mp012) with SMTP; 06 May 2005 18:45:54 +0200 X-Authenticated: #4870692 From: Andreas Rudisch <"cyb."@gmx.net> To: thierry@herbelot.com In-Reply-To: <200505061824.19708.thierry@herbelot.com> References: <200505061750.11793.thierry@herbelot.com> <20050506160240.GH21800@poupinou.org> <200505061824.19708.thierry@herbelot.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1ziutoBBrxbso5CNQWcq" Date: Fri, 06 May 2005 18:45:51 +0200 Message-Id: <1115397951.545.2.camel@p4-3200.local> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port X-Y-GMX-Trusted: 0 cc: freebsd-stable@freebsd.org Subject: Re: loss of keyboard in single-user mode in RELENG_5 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 16:45:56 -0000 --=-1ziutoBBrxbso5CNQWcq Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2005-05-06 at 18:24 +0200, Thierry Herbelot wrote: > if you can think of any other info to submit ... >=20 > TfH Take a look at this: Subject: HEADS-UP: Problem with RELENG_5{_4} Date:=20 Fri, 06 May 2005 11:37:19 -0400 (17:37 CEST) Looks like there are problems with the recent patch to fix tty panics. It seems to cause loss of keyboard input during the boot-up phase, including the point where it asks for what shell to use if you try booting to single-user. We'll fix it asap, but in the meantime be very careful with RELENG_5 and RELENG_5_4 machines. --=20 Ken Smith --=20 GnuPG key : 0xD25FCC81 | http://cyb.websimplex.de/pubkey.asc Fingerprint: D182 6F22 7EEC DD4C 0F6E 564C 691B 0372 D25F CC81 --=-1ziutoBBrxbso5CNQWcq Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCe58/aRsDctJfzIERAopjAJ9HcV25rDoYk0SglZuIYXc5ecG4qgCfT6v2 IE3hoIGaCkXtFXP6cjx927A= =HG+f -----END PGP SIGNATURE----- --=-1ziutoBBrxbso5CNQWcq-- From owner-freebsd-stable@FreeBSD.ORG Fri May 6 17:39:40 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 352BB16A4D4 for ; Fri, 6 May 2005 17:39:40 +0000 (GMT) Received: from discordia.pl (discordia.pl [212.160.154.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB55543D8E for ; Fri, 6 May 2005 17:39:39 +0000 (GMT) (envelope-from toread@discordia.pl) Received: from localhost (localhost.pl [127.0.0.1]) by discordia.pl (Postfix) with ESMTP id C59AE20B420 for ; Fri, 6 May 2005 19:39:38 +0200 (CEST) Received: from discordia.pl ([127.0.0.1]) by localhost (discordia.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05264-03 for ; Fri, 6 May 2005 19:39:29 +0200 (CEST) Received: by discordia.pl (Postfix, from userid 1001) id A3B0520B415; Fri, 6 May 2005 19:39:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by discordia.pl (Postfix) with ESMTP id 9D89B20B40F for ; Fri, 6 May 2005 19:39:29 +0200 (CEST) Date: Fri, 6 May 2005 19:39:29 +0200 (CEST) From: Piotr Gnyp To: stable@freebsd.org In-Reply-To: <20050506152346.E23993@discordia.pl> Message-ID: <20050506193639.M1058@discordia.pl> References: <20050506152346.E23993@discordia.pl> X-PGP-Key: http://discordia.pl/~toread/pub.txt Organization: The Golden Apple Corp MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at discordia.pl Subject: Re: Kernel panic: kmem_map too small X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 17:39:40 -0000 On Fri, 6 May 2005, Piotr Gnyp wrote: > panic message: > savecore: reboot after panic: kmem_malloc(45056): kmem > _map too small: 334680064 total allocated Ok, I`ve found: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/book.html#KMEM-MAP-TOO-SMALL > when i try to do kgdb i get this: > kgdb: cannot read PTD But I still don`t know what this means... Kernel is configured with -g acpi is disabled... -- "How fortunate the man with none." --Dead Can Dance From owner-freebsd-stable@FreeBSD.ORG Fri May 6 17:52:31 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEBAC16A4D4 for ; Fri, 6 May 2005 17:52:31 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AF2343D53 for ; Fri, 6 May 2005 17:52:31 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j46HqUXF031305; Fri, 6 May 2005 12:52:30 -0500 (CDT) (envelope-from dan) Date: Fri, 6 May 2005 12:52:30 -0500 From: Dan Nelson To: Christophe Yayon Message-ID: <20050506175230.GF49336@dan.emsphone.com> References: <32899.194.51.215.62.1115390072.squirrel@webmail.nbux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32899.194.51.215.62.1115390072.squirrel@webmail.nbux.com> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: freebsd-stable@freebsd.org Subject: Re: pthreads and nagios issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 17:52:32 -0000 In the last episode (May 06), Christophe Yayon said: > i am upgrading our nagios 1.2 (on freebsd 5.3-release) to nagios 2.0 > (currently last cvs after 2.0b3) on Freebsd-5.4RC3 and i saw a very > strange thing. > > After few hours, nagios main process (nagios -d ...) use lot of cpu > time and when i do a truss on the pid, i have a "kse_release" loop > message. Truss hasn't been updated to handle kse or thr threads yet, so don't rely on that output. ktrace shouldl still work, as will using gcore and gdb to get stack traces. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Fri May 6 18:14:49 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08F0316A4D4 for ; Fri, 6 May 2005 18:14:49 +0000 (GMT) Received: from dswu26.btconnect.com (dswu26.btconnect.com [193.113.154.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 34BFF43D6D for ; Fri, 6 May 2005 18:14:48 +0000 (GMT) (envelope-from alan@cyclopsvision.co.uk) Received: from AJDELL9200 (actually host 11.249.3.62.in-addr.arpa) by dswu26.btconnect.com with SMTP (XT-PP) with ESMTP; Fri, 6 May 2005 19:14:44 +0100 From: "Alan Jay" To: Date: Fri, 6 May 2005 19:14:43 +0100 Organization: Cyclops Vision Limited MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcVSM3Y2mCu7S/3RQRid40pY6u7A0AAM0Mew In-Reply-To: <20050506120055.D55C616A507@hub.freebsd.org> Message-Id: <20050506181448.34BFF43D6D@mx1.FreeBSD.org> Subject: problems with setting kern.maxdsiz in /boot/loader.conf X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: alan@cyclopsvision.co.uk List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 18:14:49 -0000 I am running 5.4 RC4 and rebooted today after changing one of the boot-time variables (maximum data size) in /boot/loader.conf. I took it from 512MB to 2GB of RAM in order to improve the MySQL performance on the server. However, upon reboot, the following error comes up: Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x58:0x8bc stack pointer = 0x10:0xf80 frame pointer = 0x10:0x0 code segment = base 0xc00f0000, limit 0xffff, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) trap number = 9 panic: general protection fault cpuid = 0 Uptime: 1s I tried resetting kern.maxdsiz backto 512MB by pressing 6 at the boot menu and doing: unset kern.maxdsiz set kern.maxdsiz=536870912 show kern.maxdsiz - this did not have any effect - exactly the same thing happened again. Is the kern.maxdsiz now being reset or being reset by /boot/loader.conf after changing things in the loader does anyone have any ideas. Nothing else has changed on the server which is being prepared for use at the moment and was updated to 5.4 RC4 just a few days ago but which has been running fine and rebooting fine since then until this change. Any ideas? Thanks in advance Alan PS I assume the only way to remove /boot/loader.conf is to use the 2nd CD set in fixit mode and remove / edit the file after mounting the root partition. From owner-freebsd-stable@FreeBSD.ORG Fri May 6 19:02:52 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21E6E16A4D4 for ; Fri, 6 May 2005 19:02:52 +0000 (GMT) Received: from smtp14.wanadoo.fr (smtp14.wanadoo.fr [193.252.23.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E2FF43D31 for ; Fri, 6 May 2005 19:02:50 +0000 (GMT) (envelope-from lists@nbux.com) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1409.wanadoo.fr (SMTP Server) with ESMTP id 57F587000096 for ; Fri, 6 May 2005 21:02:49 +0200 (CEST) Received: from daneel.nbux.com (LNeuilly-152_22-15-131.w82-127.abo.wanadoo.fr [82.127.94.131]) by mwinf1409.wanadoo.fr (SMTP Server) with ESMTP id 266AE70000B9; Fri, 6 May 2005 21:02:48 +0200 (CEST) X-ME-UUID: 20050506190249157.266AE70000B9@mwinf1409.wanadoo.fr Received: from webmail.nbux.com (daneel.nbux.com [192.168.42.2]) by daneel.nbux.com (Postfix) with ESMTP id 1B3D37F494; Fri, 6 May 2005 21:02:46 +0200 (CEST) Message-ID: <50660.192.168.0.20.1115406166.squirrel@webmail.nbux.com> In-Reply-To: <2b5f066d05050608004d0b10fa@mail.gmail.com> References: <32899.194.51.215.62.1115390072.squirrel@webmail.nbux.com> <2b5f066d05050608004d0b10fa@mail.gmail.com> Date: Fri, 6 May 2005 21:02:46 +0200 (CEST) From: "Christophe Yayon" To: "Brian McCann" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: yes cc: freebsd-stable@freebsd.org cc: Christophe Yayon Subject: Re: pthreads and nagios issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 19:02:52 -0000 Hi, But is it a Nagios or FreeBSD problem, if you read "what's new" section on nagios site, you can see : ----------------- FreeBSD and threads. On FreeBSD there's a native user-level implementation of threads called 'pthread' and there's also an optional ports collection 'linuxthreads' that uses kernel hooks. Some folks from Yahoo! have reported that using the pthread library causes Nagios to pause under heavy I/O load, causing some service check results to be lost. Switching to linuxthreads seems to help this problem, but not fix it. The lock happens in liblthread's __pthread_acquire() - it can't ever acquire the spinlock. It happens when the main thread forks to execute an active check. On the second fork to create the grandchild, the grandchild is created by fork, but never returns from liblthread's fork wrapper, because it's stuck in __pthread_acquire(). Maybe some FreeBSD users can help out with this problem. ------------------ And it appears to be a FreeBSD pthread implementation problem (not a Nagios specific problem...) What do u think about that ? > On 5/6/05, Christophe Yayon wrote: >> Hi all, >> >> i am upgrading our nagios 1.2 (on freebsd 5.3-release) to nagios 2.0 >> (currently last cvs after 2.0b3) on Freebsd-5.4RC3 and i saw a very >> strange thing. >> >> After few hours, nagios main process (nagios -d ...) use lot of cpu time >> and when i do a truss on the pid, i have a "kse_release" loop message. >> >> # top >> last pid: 75729; load averages: 1.81, 2.08, 2.03 >> 63 processes: 2 running, 61 sleeping >> CPU states: 12.5% user, 0.0% nice, 16.0% system, 0.0% interrupt, 71.5% >> idle >> Mem: 36M Active, 1639M Inact, 219M Wired, 68M Cache, 112M Buf, 44M Free >> Swap: 5000M Total, 52K Used, 5000M Free >> >> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU CPU >> COMMAND >> 40435 nagios 112 0 4688K 3544K CPU0 0 569:46 93.99% 93.99% >> nagios >> [...] >> >> # truss -p 40435 >> kse_release(0xbfbf9b70) ERR#22 "Invalid >> argument" >> kse_release(0xbfbf9b70) ERR#22 "Invalid >> argument" >> kse_release(0xbfbf9b70) ERR#22 "Invalid >> argument" >> [...] >> >> I know there is a pthread_acquire() issue with Nagios and FreeBSD >> threads, but is there any patch against this ? >> >> Thanks in advance... >> >> _______________________________________________ >> 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" >> > > I've got the same issues, as do some people on the nagios-users list. > If there is a patch available, the Nagios team still isn't aware of it > yet as that is one of the reasons 2.0 is still in beta. > > -- > _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ > Brian McCann > Systems & Network Administrator, K12USA > > "I don't have to take this abuse from you -- I've got hundreds of > people waiting to abuse me." > -- Bill Murray, "Ghostbusters" > ----- > This mail has been scanned. > From owner-freebsd-stable@FreeBSD.ORG Fri May 6 19:09:50 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9630816A4D4 for ; Fri, 6 May 2005 19:09:50 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EE8D43D67 for ; Fri, 6 May 2005 19:09:50 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j46J9nPr002264; Fri, 6 May 2005 15:09:49 -0400 (EDT) Date: Fri, 6 May 2005 15:09:49 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Christophe Yayon In-Reply-To: <50660.192.168.0.20.1115406166.squirrel@webmail.nbux.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: Brian McCann cc: freebsd-stable@freebsd.org Subject: Re: pthreads and nagios issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 19:09:50 -0000 On Fri, 6 May 2005, Christophe Yayon wrote: > Hi, > > But is it a Nagios or FreeBSD problem, if you read "what's new" section on > nagios site, you can see : > ----------------- > FreeBSD and threads. On FreeBSD there's a native user-level implementation > of threads called 'pthread' and there's also an optional ports collection > 'linuxthreads' that uses kernel hooks. Some folks from Yahoo! have > reported that using the pthread library causes Nagios to pause under heavy > I/O load, causing some service check results to be lost. Switching to > linuxthreads seems to help this problem, but not fix it. The lock happens > in liblthread's __pthread_acquire() - it can't ever acquire the spinlock. > It happens when the main thread forks to execute an active check. On the > second fork to create the grandchild, the grandchild is created by fork, > but never returns from liblthread's fork wrapper, because it's stuck in > __pthread_acquire(). Maybe some FreeBSD users can help out with this > problem. > ------------------ > And it appears to be a FreeBSD pthread implementation problem (not a > Nagios specific problem...) > What do u think about that ? Re-read what is written above. __pthread_acquire() is in liblthread; that is linuxthreads and not a POSIX function. The reported FreeBSD pthread problem above is a "pause under heavy I/O load...". I'm not sure what could cause that -- need more info. -- DE From owner-freebsd-stable@FreeBSD.ORG Fri May 6 19:32:21 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B943016A4D4 for ; Fri, 6 May 2005 19:32:21 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E44643D1D for ; Fri, 6 May 2005 19:32:21 +0000 (GMT) (envelope-from justame@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so991122nzf for ; Fri, 06 May 2005 12:32:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mupTE3GEzXsJ8DBq5vGVN8xTUUzLDguwV8hhi/H95mibCLzr+w951XbzFa2q/Qqxd7Orh9R8Kn1CNNTWGIudkOYydgOFbu3azh1Wl2dHV9tCZgVM/g7eUOoTutnQp8WNOnM2uEQpyBEq8Nh6Z1Ae32/EYpAXSVT203EkeVXFWU8= Received: by 10.36.68.11 with SMTP id q11mr825368nza; Fri, 06 May 2005 12:32:21 -0700 (PDT) Received: by 10.36.77.1 with HTTP; Fri, 6 May 2005 12:32:21 -0700 (PDT) Message-ID: <51ca7efe050506123211737b8e@mail.gmail.com> Date: Fri, 6 May 2005 21:32:21 +0200 From: just me To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: How do i enable DRI support in Xorg? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: just me List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 19:32:21 -0000 i read in some web-sites how to enable dri support for XFree86 server, but for xorg i didn't find. i'm using FreeBSD 5.3=20 and my video card is : S3 ProsavageDDR I basically followed after the instructions in the here : http://people.freebsd.org/~anholt/dri/ and still didn't succeed,any suggestions ? From owner-freebsd-stable@FreeBSD.ORG Fri May 6 22:03:03 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 439F216A4D4 for ; Fri, 6 May 2005 22:03:03 +0000 (GMT) Received: from ns1.onsitepcs.net (mail.onsitepcs.net [71.32.223.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92FEC43DAB for ; Fri, 6 May 2005 22:03:00 +0000 (GMT) (envelope-from jaimie@onsitepcs.net) Received: from ns1.onsitepcs.net (localhost.localdomain [127.0.0.1]) by ns1.onsitepcs.net (8.13.1/8.13.1) with ESMTP id j46M2lS6027313 for ; Fri, 6 May 2005 15:02:47 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by ns1.onsitepcs.net (8.13.1/8.13.1/Submit) id j46M2kBf027312 for freebsd-stable@freebsd.org; Fri, 6 May 2005 15:02:46 -0700 X-Authentication-Warning: ns1.onsitepcs.net: jaimie set sender to jaimie@onsitepcs.net using -f From: Jaimie Garner Organization: Onsite PCS inc. To: freebsd-stable@freebsd.org Date: Fri, 6 May 2005 15:02:45 -0700 User-Agent: KMail/1.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505061502.45569.jaimie@onsitepcs.net> Subject: Re: How do i enable DRI support in Xorg? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 22:03:03 -0000 Go here http://dri.freedesktop.org/wiki/Building this helped me to build Xorg + Mesa and DRI for ATI Radeon on a custome built linux system. Should not be to far off for FreeBSD. -- Jaimie Garner Onsite PCS inc. 323 SE RIverside AV Grants Pass, OR 97526 541.471.1343 866.471.1343 jaimie@onsitepcs.net www.onistepcs.net On Friday 06 May 2005 12:32 pm, just me wrote: > i read in some web-sites how to enable dri support for XFree86 server, > but for xorg i didn't find. > i'm using FreeBSD 5.3 > and my video card is : S3 ProsavageDDR > I basically followed after the instructions in the here : > http://people.freebsd.org/~anholt/dri/ > and still didn't succeed,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" From owner-freebsd-stable@FreeBSD.ORG Fri May 6 22:16:22 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A64616A4D4 for ; Fri, 6 May 2005 22:16:22 +0000 (GMT) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0A1943D7B for ; Fri, 6 May 2005 22:16:21 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from drjekyll.mkbuelow.net (p54AABA79.dip.t-dialin.net [84.170.186.121]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 215E02E8D8; Sat, 7 May 2005 00:16:19 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j46MHLE7004244; Sat, 7 May 2005 00:17:21 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Received: (from mkb@localhost) by drjekyll.mkbuelow.net (8.13.3/8.13.3/Submit) id j46MHLV2004243; Sat, 7 May 2005 00:17:21 +0200 (CEST) (envelope-from mkb) Date: Sat, 7 May 2005 00:17:20 +0200 From: Matthias Buelow To: Jaimie Garner Message-ID: <20050506221720.GA1162@drjekyll.mkbuelow.net> References: <200505061502.45569.jaimie@onsitepcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505061502.45569.jaimie@onsitepcs.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-stable@freebsd.org Subject: Re: How do i enable DRI support in Xorg? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 22:16:22 -0000 Jaimie Garner wrote: > >Go here http://dri.freedesktop.org/wiki/Building this helped me to build Xorg >+ Mesa and DRI for ATI Radeon on a custome built linux system. Should not be >to far off for FreeBSD. The OP does not have to build Xorg manually. The ports system already does this, and his video chipset is old enough to be supported by the latest release Xorg (if it isn't, then a CVS Xorg won't help.) The OP could post the error messages pertaining to DRI (from /var/log/Xorg.0.log) plus the output from "xdriinfo" and "kldstat". mkb. From owner-freebsd-stable@FreeBSD.ORG Fri May 6 22:24:32 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E868216A4D4 for ; Fri, 6 May 2005 22:24:32 +0000 (GMT) Received: from ns1.onsitepcs.net (mail.onsitepcs.net [71.32.223.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59AE643D62 for ; Fri, 6 May 2005 22:24:32 +0000 (GMT) (envelope-from jaimie@onsitepcs.net) Received: from ns1.onsitepcs.net (localhost.localdomain [127.0.0.1]) by ns1.onsitepcs.net (8.13.1/8.13.1) with ESMTP id j46MOJMZ027540 for ; Fri, 6 May 2005 15:24:19 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by ns1.onsitepcs.net (8.13.1/8.13.1/Submit) id j46MOIhI027539 for freebsd-stable@freebsd.org; Fri, 6 May 2005 15:24:18 -0700 X-Authentication-Warning: ns1.onsitepcs.net: jaimie set sender to jaimie@onsitepcs.net using -f From: Jaimie Garner Organization: Onsite PCS inc. To: freebsd-stable@freebsd.org Date: Fri, 6 May 2005 15:24:18 -0700 User-Agent: KMail/1.7.1 References: <200505061502.45569.jaimie@onsitepcs.net> <20050506221720.GA1162@drjekyll.mkbuelow.net> In-Reply-To: <20050506221720.GA1162@drjekyll.mkbuelow.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505061524.18324.jaimie@onsitepcs.net> Subject: Re: How do i enable DRI support in Xorg? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 22:24:33 -0000 I asumed it would just gave em a link to shed some light on how I did it with Linux. I havent ran X on FreeBSD. On Friday 06 May 2005 3:17 pm, Matthias Buelow wrote: > Jaimie Garner wrote: > >Go here http://dri.freedesktop.org/wiki/Building this helped me to build > > Xorg + Mesa and DRI for ATI Radeon on a custome built linux system. > > Should not be to far off for FreeBSD. > > The OP does not have to build Xorg manually. The ports system > already does this, and his video chipset is old enough to be supported > by the latest release Xorg (if it isn't, then a CVS Xorg won't help.) > > The OP could post the error messages pertaining to DRI > (from /var/log/Xorg.0.log) plus the output from "xdriinfo" > and "kldstat". > > mkb. > _______________________________________________ > 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" -- Jaimie Garner Onsite PCS inc. 323 SE RIverside AV Grants Pass, OR 97526 541.471.1343 866.471.1343 jaimie@onsitepcs.net www.onistepcs.net From owner-freebsd-stable@FreeBSD.ORG Fri May 6 22:40:27 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0F7F16A4D4 for ; Fri, 6 May 2005 22:40:27 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59F3F43DBF for ; Fri, 6 May 2005 22:40:27 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from ranger.anduin.net ([81.0.162.52] helo=[192.168.1.110]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DUBUe-000Ncd-VU for stable@freebsd.org; Sat, 07 May 2005 00:40:26 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 07 May 2005 00:39:21 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: "stable@freebsd.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: unionfs limitations? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 22:40:28 -0000 Hi, I just started playing with mounting ports into jails using unionfs (mount_unionfs -b /usr/ports_jail /usr/local/jails/jail-0/usr/ports), and many things seem to work fine. However, when trying to install either of mysql41-server or mysql41-client, I see the following: [root@mpi1] /usr/ports/databases/mysql41-server# make install ===> Installing for mysql-server-4.1.11_1 ===> mysql-server-4.1.11_1 depends on shared library: mysqlclient.14 - found ===> Generating temporary packing list ===> Checking if databases/mysql41-server already installed ln: POSIX: Operation not supported *** Error code 1 Stop in /usr/ports/databases/mysql41-server. Did I miss out on something, or is this not going to work? Do I need to think in other ways? I have stress-tested this setup pretty well over the last 24 hours, with as many as 20 mountpoints using the same ports tree, with constant package building in each of them. This was impossible last time I played with unionfs, so it must have stabilized somewhat ;) Anyone? /Eirik From owner-freebsd-stable@FreeBSD.ORG Fri May 6 23:59:02 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14AF116A4D4 for ; Fri, 6 May 2005 23:59:02 +0000 (GMT) Received: from ns1.onsitepcs.net (mail.onsitepcs.net [71.32.223.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4C5A43D91 for ; Fri, 6 May 2005 23:59:01 +0000 (GMT) (envelope-from jaimie@onsitepcs.net) Received: from ns1.onsitepcs.net (localhost.localdomain [127.0.0.1]) by ns1.onsitepcs.net (8.13.1/8.13.1) with ESMTP id j46NwmaW028562 for ; Fri, 6 May 2005 16:58:49 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by ns1.onsitepcs.net (8.13.1/8.13.1/Submit) id j46NwlDn028561 for freebsd-stable@freebsd.org; Fri, 6 May 2005 16:58:47 -0700 X-Authentication-Warning: ns1.onsitepcs.net: jaimie set sender to jaimie@onsitepcs.net using -f From: Jaimie Garner Organization: Onsite PCS inc. Date: Fri, 6 May 2005 16:58:47 -0700 User-Agent: KMail/1.7.1 To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505061658.47445.jaimie@onsitepcs.net> Subject: Re: How do i enable DRI support in Xorg? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 06 May 2005 23:59:02 -0000 You should just load it from the xorg.conf file as I remember. like this Section "Files" RgbPath "/usr/X11R6/lib/X11/rgb" ModulePath "/usr/X11R6/lib/modules" FontPath "/usr/X11R6/lib/X11/fonts/misc/" FontPath "/usr/X11R6/lib/X11/fonts/TTF/" FontPath "/usr/X11R6/lib/X11/fonts/Type1/" FontPath "/usr/X11R6/lib/X11/fonts/CID/" FontPath "/usr/X11R6/lib/X11/fonts/75dpi/" FontPath "/usr/X11R6/lib/X11/fonts/100dpi/" EndSection Section "Module" Load "extmod" Load "glx" Load "dri" Load "dbe" Load "record" Load "xtrap" Load "type1" Load "freetype" EndSection Notice the Load "dri" Or it may look like this just uncomment glx and dri Section "Module" # This loads the GLX module # Load "glx" # This loads the DRI module # Load "dri" Load "record" Load "xtrap" Load "type1" Load "freetype" EndSection I think thats it. It has been a while since I had to mess with it though On Friday 06 May 2005 4:40 pm, just me wrote: > i read the building section in the link , i i found that i already > have the dri module file for my video card, it's in > /usr/X11R6/lib/modules/dri ,savage_dri.so. so i don't think i should > build it, but how do i load it ? i tried to do kldload > full_path/savage_dri.so and it didn't work - > # kldload /usr/X11R6/lib/modules/dri/savage_dri.so > kldload: can't load /usr/X11R6/lib/modules/dri/savage_dri.so: No such > file or directory > su-2.05b# file /usr/X11R6/lib/modules/dri/savage_dri.so > /usr/X11R6/lib/modules/dri/savage_dri.so: ELF 32-bit LSB shared > object, Intel 80386, version 1 (FreeBSD), stripped > > so........what can i do ? > > On 5/7/05, Jaimie Garner wrote: > > I asumed it would just gave em a link to shed some light on how I did it > > with Linux. I havent ran X on FreeBSD. > > > > On Friday 06 May 2005 3:17 pm, Matthias Buelow wrote: > > > Jaimie Garner wrote: > > > >Go here http://dri.freedesktop.org/wiki/Building this helped me to > > > > build Xorg + Mesa and DRI for ATI Radeon on a custome built linux > > > > system. Should not be to far off for FreeBSD. > > > > > > The OP does not have to build Xorg manually. The ports system > > > already does this, and his video chipset is old enough to be supported > > > by the latest release Xorg (if it isn't, then a CVS Xorg won't help.) > > > > > > The OP could post the error messages pertaining to DRI > > > (from /var/log/Xorg.0.log) plus the output from "xdriinfo" > > > and "kldstat". > > > > > > mkb. > > > _______________________________________________ > > > 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" > > > > -- > > Jaimie Garner > > Onsite PCS inc. > > 323 SE RIverside AV > > Grants Pass, OR 97526 > > 541.471.1343 > > 866.471.1343 > > jaimie@onsitepcs.net > > www.onistepcs.net > > _______________________________________________ > > 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" -- Jaimie Garner Onsite PCS inc. 323 SE RIverside AV Grants Pass, OR 97526 541.471.1343 866.471.1343 jaimie@onsitepcs.net www.onistepcs.net From owner-freebsd-stable@FreeBSD.ORG Fri May 6 23:59:06 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A354D16A4EB for ; Fri, 6 May 2005 23:59:06 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4439E43D91 for ; Fri, 6 May 2005 23:59:06 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so571788rng for ; Fri, 06 May 2005 16:59:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=htcIs8yxdhNZhYBZOTUUcDk7DKoyMMJ6SPf/8i5DtMbpBhpDYkvMz5Th6Gopc05e8vpidIAcC6hO93qjD+q/2K2blOV0etMoQ0vLl98vhK5gYPYL+22yZWu3z1+4vQ+69oPh0MMYyPBYfz4tRQeDHIveHDKVsn9hIfIj9jcnF1Q= Received: by 10.38.13.44 with SMTP id 44mr328454rnm; Fri, 06 May 2005 16:59:03 -0700 (PDT) Received: by 10.38.207.53 with HTTP; Fri, 6 May 2005 16:59:03 -0700 (PDT) Message-ID: Date: Fri, 6 May 2005 19:59:03 -0400 From: Scott Ullrich To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Panic with 5.4-RELEASE when typing on console? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Scott Ullrich List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 23:59:06 -0000 Hi, =20 I cvsupped a bit ago and now when I type on the console I get a panic: root@builder# kgdb kernel.debug vmcore.57 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you ar= e welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:159 159 pcpu.h: No such file or directory. in pcpu.h (kgdb) backtrace #0 doadump () at pcpu.h:159 #1 0xc066e6b7 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:4= 10 #2 0xc066ea0d in panic (fmt=3D0xc08d2844 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:566 #3 0xc049d23d in db_panic (addr=3D174, have_addr=3D0, count=3D-1, modif=3D0xc7291ad0 "") at /usr/src/sys/ddb/db_command.c:435 #4 0xc049d1d4 in db_command (last_cmdp=3D0xc09b6b24, cmd_table=3D0x0, aux_cmd_tablep=3D0xc092b7fc, aux_cmd_tablep_end=3D0xc092b818) at /usr/src/sys/ddb/db_command.c:349 #5 0xc049d29c in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #6 0xc049ee35 in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_main= .c:221 #7 0xc068661f in kdb_trap (type=3D12, code=3D0, tf=3D0x1) at /usr/src/sys/kern/subr_kdb.c:468 #8 0xc0885b19 in trap_fatal (frame=3D0xc7291c64, eva=3D174) at /usr/src/sys/i386/i386/trap.c:812 #9 0xc0885877 in trap_pfault (frame=3D0xc7291c64, usermode=3D0, eva=3D174) at /usr/src/sys/i386/i386/trap.c:735 #10 0xc088546d in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D 13, tf_esi =3D -1063218240, tf_ebp =3D -953606976, tf_isp =3D -953607024, tf_ebx =3D -1056298496, tf_edx =3D -1066811620, tf_ecx =3D -1063473756, tf_eax =3D 13, tf_trapno =3D 12, tf_err =3D 0, tf_eip =3D 174, tf_cs =3D 8, tf_eflags =3D 66050, tf_esp =3D -1064933159, tf_ss =3D 13}) at /usr/src/sys/i386/i386/trap.c:425 ---Type to continue, or q to quit--- #11 0xc08732da in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #12 0x00000018 in ?? () #13 0x00000010 in ?? () #14 0x00000010 in ?? () #15 0x0000000d in ?? () #16 0xc0a093c0 in sc_devclass () #17 0xc7291cc0 in ?? () #18 0xc7291c90 in ?? () #19 0xc10a2a00 in ?? () #20 0xc069bf1c in ttylclose () at /usr/src/sys/kern/tty.c:1567 #21 0xc0856b18 in atkbd_intr (kbd=3D0xc0a093c0, arg=3D0x0) at /usr/src/sys/dev/kbd/atkbd.c:461 #22 0xc088fc2a in atkbd_isa_intr (arg=3D0x0) at /usr/src/sys/isa/atkbd_isa.= c:177 #23 0xc065a069 in ithread_loop (arg=3D0xc0edee80) at /usr/src/sys/kern/kern_intr.c:547 #24 0xc0659105 in fork_exit (callout=3D0xc0659f10 , arg=3D0xc0edee80, frame=3D0xc7291d48) at /usr/src/sys/kern/kern_fork.c:= 791 #25 0xc087333c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 209 (kgdb) Has anyone seen this problem or could this be something on my end? Scott From owner-freebsd-stable@FreeBSD.ORG Sat May 7 00:08:40 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4E2E16A4D4 for ; Sat, 7 May 2005 00:08:40 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2943143D31 for ; Sat, 7 May 2005 00:08:40 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DUClH-0007Nj-Rh for freebsd-stable@freebsd.org; Sat, 07 May 2005 02:01:39 +0200 Received: from gn-hgk-15cd4.adsl.wanadoo.nl ([81.69.122.212]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 May 2005 02:01:39 +0200 Received: from A.S.Usov by gn-hgk-15cd4.adsl.wanadoo.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 May 2005 02:01:39 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Alexander S. Usov" Date: Sat, 07 May 2005 02:08:15 +0200 Organization: KVI Lines: 14 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: gn-hgk-15cd4.adsl.wanadoo.nl User-Agent: KNode/0.9.0 Sender: news Subject: Re: Panic with 5.4-RELEASE when typing on console? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 00:08:41 -0000 Scott Ullrich wrote: > I cvsupped a bit ago and now when I type on the console I get a panic: [.... skipped ....] > Has anyone seen this problem or could this be something on my end? I have seen it. There is a similar dump of mine dated half-a-day back. It seems that this panic is somehow related to the recent break in tty code. Or at leas they have both appeared very close in time ;) -- Best regards, Alexander. From owner-freebsd-stable@FreeBSD.ORG Sat May 7 00:08:59 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D807116A4D4 for ; Sat, 7 May 2005 00:08:59 +0000 (GMT) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76BA843D99 for ; Sat, 7 May 2005 00:08:59 +0000 (GMT) (envelope-from cpghost@cordula.ws) Received: from epia2.farid-hajji.net (epia-2 [192.168.254.11]) by fw.farid-hajji.net (Postfix) with ESMTP id D63564BEF7; Sat, 7 May 2005 02:06:39 +0200 (CEST) Date: Sat, 7 May 2005 02:10:50 +0200 From: cpghost@cordula.ws To: Scott Ullrich Message-ID: <20050507001050.GB10731@epia2.farid-hajji.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i cc: freebsd-stable@freebsd.org Subject: Re: Panic with 5.4-RELEASE when typing on console? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 00:09:00 -0000 On Fri, May 06, 2005 at 07:59:03PM -0400, Scott Ullrich wrote: > I cvsupped a bit ago and now when I type on the console I get a panic: [...] > Has anyone seen this problem or could this be something on my end? Could that be related to the recent heads up? HEADS-UP: Problem with RELENG_5{_4} > Scott -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Sat May 7 00:10:48 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5677216A4D4 for ; Sat, 7 May 2005 00:10:48 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04AFB43D8F for ; Sat, 7 May 2005 00:10:48 +0000 (GMT) (envelope-from sullrich@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so572628rng for ; Fri, 06 May 2005 17:10:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YQTxvFbX83sUoKGvvlsmJwNdNSHhR8lNbcfH7rfGFnWSGUzV699YARpI2f8MZtB5y/PK30C56TN6CLqlyl03dVDg0weOixutmFYMWiedGAm8b5GhxIFxHFCeuW9W06lNpQC7F32VNRMPwn5J2waNAM1CgFqBEteIF/XKacJTboE= Received: by 10.38.76.80 with SMTP id y80mr330444rna; Fri, 06 May 2005 17:10:47 -0700 (PDT) Received: by 10.38.207.53 with HTTP; Fri, 6 May 2005 17:10:47 -0700 (PDT) Message-ID: Date: Fri, 6 May 2005 20:10:47 -0400 From: Scott Ullrich To: "cpghost@cordula.ws" In-Reply-To: <20050507001050.GB10731@epia2.farid-hajji.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050507001050.GB10731@epia2.farid-hajji.net> cc: freebsd-stable@freebsd.org Subject: Re: Panic with 5.4-RELEASE when typing on console? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Scott Ullrich List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2005 00:10:48 -0000 On 5/6/05, cpghost@cordula.ws wrote: > Could that be related to the recent heads up? > HEADS-UP: Problem with RELENG_5{_4} I think it is. Hopefully my backtrace can help.=20 Sorry for the false alarm since its known about. Scott From owner-freebsd-stable@FreeBSD.ORG Sat May 7 00:22:31 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9535A16A4D4 for ; Sat, 7 May 2005 00:22:31 +0000 (GMT) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 586D243D54 for ; Sat, 7 May 2005 00:22:31 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 9411C64E2BB; Fri, 6 May 2005 21:22:30 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 09046-04; Sat, 7 May 2005 00:22:25 +0000 (GMT) Received: from ganymede.hub.org (blk-222-81-172.eastlink.ca [24.222.81.172]) by hub.org (Postfix) with ESMTP id 1126564E2B6; Fri, 6 May 2005 21:22:30 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 04BA33A8D7; Fri, 6 May 2005 21:22:29 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 01726391CC; Fri, 6 May 2005 21:22:28 -0300 (ADT) Date: Fri, 6 May 2005 21:22:28 -0300 (ADT) From: "Marc G. Fournier" To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: Message-ID: <20050506212107.C42300@ganymede.hub.org> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1066337676-1115425348=:42300" X-Virus-Scanned: by amavisd-new at hub.org cc: "stable@freebsd.org" Subject: Re: unionfs limitations? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 00:22:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1066337676-1115425348=:42300 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE yOn Sat, 7 May 2005, Eirik [ISO-8859-1] =D8verby wrote: > Hi, > > I just started playing with mounting ports into jails using unionfs > (mount_unionfs -b /usr/ports_jail /usr/local/jails/jail-0/usr/ports), and > many things seem to work fine. > However, when trying to install either of mysql41-server or mysql41-clien= t, > I see the following: > > [root@mpi1] /usr/ports/databases/mysql41-server# make install > =3D=3D=3D> Installing for mysql-server-4.1.11_1 > =3D=3D=3D> mysql-server-4.1.11_1 depends on shared library: mysqlclient= =2E14 - > found > =3D=3D=3D> Generating temporary packing list > =3D=3D=3D> Checking if databases/mysql41-server already installed > ln: POSIX: Operation not supported > *** Error code 1 > > Stop in /usr/ports/databases/mysql41-server. > > Did I miss out on something, or is this not going to work? Do I need to > think in other ways? > I have stress-tested this setup pretty well over the last 24 hours, with = as > many as 20 mountpoints using the same ports tree, with constant package > building in each of them. This was impossible last time I played with > unionfs, so it must have stabilized somewhat ;) What version of FreeBSD? Only issue I've hit so far is just trying SBCL=20 the other day and getting an MMAP issue that I'm guessing is jail related,= =20 not unionfs ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 --0-1066337676-1115425348=:42300-- From owner-freebsd-stable@FreeBSD.ORG Sat May 7 01:19:14 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D710116A4D4 for ; Sat, 7 May 2005 01:19:14 +0000 (GMT) Received: from merlin.alerce.com (w094.z064001164.sjc-ca.dsl.cnc.net [64.1.164.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7222943D58 for ; Sat, 7 May 2005 01:19:12 +0000 (GMT) (envelope-from hartzell@kestrel.alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 9AC6721BF; Fri, 6 May 2005 18:18:32 -0700 (PDT) Received: from satchel.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by merlin.alerce.com (Postfix) with ESMTP id 6DA312181; Fri, 6 May 2005 18:18:32 -0700 (PDT) Received: from satchel.alerce.com (localhost [127.0.0.1]) by satchel.alerce.com (8.13.1/8.13.1) with ESMTP id j471JKNe013174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 May 2005 18:19:21 -0700 (PDT) (envelope-from hartzell@satchel.alerce.com) Received: (from hartzell@localhost) by satchel.alerce.com (8.13.1/8.13.1/Submit) id j471JJHh013170; Fri, 6 May 2005 18:19:19 -0700 (PDT) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <17020.6038.618856.265788@satchel.alerce.com> Date: Fri, 6 May 2005 18:19:18 -0700 To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: References: X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid X-Virus-Scanned: ClamAV using ClamSMTP cc: "stable@freebsd.org" Subject: Re: unionfs limitations? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2005 01:19:15 -0000 Eirik =D8verby writes: > Hi, >=20 > I just started playing with mounting ports into jails using unionfs > (mount_unionfs -b /usr/ports_jail /usr/local/jails/jail-0/usr/ports)= , and > many things seem to work fine. > However, when trying to install either of mysql41-server or mysql41-= client, > I see the following: >=20 > [root@mpi1] /usr/ports/databases/mysql41-server# make install > =3D=3D=3D> Installing for mysql-server-4.1.11_1 > =3D=3D=3D> mysql-server-4.1.11_1 depends on shared library: mysqlc= lient.14 - > found > =3D=3D=3D> Generating temporary packing list > =3D=3D=3D> Checking if databases/mysql41-server already installed > ln: POSIX: Operation not supported > *** Error code 1 >=20 > Stop in /usr/ports/databases/mysql41-server. >=20 > Did I miss out on something, or is this not going to work? Do I need= to > think in other ways? > [...] Here's one unionfs/jail gotcha that's bitten me a couple of times. If you actually *use* (or, have used) the ports directory to build and install stuff onto the "host" machine, the ports infrastructure in the jail gets kind of confused. It seems to be checking for the files in the dependencies, doesn't find them, goes to make them, and then [depending on what state the relevant port directory is in], things get "odd". I've started just using a virgin ports tree as the underpinnings for my unionfs'ed jails. Is there any chance that you've installed mysql-server on the host? g. From owner-freebsd-stable@FreeBSD.ORG Sat May 7 04:26:53 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55F3316A4D8 for ; Sat, 7 May 2005 04:26:53 +0000 (GMT) Received: from osl1smout1.broadpark.no (80-202-4-58.dd.nextgentel.com [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id C384743D69 for ; Sat, 7 May 2005 04:26:51 +0000 (GMT) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IG0007YI48LJ2B0@osl1smout1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 05 May 2005 07:21:57 +0200 (CEST) Received: from kg-work.kg4.no ([80.203.21.150]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with SMTP id <0IFZ00JDWYKBHZ30@osl1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Thu, 05 May 2005 05:19:27 +0200 (CEST) Date: Thu, 05 May 2005 05:15:30 +0200 From: Torfinn Ingolfsen X-Face: "t9w2,-X@O^I`jVW\sonI3.,36KBLZE*AL[y9lL[PyFD*r_S:dIL9c[8Y>V42R0"!"yb_zN,f#%.[PYYNq;m"_0v;~rUM2Yy!zmkh)3&U|u!=T(zyv,MHJv"nDH>OJ`t(@mil461d_B'Uo|'nMwlKe0Mv=kvV?Nh@>Hb<3s_z2jYgZhPb@?Wi^x1a~Hplz1.zH To: freebsd-stable@freebsd.org Message-id: <20050505051530.3235b224.torfinn.ingolfsen@broadpark.no> MIME-version: 1.0 X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd5.3) Content-type: multipart/mixed; boundary="Boundary_(ID_txn95BjdN6D/4Yu2u3CePA)" Subject: Xorg - getting VESA to work on a Radeon Xpress 200? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 04:26:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_txn95BjdN6D/4Yu2u3CePA) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT I have an amd64 machine, it has a RS480M2-IL (aka MS-7093) mainboard (don't ask me what the '-IL' means, I have no idea). I run the FreeBSD 5-stable branch on the machine: root@kg-quiet# uname -a FreeBSD kg-quiet.kg4.no 5.4-STABLE FreeBSD 5.4-STABLE #2: Tue May 3 22:40:03 CEST 2005 root@kg-quiet.kg4.no:/usr/obj/usr/src/sys/QUIET amd64 This mainboard have "ATI Radeon Xpress 200" integrated graphics, which currently isn't supported by any ATI drivers, AFAIK. So I have to use the VESA driver. I run this with Xorg 6.8.2 from ports, using the vesa driver, on an LCD that have 1280x1024 as native resolution. The problem has been that the vesa driver behaves odd; text (any text) is "blurred" (for lack of a better word) so that it is difficult / imposiible to read. Except for that (not so small) problem, Xorg has been working without problems. Recently I noticed that there was a new port; xorg-server-snap (6.8.99.5), so I tried that one. First I tried to autodetect drivers; xorg suggested the 'ati' driver, but that makes a mess of the display. so back to the vesa driver again. And to my joy I discovered that text was crisp and readable again! Nice! But there is one problem: xorg won't do 1280x1024 anymore. The log file (/var/log/Xorg.0.log) contains this line: (II) VESA(0): Not using mode "1280x1024" (no mode of this name) Huh? Earlier on in the log file, it reported: (II) VESA(0): Supported VESA Video Modes: (II) VESA(0): 720x400@70Hz (II) VESA(0): 640x480@60Hz (II) VESA(0): 640x480@67Hz (II) VESA(0): 640x480@72Hz (II) VESA(0): 640x480@75Hz (II) VESA(0): 800x600@60Hz (II) VESA(0): 800x600@72Hz (II) VESA(0): 800x600@75Hz (II) VESA(0): 832x624@75Hz (II) VESA(0): 1024x768@60Hz (II) VESA(0): 1024x768@70Hz (II) VESA(0): 1024x768@75Hz (II) VESA(0): 1280x1024@75Hz (II) VESA(0): 1152x870@75Hz The complete Xorg.0.log file is attached. I tried searching on the net (ok, "googling"), but didn't find anything that helped. Any hints on what I can try to fix this? -- Regards, Torfinn Ingolfsen, Norway --Boundary_(ID_txn95BjdN6D/4Yu2u3CePA) Content-type: application/octet-stream; name=Xorg.0.log Content-transfer-encoding: base64 Content-disposition: attachment; filename=Xorg.0.log ClRoaXMgaXMgYSBwcmUtcmVsZWFzZSB2ZXJzaW9uIG9mIHRoZSBUaGUgWC5PcmcgRm91bmRhdGlv biBYMTEuCkl0IGlzIG5vdCBzdXBwb3J0ZWQgaW4gYW55IHdheS4KQnVncyBtYXkgYmUgZmlsZWQg aW4gdGhlIGJ1Z3ppbGxhIGF0IGh0dHA6Ly9idWdzLmZyZWVkZXNrdG9wLm9yZy8uClNlbGVjdCB0 aGUgInhvcmciIHByb2R1Y3QgZm9yIGJ1Z3MgeW91IGZpbmQgaW4gdGhpcyByZWxlYXNlLgpCZWZv cmUgcmVwb3J0aW5nIGJ1Z3MgaW4gcHJlLXJlbGVhc2UgdmVyc2lvbnMgcGxlYXNlIGNoZWNrIHRo ZQpsYXRlc3QgdmVyc2lvbiBpbiB0aGUgVGhlIFguT3JnIEZvdW5kYXRpb24gIm1vbm9saXRoaWMg dHJlZSIgQ1ZTCnJlcG9zaXRvcnkgaG9zdGVkIGF0IGh0dHA6Ly93d3cuZnJlZWRlc2t0b3Aub3Jn L1NvZnR3YXJlL3hvcmcvClggV2luZG93IFN5c3RlbSBWZXJzaW9uIDYuOC45OS41ClJlbGVhc2Ug RGF0ZTogMDEgTWF5IDIwMDUgKyBjdnMKWCBQcm90b2NvbCBWZXJzaW9uIDExLCBSZXZpc2lvbiAw LCBSZWxlYXNlIDYuOC45OS41CkJ1aWxkIE9wZXJhdGluZyBTeXN0ZW06IEZyZWVCU0QgNS40IGFt ZDY0IFtFTEZdIApDdXJyZW50IE9wZXJhdGluZyBTeXN0ZW06IEZyZWVCU0Qga2ctcXVpZXQua2c0 Lm5vIDUuNC1TVEFCTEUgRnJlZUJTRCA1LjQtU1RBQkxFICMyOiBUdWUgTWF5ICAzIDIyOjQwOjAz IENFU1QgMjAwNSAgICAgcm9vdEBrZy1xdWlldC5rZzQubm86L3Vzci9vYmovdXNyL3NyYy9zeXMv UVVJRVQgYW1kNjQKQnVpbGQgRGF0ZTogMDQgTWF5IDIwMDUKCUJlZm9yZSByZXBvcnRpbmcgcHJv YmxlbXMsIGNoZWNrIGh0dHA6Ly93aWtpLlguT3JnCgl0byBtYWtlIHN1cmUgdGhhdCB5b3UgaGF2 ZSB0aGUgbGF0ZXN0IHZlcnNpb24uCk1vZHVsZSBMb2FkZXIgcHJlc2VudApNYXJrZXJzOiAoLS0p IHByb2JlZCwgKCoqKSBmcm9tIGNvbmZpZyBmaWxlLCAoPT0pIGRlZmF1bHQgc2V0dGluZywKCSgr KykgZnJvbSBjb21tYW5kIGxpbmUsICghISkgbm90aWNlLCAoSUkpIGluZm9ybWF0aW9uYWwsCgko V1cpIHdhcm5pbmcsIChFRSkgZXJyb3IsIChOSSkgbm90IGltcGxlbWVudGVkLCAoPz8pIHVua25v d24uCig9PSkgTG9nIGZpbGU6ICIvdmFyL2xvZy9Yb3JnLjAubG9nIiwgVGltZTogV2VkIE1heSAg NCAwODoyMDowNiAyMDA1Cig9PSkgVXNpbmcgY29uZmlnIGZpbGU6ICIvZXRjL1gxMS94b3JnLmNv bmYiCig9PSkgU2VydmVyTGF5b3V0ICJYLm9yZyBDb25maWd1cmVkIgooKiopIHwtLT5TY3JlZW4g IlNjcmVlbjAiICgwKQooKiopIHwgICB8LS0+TW9uaXRvciAiTW9uaXRvcjAiCigqKikgfCAgIHwt LT5EZXZpY2UgIkNhcmQwIgooKiopIHwtLT5JbnB1dCBEZXZpY2UgIk1vdXNlMCIKKCoqKSB8LS0+ SW5wdXQgRGV2aWNlICJLZXlib2FyZDAiCihXVykgVGhlIGRpcmVjdG9yeSAiL3Vzci9YMTFSNi9s aWIvWDExL2ZvbnRzL0NJRC8iIGRvZXMgbm90IGV4aXN0LgoJRW50cnkgZGVsZXRlZCBmcm9tIGZv bnQgcGF0aC4KKCoqKSBGb250UGF0aCBzZXQgdG8gIi91c3IvWDExUjYvbGliL1gxMS9mb250cy9t aXNjLywvdXNyL1gxMVI2L2xpYi9YMTEvZm9udHMvVFRGLywvdXNyL1gxMVI2L2xpYi9YMTEvZm9u dHMvVHlwZTEvLC91c3IvWDExUjYvbGliL1gxMS9mb250cy83NWRwaS8sL3Vzci9YMTFSNi9saWIv WDExL2ZvbnRzLzEwMGRwaS8iCigqKikgUmdiUGF0aCBzZXQgdG8gIi91c3IvWDExUjYvbGliL1gx MS9yZ2IiCigqKikgTW9kdWxlUGF0aCBzZXQgdG8gIi91c3IvWDExUjYvbGliL21vZHVsZXMiCihJ SSkgTW9kdWxlIEFCSSB2ZXJzaW9uczoKCVguT3JnIEFOU0kgQyBFbXVsYXRpb246IDAuMgoJWC5P cmcgVmlkZW8gRHJpdmVyOiAwLjcKCVguT3JnIFhJbnB1dCBkcml2ZXIgOiAwLjQKCVguT3JnIFNl cnZlciBFeHRlbnNpb24gOiAwLjIKCVguT3JnIEZvbnQgUmVuZGVyZXIgOiAwLjQKKElJKSBMb2Fk ZXIgcnVubmluZyBvbiBmcmVlYnNkCihJSSkgTG9hZE1vZHVsZTogImJpdG1hcCIKKElJKSBMb2Fk aW5nIC91c3IvWDExUjYvbGliL21vZHVsZXMvZm9udHMvbGliYml0bWFwLnNvCihJSSkgTW9kdWxl IGJpdG1hcDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDYuOC45OS41 LCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglNb2R1bGUgY2xhc3M6IFguT3JnIEZvbnQgUmVuZGVy ZXIKCUFCSSBjbGFzczogWC5PcmcgRm9udCBSZW5kZXJlciwgdmVyc2lvbiAwLjQKKElJKSBMb2Fk aW5nIGZvbnQgQml0bWFwCihJSSkgTG9hZE1vZHVsZTogInBjaWRhdGEiCihJSSkgTG9hZGluZyAv dXNyL1gxMVI2L2xpYi9tb2R1bGVzL2xpYnBjaWRhdGEuc28KKElJKSBNb2R1bGUgcGNpZGF0YTog dmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDYuOC45OS41LCBtb2R1bGUg dmVyc2lvbiA9IDEuMC4wCglBQkkgY2xhc3M6IFguT3JnIFZpZGVvIERyaXZlciwgdmVyc2lvbiAw LjcKKC0tKSBVc2luZyBzeXNjb25zIGRyaXZlciB3aXRoIFggc3VwcG9ydCAodmVyc2lvbiAyLjAp CigtLSkgdXNpbmcgVlQgbnVtYmVyIDkKCihJSSkgUENJOiBQQ0kgc2NhbiAoYWxsIHZhbHVlcyBh cmUgaW4gaGV4KQooSUkpIFBDSTogMDA6MDA6MDogY2hpcCAxMDAyLDU5NTAgY2FyZCAxNDYyLDcx NDEgcmV2IDAwIGNsYXNzIDA2LDAwLDAwIGhkciAwMAooSUkpIFBDSTogMDA6MDE6MDogY2hpcCAx MDAyLDVhM2YgY2FyZCAwMDAwLDAwMDAgcmV2IDAwIGNsYXNzIDA2LDA0LDAwIGhkciAwMQooSUkp IFBDSTogMDA6MTE6MDogY2hpcCAxMDAyLDQzN2EgY2FyZCAxNDYyLDcxNDEgcmV2IDAwIGNsYXNz IDAxLDAxLDhmIGhkciAwMAooSUkpIFBDSTogMDA6MTI6MDogY2hpcCAxMDAyLDQzNzkgY2FyZCAx NDYyLDcxNDEgcmV2IDAwIGNsYXNzIDAxLDAxLDhmIGhkciAwMAooSUkpIFBDSTogMDA6MTM6MDog Y2hpcCAxMDAyLDQzNzQgY2FyZCAxNDYyLDcxNDEgcmV2IDAwIGNsYXNzIDBjLDAzLDEwIGhkciA4 MAooSUkpIFBDSTogMDA6MTM6MTogY2hpcCAxMDAyLDQzNzUgY2FyZCAxNDYyLDcxNDEgcmV2IDAw IGNsYXNzIDBjLDAzLDEwIGhkciAwMAooSUkpIFBDSTogMDA6MTM6MjogY2hpcCAxMDAyLDQzNzMg Y2FyZCAxNDYyLDcxNDEgcmV2IDAwIGNsYXNzIDBjLDAzLDIwIGhkciAwMAooSUkpIFBDSTogMDA6 MTQ6MDogY2hpcCAxMDAyLDQzNzIgY2FyZCAxNDYyLDcxNDEgcmV2IDA0IGNsYXNzIDBjLDA1LDAw IGhkciA4MAooSUkpIFBDSTogMDA6MTQ6MTogY2hpcCAxMDAyLDQzNzYgY2FyZCAxNDYyLDcxNDEg cmV2IDAwIGNsYXNzIDAxLDAxLDhhIGhkciAwMAooSUkpIFBDSTogMDA6MTQ6MzogY2hpcCAxMDAy LDQzNzcgY2FyZCAxNDYyLDcxNDEgcmV2IDAwIGNsYXNzIDA2LDAxLDAwIGhkciA4MAooSUkpIFBD STogMDA6MTQ6NDogY2hpcCAxMDAyLDQzNzEgY2FyZCAwMDAwLDAwMDAgcmV2IDAwIGNsYXNzIDA2 LDA0LDAxIGhkciA4MQooSUkpIFBDSTogMDA6MTQ6NTogY2hpcCAxMDAyLDQzNzAgY2FyZCAxNDYy LDAwODAgcmV2IDAwIGNsYXNzIDA0LDAxLDAwIGhkciA4MAooSUkpIFBDSTogMDA6MTg6MDogY2hp cCAxMDIyLDExMDAgY2FyZCAwMDAwLDAwMDAgcmV2IDAwIGNsYXNzIDA2LDAwLDAwIGhkciA4MAoo SUkpIFBDSTogMDA6MTg6MTogY2hpcCAxMDIyLDExMDEgY2FyZCAwMDAwLDAwMDAgcmV2IDAwIGNs YXNzIDA2LDAwLDAwIGhkciA4MAooSUkpIFBDSTogMDA6MTg6MjogY2hpcCAxMDIyLDExMDIgY2Fy ZCAwMDAwLDAwMDAgcmV2IDAwIGNsYXNzIDA2LDAwLDAwIGhkciA4MAooSUkpIFBDSTogMDA6MTg6 MzogY2hpcCAxMDIyLDExMDMgY2FyZCAwMDAwLDAwMDAgcmV2IDAwIGNsYXNzIDA2LDAwLDAwIGhk ciA4MAooSUkpIFBDSTogMDE6MDU6MDogY2hpcCAxMDAyLDU5NTQgY2FyZCAxNDYyLDcxNDEgcmV2 IDAwIGNsYXNzIDAzLDAwLDAwIGhkciAwMAooSUkpIFBDSTogMDI6MDM6MDogY2hpcCAxMGVjLDgx MzkgY2FyZCAxNDYyLDA5M2MgcmV2IDEwIGNsYXNzIDAyLDAwLDAwIGhkciAwMAooSUkpIFBDSTog MDI6MDQ6MDogY2hpcCAxMTA2LDMwNDQgY2FyZCAxNDYyLDA5M2QgcmV2IDgwIGNsYXNzIDBjLDAw LDEwIGhkciAwMAooSUkpIFBDSTogRW5kIG9mIFBDSSBzY2FuCihJSSkgSG9zdC10by1QQ0kgYnJp ZGdlOgooSUkpIEJ1cyAwOiBicmlkZ2UgaXMgYXQgKDA6MDowKSwgKDAsMCwyKSwgQkNUUkw6IDB4 MDAwOCAoVkdBX0VOIGlzIHNldCkKKElJKSBCdXMgMCBJL08gcmFuZ2U6CglbMF0gLTEJMAkweDAw MDAwMDAwIC0gMHhmZmZmZmZmZiAoMHgxMDAwMDAwMDApIElYW0JdCihJSSkgQnVzIDAgbm9uLXBy ZWZldGNoYWJsZSBtZW1vcnkgcmFuZ2U6CglbMF0gLTEJMAkweDgwMDAwMDAwIC0gMHhmZmZmZmZm ZiAoMHg4MDAwMDAwMCkgTVhbQl0KKElJKSBCdXMgMCBwcmVmZXRjaGFibGUgbWVtb3J5IHJhbmdl OgoJWzBdIC0xCTAJMHg4MDAwMDAwMCAtIDB4ZmZmZmZmZmYgKDB4ODAwMDAwMDApIE1YW0JdCihJ SSkgUENJLXRvLVBDSSBicmlkZ2U6CihJSSkgQnVzIDE6IGJyaWRnZSBpcyBhdCAoMDoxOjApLCAo MCwxLDEpLCBCQ1RSTDogMHgwMDBhIChWR0FfRU4gaXMgc2V0KQooSUkpIEJ1cyAxIEkvTyByYW5n ZToKCVswXSAtMQkwCTB4MDAwMGUwMDAgLSAweDAwMDBlZmZmICgweDEwMDApIElYW0JdCihJSSkg QnVzIDEgbm9uLXByZWZldGNoYWJsZSBtZW1vcnkgcmFuZ2U6CglbMF0gLTEJMAkweGZkZDAwMDAw IC0gMHhmZGRmZmZmZiAoMHgxMDAwMDApIE1YW0JdCihJSSkgQnVzIDEgcHJlZmV0Y2hhYmxlIG1l bW9yeSByYW5nZToKCVswXSAtMQkwCTB4ZDAwMDAwMDAgLSAweGRmZmZmZmZmICgweDEwMDAwMDAw KSBNWFtCXQooSUkpIFBDSS10by1JU0EgYnJpZGdlOgooSUkpIEJ1cyAtMTogYnJpZGdlIGlzIGF0 ICgwOjIwOjMpLCAoMCwtMSwtMSksIEJDVFJMOiAweDAwMDggKFZHQV9FTiBpcyBzZXQpCihJSSkg U3VidHJhY3RpdmUgUENJLXRvLVBDSSBicmlkZ2U6CihJSSkgQnVzIDI6IGJyaWRnZSBpcyBhdCAo MDoyMDo0KSwgKDAsMiwyKSwgQkNUUkw6IDB4MDAwMiAoVkdBX0VOIGlzIGNsZWFyZWQpCihJSSkg QnVzIDIgSS9PIHJhbmdlOgoJWzBdIC0xCTAJMHgwMDAwZDAwMCAtIDB4MDAwMGRmZmYgKDB4MTAw MCkgSVhbQl0KKElJKSBCdXMgMiBub24tcHJlZmV0Y2hhYmxlIG1lbW9yeSByYW5nZToKCVswXSAt MQkwCTB4ZmRjMDAwMDAgLSAweGZkY2ZmZmZmICgweDEwMDAwMCkgTVhbQl0KKElJKSBCdXMgMiBw cmVmZXRjaGFibGUgbWVtb3J5IHJhbmdlOgoJWzBdIC0xCTAJMHhmZGUwMDAwMCAtIDB4ZmRlZmZm ZmYgKDB4MTAwMDAwKSBNWFtCXQooLS0pIFBDSToqKDE6NTowKSBBVEkgVGVjaG5vbG9naWVzIElu YyB1bmtub3duIGNoaXBzZXQgKDB4NTk1NCkgcmV2IDAsIE1lbSBAIDB4ZDAwMDAwMDAvMjgsIDB4 ZmRkZjAwMDAvMTYsIEkvTyBAIDB4ZWYwMC84CihJSSkgQWRkcmVzc2FibGUgYnVzIHJlc291cmNl IHJhbmdlcyBhcmUKCVswXSAtMQkwCTB4MDAwMDAwMDAgLSAweGZmZmZmZmZmICgweDEwMDAwMDAw MCkgTVhbQl0KCVsxXSAtMQkwCTB4MDAwMDAwMDAgLSAweGZmZmZmZmZmICgweDEwMDAwMDAwMCkg SVhbQl0KKElJKSBPUy1yZXBvcnRlZCByZXNvdXJjZSByYW5nZXM6CglbMF0gLTEJMAkweGZmZmZm ZmZmIC0gMHhmZmZmZmZmZiAoMHgxKSBNWFtCXQoJWzFdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAw MDAwMDAgKDB4MSkgTVhbQl0KCVsyXSAtMQkwCTB4MDAwYzAwMDAgLSAweDAwMGVmZmZmICgweDMw MDAwKSBNWFtCXQoJWzNdIC0xCTAJMHhmZmZmZmZmZiAtIDB4ZmZmZmZmZmYgKDB4MSkgSVhbQl0K CVs0XSAtMQkwCTB4MDAwMDAwMDAgLSAweDAwMDAwMGZmICgweDEwMCkgSVhbQl0KKElJKSBQQ0kg SS9PIHJlc291cmNlIG92ZXJsYXAgcmVkdWNlZCAweDAwMDA0MTAwIGZyb20gMHgwMDAwNDFmZiB0 byAweDAwMDA0MGZmCihJSSkgUENJIE1lbW9yeSByZXNvdXJjZSBvdmVybGFwIHJlZHVjZWQgMHhl MDAwMDAwMCBmcm9tIDB4ZmZmZmZmZmYgdG8gMHhkZmZmZmZmZgooSUkpIEFjdGl2ZSBQQ0kgcmVz b3VyY2UgcmFuZ2VzOgoJWzBdIC0xCTAJMHhmZGNmZTAwMCAtIDB4ZmRjZmZmZmYgKDB4MjAwMCkg TVhbQl1FCglbMV0gLTEJMAkweGZkY2ZmMDAwIC0gMHhmZGNmZmZmZiAoMHgxMDAwKSBNWFtCXUUK CVsyXSAtMQkwCTB4ZmUwMjkwMDAgLSAweGZlMDI5ZmZmICgweDEwMDApIE1YW0JdRQoJWzNdIC0x CTAJMHhmZTAyYTAwMCAtIDB4ZmUwMmJmZmYgKDB4MjAwMCkgTVhbQl1FCglbNF0gLTEJMAkweGZl MDJiMDAwIC0gMHhmZTAyYmZmZiAoMHgxMDAwKSBNWFtCXUUKCVs1XSAtMQkwCTB4ZmUwMmMwMDAg LSAweGZlMDJmZmZmICgweDQwMDApIE1YW0JdRQoJWzZdIC0xCTAJMHhmZTAyZDAwMCAtIDB4ZmUw MmRmZmYgKDB4MTAwMCkgTVhbQl1FCglbN10gLTEJMAkweGZlMDJlMDAwIC0gMHhmZTAyZmZmZiAo MHgyMDAwKSBNWFtCXUUKCVs4XSAtMQkwCTB4ZmUwMmYwMDAgLSAweGZlMDJmZmZmICgweDEwMDAp IE1YW0JdRQoJWzldIC0xCTAJMHhlMDAwMDAwMCAtIDB4ZGZmZmZmZmYgKDB4MCkgTVhbQl1FTwoJ WzEwXSAtMQkwCTB4ZmRkZjAwMDAgLSAweGZkZGZmZmZmICgweDEwMDAwKSBNWFtCXShCKQoJWzEx XSAtMQkwCTB4ZDAwMDAwMDAgLSAweGRmZmZmZmZmICgweDEwMDAwMDAwKSBNWFtCXShCKQoJWzEy XSAtMQkwCTB4MDAwMGRlMDAgLSAweDAwMDBkZWZmICgweDEwMCkgSVhbQl1FCglbMTNdIC0xCTAJ MHgwMDAwZGYwMCAtIDB4MDAwMGRmZmYgKDB4MTAwKSBJWFtCXUUKCVsxNF0gLTEJMAkweDAwMDBm MzAwIC0gMHgwMDAwZjNmZiAoMHgxMDApIElYW0JdRQoJWzE1XSAtMQkwCTB4MDAwMDA0MDAgLSAw eDAwMDAwNGZmICgweDEwMCkgSVhbQl1FCglbMTZdIC0xCTAJMHgwMDAwZjUwMCAtIDB4MDAwMGY1 ZmYgKDB4MTAwKSBJWFtCXUUKCVsxN10gLTEJMAkweDAwMDBmNjAwIC0gMHgwMDAwZjZmZiAoMHgx MDApIElYW0JdRQoJWzE4XSAtMQkwCTB4MDAwMGY3MDAgLSAweDAwMDBmN2ZmICgweDEwMCkgSVhb Ql1FCglbMTldIC0xCTAJMHgwMDAwZjgwMCAtIDB4MDAwMGY4ZmYgKDB4MTAwKSBJWFtCXUUKCVsy MF0gLTEJMAkweDAwMDBmOTAwIC0gMHgwMDAwZjlmZiAoMHgxMDApIElYW0JdRQoJWzIxXSAtMQkw CTB4MDAwMGZhMDAgLSAweDAwMDBmYWZmICgweDEwMCkgSVhbQl1FCglbMjJdIC0xCTAJMHgwMDAw ZmIwMCAtIDB4MDAwMGZiZmYgKDB4MTAwKSBJWFtCXUUKCVsyM10gLTEJMAkweDAwMDBmYzAwIC0g MHgwMDAwZmNmZiAoMHgxMDApIElYW0JdRQoJWzI0XSAtMQkwCTB4MDAwMGZkMDAgLSAweDAwMDBm ZGZmICgweDEwMCkgSVhbQl1FCglbMjVdIC0xCTAJMHgwMDAwZmUwMCAtIDB4MDAwMGZlZmYgKDB4 MTAwKSBJWFtCXUUKCVsyNl0gLTEJMAkweDAwMDBlZjAwIC0gMHgwMDAwZWZmZiAoMHgxMDApIElY W0JdKEIpCihJSSkgSW5hY3RpdmUgUENJIHJlc291cmNlIHJhbmdlczoKCVswXSAtMQkwCTB4MDAw MDQxMDAgLSAweDAwMDA0MGZmICgweDApIElYW0JdRU8KKElJKSBQQ0kgTWVtb3J5IHJlc291cmNl IG92ZXJsYXAgcmVkdWNlZCAweGZkY2ZlMDAwIGZyb20gMHhmZGNmZmZmZiB0byAweGZkY2ZlZmZm CihJSSkgUENJIE1lbW9yeSByZXNvdXJjZSBvdmVybGFwIHJlZHVjZWQgMHhmZTAyYTAwMCBmcm9t IDB4ZmUwMmJmZmYgdG8gMHhmZTAyYWZmZgooSUkpIFBDSSBNZW1vcnkgcmVzb3VyY2Ugb3Zlcmxh cCByZWR1Y2VkIDB4ZmUwMmMwMDAgZnJvbSAweGZlMDJmZmZmIHRvIDB4ZmUwMmNmZmYKKElJKSBQ Q0kgTWVtb3J5IHJlc291cmNlIG92ZXJsYXAgcmVkdWNlZCAweGZlMDJlMDAwIGZyb20gMHhmZTAy ZmZmZiB0byAweGZlMDJlZmZmCihJSSkgQWN0aXZlIFBDSSByZXNvdXJjZSByYW5nZXMgYWZ0ZXIg cmVtb3Zpbmcgb3ZlcmxhcHM6CglbMF0gLTEJMAkweGZkY2ZlMDAwIC0gMHhmZGNmZWZmZiAoMHgx MDAwKSBNWFtCXUUKCVsxXSAtMQkwCTB4ZmRjZmYwMDAgLSAweGZkY2ZmZmZmICgweDEwMDApIE1Y W0JdRQoJWzJdIC0xCTAJMHhmZTAyOTAwMCAtIDB4ZmUwMjlmZmYgKDB4MTAwMCkgTVhbQl1FCglb M10gLTEJMAkweGZlMDJhMDAwIC0gMHhmZTAyYWZmZiAoMHgxMDAwKSBNWFtCXUUKCVs0XSAtMQkw CTB4ZmUwMmIwMDAgLSAweGZlMDJiZmZmICgweDEwMDApIE1YW0JdRQoJWzVdIC0xCTAJMHhmZTAy YzAwMCAtIDB4ZmUwMmNmZmYgKDB4MTAwMCkgTVhbQl1FCglbNl0gLTEJMAkweGZlMDJkMDAwIC0g MHhmZTAyZGZmZiAoMHgxMDAwKSBNWFtCXUUKCVs3XSAtMQkwCTB4ZmUwMmUwMDAgLSAweGZlMDJl ZmZmICgweDEwMDApIE1YW0JdRQoJWzhdIC0xCTAJMHhmZTAyZjAwMCAtIDB4ZmUwMmZmZmYgKDB4 MTAwMCkgTVhbQl1FCglbOV0gLTEJMAkweGUwMDAwMDAwIC0gMHhkZmZmZmZmZiAoMHgwKSBNWFtC XUVPCglbMTBdIC0xCTAJMHhmZGRmMDAwMCAtIDB4ZmRkZmZmZmYgKDB4MTAwMDApIE1YW0JdKEIp CglbMTFdIC0xCTAJMHhkMDAwMDAwMCAtIDB4ZGZmZmZmZmYgKDB4MTAwMDAwMDApIE1YW0JdKEIp CglbMTJdIC0xCTAJMHgwMDAwZGUwMCAtIDB4MDAwMGRlZmYgKDB4MTAwKSBJWFtCXUUKCVsxM10g LTEJMAkweDAwMDBkZjAwIC0gMHgwMDAwZGZmZiAoMHgxMDApIElYW0JdRQoJWzE0XSAtMQkwCTB4 MDAwMGYzMDAgLSAweDAwMDBmM2ZmICgweDEwMCkgSVhbQl1FCglbMTVdIC0xCTAJMHgwMDAwMDQw MCAtIDB4MDAwMDA0ZmYgKDB4MTAwKSBJWFtCXUUKCVsxNl0gLTEJMAkweDAwMDBmNTAwIC0gMHgw MDAwZjVmZiAoMHgxMDApIElYW0JdRQoJWzE3XSAtMQkwCTB4MDAwMGY2MDAgLSAweDAwMDBmNmZm ICgweDEwMCkgSVhbQl1FCglbMThdIC0xCTAJMHgwMDAwZjcwMCAtIDB4MDAwMGY3ZmYgKDB4MTAw KSBJWFtCXUUKCVsxOV0gLTEJMAkweDAwMDBmODAwIC0gMHgwMDAwZjhmZiAoMHgxMDApIElYW0Jd RQoJWzIwXSAtMQkwCTB4MDAwMGY5MDAgLSAweDAwMDBmOWZmICgweDEwMCkgSVhbQl1FCglbMjFd IC0xCTAJMHgwMDAwZmEwMCAtIDB4MDAwMGZhZmYgKDB4MTAwKSBJWFtCXUUKCVsyMl0gLTEJMAkw eDAwMDBmYjAwIC0gMHgwMDAwZmJmZiAoMHgxMDApIElYW0JdRQoJWzIzXSAtMQkwCTB4MDAwMGZj MDAgLSAweDAwMDBmY2ZmICgweDEwMCkgSVhbQl1FCglbMjRdIC0xCTAJMHgwMDAwZmQwMCAtIDB4 MDAwMGZkZmYgKDB4MTAwKSBJWFtCXUUKCVsyNV0gLTEJMAkweDAwMDBmZTAwIC0gMHgwMDAwZmVm ZiAoMHgxMDApIElYW0JdRQoJWzI2XSAtMQkwCTB4MDAwMGVmMDAgLSAweDAwMDBlZmZmICgweDEw MCkgSVhbQl0oQikKKElJKSBJbmFjdGl2ZSBQQ0kgcmVzb3VyY2UgcmFuZ2VzIGFmdGVyIHJlbW92 aW5nIG92ZXJsYXBzOgoJWzBdIC0xCTAJMHgwMDAwNDEwMCAtIDB4MDAwMDQwZmYgKDB4MCkgSVhb Ql1FTwooSUkpIE9TLXJlcG9ydGVkIHJlc291cmNlIHJhbmdlcyBhZnRlciByZW1vdmluZyBvdmVy bGFwcyB3aXRoIFBDSToKCVswXSAtMQkwCTB4ZmZmZmZmZmYgLSAweGZmZmZmZmZmICgweDEpIE1Y W0JdCglbMV0gLTEJMAkweDAwMDAwMDAwIC0gMHgwMDAwMDAwMCAoMHgxKSBNWFtCXQoJWzJdIC0x CTAJMHgwMDBjMDAwMCAtIDB4MDAwZWZmZmYgKDB4MzAwMDApIE1YW0JdCglbM10gLTEJMAkweGZm ZmZmZmZmIC0gMHhmZmZmZmZmZiAoMHgxKSBJWFtCXQoJWzRdIC0xCTAJMHgwMDAwMDAwMCAtIDB4 MDAwMDAwZmYgKDB4MTAwKSBJWFtCXQooSUkpIEFsbCBzeXN0ZW0gcmVzb3VyY2UgcmFuZ2VzOgoJ WzBdIC0xCTAJMHhmZmZmZmZmZiAtIDB4ZmZmZmZmZmYgKDB4MSkgTVhbQl0KCVsxXSAtMQkwCTB4 MDAwMDAwMDAgLSAweDAwMDAwMDAwICgweDEpIE1YW0JdCglbMl0gLTEJMAkweDAwMGMwMDAwIC0g MHgwMDBlZmZmZiAoMHgzMDAwMCkgTVhbQl0KCVszXSAtMQkwCTB4ZmRjZmUwMDAgLSAweGZkY2Zl ZmZmICgweDEwMDApIE1YW0JdRQoJWzRdIC0xCTAJMHhmZGNmZjAwMCAtIDB4ZmRjZmZmZmYgKDB4 MTAwMCkgTVhbQl1FCglbNV0gLTEJMAkweGZlMDI5MDAwIC0gMHhmZTAyOWZmZiAoMHgxMDAwKSBN WFtCXUUKCVs2XSAtMQkwCTB4ZmUwMmEwMDAgLSAweGZlMDJhZmZmICgweDEwMDApIE1YW0JdRQoJ WzddIC0xCTAJMHhmZTAyYjAwMCAtIDB4ZmUwMmJmZmYgKDB4MTAwMCkgTVhbQl1FCglbOF0gLTEJ MAkweGZlMDJjMDAwIC0gMHhmZTAyY2ZmZiAoMHgxMDAwKSBNWFtCXUUKCVs5XSAtMQkwCTB4ZmUw MmQwMDAgLSAweGZlMDJkZmZmICgweDEwMDApIE1YW0JdRQoJWzEwXSAtMQkwCTB4ZmUwMmUwMDAg LSAweGZlMDJlZmZmICgweDEwMDApIE1YW0JdRQoJWzExXSAtMQkwCTB4ZmUwMmYwMDAgLSAweGZl MDJmZmZmICgweDEwMDApIE1YW0JdRQoJWzEyXSAtMQkwCTB4ZTAwMDAwMDAgLSAweGRmZmZmZmZm ICgweDApIE1YW0JdRU8KCVsxM10gLTEJMAkweGZkZGYwMDAwIC0gMHhmZGRmZmZmZiAoMHgxMDAw MCkgTVhbQl0oQikKCVsxNF0gLTEJMAkweGQwMDAwMDAwIC0gMHhkZmZmZmZmZiAoMHgxMDAwMDAw MCkgTVhbQl0oQikKCVsxNV0gLTEJMAkweGZmZmZmZmZmIC0gMHhmZmZmZmZmZiAoMHgxKSBJWFtC XQoJWzE2XSAtMQkwCTB4MDAwMDAwMDAgLSAweDAwMDAwMGZmICgweDEwMCkgSVhbQl0KCVsxN10g LTEJMAkweDAwMDBkZTAwIC0gMHgwMDAwZGVmZiAoMHgxMDApIElYW0JdRQoJWzE4XSAtMQkwCTB4 MDAwMGRmMDAgLSAweDAwMDBkZmZmICgweDEwMCkgSVhbQl1FCglbMTldIC0xCTAJMHgwMDAwZjMw MCAtIDB4MDAwMGYzZmYgKDB4MTAwKSBJWFtCXUUKCVsyMF0gLTEJMAkweDAwMDAwNDAwIC0gMHgw MDAwMDRmZiAoMHgxMDApIElYW0JdRQoJWzIxXSAtMQkwCTB4MDAwMGY1MDAgLSAweDAwMDBmNWZm ICgweDEwMCkgSVhbQl1FCglbMjJdIC0xCTAJMHgwMDAwZjYwMCAtIDB4MDAwMGY2ZmYgKDB4MTAw KSBJWFtCXUUKCVsyM10gLTEJMAkweDAwMDBmNzAwIC0gMHgwMDAwZjdmZiAoMHgxMDApIElYW0Jd RQoJWzI0XSAtMQkwCTB4MDAwMGY4MDAgLSAweDAwMDBmOGZmICgweDEwMCkgSVhbQl1FCglbMjVd IC0xCTAJMHgwMDAwZjkwMCAtIDB4MDAwMGY5ZmYgKDB4MTAwKSBJWFtCXUUKCVsyNl0gLTEJMAkw eDAwMDBmYTAwIC0gMHgwMDAwZmFmZiAoMHgxMDApIElYW0JdRQoJWzI3XSAtMQkwCTB4MDAwMGZi MDAgLSAweDAwMDBmYmZmICgweDEwMCkgSVhbQl1FCglbMjhdIC0xCTAJMHgwMDAwZmMwMCAtIDB4 MDAwMGZjZmYgKDB4MTAwKSBJWFtCXUUKCVsyOV0gLTEJMAkweDAwMDBmZDAwIC0gMHgwMDAwZmRm ZiAoMHgxMDApIElYW0JdRQoJWzMwXSAtMQkwCTB4MDAwMGZlMDAgLSAweDAwMDBmZWZmICgweDEw MCkgSVhbQl1FCglbMzFdIC0xCTAJMHgwMDAwZWYwMCAtIDB4MDAwMGVmZmYgKDB4MTAwKSBJWFtC XShCKQoJWzMyXSAtMQkwCTB4MDAwMDQxMDAgLSAweDAwMDA0MGZmICgweDApIElYW0JdRU8KKElJ KSBMb2FkTW9kdWxlOiAiZXh0bW9kIgooSUkpIExvYWRpbmcgL3Vzci9YMTFSNi9saWIvbW9kdWxl cy9leHRlbnNpb25zL2xpYmV4dG1vZC5zbwooSUkpIE1vZHVsZSBleHRtb2Q6IHZlbmRvcj0iWC5P cmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciA2LjguOTkuNSwgbW9kdWxlIHZlcnNpb24gPSAx LjAuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uCglBQkkgY2xhc3M6IFgu T3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMC4yCihJSSkgTG9hZGluZyBleHRlbnNpb24g U0hBUEUKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBNSVQtU1VORFJZLU5PTlNUQU5EQVJECihJSSkg TG9hZGluZyBleHRlbnNpb24gQklHLVJFUVVFU1RTCihJSSkgTG9hZGluZyBleHRlbnNpb24gU1lO QwooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIE1JVC1TQ1JFRU4tU0FWRVIKKElJKSBMb2FkaW5nIGV4 dGVuc2lvbiBYQy1NSVNDCihJSSkgTG9hZGluZyBleHRlbnNpb24gWEZyZWU4Ni1WaWRNb2RlRXh0 ZW5zaW9uCihJSSkgTG9hZGluZyBleHRlbnNpb24gWEZyZWU4Ni1NaXNjCihJSSkgTG9hZGluZyBl eHRlbnNpb24gWEZyZWU4Ni1ER0EKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBEUE1TCihJSSkgTG9h ZGluZyBleHRlbnNpb24gVE9HLUNVUAooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIEV4dGVuZGVkLVZp c3VhbC1JbmZvcm1hdGlvbgooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFhWaWRlbwooSUkpIExvYWRp bmcgZXh0ZW5zaW9uIFhWaWRlby1Nb3Rpb25Db21wZW5zYXRpb24KKElJKSBMb2FkaW5nIGV4dGVu c2lvbiBYLVJlc291cmNlCihJSSkgTG9hZE1vZHVsZTogImdseCIKKElJKSBMb2FkaW5nIC91c3Iv WDExUjYvbGliL21vZHVsZXMvZXh0ZW5zaW9ucy9saWJnbHguc28KKElJKSBNb2R1bGUgZ2x4OiB2 ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgNi44Ljk5LjUsIG1vZHVsZSB2 ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4dGVuc2lvbiwgdmVyc2lv biAwLjIKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgIkdMY29yZSIKKElJKSBMb2FkTW9kdWxlOiAi R0xjb3JlIgooSUkpIExvYWRpbmcgL3Vzci9YMTFSNi9saWIvbW9kdWxlcy9leHRlbnNpb25zL2xp YkdMY29yZS5zbwooSUkpIE1vZHVsZSBHTGNvcmU6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIK CWNvbXBpbGVkIGZvciA2LjguOTkuNSwgbW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJQUJJIGNsYXNz OiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uLCB2ZXJzaW9uIDAuMgooSUkpIExvYWRpbmcgZXh0ZW5z aW9uIEdMWAooSUkpIExvYWRNb2R1bGU6ICJkcmkiCihJSSkgTG9hZGluZyAvdXNyL1gxMVI2L2xp Yi9tb2R1bGVzL2V4dGVuc2lvbnMvbGliZHJpLnNvCihJSSkgTW9kdWxlIGRyaTogdmVuZG9yPSJY Lk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDYuOC45OS41LCBtb2R1bGUgdmVyc2lvbiA9 IDEuMC4wCglBQkkgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMC4yCihJ SSkgTG9hZGluZyBzdWIgbW9kdWxlICJkcm0iCihJSSkgTG9hZE1vZHVsZTogImRybSIKKElJKSBM b2FkaW5nIC91c3IvWDExUjYvbGliL21vZHVsZXMvZnJlZWJzZC9saWJkcm0uc28KKElJKSBNb2R1 bGUgZHJtOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgNi44Ljk5LjUs IG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4dGVuc2lv biwgdmVyc2lvbiAwLjIKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBYRnJlZTg2LURSSQooSUkpIExv YWRNb2R1bGU6ICJkYmUiCihJSSkgTG9hZGluZyAvdXNyL1gxMVI2L2xpYi9tb2R1bGVzL2V4dGVu c2lvbnMvbGliZGJlLnNvCihJSSkgTW9kdWxlIGRiZTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9u IgoJY29tcGlsZWQgZm9yIDYuOC45OS41LCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglNb2R1bGUg Y2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24KCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4 dGVuc2lvbiwgdmVyc2lvbiAwLjIKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBET1VCTEUtQlVGRkVS CihJSSkgTG9hZE1vZHVsZTogInJlY29yZCIKKElJKSBMb2FkaW5nIC91c3IvWDExUjYvbGliL21v ZHVsZXMvZXh0ZW5zaW9ucy9saWJyZWNvcmQuc28KKElJKSBNb2R1bGUgcmVjb3JkOiB2ZW5kb3I9 IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgNi44Ljk5LjUsIG1vZHVsZSB2ZXJzaW9u ID0gMS4xMy4wCglNb2R1bGUgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24KCUFCSSBjbGFz czogWC5PcmcgU2VydmVyIEV4dGVuc2lvbiwgdmVyc2lvbiAwLjIKKElJKSBMb2FkaW5nIGV4dGVu c2lvbiBSRUNPUkQKKElJKSBMb2FkTW9kdWxlOiAieHRyYXAiCihJSSkgTG9hZGluZyAvdXNyL1gx MVI2L2xpYi9tb2R1bGVzL2V4dGVuc2lvbnMvbGlieHRyYXAuc28KKElJKSBNb2R1bGUgeHRyYXA6 IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciA2LjguOTkuNSwgbW9kdWxl IHZlcnNpb24gPSAxLjAuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uCglB QkkgY2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMC4yCihJSSkgTG9hZGlu ZyBleHRlbnNpb24gREVDLVhUUkFQCihJSSkgTG9hZE1vZHVsZTogInR5cGUxIgooSUkpIExvYWRp bmcgL3Vzci9YMTFSNi9saWIvbW9kdWxlcy9mb250cy9saWJ0eXBlMS5zbwooSUkpIE1vZHVsZSB0 eXBlMTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDYuOC45OS41LCBt b2R1bGUgdmVyc2lvbiA9IDEuMC4yCglNb2R1bGUgY2xhc3M6IFguT3JnIEZvbnQgUmVuZGVyZXIK CUFCSSBjbGFzczogWC5PcmcgRm9udCBSZW5kZXJlciwgdmVyc2lvbiAwLjQKKElJKSBMb2FkaW5n IGZvbnQgVHlwZTEKKElJKSBMb2FkaW5nIGZvbnQgQ0lECihJSSkgTG9hZE1vZHVsZTogImZyZWV0 eXBlIgooSUkpIExvYWRpbmcgL3Vzci9YMTFSNi9saWIvbW9kdWxlcy9mb250cy9saWJmcmVldHlw ZS5zbwooSUkpIE1vZHVsZSBmcmVldHlwZTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uICYgdGhl IEFmdGVyIFgtVFQgUHJvamVjdCIKCWNvbXBpbGVkIGZvciA2LjguOTkuNSwgbW9kdWxlIHZlcnNp b24gPSAyLjEuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBGb250IFJlbmRlcmVyCglBQkkgY2xhc3M6 IFguT3JnIEZvbnQgUmVuZGVyZXIsIHZlcnNpb24gMC40CihJSSkgTG9hZGluZyBmb250IEZyZWVU eXBlCihJSSkgTG9hZE1vZHVsZTogInZlc2EiCihJSSkgTG9hZGluZyAvdXNyL1gxMVI2L2xpYi9t b2R1bGVzL2RyaXZlcnMvdmVzYV9kcnYuc28KKElJKSBNb2R1bGUgdmVzYTogdmVuZG9yPSJYLk9y ZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDYuOC45OS41LCBtb2R1bGUgdmVyc2lvbiA9IDEu MC4wCglNb2R1bGUgY2xhc3M6IFguT3JnIFZpZGVvIERyaXZlcgoJQUJJIGNsYXNzOiBYLk9yZyBW aWRlbyBEcml2ZXIsIHZlcnNpb24gMC43CihJSSkgTG9hZE1vZHVsZTogIm1vdXNlIgooSUkpIExv YWRpbmcgL3Vzci9YMTFSNi9saWIvbW9kdWxlcy9pbnB1dC9tb3VzZV9kcnYuc28KKElJKSBNb2R1 bGUgbW91c2U6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciA2LjguOTku NSwgbW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBYSW5wdXQgRHJp dmVyCglBQkkgY2xhc3M6IFguT3JnIFhJbnB1dCBkcml2ZXIsIHZlcnNpb24gMC40CihJSSkgTG9h ZE1vZHVsZTogImtiZCIKKElJKSBMb2FkaW5nIC91c3IvWDExUjYvbGliL21vZHVsZXMvaW5wdXQv a2JkX2Rydi5zbwooSUkpIE1vZHVsZSBrYmQ6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlvbiIKCWNv bXBpbGVkIGZvciA2LjguOTkuNSwgbW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJTW9kdWxlIGNsYXNz OiBYLk9yZyBYSW5wdXQgRHJpdmVyCglBQkkgY2xhc3M6IFguT3JnIFhJbnB1dCBkcml2ZXIsIHZl cnNpb24gMC40CihJSSkgVkVTQTogZHJpdmVyIGZvciBWRVNBIGNoaXBzZXRzOiB2ZXNhCihJSSkg UHJpbWFyeSBEZXZpY2UgaXM6IFBDSSAwMTowNTowCigtLSkgQ2hpcHNldCB2ZXNhIGZvdW5kCihJ SSkgcmVzb3VyY2UgcmFuZ2VzIGFmdGVyIHhmODZDbGFpbUZpeGVkUmVzb3VyY2VzKCkgY2FsbDoK CVswXSAtMQkwCTB4ZmZmZmZmZmYgLSAweGZmZmZmZmZmICgweDEpIE1YW0JdCglbMV0gLTEJMAkw eDAwMDAwMDAwIC0gMHgwMDAwMDAwMCAoMHgxKSBNWFtCXQoJWzJdIC0xCTAJMHgwMDBjMDAwMCAt IDB4MDAwZWZmZmYgKDB4MzAwMDApIE1YW0JdCglbM10gLTEJMAkweGZkY2ZlMDAwIC0gMHhmZGNm ZWZmZiAoMHgxMDAwKSBNWFtCXUUKCVs0XSAtMQkwCTB4ZmRjZmYwMDAgLSAweGZkY2ZmZmZmICgw eDEwMDApIE1YW0JdRQoJWzVdIC0xCTAJMHhmZTAyOTAwMCAtIDB4ZmUwMjlmZmYgKDB4MTAwMCkg TVhbQl1FCglbNl0gLTEJMAkweGZlMDJhMDAwIC0gMHhmZTAyYWZmZiAoMHgxMDAwKSBNWFtCXUUK CVs3XSAtMQkwCTB4ZmUwMmIwMDAgLSAweGZlMDJiZmZmICgweDEwMDApIE1YW0JdRQoJWzhdIC0x CTAJMHhmZTAyYzAwMCAtIDB4ZmUwMmNmZmYgKDB4MTAwMCkgTVhbQl1FCglbOV0gLTEJMAkweGZl MDJkMDAwIC0gMHhmZTAyZGZmZiAoMHgxMDAwKSBNWFtCXUUKCVsxMF0gLTEJMAkweGZlMDJlMDAw IC0gMHhmZTAyZWZmZiAoMHgxMDAwKSBNWFtCXUUKCVsxMV0gLTEJMAkweGZlMDJmMDAwIC0gMHhm ZTAyZmZmZiAoMHgxMDAwKSBNWFtCXUUKCVsxMl0gLTEJMAkweGUwMDAwMDAwIC0gMHhkZmZmZmZm ZiAoMHgwKSBNWFtCXUVPCglbMTNdIC0xCTAJMHhmZGRmMDAwMCAtIDB4ZmRkZmZmZmYgKDB4MTAw MDApIE1YW0JdKEIpCglbMTRdIC0xCTAJMHhkMDAwMDAwMCAtIDB4ZGZmZmZmZmYgKDB4MTAwMDAw MDApIE1YW0JdKEIpCglbMTVdIC0xCTAJMHhmZmZmZmZmZiAtIDB4ZmZmZmZmZmYgKDB4MSkgSVhb Ql0KCVsxNl0gLTEJMAkweDAwMDAwMDAwIC0gMHgwMDAwMDBmZiAoMHgxMDApIElYW0JdCglbMTdd IC0xCTAJMHgwMDAwZGUwMCAtIDB4MDAwMGRlZmYgKDB4MTAwKSBJWFtCXUUKCVsxOF0gLTEJMAkw eDAwMDBkZjAwIC0gMHgwMDAwZGZmZiAoMHgxMDApIElYW0JdRQoJWzE5XSAtMQkwCTB4MDAwMGYz MDAgLSAweDAwMDBmM2ZmICgweDEwMCkgSVhbQl1FCglbMjBdIC0xCTAJMHgwMDAwMDQwMCAtIDB4 MDAwMDA0ZmYgKDB4MTAwKSBJWFtCXUUKCVsyMV0gLTEJMAkweDAwMDBmNTAwIC0gMHgwMDAwZjVm ZiAoMHgxMDApIElYW0JdRQoJWzIyXSAtMQkwCTB4MDAwMGY2MDAgLSAweDAwMDBmNmZmICgweDEw MCkgSVhbQl1FCglbMjNdIC0xCTAJMHgwMDAwZjcwMCAtIDB4MDAwMGY3ZmYgKDB4MTAwKSBJWFtC XUUKCVsyNF0gLTEJMAkweDAwMDBmODAwIC0gMHgwMDAwZjhmZiAoMHgxMDApIElYW0JdRQoJWzI1 XSAtMQkwCTB4MDAwMGY5MDAgLSAweDAwMDBmOWZmICgweDEwMCkgSVhbQl1FCglbMjZdIC0xCTAJ MHgwMDAwZmEwMCAtIDB4MDAwMGZhZmYgKDB4MTAwKSBJWFtCXUUKCVsyN10gLTEJMAkweDAwMDBm YjAwIC0gMHgwMDAwZmJmZiAoMHgxMDApIElYW0JdRQoJWzI4XSAtMQkwCTB4MDAwMGZjMDAgLSAw eDAwMDBmY2ZmICgweDEwMCkgSVhbQl1FCglbMjldIC0xCTAJMHgwMDAwZmQwMCAtIDB4MDAwMGZk ZmYgKDB4MTAwKSBJWFtCXUUKCVszMF0gLTEJMAkweDAwMDBmZTAwIC0gMHgwMDAwZmVmZiAoMHgx MDApIElYW0JdRQoJWzMxXSAtMQkwCTB4MDAwMGVmMDAgLSAweDAwMDBlZmZmICgweDEwMCkgSVhb Ql0oQikKCVszMl0gLTEJMAkweDAwMDA0MTAwIC0gMHgwMDAwNDBmZiAoMHgwKSBJWFtCXUVPCihJ SSkgcmVzb3VyY2UgcmFuZ2VzIGFmdGVyIHByb2Jpbmc6CglbMF0gLTEJMAkweGZmZmZmZmZmIC0g MHhmZmZmZmZmZiAoMHgxKSBNWFtCXQoJWzFdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwMDAwMDAg KDB4MSkgTVhbQl0KCVsyXSAtMQkwCTB4MDAwYzAwMDAgLSAweDAwMGVmZmZmICgweDMwMDAwKSBN WFtCXQoJWzNdIC0xCTAJMHhmZGNmZTAwMCAtIDB4ZmRjZmVmZmYgKDB4MTAwMCkgTVhbQl1FCglb NF0gLTEJMAkweGZkY2ZmMDAwIC0gMHhmZGNmZmZmZiAoMHgxMDAwKSBNWFtCXUUKCVs1XSAtMQkw CTB4ZmUwMjkwMDAgLSAweGZlMDI5ZmZmICgweDEwMDApIE1YW0JdRQoJWzZdIC0xCTAJMHhmZTAy YTAwMCAtIDB4ZmUwMmFmZmYgKDB4MTAwMCkgTVhbQl1FCglbN10gLTEJMAkweGZlMDJiMDAwIC0g MHhmZTAyYmZmZiAoMHgxMDAwKSBNWFtCXUUKCVs4XSAtMQkwCTB4ZmUwMmMwMDAgLSAweGZlMDJj ZmZmICgweDEwMDApIE1YW0JdRQoJWzldIC0xCTAJMHhmZTAyZDAwMCAtIDB4ZmUwMmRmZmYgKDB4 MTAwMCkgTVhbQl1FCglbMTBdIC0xCTAJMHhmZTAyZTAwMCAtIDB4ZmUwMmVmZmYgKDB4MTAwMCkg TVhbQl1FCglbMTFdIC0xCTAJMHhmZTAyZjAwMCAtIDB4ZmUwMmZmZmYgKDB4MTAwMCkgTVhbQl1F CglbMTJdIC0xCTAJMHhlMDAwMDAwMCAtIDB4ZGZmZmZmZmYgKDB4MCkgTVhbQl1FTwoJWzEzXSAt MQkwCTB4ZmRkZjAwMDAgLSAweGZkZGZmZmZmICgweDEwMDAwKSBNWFtCXShCKQoJWzE0XSAtMQkw CTB4ZDAwMDAwMDAgLSAweGRmZmZmZmZmICgweDEwMDAwMDAwKSBNWFtCXShCKQoJWzE1XSAwCTAJ MHgwMDBhMDAwMCAtIDB4MDAwYWZmZmYgKDB4MTAwMDApIE1TW0JdCglbMTZdIDAJMAkweDAwMGIw MDAwIC0gMHgwMDBiN2ZmZiAoMHg4MDAwKSBNU1tCXQoJWzE3XSAwCTAJMHgwMDBiODAwMCAtIDB4 MDAwYmZmZmYgKDB4ODAwMCkgTVNbQl0KCVsxOF0gLTEJMAkweGZmZmZmZmZmIC0gMHhmZmZmZmZm ZiAoMHgxKSBJWFtCXQoJWzE5XSAtMQkwCTB4MDAwMDAwMDAgLSAweDAwMDAwMGZmICgweDEwMCkg SVhbQl0KCVsyMF0gLTEJMAkweDAwMDBkZTAwIC0gMHgwMDAwZGVmZiAoMHgxMDApIElYW0JdRQoJ WzIxXSAtMQkwCTB4MDAwMGRmMDAgLSAweDAwMDBkZmZmICgweDEwMCkgSVhbQl1FCglbMjJdIC0x CTAJMHgwMDAwZjMwMCAtIDB4MDAwMGYzZmYgKDB4MTAwKSBJWFtCXUUKCVsyM10gLTEJMAkweDAw MDAwNDAwIC0gMHgwMDAwMDRmZiAoMHgxMDApIElYW0JdRQoJWzI0XSAtMQkwCTB4MDAwMGY1MDAg LSAweDAwMDBmNWZmICgweDEwMCkgSVhbQl1FCglbMjVdIC0xCTAJMHgwMDAwZjYwMCAtIDB4MDAw MGY2ZmYgKDB4MTAwKSBJWFtCXUUKCVsyNl0gLTEJMAkweDAwMDBmNzAwIC0gMHgwMDAwZjdmZiAo MHgxMDApIElYW0JdRQoJWzI3XSAtMQkwCTB4MDAwMGY4MDAgLSAweDAwMDBmOGZmICgweDEwMCkg SVhbQl1FCglbMjhdIC0xCTAJMHgwMDAwZjkwMCAtIDB4MDAwMGY5ZmYgKDB4MTAwKSBJWFtCXUUK CVsyOV0gLTEJMAkweDAwMDBmYTAwIC0gMHgwMDAwZmFmZiAoMHgxMDApIElYW0JdRQoJWzMwXSAt MQkwCTB4MDAwMGZiMDAgLSAweDAwMDBmYmZmICgweDEwMCkgSVhbQl1FCglbMzFdIC0xCTAJMHgw MDAwZmMwMCAtIDB4MDAwMGZjZmYgKDB4MTAwKSBJWFtCXUUKCVszMl0gLTEJMAkweDAwMDBmZDAw IC0gMHgwMDAwZmRmZiAoMHgxMDApIElYW0JdRQoJWzMzXSAtMQkwCTB4MDAwMGZlMDAgLSAweDAw MDBmZWZmICgweDEwMCkgSVhbQl1FCglbMzRdIC0xCTAJMHgwMDAwZWYwMCAtIDB4MDAwMGVmZmYg KDB4MTAwKSBJWFtCXShCKQoJWzM1XSAtMQkwCTB4MDAwMDQxMDAgLSAweDAwMDA0MGZmICgweDAp IElYW0JdRU8KCVszNl0gMAkwCTB4MDAwMDAzYjAgLSAweDAwMDAwM2JiICgweGMpIElTW0JdCglb MzddIDAJMAkweDAwMDAwM2MwIC0gMHgwMDAwMDNkZiAoMHgyMCkgSVNbQl0KKElJKSBTZXR0aW5n IHZnYSBmb3Igc2NyZWVuIDAuCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJ2YmUiCihJSSkgTG9h ZE1vZHVsZTogInZiZSIKKElJKSBMb2FkaW5nIC91c3IvWDExUjYvbGliL21vZHVsZXMvbGlidmJl LnNvCihJSSkgTW9kdWxlIHZiZTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQg Zm9yIDYuOC45OS41LCBtb2R1bGUgdmVyc2lvbiA9IDEuMS4wCglBQkkgY2xhc3M6IFguT3JnIFZp ZGVvIERyaXZlciwgdmVyc2lvbiAwLjcKKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgImludDEwIgoo SUkpIExvYWRNb2R1bGU6ICJpbnQxMCIKKElJKSBMb2FkaW5nIC91c3IvWDExUjYvbGliL21vZHVs ZXMvbGliaW50MTAuc28KKElJKSBNb2R1bGUgaW50MTA6IHZlbmRvcj0iWC5PcmcgRm91bmRhdGlv biIKCWNvbXBpbGVkIGZvciA2LjguOTkuNSwgbW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJQUJJIGNs YXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIsIHZlcnNpb24gMC43CihJSSkgVkVTQSgwKTogaW5pdGlh bGl6aW5nIGludDEwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweGEwMDAw LDB4MjAwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5n IHJhbmdlICgweGMwMDAwLDB4NDAwMDApIHdhcyBhbHJlYWR5IGNsZWFyCihJSSkgVkVTQSgwKTog UHJpbWFyeSBWX0JJT1Mgc2VnbWVudCBpczogMHhjMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCihJSSkgVkVTQSgwKTogVkVTQSBCSU9TIGRldGVjdGVkCihJSSkgVkVTQSgwKTogVkVT QSBWQkUgVmVyc2lvbiAyLjAKKElJKSBWRVNBKDApOiBWRVNBIFZCRSBUb3RhbCBNZW06IDUyODM4 NCBrQgooSUkpIFZFU0EoMCk6IFZFU0EgVkJFIE9FTTogQVRJIFJBREVPTiBYcHJlc3MgMjAwRyBT ZXJpZXMKKElJKSBWRVNBKDApOiBWRVNBIFZCRSBPRU0gU29mdHdhcmUgUmV2OiAxLjAKKElJKSBW RVNBKDApOiBWRVNBIFZCRSBPRU0gVmVuZG9yOiBBVEkgVGVjaG5vbG9naWVzIEluYy4KKElJKSBW RVNBKDApOiBWRVNBIFZCRSBPRU0gUHJvZHVjdDogUlM0OAooSUkpIFZFU0EoMCk6IFZFU0EgVkJF IE9FTSBQcm9kdWN0IFJldjogMDEuMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFu Z2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgw LDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcg cmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUt Y29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0Eo MCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIK KD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJl YWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAw KSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5p bmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3Jp dGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZF U0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xl YXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBh bHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgx MDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5n ZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21i aW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTog V3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0p IFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAs MHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyBy YW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1j b21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgw KTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoo PT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDAp IHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgw eDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmlu ZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVT QSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFs cmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEw MDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdl ICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJp bmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBX cml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkg VkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBj bGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2Fz IGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCww eDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJh bmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNv bWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9 PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFk eSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkg d2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4 MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5n IHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRl LWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNB KDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFy Cig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxy ZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAw MCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2Ug KDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmlu aW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdy aXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBW RVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNs ZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMg YWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4 MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFu Z2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgw LDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcg cmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUt Y29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0Eo MCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIK KD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJl YWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAw KSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5p bmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3Jp dGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZF U0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xl YXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBh bHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgx MDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5n ZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21i aW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTog V3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0p IFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAs MHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyBy YW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1j b21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgw KTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoo PT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDAp IHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgw eDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmlu ZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVT QSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFs cmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEw MDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdl ICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJp bmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBX cml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkg VkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBj bGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2Fz IGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCww eDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJh bmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNv bWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9 PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFk eSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkg d2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4 MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5n IHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRl LWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNB KDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFy Cig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxy ZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAw MCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2Ug KDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmlu aW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdy aXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBW RVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNs ZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMg YWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4 MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFu Z2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgw LDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcg cmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUt Y29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooKiopIFZFU0Eo MCk6IERlcHRoIDI0LCAoLS0pIGZyYW1lYnVmZmVyIGJwcCAyNAooPT0pIFZFU0EoMCk6IFJHQiB3 ZWlnaHQgODg4Cig9PSkgVkVTQSgwKTogRGVmYXVsdCB2aXN1YWwgaXMgVHJ1ZUNvbG9yCig9PSkg VkVTQSgwKTogVXNpbmcgZ2FtbWEgY29ycmVjdGlvbiAoMS4wLCAxLjAsIDEuMCkKKElJKSBMb2Fk aW5nIHN1YiBtb2R1bGUgImRkYyIKKElJKSBMb2FkTW9kdWxlOiAiZGRjIgooSUkpIExvYWRpbmcg L3Vzci9YMTFSNi9saWIvbW9kdWxlcy9saWJkZGMuc28KKElJKSBNb2R1bGUgZGRjOiB2ZW5kb3I9 IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgNi44Ljk5LjUsIG1vZHVsZSB2ZXJzaW9u ID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDAuNwooPT0p IFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCihJSSkgVkVTQSgwKTogVkVTQSBWQkUgRERDIHN1cHBvcnRlZAooSUkp IFZFU0EoMCk6IFZFU0EgVkJFIEREQyBMZXZlbCAyCihJSSkgVkVTQSgwKTogVkVTQSBWQkUgRERD IHRyYW5zZmVyIGluIGFwcHIuIDIgc2VjLgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyBy YW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1j b21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCihJSSkgVkVTQSgw KTogVkVTQSBWQkUgRERDIHJlYWQgc3VjY2Vzc2Z1bGx5CihJSSkgVkVTQSgwKTogTWFudWZhY3R1 cmVyOiBDUFEgIE1vZGVsOiAxMzk1ICBTZXJpYWwjOiAxODI4NTI3NgooSUkpIFZFU0EoMCk6IFll YXI6IDIwMDEgIFdlZWs6IDUwCihJSSkgVkVTQSgwKTogRURJRCBWZXJzaW9uOiAxLjMKKElJKSBW RVNBKDApOiBBbmFsb2cgRGlzcGxheSBJbnB1dCwgIElucHV0IFZvbHRhZ2UgTGV2ZWw6IDAuNzAw LzAuNzAwIFYKKElJKSBWRVNBKDApOiBTeW5jOiAgU2VwYXJhdGUgIENvbXBvc2l0ZSAgU3luY09u R3JlZW4KKElJKSBWRVNBKDApOiBNYXggSC1JbWFnZSBTaXplIFtjbV06IGhvcml6LjogMzYgIHZl cnQuOiAyOQooSUkpIFZFU0EoMCk6IEdhbW1hOiAyLjIwCihJSSkgVkVTQSgwKTogRFBNUyBjYXBh YmlsaXRpZXM6IFN0YW5kQnkgU3VzcGVuZCBPZmY7IFJHQi9Db2xvciBEaXNwbGF5CihJSSkgVkVT QSgwKTogRmlyc3QgZGV0YWlsZWQgdGltaW5nIGlzIHByZWZlcnJlZCBtb2RlCihJSSkgVkVTQSgw KTogcmVkWDogMC42MzMgcmVkWTogMC4zNDAgICBncmVlblg6IDAuMjk1IGdyZWVuWTogMC41OTEK KElJKSBWRVNBKDApOiBibHVlWDogMC4xNDEgYmx1ZVk6IDAuMDk2ICAgd2hpdGVYOiAwLjMxMiB3 aGl0ZVk6IDAuMzI4CihJSSkgVkVTQSgwKTogU3VwcG9ydGVkIFZFU0EgVmlkZW8gTW9kZXM6CihJ SSkgVkVTQSgwKTogNzIweDQwMEA3MEh6CihJSSkgVkVTQSgwKTogNjQweDQ4MEA2MEh6CihJSSkg VkVTQSgwKTogNjQweDQ4MEA2N0h6CihJSSkgVkVTQSgwKTogNjQweDQ4MEA3Mkh6CihJSSkgVkVT QSgwKTogNjQweDQ4MEA3NUh6CihJSSkgVkVTQSgwKTogODAweDYwMEA2MEh6CihJSSkgVkVTQSgw KTogODAweDYwMEA3Mkh6CihJSSkgVkVTQSgwKTogODAweDYwMEA3NUh6CihJSSkgVkVTQSgwKTog ODMyeDYyNEA3NUh6CihJSSkgVkVTQSgwKTogMTAyNHg3NjhANjBIegooSUkpIFZFU0EoMCk6IDEw MjR4NzY4QDcwSHoKKElJKSBWRVNBKDApOiAxMDI0eDc2OEA3NUh6CihJSSkgVkVTQSgwKTogMTI4 MHgxMDI0QDc1SHoKKElJKSBWRVNBKDApOiAxMTUyeDg3MEA3NUh6CihJSSkgVkVTQSgwKTogTWFu dWZhY3R1cmVyJ3MgbWFzazogMAooSUkpIFZFU0EoMCk6IFN1cHBvcnRlZCBGdXR1cmUgVmlkZW8g TW9kZXM6CihJSSkgVkVTQSgwKTogIzA6IGhzaXplOiAxMjgwICB2c2l6ZSAxMDI0ICByZWZyZXNo OiA2MCAgdmlkOiAzMjg5NwooSUkpIFZFU0EoMCk6ICMxOiBoc2l6ZTogMTI4MCAgdnNpemUgMTAy NCAgcmVmcmVzaDogODUgIHZpZDogMzkyOTcKKElJKSBWRVNBKDApOiAjMjogaHNpemU6IDEwMjQg IHZzaXplIDc2OCAgcmVmcmVzaDogODUgIHZpZDogMjI4ODEKKElJKSBWRVNBKDApOiAjMzogaHNp emU6IDgwMCAgdnNpemUgNjAwICByZWZyZXNoOiA4NSAgdmlkOiAyMjg1MwooSUkpIFZFU0EoMCk6 ICM0OiBoc2l6ZTogNjQwICB2c2l6ZSA0ODAgIHJlZnJlc2g6IDg1ICB2aWQ6IDIyODMzCihJSSkg VkVTQSgwKTogU3VwcG9ydGVkIGFkZGl0aW9uYWwgVmlkZW8gTW9kZToKKElJKSBWRVNBKDApOiBj bG9jazogMTA4LjAgTUh6ICAgSW1hZ2UgU2l6ZTogIDM2MCB4IDI5MCBtbQooSUkpIFZFU0EoMCk6 IGhfYWN0aXZlOiAxMjgwICBoX3N5bmM6IDEzMjggIGhfc3luY19lbmQgMTQ0MCBoX2JsYW5rX2Vu ZCAxNjg4IGhfYm9yZGVyOiAwCihJSSkgVkVTQSgwKTogdl9hY3RpdmU6IDEwMjQgIHZfc3luYzog MTAyNSAgdl9zeW5jX2VuZCAxMDI4IHZfYmxhbmtpbmc6IDEwNjYgdl9ib3JkZXI6IDAKKElJKSBW RVNBKDApOiBSYW5nZXM6IFYgbWluOiA1OCAgViBtYXg6IDg1IEh6LCBIIG1pbjogMzIgIEggbWF4 OiA5MSBrSHosIFBpeENsb2NrIG1heCAxNjAgTUh6CihJSSkgVkVTQSgwKTogU2VyaWFsIE5vOiA5 MzVFQTA1WUEwMDEKKElJKSBWRVNBKDApOiBNb25pdG9yIG5hbWU6IENQUSBURlQ4MDMwCihJSSkg VkVTQSgwKTogU2VhcmNoaW5nIGZvciBtYXRjaGluZyBWRVNBIG1vZGUocyk6Cig9PSkgVkVTQSgw KTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoo PT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKTW9kZTogMTgyICgzMjB4MjAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmIKCVdpbkFB dHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJ V2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweGEwMDAKCVdp bkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDMyMAoJWFJlc29sdXRpb246 IDMyMAoJWVJlc29sdXRpb246IDIwMAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDgKCU51bWJl ck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDgKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1v ZGVsOiA0CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDAK CVJlZEZpZWxkUG9zaXRpb246IDAKCUdyZWVuTWFza1NpemU6IDAKCUdyZWVuRmllbGRQb3NpdGlv bjogMAoJQmx1ZU1hc2tTaXplOiAwCglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXpl OiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jh c2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4 MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5n IHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxMGQgKDMyMHgyMDAp CglNb2RlQXR0cmlidXRlczogMHhiYgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0 ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4 YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjogMHhjMDAwNGY0ZgoJQnl0ZXNQ ZXJTY2FubGluZTogNjQwCglYUmVzb2x1dGlvbjogMzIwCglZUmVzb2x1dGlvbjogMjAwCglYQ2hh clNpemU6IDgKCVlDaGFyU2l6ZTogOAoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDog MTUKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVy T2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDUKCVJlZEZpZWxkUG9zaXRpb246IDEwCglHcmVl bk1hc2tTaXplOiA1CglHcmVlbkZpZWxkUG9zaXRpb246IDUKCUJsdWVNYXNrU2l6ZTogNQoJQmx1 ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAK CURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVT QSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFs cmVhZHkgY2xlYXIKTW9kZTogMTBlICgzMjB4MjAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmIKCVdp bkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2 NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweGEwMDAK CVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDY0MAoJWFJlc29sdXRp b246IDMyMAoJWVJlc29sdXRpb246IDIwMAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDgKCU51 bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDE2CglOdW1iZXJPZkJhbmtzOiAxCglNZW1v cnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAyNTQKCVJlZE1hc2tTaXpl OiA1CglSZWRGaWVsZFBvc2l0aW9uOiAxMQoJR3JlZW5NYXNrU2l6ZTogNgoJR3JlZW5GaWVsZFBv c2l0aW9uOiA1CglCbHVlTWFza1NpemU6IDUKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFz a1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQ aHlzQmFzZVB0cjogMHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5n ZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21i aW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCipNb2RlOiAxMGYgKDMy MHgyMDApCglNb2RlQXR0cmlidXRlczogMHhiYgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0 dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21l bnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjogMHhjMDAwNGY0ZgoJ Qnl0ZXNQZXJTY2FubGluZTogOTYwCglYUmVzb2x1dGlvbjogMzIwCglZUmVzb2x1dGlvbjogMjAw CglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogOAoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQ aXhlbDogMjQKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJ TnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDgKCVJlZEZpZWxkUG9zaXRpb246IDE2 CglHcmVlbk1hc2tTaXplOiA4CglHcmVlbkZpZWxkUG9zaXRpb246IDgKCUJsdWVNYXNrU2l6ZTog OAoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRp b246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAwMDAwCig9 PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFk eSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkg d2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMTIwICgzMjB4MjAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4 YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFy aXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAw eGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDEyODAKCVhS ZXNvbHV0aW9uOiAzMjAKCVlSZXNvbHV0aW9uOiAyMDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXpl OiA4CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAzMgoJTnVtYmVyT2ZCYW5rczog MQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMjU0CglSZWRN YXNrU2l6ZTogOAoJUmVkRmllbGRQb3NpdGlvbjogMTYKCUdyZWVuTWFza1NpemU6IDgKCUdyZWVu RmllbGRQb3NpdGlvbjogOAoJQmx1ZU1hc2tTaXplOiA4CglCbHVlRmllbGRQb3NpdGlvbjogMAoJ UnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5m bzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5p bmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3Jp dGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAx OTIgKDMyMHgyNDApCglNb2RlQXR0cmlidXRlczogMHhiYgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJ V2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2lu QVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjogMHhjMDAw NGY0ZgoJQnl0ZXNQZXJTY2FubGluZTogMzIwCglYUmVzb2x1dGlvbjogMzIwCglZUmVzb2x1dGlv bjogMjQwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogOAoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJp dHNQZXJQaXhlbDogOAoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDQKCUJhbmtTaXpl OiAwCglOdW1iZXJPZkltYWdlczogMjU0CglSZWRNYXNrU2l6ZTogMAoJUmVkRmllbGRQb3NpdGlv bjogMAoJR3JlZW5NYXNrU2l6ZTogMAoJR3JlZW5GaWVsZFBvc2l0aW9uOiAwCglCbHVlTWFza1Np emU6IDAKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBv c2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAw MAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFs cmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEw MDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDE5MyAoMzIweDI0MCkKCU1vZGVBdHRyaWJ1dGVz OiAweGJiCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFu dWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVu dDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiA2NDAK CVhSZXNvbHV0aW9uOiAzMjAKCVlSZXNvbHV0aW9uOiAyNDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJT aXplOiA4CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAxNQoJTnVtYmVyT2ZCYW5r czogMQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMjU0CglS ZWRNYXNrU2l6ZTogNQoJUmVkRmllbGRQb3NpdGlvbjogMTAKCUdyZWVuTWFza1NpemU6IDUKCUdy ZWVuRmllbGRQb3NpdGlvbjogNQoJQmx1ZU1hc2tTaXplOiA1CglCbHVlRmllbGRQb3NpdGlvbjog MAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2Rl SW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21i aW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTog V3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2Rl OiAxOTQgKDMyMHgyNDApCglNb2RlQXR0cmlidXRlczogMHhiYgoJV2luQUF0dHJpYnV0ZXM6IDB4 NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJ V2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjogMHhj MDAwNGY0ZgoJQnl0ZXNQZXJTY2FubGluZTogNjQwCglYUmVzb2x1dGlvbjogMzIwCglZUmVzb2x1 dGlvbjogMjQwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogOAoJTnVtYmVyT2ZQbGFuZXM6IDEK CUJpdHNQZXJQaXhlbDogMTYKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5r U2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDUKCVJlZEZpZWxkUG9z aXRpb246IDExCglHcmVlbk1hc2tTaXplOiA2CglHcmVlbkZpZWxkUG9zaXRpb246IDUKCUJsdWVN YXNrU2l6ZTogNQoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZp ZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQw MDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgw LDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKk1vZGU6IDE5NSAoMzIweDI0MCkKCU1vZGVBdHRy aWJ1dGVzOiAweGJiCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglX aW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5C U2VnbWVudDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5l OiA5NjAKCVhSZXNvbHV0aW9uOiAzMjAKCVlSZXNvbHV0aW9uOiAyNDAKCVhDaGFyU2l6ZTogOAoJ WUNoYXJTaXplOiA4CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAyNAoJTnVtYmVy T2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczog MjU0CglSZWRNYXNrU2l6ZTogOAoJUmVkRmllbGRQb3NpdGlvbjogMTYKCUdyZWVuTWFza1NpemU6 IDgKCUdyZWVuRmllbGRQb3NpdGlvbjogOAoJQmx1ZU1hc2tTaXplOiA4CglCbHVlRmllbGRQb3Np dGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29s b3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVT QSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgpNb2RlOiAxOTYgKDMyMHgyNDApCglNb2RlQXR0cmlidXRlczogMHhiYgoJV2luQUF0dHJpYnV0 ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXpl OiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0 cjogMHhjMDAwNGY0ZgoJQnl0ZXNQZXJTY2FubGluZTogMTI4MAoJWFJlc29sdXRpb246IDMyMAoJ WVJlc29sdXRpb246IDI0MAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDgKCU51bWJlck9mUGxh bmVzOiAxCglCaXRzUGVyUGl4ZWw6IDMyCglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDog NgoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAyNTQKCVJlZE1hc2tTaXplOiA4CglSZWRG aWVsZFBvc2l0aW9uOiAxNgoJR3JlZW5NYXNrU2l6ZTogOAoJR3JlZW5GaWVsZFBvc2l0aW9uOiA4 CglCbHVlTWFza1NpemU6IDgKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAK CVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0 cjogMHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4 MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFu Z2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDFhMiAoNDAweDMwMCkKCU1v ZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczog MHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAw CglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNj YW5saW5lOiA0MDAKCVhSZXNvbHV0aW9uOiA0MDAKCVlSZXNvbHV0aW9uOiAzMDAKCVhDaGFyU2l6 ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogOAoJ TnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDQKCUJhbmtTaXplOiAwCglOdW1iZXJPZklt YWdlczogMjU0CglSZWRNYXNrU2l6ZTogMAoJUmVkRmllbGRQb3NpdGlvbjogMAoJR3JlZW5NYXNr U2l6ZTogMAoJR3JlZW5GaWVsZFBvc2l0aW9uOiAwCglCbHVlTWFza1NpemU6IDAKCUJsdWVGaWVs ZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJl Y3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCk1vZGU6IDFhMyAoNDAweDMwMCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0 cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdp blNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5G dW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiA4MDAKCVhSZXNvbHV0aW9uOiA0 MDAKCVlSZXNvbHV0aW9uOiAzMDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVy T2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMTUKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1v ZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDUK CVJlZEZpZWxkUG9zaXRpb246IDEwCglHcmVlbk1hc2tTaXplOiA1CglHcmVlbkZpZWxkUG9zaXRp b246IDUKCUJsdWVNYXNrU2l6ZTogNQoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6 ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNC YXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgw eDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmlu ZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMWE0ICg0MDB4MzAw KQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1 dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAw eGEwMDAKCVdpbkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVz UGVyU2NhbmxpbmU6IDgwMAoJWFJlc29sdXRpb246IDQwMAoJWVJlc29sdXRpb246IDMwMAoJWENo YXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVs OiAxNgoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1i ZXJPZkltYWdlczogMjU0CglSZWRNYXNrU2l6ZTogNQoJUmVkRmllbGRQb3NpdGlvbjogMTEKCUdy ZWVuTWFza1NpemU6IDYKCUdyZWVuRmllbGRQb3NpdGlvbjogNQoJQmx1ZU1hc2tTaXplOiA1CglC bHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjog MAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBW RVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNs ZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMg YWxyZWFkeSBjbGVhcgoqTW9kZTogMWE1ICg0MDB4MzAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmIK CVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5 OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweGEw MDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDEyMDAKCVhSZXNv bHV0aW9uOiA0MDAKCVlSZXNvbHV0aW9uOiAzMDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAx NgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMjQKCU51bWJlck9mQmFua3M6IDEK CU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFz a1NpemU6IDgKCVJlZEZpZWxkUG9zaXRpb246IDE2CglHcmVlbk1hc2tTaXplOiA4CglHcmVlbkZp ZWxkUG9zaXRpb246IDgKCUJsdWVNYXNrU2l6ZTogOAoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJz dmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86 IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5n IHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRl LWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMWE2 ICg0MDB4MzAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdp bkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFT ZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRm NGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDE2MDAKCVhSZXNvbHV0aW9uOiA0MDAKCVlSZXNvbHV0aW9u OiAzMDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJp dHNQZXJQaXhlbDogMzIKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6 ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDgKCVJlZEZpZWxkUG9zaXRp b246IDE2CglHcmVlbk1hc2tTaXplOiA4CglHcmVlbkZpZWxkUG9zaXRpb246IDgKCUJsdWVNYXNr U2l6ZTogOAoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxk UG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAw MDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMg YWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4 MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMWIyICg1MTJ4Mzg0KQoJTW9kZUF0dHJpYnV0 ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdy YW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdt ZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDUx MgoJWFJlc29sdXRpb246IDUxMgoJWVJlc29sdXRpb246IDM4NAoJWENoYXJTaXplOiA4CglZQ2hh clNpemU6IDE2CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiA4CglOdW1iZXJPZkJh bmtzOiAxCglNZW1vcnlNb2RlbDogNAoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAyNTQK CVJlZE1hc2tTaXplOiAwCglSZWRGaWVsZFBvc2l0aW9uOiAwCglHcmVlbk1hc2tTaXplOiAwCglH cmVlbkZpZWxkUG9zaXRpb246IDAKCUJsdWVNYXNrU2l6ZTogMAoJQmx1ZUZpZWxkUG9zaXRpb246 IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9k ZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9k ZTogMWIzICg1MTJ4Mzg0KQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAw eDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQK CVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4 YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDEwMjQKCVhSZXNvbHV0aW9uOiA1MTIKCVlSZXNv bHV0aW9uOiAzODQKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6 IDEKCUJpdHNQZXJQaXhlbDogMTUKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglC YW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDUKCVJlZEZpZWxk UG9zaXRpb246IDEwCglHcmVlbk1hc2tTaXplOiA1CglHcmVlbkZpZWxkUG9zaXRpb246IDUKCUJs dWVNYXNrU2l6ZTogNQoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2 ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAw eGQwMDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAw KSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMWI0ICg1MTJ4Mzg0KQoJTW9kZUF0 dHJpYnV0ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAK CVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdp bkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2Nhbmxp bmU6IDEwMjQKCVhSZXNvbHV0aW9uOiA1MTIKCVlSZXNvbHV0aW9uOiAzODQKCVhDaGFyU2l6ZTog OAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMTYKCU51 bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFn ZXM6IDI1NAoJUmVkTWFza1NpemU6IDUKCVJlZEZpZWxkUG9zaXRpb246IDExCglHcmVlbk1hc2tT aXplOiA2CglHcmVlbkZpZWxkUG9zaXRpb246IDUKCUJsdWVNYXNrU2l6ZTogNQoJQmx1ZUZpZWxk UG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVj dENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgwKTog V3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0p IFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKKk1vZGU6IDFiNSAoNTEyeDM4NCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0 cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdp blNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5G dW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiAxNTM2CglYUmVzb2x1dGlvbjog NTEyCglZUmVzb2x1dGlvbjogMzg0CglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJl ck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDI0CglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlN b2RlbDogNgoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAyNTQKCVJlZE1hc2tTaXplOiA4 CglSZWRGaWVsZFBvc2l0aW9uOiAxNgoJR3JlZW5NYXNrU2l6ZTogOAoJR3JlZW5GaWVsZFBvc2l0 aW9uOiA4CglCbHVlTWFza1NpemU6IDgKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1Np emU6IDAKCVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlz QmFzZVB0cjogMHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5p bmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDFiNiAoNTEyeDM4 NCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmli dXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDog MHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRl c1BlclNjYW5saW5lOiAyMDQ4CglYUmVzb2x1dGlvbjogNTEyCglZUmVzb2x1dGlvbjogMzg0CglY Q2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4 ZWw6IDMyCglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51 bWJlck9mSW1hZ2VzOiAyNTQKCVJlZE1hc2tTaXplOiA4CglSZWRGaWVsZFBvc2l0aW9uOiAxNgoJ R3JlZW5NYXNrU2l6ZTogOAoJR3JlZW5GaWVsZFBvc2l0aW9uOiA4CglCbHVlTWFza1NpemU6IDgK CUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9u OiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAwMAooPT0p IFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCk1vZGU6IDFjMiAoNjQweDM1MCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJi CglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0 eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhh MDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiA2NDAKCVhSZXNv bHV0aW9uOiA2NDAKCVlSZXNvbHV0aW9uOiAzNTAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAx NAoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogOAoJTnVtYmVyT2ZCYW5rczogMQoJ TWVtb3J5TW9kZWw6IDQKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMjU0CglSZWRNYXNr U2l6ZTogMAoJUmVkRmllbGRQb3NpdGlvbjogMAoJR3JlZW5NYXNrU2l6ZTogMAoJR3JlZW5GaWVs ZFBvc2l0aW9uOiAwCglCbHVlTWFza1NpemU6IDAKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3Zk TWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAw CglQaHlzQmFzZVB0cjogMHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyBy YW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1j b21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDFjMyAo NjQweDM1MCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5C QXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2Vn bWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRm CglCeXRlc1BlclNjYW5saW5lOiAxMjgwCglYUmVzb2x1dGlvbjogNjQwCglZUmVzb2x1dGlvbjog MzUwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTQKCU51bWJlck9mUGxhbmVzOiAxCglCaXRz UGVyUGl4ZWw6IDE1CglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6 IDAKCU51bWJlck9mSW1hZ2VzOiAyNTQKCVJlZE1hc2tTaXplOiA1CglSZWRGaWVsZFBvc2l0aW9u OiAxMAoJR3JlZW5NYXNrU2l6ZTogNQoJR3JlZW5GaWVsZFBvc2l0aW9uOiA1CglCbHVlTWFza1Np emU6IDUKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBv c2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAw MAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFs cmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEw MDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDFjNCAoNjQweDM1MCkKCU1vZGVBdHRyaWJ1dGVz OiAweGJiCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFu dWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVu dDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiAxMjgw CglYUmVzb2x1dGlvbjogNjQwCglZUmVzb2x1dGlvbjogMzUwCglYQ2hhclNpemU6IDgKCVlDaGFy U2l6ZTogMTQKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDE2CglOdW1iZXJPZkJh bmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAyNTQK CVJlZE1hc2tTaXplOiA1CglSZWRGaWVsZFBvc2l0aW9uOiAxMQoJR3JlZW5NYXNrU2l6ZTogNgoJ R3JlZW5GaWVsZFBvc2l0aW9uOiA1CglCbHVlTWFza1NpemU6IDUKCUJsdWVGaWVsZFBvc2l0aW9u OiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1v ZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNv bWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCipN b2RlOiAxYzUgKDY0MHgzNTApCglNb2RlQXR0cmlidXRlczogMHhiYgoJV2luQUF0dHJpYnV0ZXM6 IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2 NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjog MHhjMDAwNGY0ZgoJQnl0ZXNQZXJTY2FubGluZTogMTkyMAoJWFJlc29sdXRpb246IDY0MAoJWVJl c29sdXRpb246IDM1MAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE0CglOdW1iZXJPZlBsYW5l czogMQoJQml0c1BlclBpeGVsOiAyNAoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYK CUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMjU0CglSZWRNYXNrU2l6ZTogOAoJUmVkRmll bGRQb3NpdGlvbjogMTYKCUdyZWVuTWFza1NpemU6IDgKCUdyZWVuRmllbGRQb3NpdGlvbjogOAoJ Qmx1ZU1hc2tTaXplOiA4CglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglS c3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6 IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEw MDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdl ICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxYzYgKDY0MHgzNTApCglNb2Rl QXR0cmlidXRlczogMHhiYgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4 MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJ V2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjogMHhjMDAwNGY0ZgoJQnl0ZXNQZXJTY2Fu bGluZTogMjU2MAoJWFJlc29sdXRpb246IDY0MAoJWVJlc29sdXRpb246IDM1MAoJWENoYXJTaXpl OiA4CglZQ2hhclNpemU6IDE0CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAzMgoJ TnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZklt YWdlczogMjU0CglSZWRNYXNrU2l6ZTogOAoJUmVkRmllbGRQb3NpdGlvbjogMTYKCUdyZWVuTWFz a1NpemU6IDgKCUdyZWVuRmllbGRQb3NpdGlvbjogOAoJQmx1ZU1hc2tTaXplOiA4CglCbHVlRmll bGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGly ZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9 PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFk eSBjbGVhcgpNb2RlOiAxMDAgKDY0MHg0MDApCglNb2RlQXR0cmlidXRlczogMHhiYgoJV2luQUF0 dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglX aW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2lu RnVuY1B0cjogMHhjMDAwNGY0ZgoJQnl0ZXNQZXJTY2FubGluZTogNjQwCglYUmVzb2x1dGlvbjog NjQwCglZUmVzb2x1dGlvbjogNDAwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJl ck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDgKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1v ZGVsOiA0CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDAK CVJlZEZpZWxkUG9zaXRpb246IDAKCUdyZWVuTWFza1NpemU6IDAKCUdyZWVuRmllbGRQb3NpdGlv bjogMAoJQmx1ZU1hc2tTaXplOiAwCglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXpl OiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jh c2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4 MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5n IHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxODMgKDY0MHg0MDAp CglNb2RlQXR0cmlidXRlczogMHhiYgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0 ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4 YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjogMHhjMDAwNGY0ZgoJQnl0ZXNQ ZXJTY2FubGluZTogMTI4MAoJWFJlc29sdXRpb246IDY0MAoJWVJlc29sdXRpb246IDQwMAoJWENo YXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVs OiAxNQoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1i ZXJPZkltYWdlczogMjU0CglSZWRNYXNrU2l6ZTogNQoJUmVkRmllbGRQb3NpdGlvbjogMTAKCUdy ZWVuTWFza1NpemU6IDUKCUdyZWVuRmllbGRQb3NpdGlvbjogNQoJQmx1ZU1hc2tTaXplOiA1CglC bHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjog MAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBW RVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNs ZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMg YWxyZWFkeSBjbGVhcgpNb2RlOiAxODQgKDY0MHg0MDApCglNb2RlQXR0cmlidXRlczogMHhiYgoJ V2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6 IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAw MAoJV2luRnVuY1B0cjogMHhjMDAwNGY0ZgoJQnl0ZXNQZXJTY2FubGluZTogMTI4MAoJWFJlc29s dXRpb246IDY0MAoJWVJlc29sdXRpb246IDQwMAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE2 CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAxNgoJTnVtYmVyT2ZCYW5rczogMQoJ TWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMjU0CglSZWRNYXNr U2l6ZTogNQoJUmVkRmllbGRQb3NpdGlvbjogMTEKCUdyZWVuTWFza1NpemU6IDYKCUdyZWVuRmll bGRQb3NpdGlvbjogNQoJQmx1ZU1hc2tTaXplOiA1CglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2 ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzog MAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcg cmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUt Y29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoqTW9kZTogMTg1 ICg2NDB4NDAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdp bkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFT ZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRm NGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDE5MjAKCVhSZXNvbHV0aW9uOiA2NDAKCVlSZXNvbHV0aW9u OiA0MDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJp dHNQZXJQaXhlbDogMjQKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6 ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDgKCVJlZEZpZWxkUG9zaXRp b246IDE2CglHcmVlbk1hc2tTaXplOiA4CglHcmVlbkZpZWxkUG9zaXRpb246IDgKCUJsdWVNYXNr U2l6ZTogOAoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxk UG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAw MDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMg YWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4 MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMTg2ICg2NDB4NDAwKQoJTW9kZUF0dHJpYnV0 ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdy YW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdt ZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDI1 NjAKCVhSZXNvbHV0aW9uOiA2NDAKCVlSZXNvbHV0aW9uOiA0MDAKCVhDaGFyU2l6ZTogOAoJWUNo YXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMzIKCU51bWJlck9m QmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDI1 NAoJUmVkTWFza1NpemU6IDgKCVJlZEZpZWxkUG9zaXRpb246IDE2CglHcmVlbk1hc2tTaXplOiA4 CglHcmVlbkZpZWxkUG9zaXRpb246IDgKCUJsdWVNYXNrU2l6ZTogOAoJQmx1ZUZpZWxkUG9zaXRp b246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9y TW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUt Y29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0Eo MCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIK TW9kZTogMTAxICg2NDB4NDgwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVz OiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTog NjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6 IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDY0MAoJWFJlc29sdXRpb246IDY0MAoJWVJl c29sdXRpb246IDQ4MAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglOdW1iZXJPZlBsYW5l czogMQoJQml0c1BlclBpeGVsOiA4CglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNAoJ QmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAyNTQKCVJlZE1hc2tTaXplOiAwCglSZWRGaWVs ZFBvc2l0aW9uOiAwCglHcmVlbk1hc2tTaXplOiAwCglHcmVlbkZpZWxkUG9zaXRpb246IDAKCUJs dWVNYXNrU2l6ZTogMAoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2 ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAw eGQwMDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAw KSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMTEwICg2NDB4NDgwKQoJTW9kZUF0 dHJpYnV0ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAK CVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdp bkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2Nhbmxp bmU6IDEyODAKCVhSZXNvbHV0aW9uOiA2NDAKCVlSZXNvbHV0aW9uOiA0ODAKCVhDaGFyU2l6ZTog OAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMTUKCU51 bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFn ZXM6IDI1NAoJUmVkTWFza1NpemU6IDUKCVJlZEZpZWxkUG9zaXRpb246IDEwCglHcmVlbk1hc2tT aXplOiA1CglHcmVlbkZpZWxkUG9zaXRpb246IDUKCUJsdWVNYXNrU2l6ZTogNQoJQmx1ZUZpZWxk UG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVj dENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgwKTog V3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0p IFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKTW9kZTogMTExICg2NDB4NDgwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmIKCVdpbkFBdHRy aWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2lu U2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1 bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDEyODAKCVhSZXNvbHV0aW9uOiA2 NDAKCVlSZXNvbHV0aW9uOiA0ODAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVy T2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMTYKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1v ZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDUK CVJlZEZpZWxkUG9zaXRpb246IDExCglHcmVlbk1hc2tTaXplOiA2CglHcmVlbkZpZWxkUG9zaXRp b246IDUKCUJsdWVNYXNrU2l6ZTogNQoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6 ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNC YXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgw eDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmlu ZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKk1vZGU6IDExMiAoNjQweDQ4 MCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmli dXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDog MHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRl c1BlclNjYW5saW5lOiAxOTIwCglYUmVzb2x1dGlvbjogNjQwCglZUmVzb2x1dGlvbjogNDgwCglY Q2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4 ZWw6IDI0CglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51 bWJlck9mSW1hZ2VzOiAyNTQKCVJlZE1hc2tTaXplOiA4CglSZWRGaWVsZFBvc2l0aW9uOiAxNgoJ R3JlZW5NYXNrU2l6ZTogOAoJR3JlZW5GaWVsZFBvc2l0aW9uOiA4CglCbHVlTWFza1NpemU6IDgK CUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9u OiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAwMAooPT0p IFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCk1vZGU6IDEyMSAoNjQweDQ4MCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJi CglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0 eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhh MDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiAyNTYwCglYUmVz b2x1dGlvbjogNjQwCglZUmVzb2x1dGlvbjogNDgwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTog MTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDMyCglOdW1iZXJPZkJhbmtzOiAx CglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAyNTQKCVJlZE1h c2tTaXplOiA4CglSZWRGaWVsZFBvc2l0aW9uOiAxNgoJR3JlZW5NYXNrU2l6ZTogOAoJR3JlZW5G aWVsZFBvc2l0aW9uOiA4CglCbHVlTWFza1NpemU6IDgKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglS c3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZv OiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmlu ZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDEw MyAoODAweDYwMCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0cmlidXRlczogMHg3CglX aW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5B U2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0 ZjRmCglCeXRlc1BlclNjYW5saW5lOiA4MDAKCVhSZXNvbHV0aW9uOiA4MDAKCVlSZXNvbHV0aW9u OiA2MDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNAoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJp dHNQZXJQaXhlbDogOAoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDQKCUJhbmtTaXpl OiAwCglOdW1iZXJPZkltYWdlczogMjU0CglSZWRNYXNrU2l6ZTogMAoJUmVkRmllbGRQb3NpdGlv bjogMAoJR3JlZW5NYXNrU2l6ZTogMAoJR3JlZW5GaWVsZFBvc2l0aW9uOiAwCglCbHVlTWFza1Np emU6IDAKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBv c2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAw MAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFs cmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEw MDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDExMyAoODAweDYwMCkKCU1vZGVBdHRyaWJ1dGVz OiAweGJiCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFu dWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVu dDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiAxNjAw CglYUmVzb2x1dGlvbjogODAwCglZUmVzb2x1dGlvbjogNjAwCglYQ2hhclNpemU6IDgKCVlDaGFy U2l6ZTogMTQKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDE1CglOdW1iZXJPZkJh bmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAyNTQK CVJlZE1hc2tTaXplOiA1CglSZWRGaWVsZFBvc2l0aW9uOiAxMAoJR3JlZW5NYXNrU2l6ZTogNQoJ R3JlZW5GaWVsZFBvc2l0aW9uOiA1CglCbHVlTWFza1NpemU6IDUKCUJsdWVGaWVsZFBvc2l0aW9u OiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1v ZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNv bWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1v ZGU6IDExNCAoODAweDYwMCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0cmlidXRlczog MHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0 CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5GdW5jUHRyOiAw eGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiAxNjAwCglYUmVzb2x1dGlvbjogODAwCglZUmVz b2x1dGlvbjogNjAwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTQKCU51bWJlck9mUGxhbmVz OiAxCglCaXRzUGVyUGl4ZWw6IDE2CglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJ QmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAyNTQKCVJlZE1hc2tTaXplOiA1CglSZWRGaWVs ZFBvc2l0aW9uOiAxMQoJR3JlZW5NYXNrU2l6ZTogNgoJR3JlZW5GaWVsZFBvc2l0aW9uOiA1CglC bHVlTWFza1NpemU6IDUKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJz dmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjog MHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAw MCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2Ug KDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCipNb2RlOiAxMTUgKDgwMHg2MDApCglNb2Rl QXR0cmlidXRlczogMHhiYgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4 MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJ V2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjogMHhjMDAwNGY0ZgoJQnl0ZXNQZXJTY2Fu bGluZTogMjQwMAoJWFJlc29sdXRpb246IDgwMAoJWVJlc29sdXRpb246IDYwMAoJWENoYXJTaXpl OiA4CglZQ2hhclNpemU6IDE0CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAyNAoJ TnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZklt YWdlczogMjU0CglSZWRNYXNrU2l6ZTogOAoJUmVkRmllbGRQb3NpdGlvbjogMTYKCUdyZWVuTWFz a1NpemU6IDgKCUdyZWVuRmllbGRQb3NpdGlvbjogOAoJQmx1ZU1hc2tTaXplOiA4CglCbHVlRmll bGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGly ZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDAp OiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9 PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFk eSBjbGVhcgpNb2RlOiAxMjIgKDgwMHg2MDApCglNb2RlQXR0cmlidXRlczogMHhiYgoJV2luQUF0 dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglX aW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2lu RnVuY1B0cjogMHhjMDAwNGY0ZgoJQnl0ZXNQZXJTY2FubGluZTogMzIwMAoJWFJlc29sdXRpb246 IDgwMAoJWVJlc29sdXRpb246IDYwMAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE0CglOdW1i ZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAzMgoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5 TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMjU0CglSZWRNYXNrU2l6ZTog OAoJUmVkRmllbGRQb3NpdGlvbjogMTYKCUdyZWVuTWFza1NpemU6IDgKCUdyZWVuRmllbGRQb3Np dGlvbjogOAoJQmx1ZU1hc2tTaXplOiA4CglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tT aXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5 c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2Ug KDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmlu aW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxMDUgKDEwMjR4 NzY4KQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRy aWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50 OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5 dGVzUGVyU2NhbmxpbmU6IDEwMjQKCVhSZXNvbHV0aW9uOiAxMDI0CglZUmVzb2x1dGlvbjogNzY4 CglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVy UGl4ZWw6IDgKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA0CglCYW5rU2l6ZTogMAoJ TnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDAKCVJlZEZpZWxkUG9zaXRpb246IDAK CUdyZWVuTWFza1NpemU6IDAKCUdyZWVuRmllbGRQb3NpdGlvbjogMAoJQmx1ZU1hc2tTaXplOiAw CglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlv bjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxMTYgKDEwMjR4NzY4KQoJTW9kZUF0dHJpYnV0ZXM6IDB4 YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFy aXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAw eGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDIwNDgKCVhS ZXNvbHV0aW9uOiAxMDI0CglZUmVzb2x1dGlvbjogNzY4CglYQ2hhclNpemU6IDgKCVlDaGFyU2l6 ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDE1CglOdW1iZXJPZkJhbmtz OiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiAyNTQKCVJl ZE1hc2tTaXplOiA1CglSZWRGaWVsZFBvc2l0aW9uOiAxMAoJR3JlZW5NYXNrU2l6ZTogNQoJR3Jl ZW5GaWVsZFBvc2l0aW9uOiA1CglCbHVlTWFza1NpemU6IDUKCUJsdWVGaWVsZFBvc2l0aW9uOiAw CglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJ bmZvOiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJp bmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBX cml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6 IDExNyAoMTAyNHg3NjgpCglNb2RlQXR0cmlidXRlczogMHhiYgoJV2luQUF0dHJpYnV0ZXM6IDB4 NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJ V2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjogMHhj MDAwNGY0ZgoJQnl0ZXNQZXJTY2FubGluZTogMjA0OAoJWFJlc29sdXRpb246IDEwMjQKCVlSZXNv bHV0aW9uOiA3NjgKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6 IDEKCUJpdHNQZXJQaXhlbDogMTYKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglC YW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDI1NAoJUmVkTWFza1NpemU6IDUKCVJlZEZpZWxk UG9zaXRpb246IDExCglHcmVlbk1hc2tTaXplOiA2CglHcmVlbkZpZWxkUG9zaXRpb246IDUKCUJs dWVNYXNrU2l6ZTogNQoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2 ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAw eGQwMDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAw KSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKk1vZGU6IDExOCAoMTAyNHg3NjgpCglNb2Rl QXR0cmlidXRlczogMHhiYgoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4 MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJ V2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjogMHhjMDAwNGY0ZgoJQnl0ZXNQZXJTY2Fu bGluZTogMzA3MgoJWFJlc29sdXRpb246IDEwMjQKCVlSZXNvbHV0aW9uOiA3NjgKCVhDaGFyU2l6 ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMjQK CU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJ bWFnZXM6IDIyOAoJUmVkTWFza1NpemU6IDgKCVJlZEZpZWxkUG9zaXRpb246IDE2CglHcmVlbk1h c2tTaXplOiA4CglHcmVlbkZpZWxkUG9zaXRpb246IDgKCUJsdWVNYXNrU2l6ZTogOAoJQmx1ZUZp ZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURp cmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgw KTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgoo PT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKTW9kZTogMTIzICgxMDI0eDc2OCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJhCglXaW5B QXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQK CVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAwCglX aW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiA0MDk2CglYUmVzb2x1dGlv bjogMTAyNAoJWVJlc29sdXRpb246IDc2OAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglO dW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAzMgoJTnVtYmVyT2ZCYW5rczogMQoJTWVt b3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMTcxCglSZWRNYXNrU2l6 ZTogOAoJUmVkRmllbGRQb3NpdGlvbjogMTYKCUdyZWVuTWFza1NpemU6IDgKCUdyZWVuRmllbGRQ b3NpdGlvbjogOAoJQmx1ZU1hc2tTaXplOiA4CglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1h c2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJ UGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFu Z2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxMDcgKDEy ODB4MTAyNCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5C QXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2Vn bWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRm CglCeXRlc1BlclNjYW5saW5lOiAxMjgwCglYUmVzb2x1dGlvbjogMTI4MAoJWVJlc29sdXRpb246 IDEwMjQKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJp dHNQZXJQaXhlbDogOAoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDQKCUJhbmtTaXpl OiAwCglOdW1iZXJPZkltYWdlczogMjU0CglSZWRNYXNrU2l6ZTogMAoJUmVkRmllbGRQb3NpdGlv bjogMAoJR3JlZW5NYXNrU2l6ZTogMAoJR3JlZW5GaWVsZFBvc2l0aW9uOiAwCglCbHVlTWFza1Np emU6IDAKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBv c2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAw MAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFs cmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEw MDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDExOSAoMTI4MHgxMDI0KQoJTW9kZUF0dHJpYnV0 ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdy YW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdt ZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDI1 NjAKCVhSZXNvbHV0aW9uOiAxMjgwCglZUmVzb2x1dGlvbjogMTAyNAoJWENoYXJTaXplOiA4CglZ Q2hhclNpemU6IDE2CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAxNQoJTnVtYmVy T2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczog MjA1CglSZWRNYXNrU2l6ZTogNQoJUmVkRmllbGRQb3NpdGlvbjogMTAKCUdyZWVuTWFza1NpemU6 IDUKCUdyZWVuRmllbGRQb3NpdGlvbjogNQoJQmx1ZU1hc2tTaXplOiA1CglCbHVlRmllbGRQb3Np dGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29s b3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVT QSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgpNb2RlOiAxMWEgKDEyODB4MTAyNCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0cmli dXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNp emU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5GdW5j UHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiAyNTYwCglYUmVzb2x1dGlvbjogMTI4 MAoJWVJlc29sdXRpb246IDEwMjQKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVy T2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMTYKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1v ZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDIwNQoJUmVkTWFza1NpemU6IDUK CVJlZEZpZWxkUG9zaXRpb246IDExCglHcmVlbk1hc2tTaXplOiA2CglHcmVlbkZpZWxkUG9zaXRp b246IDUKCUJsdWVNYXNrU2l6ZTogNQoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6 ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNC YXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgw eDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmlu ZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMTFiICgxMjgweDEw MjQpCglNb2RlQXR0cmlidXRlczogMHhiYQoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJp YnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6 IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjogMHhjMDAwNGY0ZgoJQnl0 ZXNQZXJTY2FubGluZTogMzg0MAoJWFJlc29sdXRpb246IDEyODAKCVlSZXNvbHV0aW9uOiAxMDI0 CglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRzUGVy UGl4ZWw6IDI0CglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6IDAK CU51bWJlck9mSW1hZ2VzOiAxMzYKCVJlZE1hc2tTaXplOiA4CglSZWRGaWVsZFBvc2l0aW9uOiAx NgoJR3JlZW5NYXNrU2l6ZTogOAoJR3JlZW5GaWVsZFBvc2l0aW9uOiA4CglCbHVlTWFza1NpemU6 IDgKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0 aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0cjogMHhkMDAwMDAwMAoo PT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVh ZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDAp IHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDEyNCAoMTI4MHgxMDI0KQoJTW9kZUF0dHJpYnV0ZXM6 IDB4YmEKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51 bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50 OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDUxMjAK CVhSZXNvbHV0aW9uOiAxMjgwCglZUmVzb2x1dGlvbjogMTAyNAoJWENoYXJTaXplOiA4CglZQ2hh clNpemU6IDE2CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVsOiAzMgoJTnVtYmVyT2ZC YW5rczogMQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMTAy CglSZWRNYXNrU2l6ZTogOAoJUmVkRmllbGRQb3NpdGlvbjogMTYKCUdyZWVuTWFza1NpemU6IDgK CUdyZWVuRmllbGRQb3NpdGlvbjogOAoJQmx1ZU1hc2tTaXplOiA4CglCbHVlRmllbGRQb3NpdGlv bjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JN b2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1j b21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgw KTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpN b2RlOiAxNDAgKDE0MDB4MTA1MCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0cmlidXRl czogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6 IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5GdW5jUHRy OiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiAxNDAwCglYUmVzb2x1dGlvbjogMTQwMAoJ WVJlc29sdXRpb246IDEwNTAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQ bGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogOAoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6 IDQKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMjU0CglSZWRNYXNrU2l6ZTogMAoJUmVk RmllbGRQb3NpdGlvbjogMAoJR3JlZW5NYXNrU2l6ZTogMAoJR3JlZW5GaWVsZFBvc2l0aW9uOiAw CglCbHVlTWFza1NpemU6IDAKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3ZkTWFza1NpemU6IDAK CVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAwCglQaHlzQmFzZVB0 cjogMHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4 MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFu Z2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDE0MSAoMTQwMHgxMDUwKQoJ TW9kZUF0dHJpYnV0ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdpbkJBdHRyaWJ1dGVz OiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFTZWdtZW50OiAweGEw MDAKCVdpbkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRmNGYKCUJ5dGVzUGVy U2NhbmxpbmU6IDI4MDAKCVhSZXNvbHV0aW9uOiAxNDAwCglZUmVzb2x1dGlvbjogMTA1MAoJWENo YXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglOdW1iZXJPZlBsYW5lczogMQoJQml0c1BlclBpeGVs OiAxNQoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtTaXplOiAwCglOdW1i ZXJPZkltYWdlczogMTgyCglSZWRNYXNrU2l6ZTogNQoJUmVkRmllbGRQb3NpdGlvbjogMTAKCUdy ZWVuTWFza1NpemU6IDUKCUdyZWVuRmllbGRQb3NpdGlvbjogNQoJQmx1ZU1hc2tTaXplOiA1CglC bHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjog MAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBW RVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNs ZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMg YWxyZWFkeSBjbGVhcgpNb2RlOiAxNDIgKDE0MDB4MTA1MCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJi CglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0 eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhh MDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiAyODAwCglYUmVz b2x1dGlvbjogMTQwMAoJWVJlc29sdXRpb246IDEwNTAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXpl OiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMTYKCU51bWJlck9mQmFua3M6 IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFnZXM6IDE4MgoJUmVk TWFza1NpemU6IDUKCVJlZEZpZWxkUG9zaXRpb246IDExCglHcmVlbk1hc2tTaXplOiA2CglHcmVl bkZpZWxkUG9zaXRpb246IDUKCUJsdWVNYXNrU2l6ZTogNQoJQmx1ZUZpZWxkUG9zaXRpb246IDAK CVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUlu Zm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmlu aW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdy aXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKk1vZGU6 IDE0MyAoMTQwMHgxMDUwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmIKCVdpbkFBdHRyaWJ1dGVzOiAw eDcKCVdpbkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQK CVdpbkFTZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4 YzAwMDRmNGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDQyMDAKCVhSZXNvbHV0aW9uOiAxNDAwCglZUmVz b2x1dGlvbjogMTA1MAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglOdW1iZXJPZlBsYW5l czogMQoJQml0c1BlclBpeGVsOiAyNAoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYK CUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMTIwCglSZWRNYXNrU2l6ZTogOAoJUmVkRmll bGRQb3NpdGlvbjogMTYKCUdyZWVuTWFza1NpemU6IDgKCUdyZWVuRmllbGRQb3NpdGlvbjogOAoJ Qmx1ZU1hc2tTaXplOiA4CglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglS c3ZkRmllbGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6 IDB4ZDAwMDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEw MDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdl ICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxNDQgKDE0MDB4MTA1MCkKCU1v ZGVBdHRyaWJ1dGVzOiAweGJiCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczog MHgwCglXaW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAw CglXaW5CU2VnbWVudDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNj YW5saW5lOiA1NjAwCglYUmVzb2x1dGlvbjogMTQwMAoJWVJlc29sdXRpb246IDEwNTAKCVhDaGFy U2l6ZTogOAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDog MzIKCU51bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVy T2ZJbWFnZXM6IDkwCglSZWRNYXNrU2l6ZTogOAoJUmVkRmllbGRQb3NpdGlvbjogMTYKCUdyZWVu TWFza1NpemU6IDgKCUdyZWVuRmllbGRQb3NpdGlvbjogOAoJQmx1ZU1hc2tTaXplOiA4CglCbHVl RmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmllbGRQb3NpdGlvbjogMAoJ RGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAwMDAwMDAKKD09KSBWRVNB KDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFy Cig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxy ZWFkeSBjbGVhcgpNb2RlOiAxNzIgKDE2MDB4MTIwMCkKCU1vZGVBdHRyaWJ1dGVzOiAweGJiCglX aW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglXaW5HcmFudWxhcml0eTog NjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5CU2VnbWVudDogMHhhMDAw CglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5lOiAxNjAwCglYUmVzb2x1 dGlvbjogMTYwMAoJWVJlc29sdXRpb246IDEyMDAKCVhDaGFyU2l6ZTogOAoJWUNoYXJTaXplOiAx NgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogOAoJTnVtYmVyT2ZCYW5rczogMQoJ TWVtb3J5TW9kZWw6IDQKCUJhbmtTaXplOiAwCglOdW1iZXJPZkltYWdlczogMjU0CglSZWRNYXNr U2l6ZTogMAoJUmVkRmllbGRQb3NpdGlvbjogMAoJR3JlZW5NYXNrU2l6ZTogMAoJR3JlZW5GaWVs ZFBvc2l0aW9uOiAwCglCbHVlTWFza1NpemU6IDAKCUJsdWVGaWVsZFBvc2l0aW9uOiAwCglSc3Zk TWFza1NpemU6IDAKCVJzdmRGaWVsZFBvc2l0aW9uOiAwCglEaXJlY3RDb2xvck1vZGVJbmZvOiAw CglQaHlzQmFzZVB0cjogMHhkMDAwMDAwMAooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyBy YW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1j b21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCk1vZGU6IDE3MyAo MTYwMHgxMjAwKQoJTW9kZUF0dHJpYnV0ZXM6IDB4YmEKCVdpbkFBdHRyaWJ1dGVzOiAweDcKCVdp bkJBdHRyaWJ1dGVzOiAweDAKCVdpbkdyYW51bGFyaXR5OiA2NAoJV2luU2l6ZTogNjQKCVdpbkFT ZWdtZW50OiAweGEwMDAKCVdpbkJTZWdtZW50OiAweGEwMDAKCVdpbkZ1bmNQdHI6IDB4YzAwMDRm NGYKCUJ5dGVzUGVyU2NhbmxpbmU6IDMyMDAKCVhSZXNvbHV0aW9uOiAxNjAwCglZUmVzb2x1dGlv bjogMTIwMAoJWENoYXJTaXplOiA4CglZQ2hhclNpemU6IDE2CglOdW1iZXJPZlBsYW5lczogMQoJ Qml0c1BlclBpeGVsOiAxNQoJTnVtYmVyT2ZCYW5rczogMQoJTWVtb3J5TW9kZWw6IDYKCUJhbmtT aXplOiAwCglOdW1iZXJPZkltYWdlczogMTM4CglSZWRNYXNrU2l6ZTogNQoJUmVkRmllbGRQb3Np dGlvbjogMTAKCUdyZWVuTWFza1NpemU6IDUKCUdyZWVuRmllbGRQb3NpdGlvbjogNQoJQmx1ZU1h c2tTaXplOiA1CglCbHVlRmllbGRQb3NpdGlvbjogMAoJUnN2ZE1hc2tTaXplOiAwCglSc3ZkRmll bGRQb3NpdGlvbjogMAoJRGlyZWN0Q29sb3JNb2RlSW5mbzogMAoJUGh5c0Jhc2VQdHI6IDB4ZDAw MDAwMDAKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAs MHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgpNb2RlOiAxNzQgKDE2MDB4MTIwMCkKCU1vZGVBdHRy aWJ1dGVzOiAweGJhCglXaW5BQXR0cmlidXRlczogMHg3CglXaW5CQXR0cmlidXRlczogMHgwCglX aW5HcmFudWxhcml0eTogNjQKCVdpblNpemU6IDY0CglXaW5BU2VnbWVudDogMHhhMDAwCglXaW5C U2VnbWVudDogMHhhMDAwCglXaW5GdW5jUHRyOiAweGMwMDA0ZjRmCglCeXRlc1BlclNjYW5saW5l OiAzMjAwCglYUmVzb2x1dGlvbjogMTYwMAoJWVJlc29sdXRpb246IDEyMDAKCVhDaGFyU2l6ZTog OAoJWUNoYXJTaXplOiAxNgoJTnVtYmVyT2ZQbGFuZXM6IDEKCUJpdHNQZXJQaXhlbDogMTYKCU51 bWJlck9mQmFua3M6IDEKCU1lbW9yeU1vZGVsOiA2CglCYW5rU2l6ZTogMAoJTnVtYmVyT2ZJbWFn ZXM6IDEzOAoJUmVkTWFza1NpemU6IDUKCVJlZEZpZWxkUG9zaXRpb246IDExCglHcmVlbk1hc2tT aXplOiA2CglHcmVlbkZpZWxkUG9zaXRpb246IDUKCUJsdWVNYXNrU2l6ZTogNQoJQmx1ZUZpZWxk UG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVj dENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgwKTog V3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0p IFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkg Y2xlYXIKTW9kZTogMTc1ICgxNjAweDEyMDApCglNb2RlQXR0cmlidXRlczogMHhiYQoJV2luQUF0 dHJpYnV0ZXM6IDB4NwoJV2luQkF0dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglX aW5TaXplOiA2NAoJV2luQVNlZ21lbnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2lu RnVuY1B0cjogMHhjMDAwNGY0ZgoJQnl0ZXNQZXJTY2FubGluZTogNDgwMAoJWFJlc29sdXRpb246 IDE2MDAKCVlSZXNvbHV0aW9uOiAxMjAwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51 bWJlck9mUGxhbmVzOiAxCglCaXRzUGVyUGl4ZWw6IDI0CglOdW1iZXJPZkJhbmtzOiAxCglNZW1v cnlNb2RlbDogNgoJQmFua1NpemU6IDAKCU51bWJlck9mSW1hZ2VzOiA5MgoJUmVkTWFza1NpemU6 IDgKCVJlZEZpZWxkUG9zaXRpb246IDE2CglHcmVlbk1hc2tTaXplOiA4CglHcmVlbkZpZWxkUG9z aXRpb246IDgKCUJsdWVNYXNrU2l6ZTogOAoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNr U2l6ZTogMAoJUnN2ZEZpZWxkUG9zaXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBo eXNCYXNlUHRyOiAweGQwMDAwMDAwCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdl ICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJp bmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKTW9kZTogMTc2ICgxNjAw eDEyMDApCglNb2RlQXR0cmlidXRlczogMHhiYQoJV2luQUF0dHJpYnV0ZXM6IDB4NwoJV2luQkF0 dHJpYnV0ZXM6IDB4MAoJV2luR3JhbnVsYXJpdHk6IDY0CglXaW5TaXplOiA2NAoJV2luQVNlZ21l bnQ6IDB4YTAwMAoJV2luQlNlZ21lbnQ6IDB4YTAwMAoJV2luRnVuY1B0cjogMHhjMDAwNGY0ZgoJ Qnl0ZXNQZXJTY2FubGluZTogNjQwMAoJWFJlc29sdXRpb246IDE2MDAKCVlSZXNvbHV0aW9uOiAx MjAwCglYQ2hhclNpemU6IDgKCVlDaGFyU2l6ZTogMTYKCU51bWJlck9mUGxhbmVzOiAxCglCaXRz UGVyUGl4ZWw6IDMyCglOdW1iZXJPZkJhbmtzOiAxCglNZW1vcnlNb2RlbDogNgoJQmFua1NpemU6 IDAKCU51bWJlck9mSW1hZ2VzOiA2OAoJUmVkTWFza1NpemU6IDgKCVJlZEZpZWxkUG9zaXRpb246 IDE2CglHcmVlbk1hc2tTaXplOiA4CglHcmVlbkZpZWxkUG9zaXRpb246IDgKCUJsdWVNYXNrU2l6 ZTogOAoJQmx1ZUZpZWxkUG9zaXRpb246IDAKCVJzdmRNYXNrU2l6ZTogMAoJUnN2ZEZpZWxkUG9z aXRpb246IDAKCURpcmVjdENvbG9yTW9kZUluZm86IDAKCVBoeXNCYXNlUHRyOiAweGQwMDAwMDAw CgooSUkpIFZFU0EoMCk6IFRvdGFsIE1lbW9yeTogODI1NiA2NEtCIGJhbmtzICg1MjgzODRrQikK KElJKSBWRVNBKDApOiBNb25pdG9yMDogVXNpbmcgZGVmYXVsdCBoc3luYyByYW5nZSBvZiAzMi4w MC05MS4wMCBrSHoKKElJKSBWRVNBKDApOiBNb25pdG9yMDogVXNpbmcgZGVmYXVsdCB2cmVmcmVz aCByYW5nZSBvZiA1OC4wMC04NS4wMCBIegooSUkpIFZFU0EoMCk6IE5vdCB1c2luZyBtb2RlICIx MjgweDEwMjQiIChubyBtb2RlIG9mIHRoaXMgbmFtZSkKKElJKSBWRVNBKDApOiBOb3QgdXNpbmcg YnVpbHQtaW4gbW9kZSAiMTQwMHgxMDUwIiAod2lkdGggdG9vIGxhcmdlIGZvciB2aXJ0dWFsIHNp emUpCigtLSkgVkVTQSgwKTogVmlydHVhbCBzaXplIGlzIDEwMjR4NzY4IChwaXRjaCAxMDI0KQoo KiopIFZFU0EoMCk6ICpCdWlsdC1pbiBtb2RlICIxMDI0eDc2OCIKKCoqKSBWRVNBKDApOiAgQnVp bHQtaW4gbW9kZSAiODAweDYwMCIKKCoqKSBWRVNBKDApOiAgQnVpbHQtaW4gbW9kZSAiNjQweDQ4 MCIKKCoqKSBWRVNBKDApOiAgQnVpbHQtaW4gbW9kZSAiNjQweDQwMCIKKCoqKSBWRVNBKDApOiAg QnVpbHQtaW4gbW9kZSAiNjQweDM1MCIKKC0tKSBWRVNBKDApOiBEaXNwbGF5IGRpbWVuc2lvbnM6 ICgzNjAsIDI5MCkgbW0KKC0tKSBWRVNBKDApOiBEUEkgc2V0IHRvICg3MiwgNjcpCihJSSkgVkVT QSgwKTogQXR0ZW1wdGluZyB0byB1c2UgODVIeiByZWZyZXNoIGZvciBtb2RlICIxMDI0eDc2OCIg KDExOCkKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdh cyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAs MHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooSUkpIFZFU0EoMCk6IEF0dGVtcHRpbmcgdG8gdXNl IDg1SHogcmVmcmVzaCBmb3IgbW9kZSAiODAweDYwMCIgKDExNSkKKD09KSBWRVNBKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVT QSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgooSUkpIFZFU0EoMCk6IEF0dGVtcHRpbmcgdG8gdXNlIDg1SHogcmVmcmVzaCBmb3IgbW9kZSAi NjQweDQ4MCIgKDExMikKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCww eDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJh bmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooSUkpIFZFU0EoMCk6IEF0dGVtcHRp bmcgdG8gdXNlIDg1SHogcmVmcmVzaCBmb3IgbW9kZSAiNjQweDQwMCIgKDE4NSkKKD09KSBWRVNB KDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFy Cig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxy ZWFkeSBjbGVhcgooSUkpIFZFU0EoMCk6IEF0dGVtcHRpbmcgdG8gdXNlIDg1SHogcmVmcmVzaCBm b3IgbW9kZSAiNjQweDM1MCIgKDFjNSkKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFu Z2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooKiopIFZFU0EoMCk6 IFVzaW5nICJTaGFkb3cgRnJhbWVidWZmZXIiCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJzaGFk b3ciCihJSSkgTG9hZE1vZHVsZTogInNoYWRvdyIKKElJKSBMb2FkaW5nIC91c3IvWDExUjYvbGli L21vZHVsZXMvbGlic2hhZG93LnNvCihJSSkgTW9kdWxlIHNoYWRvdzogdmVuZG9yPSJYLk9yZyBG b3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDYuOC45OS41LCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4w CglBQkkgY2xhc3M6IFguT3JnIEFOU0kgQyBFbXVsYXRpb24sIHZlcnNpb24gMC4yCihJSSkgTG9h ZGluZyBzdWIgbW9kdWxlICJmYiIKKElJKSBMb2FkTW9kdWxlOiAiZmIiCihJSSkgTG9hZGluZyAv dXNyL1gxMVI2L2xpYi9tb2R1bGVzL2xpYmZiLnNvCihJSSkgTW9kdWxlIGZiOiB2ZW5kb3I9Ilgu T3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgNi44Ljk5LjUsIG1vZHVsZSB2ZXJzaW9uID0g MS4wLjAKCUFCSSBjbGFzczogWC5PcmcgQU5TSSBDIEVtdWxhdGlvbiwgdmVyc2lvbiAwLjIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCig9PSkgRGVwdGggMjQgcGl4bWFwIGZvcm1hdCBpcyAzMiBicHAKKElJKSBkbyBJIG5l ZWQgUkFDPyAgTm8sIEkgZG9uJ3QuCihJSSkgcmVzb3VyY2UgcmFuZ2VzIGFmdGVyIHByZUluaXQ6 CglbMF0gLTEJMAkweGZmZmZmZmZmIC0gMHhmZmZmZmZmZiAoMHgxKSBNWFtCXQoJWzFdIC0xCTAJ MHgwMDAwMDAwMCAtIDB4MDAwMDAwMDAgKDB4MSkgTVhbQl0KCVsyXSAtMQkwCTB4MDAwYzAwMDAg LSAweDAwMGVmZmZmICgweDMwMDAwKSBNWFtCXQoJWzNdIC0xCTAJMHhmZGNmZTAwMCAtIDB4ZmRj ZmVmZmYgKDB4MTAwMCkgTVhbQl1FCglbNF0gLTEJMAkweGZkY2ZmMDAwIC0gMHhmZGNmZmZmZiAo MHgxMDAwKSBNWFtCXUUKCVs1XSAtMQkwCTB4ZmUwMjkwMDAgLSAweGZlMDI5ZmZmICgweDEwMDAp IE1YW0JdRQoJWzZdIC0xCTAJMHhmZTAyYTAwMCAtIDB4ZmUwMmFmZmYgKDB4MTAwMCkgTVhbQl1F CglbN10gLTEJMAkweGZlMDJiMDAwIC0gMHhmZTAyYmZmZiAoMHgxMDAwKSBNWFtCXUUKCVs4XSAt MQkwCTB4ZmUwMmMwMDAgLSAweGZlMDJjZmZmICgweDEwMDApIE1YW0JdRQoJWzldIC0xCTAJMHhm ZTAyZDAwMCAtIDB4ZmUwMmRmZmYgKDB4MTAwMCkgTVhbQl1FCglbMTBdIC0xCTAJMHhmZTAyZTAw MCAtIDB4ZmUwMmVmZmYgKDB4MTAwMCkgTVhbQl1FCglbMTFdIC0xCTAJMHhmZTAyZjAwMCAtIDB4 ZmUwMmZmZmYgKDB4MTAwMCkgTVhbQl1FCglbMTJdIC0xCTAJMHhlMDAwMDAwMCAtIDB4ZGZmZmZm ZmYgKDB4MCkgTVhbQl1FTwoJWzEzXSAtMQkwCTB4ZmRkZjAwMDAgLSAweGZkZGZmZmZmICgweDEw MDAwKSBNWFtCXShCKQoJWzE0XSAtMQkwCTB4ZDAwMDAwMDAgLSAweGRmZmZmZmZmICgweDEwMDAw MDAwKSBNWFtCXShCKQoJWzE1XSAwCTAJMHgwMDBhMDAwMCAtIDB4MDAwYWZmZmYgKDB4MTAwMDAp IE1TW0JdCglbMTZdIDAJMAkweDAwMGIwMDAwIC0gMHgwMDBiN2ZmZiAoMHg4MDAwKSBNU1tCXQoJ WzE3XSAwCTAJMHgwMDBiODAwMCAtIDB4MDAwYmZmZmYgKDB4ODAwMCkgTVNbQl0KCVsxOF0gLTEJ MAkweGZmZmZmZmZmIC0gMHhmZmZmZmZmZiAoMHgxKSBJWFtCXQoJWzE5XSAtMQkwCTB4MDAwMDAw MDAgLSAweDAwMDAwMGZmICgweDEwMCkgSVhbQl0KCVsyMF0gLTEJMAkweDAwMDBkZTAwIC0gMHgw MDAwZGVmZiAoMHgxMDApIElYW0JdRQoJWzIxXSAtMQkwCTB4MDAwMGRmMDAgLSAweDAwMDBkZmZm ICgweDEwMCkgSVhbQl1FCglbMjJdIC0xCTAJMHgwMDAwZjMwMCAtIDB4MDAwMGYzZmYgKDB4MTAw KSBJWFtCXUUKCVsyM10gLTEJMAkweDAwMDAwNDAwIC0gMHgwMDAwMDRmZiAoMHgxMDApIElYW0Jd RQoJWzI0XSAtMQkwCTB4MDAwMGY1MDAgLSAweDAwMDBmNWZmICgweDEwMCkgSVhbQl1FCglbMjVd IC0xCTAJMHgwMDAwZjYwMCAtIDB4MDAwMGY2ZmYgKDB4MTAwKSBJWFtCXUUKCVsyNl0gLTEJMAkw eDAwMDBmNzAwIC0gMHgwMDAwZjdmZiAoMHgxMDApIElYW0JdRQoJWzI3XSAtMQkwCTB4MDAwMGY4 MDAgLSAweDAwMDBmOGZmICgweDEwMCkgSVhbQl1FCglbMjhdIC0xCTAJMHgwMDAwZjkwMCAtIDB4 MDAwMGY5ZmYgKDB4MTAwKSBJWFtCXUUKCVsyOV0gLTEJMAkweDAwMDBmYTAwIC0gMHgwMDAwZmFm ZiAoMHgxMDApIElYW0JdRQoJWzMwXSAtMQkwCTB4MDAwMGZiMDAgLSAweDAwMDBmYmZmICgweDEw MCkgSVhbQl1FCglbMzFdIC0xCTAJMHgwMDAwZmMwMCAtIDB4MDAwMGZjZmYgKDB4MTAwKSBJWFtC XUUKCVszMl0gLTEJMAkweDAwMDBmZDAwIC0gMHgwMDAwZmRmZiAoMHgxMDApIElYW0JdRQoJWzMz XSAtMQkwCTB4MDAwMGZlMDAgLSAweDAwMDBmZWZmICgweDEwMCkgSVhbQl1FCglbMzRdIC0xCTAJ MHgwMDAwZWYwMCAtIDB4MDAwMGVmZmYgKDB4MTAwKSBJWFtCXShCKQoJWzM1XSAtMQkwCTB4MDAw MDQxMDAgLSAweDAwMDA0MGZmICgweDApIElYW0JdRU8KCVszNl0gMAkwCTB4MDAwMDAzYjAgLSAw eDAwMDAwM2JiICgweGMpIElTW0JdCglbMzddIDAJMAkweDAwMDAwM2MwIC0gMHgwMDAwMDNkZiAo MHgyMCkgSVNbQl0KKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgImludDEwIgooSUkpIExvYWRNb2R1 bGU6ICJpbnQxMCIKKElJKSBSZWxvYWRpbmcgL3Vzci9YMTFSNi9saWIvbW9kdWxlcy9saWJpbnQx MC5zbwooSUkpIFZFU0EoMCk6IGluaXRpYWxpemluZyBpbnQxMAooPT0pIFZFU0EoMCk6IFdyaXRl LWNvbWJpbmluZyByYW5nZSAoMHhhMDAwMCwweDIwMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooSUkp IFZFU0EoMCk6IFByaW1hcnkgVl9CSU9TIHNlZ21lbnQgaXM6IDB4YzAwMAooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgooSUkpIFZFU0EoMCk6IFZFU0EgQklPUyBkZXRlY3RlZAooSUkpIFZF U0EoMCk6IFZFU0EgVkJFIFZlcnNpb24gMi4wCihJSSkgVkVTQSgwKTogVkVTQSBWQkUgVG90YWwg TWVtOiA1MjgzODQga0IKKElJKSBWRVNBKDApOiBWRVNBIFZCRSBPRU06IEFUSSBSQURFT04gWHBy ZXNzIDIwMEcgU2VyaWVzCihJSSkgVkVTQSgwKTogVkVTQSBWQkUgT0VNIFNvZnR3YXJlIFJldjog MS4wCihJSSkgVkVTQSgwKTogVkVTQSBWQkUgT0VNIFZlbmRvcjogQVRJIFRlY2hub2xvZ2llcyBJ bmMuCihJSSkgVkVTQSgwKTogVkVTQSBWQkUgT0VNIFByb2R1Y3Q6IFJTNDgKKElJKSBWRVNBKDAp OiBWRVNBIFZCRSBPRU0gUHJvZHVjdCBSZXY6IDAxLjAwCihXVykgVkVTQSgwKTogRmFpbGVkIHRv IHNldCB3cml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4ZDAwMDAwMDAsMHgyMDQwMDAwMCkKKElJKSBW RVNBKDApOiB2aXJ0dWFsIGFkZHJlc3MgPSAweDgwMjdmNzAwMCwKCXBoeXNpY2FsIGFkZHJlc3Mg PSAweGQwMDAwMDAwLCBzaXplID0gNTQxMDY1MjE2Cig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmlu aW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdy aXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBW RVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNs ZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMg YWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4 MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFu Z2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29t YmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgw LDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcg cmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCihJSSkgVkVTQSgwKTogVkJFU2V0 VkJFTW9kZSBmYWlsZWQoPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4 MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFu Z2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCi4uLlRyaWVkIGFnYWluIHdpdGhvdXQg Y3VzdG9taXplZCB2YWx1ZXMuCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgw eDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmlu ZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVT QSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVh cgooPT0pIFZFU0EoMCk6IERlZmF1bHQgdmlzdWFsIGlzIFRydWVDb2xvcgooPT0pIFZFU0EoMCk6 IEJhY2tpbmcgc3RvcmUgZGlzYWJsZWQKKD09KSBSYW5kUiBlbmFibGVkCihJSSkgU2V0dGluZyB2 Z2EgZm9yIHNjcmVlbiAwLgooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gTUlU LVNITQooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gWElucHV0RXh0ZW5zaW9u CihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYVEVTVAooSUkpIEluaXRpYWxp emluZyBidWlsdC1pbiBleHRlbnNpb24gWEtFWUJPQVJECihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0 LWluIGV4dGVuc2lvbiBYQy1BUFBHUk9VUAooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRl bnNpb24gU0VDVVJJVFkKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhJTkVS QU1BCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYRklYRVMKKElJKSBJbml0 aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhGcmVlODYtQmlnZm9udAooSUkpIEluaXRpYWxp emluZyBidWlsdC1pbiBleHRlbnNpb24gUkVOREVSCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWlu IGV4dGVuc2lvbiBSQU5EUgooSUkpIEluaXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gQ09N UE9TSVRFCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBEQU1BR0UKKElJKSBJ bml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhFVklFCigqKikgT3B0aW9uICJQcm90b2Nv bCIgImF1dG8iCigqKikgTW91c2UwOiBEZXZpY2U6ICIvZGV2L3N5c21vdXNlIgooKiopIE1vdXNl MDogUHJvdG9jb2w6ICJhdXRvIgooKiopIE9wdGlvbiAiQ29yZVBvaW50ZXIiCigqKikgTW91c2Uw OiBDb3JlIFBvaW50ZXIKKCoqKSBPcHRpb24gIkRldmljZSIgIi9kZXYvc3lzbW91c2UiCig9PSkg TW91c2UwOiBFbXVsYXRlM0J1dHRvbnMsIEVtdWxhdGUzVGltZW91dDogNTAKKD09KSBNb3VzZTA6 IEJ1dHRvbnM6IDMKKCoqKSBPcHRpb24gIkNvcmVLZXlib2FyZCIKKCoqKSBLZXlib2FyZDA6IENv cmUgS2V5Ym9hcmQKKCoqKSBPcHRpb24gIlByb3RvY29sIiAic3RhbmRhcmQiCigqKikgS2V5Ym9h cmQwOiBQcm90b2NvbDogc3RhbmRhcmQKKCoqKSBPcHRpb24gIkF1dG9SZXBlYXQiICI1MDAgMzAi CigqKikgT3B0aW9uICJYa2JSdWxlcyIgInhvcmciCigqKikgS2V5Ym9hcmQwOiBYa2JSdWxlczog InhvcmciCigqKikgT3B0aW9uICJYa2JNb2RlbCIgInBjMTA1IgooKiopIEtleWJvYXJkMDogWGti TW9kZWw6ICJwYzEwNSIKKCoqKSBPcHRpb24gIlhrYkxheW91dCIgIm5vIgooKiopIEtleWJvYXJk MDogWGtiTGF5b3V0OiAibm8iCigqKikgT3B0aW9uICJDdXN0b21LZXljb2RlcyIgIm9mZiIKKCoq KSBLZXlib2FyZDA6IEN1c3RvbUtleWNvZGVzIGRpc2FibGVkCihJSSkgWElOUFVUOiBBZGRpbmcg ZXh0ZW5kZWQgaW5wdXQgZGV2aWNlICJLZXlib2FyZDAiICh0eXBlOiBLRVlCT0FSRCkKKElJKSBY SU5QVVQ6IEFkZGluZyBleHRlbmRlZCBpbnB1dCBkZXZpY2UgIk1vdXNlMCIgKHR5cGU6IE1PVVNF KQooSUkpIE1vdXNlMDogU2V0dXBBdXRvOiBody5pZnR5cGUgaXMgNCwgaHcubW9kZWwgaXMgMAoo SUkpIE1vdXNlMDogU2V0dXBBdXRvOiBwcm90b2NvbCBpcyBTeXNNb3VzZQooPT0pIFZFU0EoMCk6 IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09 KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5 IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3 YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgw LDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIKKD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcg cmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJlYWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUt Y29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0Eo MCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAoMHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIK KD09KSBWRVNBKDApOiBXcml0ZS1jb21iaW5pbmcgcmFuZ2UgKDB4MCwweDEwMDApIHdhcyBhbHJl YWR5IGNsZWFyCig9PSkgVkVTQSgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweDAsMHgxMDAw KSB3YXMgYWxyZWFkeSBjbGVhcgooPT0pIFZFU0EoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHgwLDB4MTAwMCkgd2FzIGFscmVhZHkgY2xlYXIK --Boundary_(ID_txn95BjdN6D/4Yu2u3CePA)-- From owner-freebsd-stable@FreeBSD.ORG Sat May 7 05:38:29 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99AE916A4D8 for ; Sat, 7 May 2005 05:38:29 +0000 (GMT) Received: from smtp801.mail.sc5.yahoo.com (smtp801.mail.sc5.yahoo.com [66.163.168.180]) by mx1.FreeBSD.org (Postfix) with SMTP id 5B0F143D88 for ; Sat, 7 May 2005 05:38:29 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.205.64 with login) by smtp801.mail.sc5.yahoo.com with SMTP; 7 May 2005 05:38:28 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id D7FBC612C; Sat, 7 May 2005 00:38:27 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09008-16-2; Sat, 7 May 2005 00:38:24 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id C4C0360D5; Sat, 7 May 2005 00:38:24 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by compgeek.noacks.org (8.13.3/8.13.3) with ESMTP id j475cOUH004379; Sat, 7 May 2005 00:38:24 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <427C5447.9090800@alumni.rice.edu> Date: Sat, 07 May 2005 00:38:15 -0500 From: Jonathan Noack User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050428) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Torfinn Ingolfsen References: <20050505051530.3235b224.torfinn.ingolfsen@broadpark.no> In-Reply-To: <20050505051530.3235b224.torfinn.ingolfsen@broadpark.no> X-Enigmail-Version: 0.91.0.0 OpenPGP: id=991D8195; url=http://www.noacks.org/cert/noackjr.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA514610C9B277565E2779A04" X-Virus-Scanned: amavisd-new at noacks.org cc: freebsd-stable@freebsd.org Subject: Re: Xorg - getting VESA to work on a Radeon Xpress 200? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2005 05:38:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA514610C9B277565E2779A04 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/04/05 22:15, Torfinn Ingolfsen wrote: > I have an amd64 machine, it has a RS480M2-IL (aka MS-7093) mainboard > (don't ask me what the '-IL' means, I have no idea). > I run the FreeBSD 5-stable branch on the machine: > root@kg-quiet# uname -a > FreeBSD kg-quiet.kg4.no 5.4-STABLE FreeBSD 5.4-STABLE #2: Tue May 3 > 22:40:03 CEST 2005 root@kg-quiet.kg4.no:/usr/obj/usr/src/sys/QUIET > amd64 > > This mainboard have "ATI Radeon Xpress 200" integrated graphics, which > currently isn't supported by any ATI drivers, AFAIK. So I have to use > the VESA driver. > I run this with Xorg 6.8.2 from ports, using the vesa driver, on an LCD > that have 1280x1024 as native resolution. The problem has been that the > vesa driver behaves odd; text (any text) is "blurred" (for lack of a > better word) so that it is difficult / imposiible to read. Except for > that (not so small) problem, Xorg has been working without problems. > > Recently I noticed that there was a new port; xorg-server-snap > (6.8.99.5), so I tried that one. First I tried to autodetect drivers; > xorg suggested the 'ati' driver, but that makes a mess of the display. > so back to the vesa driver again. And to my joy I discovered that text > was crisp and readable again! Nice! > But there is one problem: xorg won't do 1280x1024 anymore. > The log file (/var/log/Xorg.0.log) contains this line: > > (II) VESA(0): Not using mode "1280x1024" (no mode of this name) > > Huh? Earlier on in the log file, it reported: > (II) VESA(0): Supported VESA Video Modes: > (II) VESA(0): 720x400@70Hz > (II) VESA(0): 640x480@60Hz > (II) VESA(0): 640x480@67Hz > (II) VESA(0): 640x480@72Hz > (II) VESA(0): 640x480@75Hz > (II) VESA(0): 800x600@60Hz > (II) VESA(0): 800x600@72Hz > (II) VESA(0): 800x600@75Hz > (II) VESA(0): 832x624@75Hz > (II) VESA(0): 1024x768@60Hz > (II) VESA(0): 1024x768@70Hz > (II) VESA(0): 1024x768@75Hz > (II) VESA(0): 1280x1024@75Hz > (II) VESA(0): 1152x870@75Hz > > The complete Xorg.0.log file is attached. > I tried searching on the net (ok, "googling"), but didn't find anything > that helped. > > Any hints on what I can try to fix this? Support for your chipset was added at the end of March, so it definitely should be in 6.8.99.5: https://bugs.freedesktop.org/show_bug.cgi?id=2827 Try the radeon driver. You may get the same results as the ati driver (I think ati is a generic name that gets you radeon, r128, etc.), but radeon is the correct choice. If it doesn't work you should file a bug. I'm not sure how to fix your VESA problem... -- Jonathan Noack | noackjr@alumni.rice.edu | OpenPGP: 0x991D8195 --------------enigA514610C9B277565E2779A04 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCfFRPUFz01pkdgZURAv3bAJ48d3wH3X0PooU57sRxk4iyFD4c4gCgxz0u oFYHIvm2SBUL0wT151g6bIk= =dZOb -----END PGP SIGNATURE----- --------------enigA514610C9B277565E2779A04-- From owner-freebsd-stable@FreeBSD.ORG Sat May 7 09:51:23 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E8C016A4D8 for ; Sat, 7 May 2005 09:51:23 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCED743D7C for ; Sat, 7 May 2005 09:51:22 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from ranger.anduin.net ([81.0.162.52] helo=[192.168.1.110]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DULxw-0000lu-QH; Sat, 07 May 2005 11:51:21 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 07 May 2005 11:50:18 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: Message-ID: In-Reply-To: <17020.6038.618856.265788@satchel.alerce.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable cc: "stable@freebsd.org" Subject: Re: unionfs limitations? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 09:51:23 -0000 On 07-05-05 03:19, "George Hartzell" wrote: > Eirik =D8verby writes: >> Hi, >>=20 >> I just started playing with mounting ports into jails using unionfs >> (mount_unionfs -b /usr/ports_jail /usr/local/jails/jail-0/usr/ports), an= d >> many things seem to work fine. >> However, when trying to install either of mysql41-server or mysql41-clie= nt, >> I see the following: >>=20 >> [root@mpi1] /usr/ports/databases/mysql41-server# make install >> =3D=3D=3D> Installing for mysql-server-4.1.11_1 >> =3D=3D=3D> mysql-server-4.1.11_1 depends on shared library: mysqlclient.14 - >> found >> =3D=3D=3D> Generating temporary packing list >> =3D=3D=3D> Checking if databases/mysql41-server already installed >> ln: POSIX: Operation not supported >> *** Error code 1 >>=20 >> Stop in /usr/ports/databases/mysql41-server. >>=20 >> Did I miss out on something, or is this not going to work? Do I need to >> think in other ways? >> [...] >=20 > Here's one unionfs/jail gotcha that's bitten me a couple of times. If > you actually *use* (or, have used) the ports directory to build and > install stuff onto the "host" machine, the ports infrastructure in the > jail gets kind of confused. It seems to be checking for the files in > the dependencies, doesn't find them, goes to make them, and then > [depending on what state the relevant port directory is in], things > get "odd". I noticed that pretty early on, yea ;) =20 > I've started just using a virgin ports tree as the underpinnings for > my unionfs'ed jails. Same here.. =20 > Is there any chance that you've installed mysql-server on the host? Indeed I have, but not from that ports tree. What I did was create myself a "template" jail, containing all the base stuff plus some essential ports (perl and stuff). Then I unionfs-mount this one into all of my jails, and customize them at will. Weird thing happened this morning though, suddenly the box seemed half-dead= . I didn't touch it, someone else noticed because they weren't able to ssh in= . TCP connection established, but no auth phase. I also noticed in my active ssh sessions, that things were "dead", in the sense that when on the shell prompt, pressing ENTER only gave me a new, blank line. Logging in via serial console didn't work either, put in username and press ENTER and nothing happened. Best thing was when I tried to enter the debugger, it started spewing huge amounts of crap at me, to a point where I simply had to yank the power (i have remote power sockets, a blessing! ;). Not sure if this was unionfs related, but I'm on 5.4 as of a couple of days ago, so it is entirely possible there's something else weird up. Am I being too much of an optimist, hoping that my unionfs approach will work? The POSIX issue still stands, though. /Eirik From owner-freebsd-stable@FreeBSD.ORG Sat May 7 09:59:38 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BCC316A4D8 for ; Sat, 7 May 2005 09:59:38 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id A277743DAE for ; Sat, 7 May 2005 09:59:37 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from ranger.anduin.net ([81.0.162.52] helo=[192.168.1.110]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DUM5w-0009Bf-Ba; Sat, 07 May 2005 11:59:36 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 07 May 2005 11:58:30 +0200 From: Eirik =?ISO-8859-1?B?2A==?=verby To: "Marc G. Fournier" Message-ID: In-Reply-To: <20050506212107.C42300@ganymede.hub.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable cc: "stable@freebsd.org" Subject: Re: unionfs limitations? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 09:59:38 -0000 On 07-05-05 02:22, "Marc G. Fournier" wrote: > yOn Sat, 7 May 2005, Eirik [ISO-8859-1] =D8verby wrote: >=20 >> Hi, >>=20 >> I just started playing with mounting ports into jails using unionfs >> (mount_unionfs -b /usr/ports_jail /usr/local/jails/jail-0/usr/ports), an= d >> many things seem to work fine. >> However, when trying to install either of mysql41-server or mysql41-clie= nt, >> I see the following: >>=20 >> [root@mpi1] /usr/ports/databases/mysql41-server# make install >> =3D=3D=3D> Installing for mysql-server-4.1.11_1 >> =3D=3D=3D> mysql-server-4.1.11_1 depends on shared library: mysqlclient.14 - >> found >> =3D=3D=3D> Generating temporary packing list >> =3D=3D=3D> Checking if databases/mysql41-server already installed >> ln: POSIX: Operation not supported >> *** Error code 1 >>=20 >> Stop in /usr/ports/databases/mysql41-server. >>=20 >> Did I miss out on something, or is this not going to work? Do I need to >> think in other ways? >> I have stress-tested this setup pretty well over the last 24 hours, with= as >> many as 20 mountpoints using the same ports tree, with constant package >> building in each of them. This was impossible last time I played with >> unionfs, so it must have stabilized somewhat ;) >=20 > What version of FreeBSD? Only issue I've hit so far is just trying SBCL > the other day and getting an MMAP issue that I'm guessing is jail related= , > not unionfs ... 5.4 as of a couple of days ago.. Are you able to install mysql41-server from ports in your unionfs-mounted ports tree? Building works, installing doesn't... /Eirik >=20 > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.or= g) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 76156= 64 From owner-freebsd-stable@FreeBSD.ORG Sat May 7 12:19:51 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63EF516A4DA for ; Sat, 7 May 2005 12:19:51 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFD5E43D9B for ; Sat, 7 May 2005 12:19:50 +0000 (GMT) (envelope-from luktheluckyboy@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1152738wri for ; Sat, 07 May 2005 05:19:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kLoVuoaADyEst2rDUUbVEGidkq2FKbzsuv9pcVzCw/2NOWY0ADsEWtD0fTTL+4Rdkn+KR/kUewe7t5G7vxEvJz7fl5r53moxx69ZWt4mvhbM4E1PrDOY5IH5MShAhwC13tkgahEV4HXoZJ1esTbJoeUEWXRWXQXQrTrRx4qEvxA= Received: by 10.54.45.20 with SMTP id s20mr1365439wrs; Sat, 07 May 2005 05:19:50 -0700 (PDT) Received: by 10.54.34.70 with HTTP; Sat, 7 May 2005 05:19:50 -0700 (PDT) Message-ID: <7b1df2440505070519684d85cd@mail.gmail.com> Date: Sat, 7 May 2005 14:19:50 +0200 From: Luk van den Borne To: Jaimie Garner In-Reply-To: <200505061524.18324.jaimie@onsitepcs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200505061502.45569.jaimie@onsitepcs.net> <20050506221720.GA1162@drjekyll.mkbuelow.net> <200505061524.18324.jaimie@onsitepcs.net> cc: freebsd-stable@freebsd.org Subject: Re: How do i enable DRI support in Xorg? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Luk van den Borne List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2005 12:19:51 -0000 Does FreeBSD already support the i830/i915 DRI drivers? According to http://people.freebsd.org/~anholt/dri/, the i810 is still on the TODO list, which makes me wonder about newer chipsets. I get this error in my xorg log: (II) Loading sub module "drm" (II) LoadModule: "drm" (II) Loading /usr/X11R6/lib/modules/freebsd/libdrm.a (II) Module drm: vendor=3D"X.Org Foundation" drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: open result is -1, (No such file or directory) drmOpenDevice: Open failed [drm] failed to load kernel module "i915" (II) I810(0): [drm] drmOpen failed On 5/7/05, Jaimie Garner wrote: > I asumed it would just gave em a link to shed some light on how I did it = with > Linux. I havent ran X on FreeBSD. > On Friday 06 May 2005 3:17 pm, Matthias Buelow wrote: > > Jaimie Garner wrote: > > >Go here http://dri.freedesktop.org/wiki/Building this helped me to bui= ld > > > Xorg + Mesa and DRI for ATI Radeon on a custome built linux system. > > > Should not be to far off for FreeBSD. > > > > The OP does not have to build Xorg manually. The ports system > > already does this, and his video chipset is old enough to be supported > > by the latest release Xorg (if it isn't, then a CVS Xorg won't help.) > > > > The OP could post the error messages pertaining to DRI > > (from /var/log/Xorg.0.log) plus the output from "xdriinfo" > > and "kldstat". > > > > mkb. > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" >=20 > -- > Jaimie Garner > Onsite PCS inc. > 323 SE RIverside AV > Grants Pass, OR 97526 > 541.471.1343 > 866.471.1343 > jaimie@onsitepcs.net > www.onistepcs.net > _______________________________________________ > 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 May 7 13:06:33 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37F6416A4DA for ; Sat, 7 May 2005 13:06:33 +0000 (GMT) Received: from mail.tpgi.com.au (mail5.tpgi.com.au [203.12.160.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC22543D7C for ; Sat, 7 May 2005 13:06:31 +0000 (GMT) (envelope-from agh@tpg.com.au) Received: from [192.168.0.2] (220-244-72-6.tpgi.com.au [220.244.72.6]) by mail.tpgi.com.au (8.12.10/8.12.10) with ESMTP id j47D6Fci017292 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 7 May 2005 23:06:17 +1000 From: "Alastair G. Hogge" To: freebsd-stable@FreeBSD.ORG Date: Sat, 7 May 2005 23:11:29 +1000 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_B6LfC6D2DgH28pR" Message-Id: <200505072311.29880.agh@tpg.com.au> X-TPG-Antivirus: Passed X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Can no longer update any ports. Configure problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 13:06:33 -0000 --Boundary-00=_B6LfC6D2DgH28pR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I get the following for a whole bunch of out dated ports on my system. This is taken from autoconf, but it's basicly the same for all other ports. ===> Vulnerability check disabled, database not found ===> Extracting for autoconf-2.59_2 => Checksum OK for autoconf-2.59.tar.bz2. ===> autoconf-2.59_2 depends on file: /usr/local/bin/perl5.8.6 - found ===> Patching for autoconf-2.59_2 ===> autoconf-2.59_2 depends on file: /usr/local/bin/perl5.8.6 - found ===> Applying FreeBSD patches for autoconf-2.59_2 ===> autoconf-2.59_2 depends on executable: gm4 - found ===> autoconf-2.59_2 depends on executable: help2man - found ===> autoconf-2.59_2 depends on executable: gmake - found ===> autoconf-2.59_2 depends on file: /usr/local/bin/perl5.8.6 - found ===> Configuring for autoconf-2.59_2 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... configure: error: ls -t appears to fail. Make sure there is not a broken alias in your environment configure: error: newly created file is older than distributed files! Check your system clock ===> Script "configure" failed unexpectedly. Please report the problem to ports@FreeBSD.org [maintainer] and attach the "/usr/ports/devel/autoconf259/work/autoconf-2.59/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/devel/autoconf259. uname -a: FreeBSD nova 5.4-STABLE FreeBSD 5.4-STABLE #0: Wed May 4 21:25:55 EST 2005 agh@nova:/usr/obj/usr/src/sys/NOVA i386 My system clock is set correctly. Attached is "ls /var/db/pkg", "portsversion -v" and the config log from the autoconf port. I'm pretty sure I didn't miss anything in /usr/ports/UPDATING Thanks -Alastair --Boundary-00=_B6LfC6D2DgH28pR Content-Type: text/plain; charset="iso-8859-1"; name="ls_var_db_pkg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ls_var_db_pkg" Hermes-1.3.3_1 ImageMagick-6.2.0.5 ORBit2-2.12.1_1 OpenEXR-1.2.1_1 QuakeForge-0.5.5 TenDRA-4.20040902 WordNet-2.0 Xaw3d-1.5_1 aMule-devel-2.0.0rc7_3 aalib-1.4.r5_1 abuse_sdl-0.7.0_2 acroread7-7.0.0 allegro-esound-4.1.12_1 allegrogl-0.2.4 amspsfnt-1.0_3 apache-2.0.53_1 apache-ant-1.6.2 apr-nothr-db4-1.0.1_1 arts-1.4.0,1 artswrapper-1.2.1_1 aspell-0.60.2 atk-1.9.1 audacity-1.2.3_1 autoconf-2.13.000227_5 autoconf-2.53_3 autoconf-2.59_2 automake-1.4.6_1 automake-1.5_2,1 automake-1.9.5 avifile-0.7.41,2 bash-2.05b.007_2 bison-1.75_2 bitstream-vera-1.10_1 blender-devel-2.36 boinc-client-4.19 boinc-setiathome-4.07 bonnie-2.0.6 boost-python-1.32.0_2 boxtools-0.70.0 cabextract-1.1 callgrind-0.9.8 cdparanoia-3.9.8_7 cdrdao-1.1.9 cdrtools-2.01 cedet-emacs21-1.0.b3.b cmpsfont-1.0_4 compat4x-i386-5.3 cryptopp-5.2.1 ctorrent-1.3.4 cups-base-1.1.23.0_3 cups-pstoraster-7.07_3 curl-7.13.1_1 cvsup-without-gui-16.1h_2 cvsutils-2003.02.03 cyrus-sasl-2.1.20_1 db3-3.3.11_2,1 db4-4.0.14_1,1 db41-4.1.25_2 db42-4.2.52_4 dbh-1.0.24 deng-1.8.6 desktop-file-utils-0.10_2 dict-1.9.15 dirmngr-0.9.0_1 djbfft-0.76_2 docbook-1.3 docbook-241_2 docbook-3.0_2 docbook-3.1_2 docbook-4.0_2 docbook-4.1_2 docbook-sk-4.1.2_3 docbook-xml-4.2_1 docbook-xsl-1.68.1 docproj-jadetex-1.13 dosunix-1.0.13 dri-6.2.1,2 dsssl-docbook-modular-1.79,1 dvipsk-tetex-5.95a_1 eawpats-12 ecb-emacs21-2.31 eclipse-3.0.1_4 emacs-21.3_5 esound-0.2.35_1 expat-1.95.8 ezm3-1.2 faac-1.24_4 faad2-2.0_5,1 fam-2.6.9_6 fastest_cvsup-0.2.9_1 ffmpeg-0.4.9.p1_2 fftw-2.1.5_2 fftw3-3.0.1_4 firefox-1.0.2,1 flac-1.1.2 fontconfig-2.2.3,1 freetype-1.3.1_3 freetype2-2.1.9 fribidi-0.10.4_1 fuhquake-0.31_1 gconf2-2.10.0 gd-2.0.33_1,1 gdk-pixbuf-0.22.0_3 gengetopt-2.11 gettext-0.14.1 ghostscript-gnu-7.07_12 ghostview-1.5 gimp-2.2.4_4,1 gimp-print-4.2.7_1 glib-1.2.10_11 glib-2.6.3_1 gmake-3.80_2 gnokii-0.6.4,1 gnome-icon-theme-2.10.0 gnomehier-2.0_6 gnomekeyring-0.4.2 gnomemimedata-2.4.2 gnomevfs2-2.10.0_1 gnupg-1.4.0_1 gnupg-devel-1.9.14_2 gnutls-1.0.24_1 gocr-0.40 gpgme-1.0.2 gphoto2-2.1.5 graphviz-2.2 grip-3.2.0_7 gsfonts-8.11_2 gstreamer-0.8.9_2 gstreamer-plugins-0.8.8_3 gtk-1.2.10_12 gtk-2.6.4_1 gtk-engines2-2.6.2 gtk-xfce-engine-2.2.6 gtkglarea-1.2.3 gtkspell2-2.0.10_1 guilib-1.1.1_2 hdf-4.2r1 hdf-szip-2.0 help2man-1.35.1 hicolor-icon-theme-0.5 host-991529 html-4.01_2 id3lib-3.8.3_1 imake-6.8.2 imlib-1.9.15_2 intltool-0.33 iso8879-1986_2 ispell-3.2.06_13 jackit-0.99.0 jade-1.2.1_9 jadetex-3.13_1 jam-2.5_2 jasper-1.701.0 javavmwrapper-2.0_4 jbigkit-1.6 jdk-1.4.2p6_7 jmk-x11-fonts-3.0 jpeg-6b_3 jpeg-mmx-0.1.6 k3b-0.11.20_1 kde-icons-GorillaSVG-1.4 kde-icons-IcOsX-0.7 kde-icons-amaranth-0.8 kde-icons-amaranth-althaea-0.5 kde-icons-crystalosx-0.1.1 kde-icons-graphite-rade8-1.03 kde-icons-kids-0.8 kde-icons-kool-gorilla-1.3.5 kde-icons-lime-rade8-1.01 kde-icons-marbles-translucent-0.1.3 kde-icons-noia-1.00 kde-icons-noia-warm-0.95 kde-icons-nuvola-1.0 kde-icons-outline-0.1.0 kde-icons-realistic-0.10 kde-icons-sky-0.7.3 kde-icons-steel-1.2.5 kde-icons-umicons-2.0 kde-icons-wasp-2.6.1 kdeaccessibility-3.4.0 kdeaddons-3.4.0 kdeaddons-atlantikdesigner-3.4.0 kdeaddons-kaddressbook-plugins-3.4.0 kdeaddons-kate-plugins-3.4.0 kdeaddons-kfile-plugins-3.4.0 kdeaddons-kicker-applets-3.4.0 kdeaddons-knewsticker-scripts-3.4.0 kdeaddons-konq-plugins-3.4.0 kdeaddons-ksig-3.4.0 kdeaddons-noatun-plugins-3.4.0 kdeaddons-renamedlg-plugins-3.4.0 kdeaddons-vimpart-3.4.0 kdeadmin-3.4.0 kdeartwork-3.4.0 kdebase-3.4.0_1 kdebase-kompmgr-3.4.0 kdeedu-3.4.0_1 kdegames-3.4.0 kdegraphics-3.4.0 kdegraphics-kamera-3.4.0 kdegraphics-kooka-3.4.0 kdegraphics-kuickshow-3.4.0 kdehier-1.0_6 kdelibs-3.4.0 kdemultimedia-3.4.0 kdemultimedia-akode-3.4.0 kdemultimedia-akode-plugins-mpc-3.4.0 kdemultimedia-akode-plugins-mpeg-3.4.0 kdemultimedia-akode-plugins-oss-3.4.0 kdemultimedia-akode-plugins-resampler-3.4.0 kdemultimedia-akode-plugins-xiph-3.4.0 kdemultimedia-juk-3.4.0 kdemultimedia-mpeglib_artsplug-3.4.0 kdemultimedia-xine_artsplugin-3.4.0 kdenetwork-3.4.0 kdepim-3.4.0 kdesdk-3.4.0 kdetoys-3.4.0 kdeutils-3.4.0 kdevelop-3.2.0 kdewebdev-3.4.0,2 koffice-1.3.5_2,1 konversation-0.15.1_1 ksetiwatch-3.0.0_1 lame-3.96.1 lcms-1.14,1 lib3ds-1.2.0 libIDL-0.8.5_1 libXft-2.1.6 libXgFonts-1.0 liba52-0.7.4_1 libao-esound-0.8.5 libart_lgpl2-2.3.17 libassuan-0.6.9 libaudiofile-0.2.6 libbonobo-2.8.1_1 libbonoboui-2.8.1_2 libcddb-0.9.6 libcdio-0.72_1 libcroco-0.6.0_1 libdv-0.103 libdvdcss-1.2.8_1 libdvdread-0.9.4_1 libexecinfo-1.1_1 libexif-0.6.10 libfame-0.9.1_1 libfpx-1.2.0.12 libgcrypt-1.2.1 libggi-2.1.0,1 libghttp-1.0.9 libgii-0.9.0 libglade2-2.5.1_2 libglut-6.0.1 libgnome-2.10.0 libgnomecanvas-2.10.0_1 libgnomeui-2.10.0_1 libgpg-error-1.0_1 libgphoto2-2.1.5 libgsf-1.11.1 libiconv-1.9.2_1 libid3tag-0.15.0b_2 libidn-0.5.15 libijs-0.35 libksba-0.9.10_1 libltdl-1.5.10 libmad-0.15.1b_1 libmal-0.40 libmikmod-esound-3.1.11 libmng-1.0.8 libmpeg2-0.4.0b_1 libmusicbrainz-2.1.1 libogg-1.1.2_1,3 libpaper-1.1.14.3 libquicktime-0.9.4_1 librsvg2-2.9.5_2 libsamplerate-0.1.2 libsidplay-1.36.59 libsndfile-1.0.11 libtheora-1.0.a4 libtool-1.3.5_2 libtool-1.5.10_1 libtunepimp-0.3.0_2 libungif-4.1.3 libusb-0.1.7_1 libvorbis-1.1.0_1,3 libwmf-0.2.8.3 libwww-5.4.0_1 libxfce4gui-4.2.1 libxfce4mcs-4.2.1 libxfce4util-4.2.1 libxine-1.0_2 libxml-1.8.17_3 libxml2-2.6.18 libxslt-1.1.13 linc-1.0.3_3 links-2.1.p15,1 linux-XFree86-libs-4.3.99.902_2 linux-allegro-4.0.3_1 linux-atk-1.2.0_2 linux-blackdown-jdk-1.3.1_3 linux-divx4linux-5.0.20030428_1 linux-esound-0.2.22_3 linux-expat-1.95.5_2 linux-flashplugin-6.0r79_2 linux-fontconfig-2.1_2 linux-glib2-2.2.1_2 linux-gtk-1.2_4 linux-gtk2-2.2.1_3 linux-jpeg-6b.15_3 linux-libaudiofile-0.1.11_4 linux-libglade-0.14_2 linux-libxml-1.8.10_2 linux-pango-1.2.1_2 linux-png-1.2.7_5 linux-realplayer-10.0.3 linux-sun-jdk-1.4.2.05 linux-tiff-3.6.1_1 linux_base-8-8.0_6 linuxdoc-1.1_1 linuxpluginwrapper-20050320 linuxthreads-2.2.3_16 lua-5.0.2 lzo-1.08_1 m4-1.4.3 mDNSResponder-98_1 madplay-esound-0.15.0b_2 mjpegtools-1.6.2_2 mpeg2codec-1.2_1 mpeg4ip-1.1_3 mpeg4ip-libmp4v2-1.1_1 mpeg_play-2.4 mpgtx-1.3.1 mplayer-gtk-esound-0.99.7 mupen64-0.4 mupen64-base-0.4 mupen64-dummyaudio-0.4 mupen64-input-0.4 mupen64-rice-5.2.0 mupen64-rsp-0.4 mupen64-sdlaudio-1.2 mupen64-sdlinput-0.0.8 nas-1.7 nasm-0.98.39,1 neon-0.24.7 net-snmp-5.2.1_2 netpanzer-0.8 netpanzer-data-0.8 netpbm-10.26.5_1 nmap-3.81 nmapfe-3.81 nspr-4.4.1_1 nvclock-0.7_4 nvidia-settings-1.0_3 ocaml-3.08.2 open-motif-2.2.3_1 openal-20050202 openldap-client-2.2.23 openslp-1.0.11_1 openssl-0.9.7g opera-7.54.20050131 p5-Digest-1.10 p5-Digest-MD5-2.33 p5-MIME-Base64-3.05 p5-Test-Harness-2.42 p5-Test-Simple-0.54 p5-Time-HiRes-1.66,1 p5-XML-Parser-2.34_1 p5-gettext-1.03 p5-type1inst-0.6.1_2 pango-1.8.1 pccts-1.33.33 pcre-5.0 peps-1.0_1 perl-5.8.6_2 physfs-1.0.0 pilot-link-0.11.8_3 pkgconfig-0.15.0_1 pkgdb.db png-1.2.8_1 popt-1.7 portaudio-18.1_2 portupgrade-20041226_2 pth-2.0.3 py24-expat-2.4_3 py24-imaging-1.1.4 py24-numeric-23.7 py24-opengl-2.0.1.07_1 py24-qt-3.13_1 py24-sip-4.2 py24-tkinter-2.4_1 py24-wxPython-2.4.2.4_4 python-2.3.5 python-2.4.1 qca-tls-1.0_1 qemu-0.6.2s.20050305 qmake-3.3.4 qscintilla-1.5.1 qt-3.3.4 qt-bluecurve-theme-0.88 rar-3.41,1 rpm-3.0.6_9 rpm2cpio-1.2_2 ruby-1.8.2_3 ruby18-alexandria-0.5.0 ruby18-amazon-0.8.5 ruby18-atk-0.12.0 ruby18-bdb1-0.2.2 ruby18-gconf2-0.12.0 ruby18-gdk_pixbuf2-0.12.0 ruby18-gettext-0.8.0 ruby18-glib2-0.12.0 ruby18-gnome2-0.12.0 ruby18-gnomecanvas2-0.12.0 ruby18-gtk2-0.12.0 ruby18-libart2-0.12.0 ruby18-libglade2-0.12.0 ruby18-pango-0.12.0 ruby18-racc-1.4.4 samba-3.0.12_1,1 samba-libsmbclient-3.0.14a_2 sane-backends-1.0.15 scons-0.96.90_1 scr2png-1.1_4 scr2txt-1.1 scrollkeeper-0.3.14_1,1 sdl-1.2.8,2 sdl_image-1.2.4 sdl_mixer-1.2.6 sdl_net-1.2.5_2 sdl_sound-1.0.1_5 sdl_ttf-2.0.7 sdocbook-xml-4.1.2.5_2 setiathome-3.08_3 sgmlformat-1.7_2 shared-mime-info-0.15_9 sidplay-1.0.9 sigslot-1.0.0 skyutils-2.6 smpeg-0.4.4_3 smssend-3.3 speex-1.0.4_1,1 startup-notification-0.8_1 stratagus-2.1_1 subversion-1.1.3 supertux-0.1.2 svgalib-1.4.3_4 swig-1.1p5_9 t1lib-5.0.1,1 taglib-1.3.1 tcl-8.3.5_5 tcl-8.4.7,1 teTeX-3.0 teTeX-base-3.0_3 teTeX-texmf-3.0_3 tex-texmflocal-1.9 texi2html-1.76_1,1 tidy-20000804_2 tiff-3.7.1_2 timidity++-esound-2.11.3_1 timidity++-gtk-2.11.3_1 timidity-0.2i tk-8.3.5_5 tk-8.4.7,2 ttmkfdir-20021109_1 tuxracer-0.61_2 unrar-3.43,3 unshield-0.3 unzip-5.52_1 urban-1.5.3_1 urban-sounds-1.5.3 urwfonts-1.0 urwfonts-ttf-1.0.7b18 uulib-0.5.20 valgrind-352_3 vcdimager-0.7.21_1 vim-6.3.62 vorbis-tools-1.0.1_4,3 vte-0.11.12_1 wargus-2.1_2 webfonts-0.21_1 wget-1.8.2_7 win32-codecs-3.1.0.p5,1 wine-20050419 wrapper-1.0_3 wv2-0.2.2_1 wxgtk-2.4.2_8 wxgtk-common-2.4.2_1 wxgtk2-2.4.2_6 xanim-2.92.0 xdvik-tetex-22.84.8_1 xhtml-1.0.20020801_4 xmame-0.95 xmlcatmgr-2.2 xmms-esound-1.2.10_3 xorg-6.8.2 xorg-clients-6.8.2 xorg-documents-6.8.2 xorg-fonts-100dpi-6.8.2 xorg-fonts-75dpi-6.8.2 xorg-fonts-cyrillic-6.8.2 xorg-fonts-encodings-6.8.2 xorg-fonts-miscbitmaps-6.8.2 xorg-fonts-truetype-6.8.2 xorg-fonts-type1-6.8.2 xorg-fontserver-6.8.2 xorg-libraries-6.8.2 xorg-manpages-6.8.2 xorg-nestserver-6.8.2 xorg-printserver-6.8.2 xorg-server-6.8.2 xorg-vfbserver-6.8.2 xpdf-3.00_6 xrestop-0.3 xrisk-2.15 xterm-202 xvid-1.0.3,1 xvidcap-1.1.3.7_1 zip-2.3_2 zsnes-1.42,1 --Boundary-00=_B6LfC6D2DgH28pR Content-Type: text/plain; charset="iso-8859-1"; name="portsversion_v" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="portsversion_v" Hermes-1.3.3_1 = up-to-date with port ImageMagick-6.2.0.5 < needs updating (port has 6.2.2.1) ORBit2-2.12.1_1 < needs updating (port has 2.12.2) OpenEXR-1.2.1_1 = up-to-date with port QuakeForge-0.5.5 = up-to-date with port TenDRA-4.20040902 = up-to-date with port WordNet-2.0 = up-to-date with port Xaw3d-1.5_1 = up-to-date with port aMule-devel-2.0.0rc7_3 = up-to-date with port aalib-1.4.r5_1 = up-to-date with port abuse_sdl-0.7.0_2 = up-to-date with port acroread7-7.0.0 = up-to-date with port allegro-esound-4.1.12_1 = up-to-date with port allegrogl-0.2.4 = up-to-date with port amspsfnt-1.0_3 = up-to-date with port apache-2.0.53_1 < needs updating (port has 2.0.54) apache-ant-1.6.2 = up-to-date with port apr-nothr-db4-1.0.1_1 = up-to-date with port arts-1.4.0,1 = up-to-date with port artswrapper-1.2.1_1 = up-to-date with port aspell-0.60.2 = up-to-date with port atk-1.9.1 = up-to-date with port audacity-1.2.3_1 = up-to-date with port autoconf-2.13.000227_5 = up-to-date with port autoconf-2.53_3 = up-to-date with port autoconf-2.59_2 = up-to-date with port automake-1.4.6_1 = up-to-date with port automake-1.5_2,1 = up-to-date with port automake-1.9.5 = up-to-date with port avifile-0.7.41,2 = up-to-date with port bash-2.05b.007_2 < needs updating (port has 2.05b.007_3) bison-1.75_2 = up-to-date with port bitstream-vera-1.10_1 = up-to-date with port blender-devel-2.36 = up-to-date with port boinc-client-4.19 < needs updating (port has 4.67.20050320) boinc-setiathome-4.07 < needs updating (port has 4.07.20050218) bonnie-2.0.6 = up-to-date with port boost-python-1.32.0_2 = up-to-date with port boxtools-0.70.0 = up-to-date with port cabextract-1.1 = up-to-date with port callgrind-0.9.8 = up-to-date with port cdparanoia-3.9.8_7 = up-to-date with port cdrdao-1.1.9 = up-to-date with port cdrtools-2.01 = up-to-date with port cedet-emacs21-1.0.b3.b = up-to-date with port cmpsfont-1.0_4 = up-to-date with port compat4x-i386-5.3 = up-to-date with port cryptopp-5.2.1 < needs updating (port has 5.2.1_1) ctorrent-1.3.4 = up-to-date with port cups-base-1.1.23.0_3 < needs updating (port has 1.1.23.0_4) cups-pstoraster-7.07_3 = up-to-date with port curl-7.13.1_1 = up-to-date with port cvsup-without-gui-16.1h_2 = up-to-date with port cvsutils-2003.02.03 = up-to-date with port cyrus-sasl-2.1.20_1 = up-to-date with port db3-3.3.11_2,1 = up-to-date with port db4-4.0.14_1,1 = up-to-date with port db41-4.1.25_2 < needs updating (port has 4.1.25_3) db42-4.2.52_4 = up-to-date with port dbh-1.0.24 = up-to-date with port deng-1.8.6 = up-to-date with port desktop-file-utils-0.10_2 = up-to-date with port dict-1.9.15 = up-to-date with port dirmngr-0.9.0_1 < needs updating (port has 0.9.2) djbfft-0.76_2 = up-to-date with port docbook-1.3 = up-to-date with port docbook-241_2 = up-to-date with port docbook-3.0_2 = up-to-date with port docbook-3.1_2 = up-to-date with port docbook-4.0_2 = up-to-date with port docbook-4.1_2 = up-to-date with port docbook-sk-4.1.2_3 = up-to-date with port docbook-xml-4.2_1 = up-to-date with port docbook-xsl-1.68.1 = up-to-date with port docproj-jadetex-1.13 = up-to-date with port dosunix-1.0.13 = up-to-date with port dri-6.2.1,2 = up-to-date with port dsssl-docbook-modular-1.79,1 = up-to-date with port dvipsk-tetex-5.95a_1 = up-to-date with port eawpats-12 < needs updating (port has 12_1) ecb-emacs21-2.31 = up-to-date with port eclipse-3.0.1_4 = up-to-date with port emacs-21.3_5 = up-to-date with port esound-0.2.35_1 < needs updating (port has 0.2.35_2) expat-1.95.8 < needs updating (port has 1.95.8_1) ezm3-1.2 = up-to-date with port faac-1.24_4 = up-to-date with port faad2-2.0_5,1 = up-to-date with port fam-2.6.9_6 = up-to-date with port fastest_cvsup-0.2.9_1 = up-to-date with port ffmpeg-0.4.9.p1_2 = up-to-date with port fftw-2.1.5_2 = up-to-date with port fftw3-3.0.1_4 = up-to-date with port firefox-1.0.2,1 < needs updating (port has 1.0.3,1) flac-1.1.2 = up-to-date with port fontconfig-2.2.3,1 = up-to-date with port freetype-1.3.1_3 = up-to-date with port freetype2-2.1.9 = up-to-date with port fribidi-0.10.4_1 = up-to-date with port fuhquake-0.31_1 = up-to-date with port gconf2-2.10.0 = up-to-date with port gd-2.0.33_1,1 = up-to-date with port gdk-pixbuf-0.22.0_3 = up-to-date with port gengetopt-2.11 = up-to-date with port gettext-0.14.1 = up-to-date with port ghostscript-gnu-7.07_12 = up-to-date with port ghostview-1.5 = up-to-date with port gimp-2.2.4_4,1 < needs updating (port has 2.2.6,1) gimp-print-4.2.7_1 = up-to-date with port glib-1.2.10_11 = up-to-date with port glib-2.6.3_1 < needs updating (port has 2.6.4) gmake-3.80_2 = up-to-date with port gnokii-0.6.4,1 = up-to-date with port gnome-icon-theme-2.10.0 < needs updating (port has 2.10.1_1) gnomehier-2.0_6 = up-to-date with port gnomekeyring-0.4.2 < needs updating (port has 0.4.2_1) gnomemimedata-2.4.2 = up-to-date with port gnomevfs2-2.10.0_1 < needs updating (port has 2.10.1) gnupg-1.4.0_1 < needs updating (port has 1.4.1) gnupg-devel-1.9.14_2 < needs updating (port has 1.9.16) gnutls-1.0.24_1 = up-to-date with port gocr-0.40 = up-to-date with port gpgme-1.0.2 = up-to-date with port gphoto2-2.1.5 = up-to-date with port graphviz-2.2 = up-to-date with port grip-3.2.0_7 = up-to-date with port gsfonts-8.11_2 = up-to-date with port gstreamer-0.8.9_2 < needs updating (port has 0.8.10) gstreamer-plugins-0.8.8_3 = up-to-date with port gtk-1.2.10_12 < needs updating (port has 1.2.10_13) gtk-2.6.4_1 < needs updating (port has 2.6.7) gtk-engines2-2.6.2 < needs updating (port has 2.6.3_3) gtk-xfce-engine-2.2.6 = up-to-date with port gtkglarea-1.2.3 = up-to-date with port gtkspell2-2.0.10_1 = up-to-date with port guilib-1.1.1_2 = up-to-date with port hdf-4.2r1 = up-to-date with port hdf-szip-2.0 = up-to-date with port help2man-1.35.1 = up-to-date with port hicolor-icon-theme-0.5 = up-to-date with port host-991529 = up-to-date with port html-4.01_2 = up-to-date with port id3lib-3.8.3_1 = up-to-date with port imake-6.8.2 = up-to-date with port imlib-1.9.15_2 = up-to-date with port intltool-0.33 = up-to-date with port iso8879-1986_2 = up-to-date with port ispell-3.2.06_13 = up-to-date with port jackit-0.99.0 = up-to-date with port jade-1.2.1_9 = up-to-date with port jadetex-3.13_1 = up-to-date with port jam-2.5_2 = up-to-date with port jasper-1.701.0 = up-to-date with port javavmwrapper-2.0_4 = up-to-date with port jbigkit-1.6 = up-to-date with port jdk-1.4.2p6_7 < needs updating (port has 1.4.2p7) jmk-x11-fonts-3.0 = up-to-date with port jpeg-6b_3 = up-to-date with port jpeg-mmx-0.1.6 = up-to-date with port k3b-0.11.20_1 < needs updating (port has 0.11.23) kde-icons-GorillaSVG-1.4 = up-to-date with port kde-icons-IcOsX-0.7 = up-to-date with port kde-icons-amaranth-0.8 = up-to-date with port kde-icons-amaranth-althaea-0.5 = up-to-date with port kde-icons-crystalosx-0.1.1 = up-to-date with port kde-icons-graphite-rade8-1.03 = up-to-date with port kde-icons-kids-0.8 = up-to-date with port kde-icons-kool-gorilla-1.3.5 = up-to-date with port kde-icons-lime-rade8-1.01 = up-to-date with port kde-icons-marbles-translucent-0.1.3 = up-to-date with port kde-icons-noia-1.00 = up-to-date with port kde-icons-noia-warm-0.95 = up-to-date with port kde-icons-nuvola-1.0 < needs updating (port has 1.0_1) kde-icons-outline-0.1.0 = up-to-date with port kde-icons-realistic-0.10 = up-to-date with port kde-icons-sky-0.7.3 = up-to-date with port kde-icons-steel-1.2.5 = up-to-date with port kde-icons-umicons-2.0 = up-to-date with port kde-icons-wasp-2.6.1 = up-to-date with port kdeaccessibility-3.4.0 = up-to-date with port kdeaddons-3.4.0 = up-to-date with port kdeaddons-atlantikdesigner-3.4.0 = up-to-date with port kdeaddons-kaddressbook-plugins-3.4.0 = up-to-date with port kdeaddons-kate-plugins-3.4.0 = up-to-date with port kdeaddons-kfile-plugins-3.4.0 = up-to-date with port kdeaddons-kicker-applets-3.4.0 = up-to-date with port kdeaddons-knewsticker-scripts-3.4.0 = up-to-date with port kdeaddons-konq-plugins-3.4.0 = up-to-date with port kdeaddons-ksig-3.4.0 = up-to-date with port kdeaddons-noatun-plugins-3.4.0 = up-to-date with port kdeaddons-renamedlg-plugins-3.4.0 = up-to-date with port kdeaddons-vimpart-3.4.0 = up-to-date with port kdeadmin-3.4.0 = up-to-date with port kdeartwork-3.4.0 = up-to-date with port kdebase-3.4.0_1 = up-to-date with port kdebase-kompmgr-3.4.0 = up-to-date with port kdeedu-3.4.0_1 = up-to-date with port kdegames-3.4.0 = up-to-date with port kdegraphics-3.4.0 = up-to-date with port kdegraphics-kamera-3.4.0 = up-to-date with port kdegraphics-kooka-3.4.0 = up-to-date with port kdegraphics-kuickshow-3.4.0 = up-to-date with port kdehier-1.0_6 = up-to-date with port kdelibs-3.4.0 < needs updating (port has 3.4.0_2) kdemultimedia-3.4.0 = up-to-date with port kdemultimedia-akode-3.4.0 = up-to-date with port kdemultimedia-akode-plugins-mpc-3.4.0 = up-to-date with port kdemultimedia-akode-plugins-mpeg-3.4.0 = up-to-date with port kdemultimedia-akode-plugins-oss-3.4.0 = up-to-date with port kdemultimedia-akode-plugins-resampler-3.4.0 = up-to-date with port kdemultimedia-akode-plugins-xiph-3.4.0 = up-to-date with port kdemultimedia-juk-3.4.0 = up-to-date with port kdemultimedia-mpeglib_artsplug-3.4.0 = up-to-date with port kdemultimedia-xine_artsplugin-3.4.0 = up-to-date with port kdenetwork-3.4.0 < needs updating (port has 3.4.0_1) kdepim-3.4.0 = up-to-date with port kdesdk-3.4.0 = up-to-date with port kdetoys-3.4.0 = up-to-date with port kdeutils-3.4.0 = up-to-date with port kdevelop-3.2.0 = up-to-date with port kdewebdev-3.4.0,2 < needs updating (port has 3.4.0_1,2) koffice-1.3.5_2,1 = up-to-date with port konversation-0.15.1_1 < needs updating (port has 0.17_1) ksetiwatch-3.0.0_1 < needs updating (port has 3.0.1) lame-3.96.1 = up-to-date with port lcms-1.14,1 = up-to-date with port lib3ds-1.2.0 = up-to-date with port libIDL-0.8.5_1 = up-to-date with port libXft-2.1.6 < needs updating (port has 2.1.6_1) libXgFonts-1.0 = up-to-date with port liba52-0.7.4_1 = up-to-date with port libao-esound-0.8.5 = up-to-date with port libart_lgpl2-2.3.17 = up-to-date with port libassuan-0.6.9 = up-to-date with port libaudiofile-0.2.6 = up-to-date with port libbonobo-2.8.1_1 = up-to-date with port libbonoboui-2.8.1_2 = up-to-date with port libcddb-0.9.6 < needs updating (port has 1.0.0) libcdio-0.72_1 < needs updating (port has 0.73) libcroco-0.6.0_1 = up-to-date with port libdv-0.103 < needs updating (port has 0.104) libdvdcss-1.2.8_1 = up-to-date with port libdvdread-0.9.4_1 = up-to-date with port libexecinfo-1.1_1 = up-to-date with port libexif-0.6.10 < needs updating (port has 0.6.12_1) libfame-0.9.1_1 = up-to-date with port libfpx-1.2.0.12 = up-to-date with port libgcrypt-1.2.1 < needs updating (port has 1.2.1_1) libggi-2.1.0,1 < needs updating (port has 2.1.1,1) libghttp-1.0.9 = up-to-date with port libgii-0.9.0 < needs updating (port has 0.9.1) libglade2-2.5.1_2 = up-to-date with port libglut-6.0.1 = up-to-date with port libgnome-2.10.0 < needs updating (port has 2.10.0_1) libgnomecanvas-2.10.0_1 = up-to-date with port libgnomeui-2.10.0_1 = up-to-date with port libgpg-error-1.0_1 = up-to-date with port libgphoto2-2.1.5 < needs updating (port has 2.1.5_1) libgsf-1.11.1 = up-to-date with port libiconv-1.9.2_1 = up-to-date with port libid3tag-0.15.0b_2 = up-to-date with port libidn-0.5.15 = up-to-date with port libijs-0.35 = up-to-date with port libksba-0.9.10_1 < needs updating (port has 0.9.11) libltdl-1.5.10 = up-to-date with port libmad-0.15.1b_1 = up-to-date with port libmal-0.40 = up-to-date with port libmikmod-esound-3.1.11 = up-to-date with port libmng-1.0.8 = up-to-date with port libmpeg2-0.4.0b_1 = up-to-date with port libmusicbrainz-2.1.1 = up-to-date with port libogg-1.1.2_1,3 = up-to-date with port libpaper-1.1.14.3 = up-to-date with port libquicktime-0.9.4_1 = up-to-date with port librsvg2-2.9.5_2 = up-to-date with port libsamplerate-0.1.2 = up-to-date with port libsidplay-1.36.59 = up-to-date with port libsndfile-1.0.11 = up-to-date with port libtheora-1.0.a4 = up-to-date with port libtool-1.3.5_2 = up-to-date with port libtool-1.5.10_1 = up-to-date with port libtunepimp-0.3.0_2 = up-to-date with port libungif-4.1.3 = up-to-date with port libusb-0.1.7_1 < needs updating (port has 0.1.10a) libvorbis-1.1.0_1,3 = up-to-date with port libwmf-0.2.8.3 = up-to-date with port libwww-5.4.0_1 = up-to-date with port libxfce4gui-4.2.1 = up-to-date with port libxfce4mcs-4.2.1 = up-to-date with port libxfce4util-4.2.1 = up-to-date with port libxine-1.0_2 < needs updating (port has 1.0.1) libxml-1.8.17_3 = up-to-date with port libxml2-2.6.18 < needs updating (port has 2.6.19) libxslt-1.1.13 < needs updating (port has 1.1.14) linc-1.0.3_3 = up-to-date with port links-2.1.p15,1 < needs updating (port has 2.1.p17,1) linux-XFree86-libs-4.3.99.902_2 = up-to-date with port linux-allegro-4.0.3_1 = up-to-date with port linux-atk-1.2.0_2 = up-to-date with port linux-blackdown-jdk-1.3.1_3 < needs updating (port has 1.3.1_4) linux-divx4linux-5.0.20030428_1 = up-to-date with port linux-esound-0.2.22_3 = up-to-date with port linux-expat-1.95.5_2 = up-to-date with port linux-flashplugin-6.0r79_2 = up-to-date with port linux-fontconfig-2.1_2 = up-to-date with port linux-glib2-2.2.1_2 = up-to-date with port linux-gtk-1.2_4 = up-to-date with port linux-gtk2-2.2.1_3 = up-to-date with port linux-jpeg-6b.15_3 = up-to-date with port linux-libaudiofile-0.1.11_4 = up-to-date with port linux-libglade-0.14_2 = up-to-date with port linux-libxml-1.8.10_2 = up-to-date with port linux-pango-1.2.1_2 = up-to-date with port linux-png-1.2.7_5 = up-to-date with port linux-realplayer-10.0.3 < needs updating (port has 10.0.4) linux-sun-jdk-1.4.2.05 < needs updating (port has 1.4.2.08_1) linux-tiff-3.6.1_1 = up-to-date with port linux_base-8-8.0_6 = up-to-date with port linuxdoc-1.1_1 = up-to-date with port linuxpluginwrapper-20050320 = up-to-date with port linuxthreads-2.2.3_16 = up-to-date with port lua-5.0.2 = up-to-date with port lzo-1.08_1 = up-to-date with port m4-1.4.3 = up-to-date with port mDNSResponder-98_1 = up-to-date with port madplay-esound-0.15.0b_2 = up-to-date with port mjpegtools-1.6.2_2 = up-to-date with port mpeg2codec-1.2_1 = up-to-date with port mpeg4ip-1.1_3 = up-to-date with port mpeg4ip-libmp4v2-1.1_1 = up-to-date with port mpeg_play-2.4 = up-to-date with port mpgtx-1.3.1 = up-to-date with port mplayer-gtk-esound-0.99.7 = up-to-date with port mupen64-0.4 = up-to-date with port mupen64-base-0.4 = up-to-date with port mupen64-dummyaudio-0.4 = up-to-date with port mupen64-input-0.4 = up-to-date with port mupen64-rice-5.2.0 = up-to-date with port mupen64-rsp-0.4 = up-to-date with port mupen64-sdlaudio-1.2 = up-to-date with port mupen64-sdlinput-0.0.8 = up-to-date with port nas-1.7 = up-to-date with port nasm-0.98.39,1 = up-to-date with port neon-0.24.7 = up-to-date with port net-snmp-5.2.1_2 = up-to-date with port netpanzer-0.8 = up-to-date with port netpanzer-data-0.8 = up-to-date with port netpbm-10.26.5_1 < needs updating (port has 10.26.6) nmap-3.81 = up-to-date with port nmapfe-3.81 = up-to-date with port nspr-4.4.1_1 = up-to-date with port nvclock-0.7_4 = up-to-date with port nvidia-settings-1.0_3 = up-to-date with port ocaml-3.08.2 < needs updating (port has 3.08.3) open-motif-2.2.3_1 = up-to-date with port openal-20050202 < needs updating (port has 20050401) openldap-client-2.2.23 < needs updating (port has 2.2.26) openslp-1.0.11_1 = up-to-date with port openssl-0.9.7g = up-to-date with port opera-7.54.20050131 < needs updating (port has 8.0.20050415) p5-Digest-1.10 = up-to-date with port p5-Digest-MD5-2.33 = up-to-date with port p5-MIME-Base64-3.05 = up-to-date with port p5-Test-Harness-2.42 = up-to-date with port p5-Test-Simple-0.54 = up-to-date with port p5-Time-HiRes-1.66,1 = up-to-date with port p5-XML-Parser-2.34_1 = up-to-date with port p5-gettext-1.03 = up-to-date with port p5-type1inst-0.6.1_2 = up-to-date with port pango-1.8.1 = up-to-date with port pccts-1.33.33 = up-to-date with port pcre-5.0 = up-to-date with port peps-1.0_1 = up-to-date with port perl-5.8.6_2 = up-to-date with port physfs-1.0.0 = up-to-date with port pilot-link-0.11.8_3 = up-to-date with port pkgconfig-0.15.0_1 < needs updating (port has 0.17.2) png-1.2.8_1 = up-to-date with port popt-1.7 = up-to-date with port portaudio-18.1_2 = up-to-date with port portupgrade-20041226_2 = up-to-date with port pth-2.0.3 = up-to-date with port py24-expat-2.4_3 < needs updating (port has 2.4.1_3) py24-imaging-1.1.4 = up-to-date with port py24-numeric-23.7 = up-to-date with port py24-opengl-2.0.1.07_1 = up-to-date with port py24-qt-3.13_1 < needs updating (port has 3.14.1) py24-sip-4.2 < needs updating (port has 4.2.1) py24-tkinter-2.4_1 < needs updating (port has 2.4.1_1) py24-wxPython-2.4.2.4_4 = up-to-date with port python-2.3.5 = up-to-date with port python-2.4.1 = up-to-date with port qca-tls-1.0_1 = up-to-date with port qemu-0.6.2s.20050305 < needs updating (port has 0.7.0) qmake-3.3.4 = up-to-date with port qscintilla-1.5.1 = up-to-date with port qt-3.3.4 = up-to-date with port qt-bluecurve-theme-0.88 = up-to-date with port rar-3.41,1 = up-to-date with port rpm-3.0.6_9 = up-to-date with port rpm2cpio-1.2_2 = up-to-date with port ruby-1.8.2_3 = up-to-date with port ruby18-alexandria-0.5.0 = up-to-date with port ruby18-amazon-0.8.5 = up-to-date with port ruby18-atk-0.12.0 = up-to-date with port ruby18-bdb1-0.2.2 = up-to-date with port ruby18-gconf2-0.12.0 = up-to-date with port ruby18-gdk_pixbuf2-0.12.0 = up-to-date with port ruby18-gettext-0.8.0 = up-to-date with port ruby18-glib2-0.12.0 = up-to-date with port ruby18-gnome2-0.12.0 = up-to-date with port ruby18-gnomecanvas2-0.12.0 = up-to-date with port ruby18-gtk2-0.12.0 = up-to-date with port ruby18-libart2-0.12.0 = up-to-date with port ruby18-libglade2-0.12.0 = up-to-date with port ruby18-pango-0.12.0 = up-to-date with port ruby18-racc-1.4.4 = up-to-date with port samba-3.0.12_1,1 < needs updating (port has 3.0.14a,1) samba-libsmbclient-3.0.14a_2 = up-to-date with port sane-backends-1.0.15 = up-to-date with port scons-0.96.90_1 = up-to-date with port scr2png-1.1_4 = up-to-date with port scr2txt-1.1 = up-to-date with port scrollkeeper-0.3.14_1,1 = up-to-date with port sdl-1.2.8,2 = up-to-date with port sdl_image-1.2.4 = up-to-date with port sdl_mixer-1.2.6 = up-to-date with port sdl_net-1.2.5_2 = up-to-date with port sdl_sound-1.0.1_5 = up-to-date with port sdl_ttf-2.0.7 = up-to-date with port sdocbook-xml-4.1.2.5_2 = up-to-date with port setiathome-3.08_3 = up-to-date with port sgmlformat-1.7_2 = up-to-date with port shared-mime-info-0.15_9 < needs updating (port has 0.16_1) sidplay-1.0.9 = up-to-date with port sigslot-1.0.0 = up-to-date with port skyutils-2.6 = up-to-date with port smpeg-0.4.4_3 = up-to-date with port smssend-3.3 = up-to-date with port speex-1.0.4_1,1 = up-to-date with port startup-notification-0.8_1 = up-to-date with port stratagus-2.1_1 = up-to-date with port subversion-1.1.3 < needs updating (port has 1.1.4) supertux-0.1.2 = up-to-date with port svgalib-1.4.3_4 = up-to-date with port swig-1.1p5_9 = up-to-date with port t1lib-5.0.1,1 = up-to-date with port taglib-1.3.1 = up-to-date with port tcl-8.3.5_5 = up-to-date with port tcl-8.4.7,1 = up-to-date with port teTeX-3.0 = up-to-date with port teTeX-base-3.0_3 = up-to-date with port teTeX-texmf-3.0_3 = up-to-date with port tex-texmflocal-1.9 = up-to-date with port texi2html-1.76_1,1 = up-to-date with port tidy-20000804_2 = up-to-date with port tiff-3.7.1_2 < needs updating (port has 3.7.2) timidity++-esound-2.11.3_1 < needs updating (port has 2.13.2) timidity++-gtk-2.11.3_1 = up-to-date with port timidity-0.2i = up-to-date with port tk-8.3.5_5 = up-to-date with port tk-8.4.7,2 = up-to-date with port ttmkfdir-20021109_1 = up-to-date with port tuxracer-0.61_2 = up-to-date with port unrar-3.43,3 = up-to-date with port unshield-0.3 = up-to-date with port unzip-5.52_1 = up-to-date with port urban-1.5.3_1 = up-to-date with port urban-sounds-1.5.3 = up-to-date with port urwfonts-1.0 = up-to-date with port urwfonts-ttf-1.0.7b18 = up-to-date with port uulib-0.5.20 = up-to-date with port valgrind-352_3 = up-to-date with port vcdimager-0.7.21_1 < needs updating (port has 0.7.21_2) vim-6.3.62 = up-to-date with port vorbis-tools-1.0.1_4,3 = up-to-date with port vte-0.11.12_1 < needs updating (port has 0.11.13_1) wargus-2.1_2 = up-to-date with port webfonts-0.21_1 = up-to-date with port wget-1.8.2_7 = up-to-date with port win32-codecs-3.1.0.p5,1 = up-to-date with port wine-20050419 = up-to-date with port wrapper-1.0_3 = up-to-date with port wv2-0.2.2_1 = up-to-date with port wxgtk-2.4.2_8 = up-to-date with port wxgtk-common-2.4.2_1 = up-to-date with port wxgtk2-2.4.2_6 = up-to-date with port xanim-2.92.0 = up-to-date with port xdvik-tetex-22.84.8_1 = up-to-date with port xhtml-1.0.20020801_4 = up-to-date with port xmame-0.95 = up-to-date with port xmlcatmgr-2.2 = up-to-date with port xmms-esound-1.2.10_3 < needs updating (port has 1.2.10_4) xorg-6.8.2 = up-to-date with port xorg-clients-6.8.2 = up-to-date with port xorg-documents-6.8.2 = up-to-date with port xorg-fonts-100dpi-6.8.2 = up-to-date with port xorg-fonts-75dpi-6.8.2 = up-to-date with port xorg-fonts-cyrillic-6.8.2 = up-to-date with port xorg-fonts-encodings-6.8.2 = up-to-date with port xorg-fonts-miscbitmaps-6.8.2 = up-to-date with port xorg-fonts-truetype-6.8.2 = up-to-date with port xorg-fonts-type1-6.8.2 = up-to-date with port xorg-fontserver-6.8.2 = up-to-date with port xorg-libraries-6.8.2 = up-to-date with port xorg-manpages-6.8.2 = up-to-date with port xorg-nestserver-6.8.2 = up-to-date with port xorg-printserver-6.8.2 = up-to-date with port xorg-server-6.8.2 = up-to-date with port xorg-vfbserver-6.8.2 = up-to-date with port xpdf-3.00_6 = up-to-date with port xrestop-0.3 = up-to-date with port xrisk-2.15 = up-to-date with port xterm-202 = up-to-date with port xvid-1.0.3,1 = up-to-date with port xvidcap-1.1.3.7_1 = up-to-date with port zip-2.3_2 = up-to-date with port zsnes-1.42,1 = up-to-date with port --Boundary-00=_B6LfC6D2DgH28pR-- From owner-freebsd-stable@FreeBSD.ORG Sat May 7 13:33:56 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BEC816A4DB for ; Sat, 7 May 2005 13:33:56 +0000 (GMT) Received: from mbc.edu (mail.mbc.edu [216.57.240.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBC4E43D67 for ; Sat, 7 May 2005 13:33:55 +0000 (GMT) (envelope-from ckleski@mbc.edu) Received: from [192.168.0.101] by mbc.edu (Cipher TLSv1:RC4-MD5:128) (MDaemon.PRO.v8.0.0f2.R) with ESMTP id md50004879650.msg for ; Sat, 07 May 2005 09:33:33 -0400 From: ckleski@mbc.edu To: Luk van den Borne Date: Sat, 7 May 2005 09:35:16 +0000 User-Agent: KMail/1.7.2 References: <200505061502.45569.jaimie@onsitepcs.net> <200505061524.18324.jaimie@onsitepcs.net> <7b1df2440505070519684d85cd@mail.gmail.com> In-Reply-To: <7b1df2440505070519684d85cd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505070935.16941.ckleski@mbc.edu> X-SortMonster-MessageSniffer-Message: md50004879650.msg X-SortMonster-MessageSniffer-Rules: tgibseut-MDPv0.53b (SNFv2-3.1i2) No patterns matched. X-SortMonster-MessageSniffer-Result: 0 X-Authenticated-Sender: ckleski@mbc.edu X-Spam-Processed: mail.mbc.edu, Sat, 07 May 2005 09:33:33 -0400 (not processed: message from trusted or authenticated source) X-Lookup-Warning: HELO/EHLO lookup on 192.168.0.101 does not match 65.202.151.105 X-MDRemoteIP: 65.202.151.105 X-Return-Path: ckleski@mbc.edu X-MDaemon-Deliver-To: freebsd-stable@freebsd.org X-MDAV-Processed: mail.mbc.edu, Sat, 07 May 2005 09:33:36 -0400 cc: freebsd-stable@freebsd.org Subject: Re: How do i enable DRI support in Xorg? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 13:33:56 -0000 It is not yet supported. Check out http://dri.sourceforge.net/cgi-bin/moin.cgi/ You can get the source from CVS and try playing around with it. You want drmsub0 and drmsub1 to attach properly. If you can make it work, many people would be interested. On Saturday 07 May 2005 12:19 pm, Luk van den Borne wrote: > Does FreeBSD already support the i830/i915 DRI drivers? According to > http://people.freebsd.org/~anholt/dri/, the i810 is still on the TODO > list, which makes me wonder about newer chipsets. I get this error in > my xorg log: > > (II) Loading sub module "drm" > (II) LoadModule: "drm" > (II) Loading /usr/X11R6/lib/modules/freebsd/libdrm.a > (II) Module drm: vendor="X.Org Foundation" > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is -1, (No such file or directory) > drmOpenDevice: open result is -1, (No such file or directory) > drmOpenDevice: Open failed > drmOpenDevice: node name is /dev/dri/card0 > drmOpenDevice: open result is -1, (No such file or directory) > drmOpenDevice: open result is -1, (No such file or directory) > drmOpenDevice: Open failed > [drm] failed to load kernel module "i915" > (II) I810(0): [drm] drmOpen failed > > On 5/7/05, Jaimie Garner wrote: > > I asumed it would just gave em a link to shed some light on how I did it > > with Linux. I havent ran X on FreeBSD. > > > > On Friday 06 May 2005 3:17 pm, Matthias Buelow wrote: > > > Jaimie Garner wrote: > > > >Go here http://dri.freedesktop.org/wiki/Building this helped me to > > > > build Xorg + Mesa and DRI for ATI Radeon on a custome built linux > > > > system. Should not be to far off for FreeBSD. > > > > > > The OP does not have to build Xorg manually. The ports system > > > already does this, and his video chipset is old enough to be supported > > > by the latest release Xorg (if it isn't, then a CVS Xorg won't help.) > > > > > > The OP could post the error messages pertaining to DRI > > > (from /var/log/Xorg.0.log) plus the output from "xdriinfo" > > > and "kldstat". > > > > > > mkb. > > > _______________________________________________ > > > 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" > > > > -- > > Jaimie Garner > > Onsite PCS inc. > > 323 SE RIverside AV > > Grants Pass, OR 97526 > > 541.471.1343 > > 866.471.1343 > > jaimie@onsitepcs.net > > www.onistepcs.net > > _______________________________________________ > > 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 Sat May 7 13:53:55 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20CE216A4DC for ; Sat, 7 May 2005 13:53:55 +0000 (GMT) Received: from mail.efacilitas.de (efacilitas.de [213.133.110.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79FC243D99 for ; Sat, 7 May 2005 13:53:54 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-39-61.dynamic.qsc.de [212.202.39.61]) by mail.efacilitas.de (Postfix) with ESMTP id 1B596123A1D; Sat, 7 May 2005 15:52:37 +0200 (CEST) Received: from localhost (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id 58A5612B390; Sat, 7 May 2005 15:53:04 +0200 (CEST) Received: from eurystheus.local ([192.168.1.67]) by localhost (eurystheus.locaL [192.168.1.67]) (amavisd-new, port 10024) with ESMTP id 48131-01; Sat, 7 May 2005 15:52:59 +0200 (CEST) Received: from [192.168.1.67] (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id 2F99D12B01A; Sat, 7 May 2005 15:52:59 +0200 (CEST) Message-ID: <427CC83A.30706@cs.tu-berlin.de> Date: Sat, 07 May 2005 15:52:58 +0200 From: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jaimie Garner References: <200505061658.47445.jaimie@onsitepcs.net> In-Reply-To: <200505061658.47445.jaimie@onsitepcs.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at example.com cc: freebsd-stable@freebsd.org Subject: Re: How do i enable DRI support in Xorg? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 13:53:55 -0000 Don't forget to mention the port 'graphics/dri' and an appropriate kernel module resp. support. ;-) Björn From owner-freebsd-stable@FreeBSD.ORG Sat May 7 14:06:08 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 662B416A4DB for ; Sat, 7 May 2005 14:06:08 +0000 (GMT) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 274DC43D6B for ; Sat, 7 May 2005 14:06:07 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 99EED64E37C; Sat, 7 May 2005 11:06:06 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 35290-05; Sat, 7 May 2005 14:06:01 +0000 (GMT) Received: from ganymede.hub.org (blk-222-81-172.eastlink.ca [24.222.81.172]) by hub.org (Postfix) with ESMTP id 27AB164DCC0; Sat, 7 May 2005 11:06:06 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 5DEF838C2D; Sat, 7 May 2005 11:06:05 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 5CC1338BFD; Sat, 7 May 2005 11:06:05 -0300 (ADT) Date: Sat, 7 May 2005 11:06:05 -0300 (ADT) From: "Marc G. Fournier" To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: Message-ID: <20050507110403.D42300@ganymede.hub.org> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-144879048-1115474765=:42300" X-Virus-Scanned: by amavisd-new at hub.org cc: "stable@freebsd.org" cc: hartzell@alerce.com Subject: Re: unionfs limitations? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 14:06:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-144879048-1115474765=:42300 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 7 May 2005, Eirik [ISO-8859-1] =D8verby wrote: > On 07-05-05 03:19, "George Hartzell" wrote: > >> Eirik =D8verby writes: >>> Hi, >>> >>> I just started playing with mounting ports into jails using unionfs >>> (mount_unionfs -b /usr/ports_jail /usr/local/jails/jail-0/usr/ports), a= nd >>> many things seem to work fine. >>> However, when trying to install either of mysql41-server or mysql41-cli= ent, >>> I see the following: >>> >>> [root@mpi1] /usr/ports/databases/mysql41-server# make install >>> =3D=3D=3D> Installing for mysql-server-4.1.11_1 >>> =3D=3D=3D> mysql-server-4.1.11_1 depends on shared library: mysqlclie= nt.14 - >>> found >>> =3D=3D=3D> Generating temporary packing list >>> =3D=3D=3D> Checking if databases/mysql41-server already installed >>> ln: POSIX: Operation not supported >>> *** Error code 1 >>> >>> Stop in /usr/ports/databases/mysql41-server. >>> >>> Did I miss out on something, or is this not going to work? Do I need to >>> think in other ways? >>> [...] >> >> Here's one unionfs/jail gotcha that's bitten me a couple of times. If >> you actually *use* (or, have used) the ports directory to build and >> install stuff onto the "host" machine, the ports infrastructure in the >> jail gets kind of confused. It seems to be checking for the files in >> the dependencies, doesn't find them, goes to make them, and then >> [depending on what state the relevant port directory is in], things >> get "odd". > > I noticed that pretty early on, yea ;) Has 5.x *really* gone that far downhill? :( I've been doing the above since about day one ... *but* ... is this the=20 case if you set WRKDIRPREFIX=3D to somewhere else in /etc/make.conf? I=20 don't build the actual port *in* /usr/ports, so the only thing that gets=20 written in /usr/ports is /usr/ports/distfiles ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 --0-144879048-1115474765=:42300-- From owner-freebsd-stable@FreeBSD.ORG Sat May 7 14:09:02 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 628DB16A4DB for ; Sat, 7 May 2005 14:09:02 +0000 (GMT) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2076A43D91 for ; Sat, 7 May 2005 14:09:02 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id D53EC64E388; Sat, 7 May 2005 11:09:01 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 33008-07; Sat, 7 May 2005 14:08:56 +0000 (GMT) Received: from ganymede.hub.org (blk-222-81-172.eastlink.ca [24.222.81.172]) by hub.org (Postfix) with ESMTP id 5EE0E64E384; Sat, 7 May 2005 11:09:01 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id 6D26037370; Sat, 7 May 2005 11:09:00 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 69B2835E8C; Sat, 7 May 2005 11:09:00 -0300 (ADT) Date: Sat, 7 May 2005 11:09:00 -0300 (ADT) From: "Marc G. Fournier" To: Eirik =?ISO-8859-1?B?2A==?=verby In-Reply-To: Message-ID: <20050507110616.S42300@ganymede.hub.org> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1349575065-1115474940=:42300" X-Virus-Scanned: by amavisd-new at hub.org cc: "stable@freebsd.org" Subject: Re: unionfs limitations? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 14:09:02 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1349575065-1115474940=:42300 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sat, 7 May 2005, Eirik [ISO-8859-1] =D8verby wrote: > > > > On 07-05-05 02:22, "Marc G. Fournier" wrote: > >> yOn Sat, 7 May 2005, Eirik [ISO-8859-1] =D8verby wrote: >> >>> Hi, >>> >>> I just started playing with mounting ports into jails using unionfs >>> (mount_unionfs -b /usr/ports_jail /usr/local/jails/jail-0/usr/ports), a= nd >>> many things seem to work fine. >>> However, when trying to install either of mysql41-server or mysql41-cli= ent, >>> I see the following: >>> >>> [root@mpi1] /usr/ports/databases/mysql41-server# make install >>> =3D=3D=3D> Installing for mysql-server-4.1.11_1 >>> =3D=3D=3D> mysql-server-4.1.11_1 depends on shared library: mysqlclie= nt.14 - >>> found >>> =3D=3D=3D> Generating temporary packing list >>> =3D=3D=3D> Checking if databases/mysql41-server already installed >>> ln: POSIX: Operation not supported >>> *** Error code 1 >>> >>> Stop in /usr/ports/databases/mysql41-server. >>> >>> Did I miss out on something, or is this not going to work? Do I need to >>> think in other ways? >>> I have stress-tested this setup pretty well over the last 24 hours, wit= h as >>> many as 20 mountpoints using the same ports tree, with constant package >>> building in each of them. This was impossible last time I played with >>> unionfs, so it must have stabilized somewhat ;) >> >> What version of FreeBSD? Only issue I've hit so far is just trying SBCL >> the other day and getting an MMAP issue that I'm guessing is jail relate= d, >> not unionfs ... > > 5.4 as of a couple of days ago.. > Are you able to install mysql41-server from ports in your unionfs-mounted > ports tree? Building works, installing doesn't... Yes, but due to all I've read on unionfs's "state" in 5.x, I've not moved= =20 from 4.x on any of my production servers ... from what I've been reading=20 about 5.x + unionfs, things have deteriorated back to the point (if not,=20 in some cases, worse) then when I originally started with it under 4.x :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 --0-1349575065-1115474940=:42300-- From owner-freebsd-stable@FreeBSD.ORG Sat May 7 14:29:18 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25B2116A4DB; Sat, 7 May 2005 14:29:18 +0000 (GMT) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF04343D46; Sat, 7 May 2005 14:29:17 +0000 (GMT) (envelope-from krion@voodoo.oberon.net) Received: from krion by voodoo.oberon.net with local (Exim 4.51 (FreeBSD)) id 1DUQIx-000FiK-Bi; Sat, 07 May 2005 16:29:19 +0200 Date: Sat, 7 May 2005 16:29:19 +0200 From: Kirill Ponomarew To: freebsd-stable@FreeBSD.org Message-ID: <20050507142919.GA60320@voodoo.oberon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-NCC-Regid: de.oberon X-NIC-HDL: KP869-RIPE cc: matk@FreeBSD.org Subject: problems with Maestro sound card X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 14:29:18 -0000 Trying to kldload Maestro sound card module (snd_maestro.ko) on FreeBSD 5.4-RC4 on Toshiba Satellite 4060XCDT fails with: pcm0: port 0xfc00-0xfcff irq 11 at device 12.0 on pci0 pcm0: agg_rdcodec() RW_DONE timed out. pcm0: will perform cold reset. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_rdcodec() PROGLESS timed out. pcm0: pcm0: agg_rdcodec() PROGLESS timed out. pcm0: agg_rdcodec() RW_DONE timed out. pcm0: ac97 codec reports dac not ready pcm0: agg_wrcodec() PROGLESS timed out. pcm0: agg_wrcodec() PROGLESS timed out. The same troubles I got on FreeBSD 5.3-RELEASE. Any tips and advices ? Thanks. -Kirill From owner-freebsd-stable@FreeBSD.ORG Sat May 7 18:36:03 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B46416A4DB for ; Sat, 7 May 2005 18:36:03 +0000 (GMT) Received: from merlin.alerce.com (w094.z064001164.sjc-ca.dsl.cnc.net [64.1.164.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87BF343D7F for ; Sat, 7 May 2005 18:36:02 +0000 (GMT) (envelope-from hartzell@kestrel.alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id B2B1C2181; Sat, 7 May 2005 11:35:21 -0700 (PDT) Received: from satchel.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) Authority" (verified OK)) by merlin.alerce.com (Postfix) with ESMTP id 88197215F; Sat, 7 May 2005 11:35:21 -0700 (PDT) Received: from satchel.alerce.com (localhost [127.0.0.1]) by satchel.alerce.com (8.13.1/8.13.1) with ESMTP id j47Ia6uh013456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 May 2005 11:36:07 -0700 (PDT) (envelope-from hartzell@satchel.alerce.com) Received: (from hartzell@localhost) by satchel.alerce.com (8.13.1/8.13.1/Submit) id j47Ia4iJ013453; Sat, 7 May 2005 11:36:04 -0700 (PDT) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <17021.2707.856366.112695@satchel.alerce.com> Date: Sat, 7 May 2005 11:36:03 -0700 To: "Marc G. Fournier" In-Reply-To: <20050507110403.D42300@ganymede.hub.org> References: <20050507110403.D42300@ganymede.hub.org> X-Mailer: VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid X-Virus-Scanned: ClamAV using ClamSMTP cc: "stable@freebsd.org" cc: hartzell@alerce.com cc: Eirik =?ISO-8859-1?B?2A==?=verby Subject: Re: unionfs limitations? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hartzell@alerce.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2005 18:36:03 -0000 Marc G. Fournier writes: > On Sat, 7 May 2005, Eirik [ISO-8859-1] =D8verby wrote: >=20 > > On 07-05-05 03:19, "George Hartzell" = wrote: > >[...] > >> Here's one unionfs/jail gotcha that's bitten me a couple of times= . If > >> you actually *use* (or, have used) the ports directory to build a= nd > >> install stuff onto the "host" machine, the ports infrastructure i= n the > >> jail gets kind of confused. It seems to be checking for the file= s in > >> the dependencies, doesn't find them, goes to make them, and then > >> [depending on what state the relevant port directory is in], thin= gs > >> get "odd". > > > > I noticed that pretty early on, yea ;) >=20 > Has 5.x *really* gone that far downhill? :( That particular problem isn't a 5.x thing *at all*, it's just a consequence of the way ports work (recording some info as dot files in the work directory) and dependencies are tracked (looking for files out in /usr/local). As soon as I thought about it, it was clear what *I'd* done. > I've been doing the above since about day one ... *but* ... is this = the=20 > case if you set WRKDIRPREFIX=3D to somewhere else in /etc/make.conf?= I=20 > don't build the actual port *in* /usr/ports, so the only thing that = gets=20 > written in /usr/ports is /usr/ports/distfiles ... I think that having the work directories to something else would have avoided the problem quite nicely. Again, it's not a FreeBSD 5 isse at all, just me getting exactly what I asked for.... g. From owner-freebsd-stable@FreeBSD.ORG Sat May 7 20:25:00 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EE3016A4DD for ; Sat, 7 May 2005 20:25:00 +0000 (GMT) Received: from aisdirect.co.uk (dsl-217-155-102-238.zen.co.uk [217.155.102.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEF4643D77 for ; Sat, 7 May 2005 20:24:59 +0000 (GMT) (envelope-from jcr@canuck.co.uk) Received: from [192.168.0.18] (helo=[192.168.0.18]) by aisdirect.co.uk with esmtp (Exim 4.24; FreeBSD 4.8) id 1DUVoY-00043g-HX for freebsd-stable@freebsd.org; Sat, 07 May 2005 21:22:18 +0100 Message-ID: <427D2497.4000406@canuck.co.uk> Date: Sat, 07 May 2005 21:27:03 +0100 From: jcr User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050329) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: half-dead 5.[34] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 20:25:00 -0000 >Weird thing happened this morning though, suddenly the box seemed half-dead. >I didn't touch it, someone else noticed because they weren't able to ssh in. >TCP connection established, but no auth phase. >I also noticed in my active ssh sessions, that things were "dead", in the >sense that when on the shell prompt, pressing ENTER only gave me a new, >blank line. Logging in via serial console didn't work either, put in >username and press ENTER and nothing happened. > This may be unrelated, but I had almost exactly these symptoms on April 1st with RELENG_5_3 built from March 25th cvsup. SSH connection got a bit further. prompted on remote system with correct key fingerprint, but got no further. Same scroll-only behavior on console, I could still change vtys, but each had the problem. No response to ctl-alt-del, so pulled plug. No jails or unionfs, running Apache1.3, mysql4.1, PHP 4 and Zend ZDE server 4. msi km4m-v, 256 ddr333, AthlonXP1800+. Last thing in syslog was making xpdf from ports. I put it down at the time to having earlier tried to launch openoffice installer from the machine over ssh-tunneld-X, which never come up. Figured it had quietly eaten all the mem or such. Hasn't recurred, box is otherwise absolutely stable. -- From owner-freebsd-stable@FreeBSD.ORG Sat May 7 21:23:26 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EF7616A4DD for ; Sat, 7 May 2005 21:23:26 +0000 (GMT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96F3E43D92 for ; Sat, 7 May 2005 21:23:25 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DUWef-0003O5-0B for freebsd-stable@freebsd.org; Sat, 07 May 2005 23:16:09 +0200 Received: from gn-hgk-15cd4.adsl.wanadoo.nl ([81.69.122.212]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 May 2005 23:16:08 +0200 Received: from A.S.Usov by gn-hgk-15cd4.adsl.wanadoo.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 07 May 2005 23:16:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Alexander S. Usov" Date: Sat, 07 May 2005 23:22:38 +0200 Organization: KVI Lines: 13 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: gn-hgk-15cd4.adsl.wanadoo.nl User-Agent: KNode/0.9.0 Sender: news Subject: ehci is broken? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 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, 07 May 2005 21:23:26 -0000 Hi! It looks that somewhere recently something was broken in ehci again. Trying to write something to msdosfs/ext3fs mounted from external usb2 drive blocks quite qickly. Writing process gets stuck in wdrain state, and disk seems unresponsive -- it just lights up the lamp and does nothing. Any ideas what to check? -- Best regards, Alexander.