From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 03:29:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A1EC106566C for ; Sun, 21 Feb 2010 03:29:46 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 003138FC1A for ; Sun, 21 Feb 2010 03:29:45 +0000 (UTC) Received: by bwz8 with SMTP id 8so979843bwz.3 for ; Sat, 20 Feb 2010 19:29:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.137.16 with SMTP id u16mr8550051bkt.165.1266721960081; Sat, 20 Feb 2010 19:12:40 -0800 (PST) X-Originating-IP: [213.146.115.42] In-Reply-To: <20100220233546.GA36973@icarus.home.lan> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> <20100220202108.e1dd1b74.torfinn.ingolfsen@broadpark.no> <20100220193718.GA33214@icarus.home.lan> <20100220224959.c424dd9e.torfinn.ingolfsen@broadpark.no> <20100220233546.GA36973@icarus.home.lan> Date: Sun, 21 Feb 2010 04:12:39 +0100 Message-ID: From: "C. P. Ghost" To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 03:29:46 -0000 On Sun, Feb 21, 2010 at 12:35 AM, Jeremy Chadwick wrote: > We can safely rule out the Silicon Image controller (otherwise "ataX" > wouldn't be involved), which leaves the AMD SB700 SATA controller and > the AMD SB700 PATA controller. > > What exact disks (e.g. adX) are attached to ata5 and ata6? You haven't > provided dmesg output in any of your posts, and atacontrol/pciconf is > not sufficient (I should really improve atacontrol by printing this > information. I'll work on that in a few minutes). > > Some Linux users have reported AHCI-related issues with the SB600 > southbridge, but the core of the problem turned out to be MSI on certain > AMD northbridges (specifically RS480, RS400, and RS200). By disabling > MSI entirely they were able to achieve stability. The FreeBSD > equivalent would be to set the following in loader.conf and reboot: > > hw.pci.enable_msix="0" > hw.pci.enable_msi="0" > > The Linux quirk fix for this: > > > http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=queue-2.6.21/pci-quirks-disable-msi-on-rs400-200-and-rs480.patch;hb=05ab505f2909acf3a614d3e6a32271c4c1f8a69d > > Your board has an AMD 740G northbridge, but it might be worth trying the > MSI disable trick anyway. If it doesn't fix the problem then definitely > re-enable MSI. Isn't hardware fun? ;-) > Just one more data point. I have a machine with similar hardware: an MSI K9A2GM-FIH motherboard: http://eu.msi.com/index.php?func=proddesc&maincat_no=1&prod_no=1436 with an AMD 780G northbridge and AMD SB700 SATA controller, and I experienced freezes after switching to AHCI. Those freezes happened e.g. after some sustained random disk activity, followed by starting 'dvdisaster'. Then the HDD LDD started to blink slooooowwwwly, every 10 seconds on, then off and again. No more disk activity on the aha0 controller was possible. The system remained responsive as long as it didn't involve disk activity (i.e. pings, mouse, keyboard etc.., but not starting new processes). I'm pretty sure it started happening (very sporadically) only after I've switched to an AHCI setup. It didn't freeze before under the same load pattern. I can't test disabling MSI right now on that box, but will try it on a similar test machine in a few days (where I hope to reproduce this). Thanks for the hint! ahci0: port 0xc000-0xc007,0xb000-0xb003,0xa000 -0xa007,0x9000-0x9003,0x8000-0x800f mem 0xfe7ff800-0xfe7ffbff irq 22 at device 1 7.0 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found Package, expected Buffer 20090521 nspredef-1051 (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA/ATAPI-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes) ada0: Command Queueing enabled ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 05:08:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9EF51065670 for ; Sun, 21 Feb 2010 05:08:37 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 713128FC0A for ; Sun, 21 Feb 2010 05:08:37 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1L58VCS017970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Feb 2010 16:08:32 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1L58PSd054858; Sun, 21 Feb 2010 16:08:25 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1L58NtC054857; Sun, 21 Feb 2010 16:08:23 +1100 (EST) (envelope-from peter) Date: Sun, 21 Feb 2010 16:08:23 +1100 From: Peter Jeremy To: Torfinn Ingolfsen Message-ID: <20100221050823.GB22670@server.vk2pj.dyndns.org> References: <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline In-Reply-To: <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 05:08:38 -0000 --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-20 22:32:01 +0100, Torfinn Ingolfsen wrote: >On Sat, 20 Feb 2010 12:53:51 +1100 >Peter Jeremy wrote: > >> Looks reasonable. Let us know the results. I'd be interested in >> the output from "ntpdc -c loopi -c sysi". > >Ok, here we go (the server panic'ed again last night): >root@kg-f2# uptime >10:28PM up 2:26, 3 users, load averages: 0.00, 0.00, 0.00 >root@kg-f2# sysctl machdep.acpi_timer_freq >machdep.acpi_timer_freq: 3577045 >root@kg-f2# tvlm >Feb 20 20:06:41 kg-f2 ntpd[942]: kernel time sync status change 2001 >Feb 20 20:21:49 kg-f2 ntpd[942]: time reset +1.118880 s >Feb 20 20:37:53 kg-f2 ntpd[942]: time reset +1.188538 s >Feb 20 20:53:03 kg-f2 ntpd[942]: time reset +1.121903 s >Feb 20 21:09:00 kg-f2 ntpd[942]: time reset +1.179924 s >Feb 20 21:24:57 kg-f2 ntpd[942]: time reset +1.178490 s >Feb 20 21:39:58 kg-f2 ntpd[942]: time reset +1.110647 s >Feb 20 21:55:53 kg-f2 ntpd[942]: time reset +1.177292 s >Feb 20 22:11:44 kg-f2 ntpd[942]: time reset +1.172358 s >Feb 20 22:26:48 kg-f2 ntpd[942]: time reset +1.114350 s That's definitely not good - though it's marginally better than before. I have checked on a local machine and the timecounter frequency definitely needs to be adjusted in the opposite direction to the ntpd drift. I think I see the problem: I suggested 3579545Hz - 2500ppm, which gives an ACPI frequency of 3570596Hz. There was some miscommunication and you have set an ACPI frequency of 3577045Hz which is 2500Hz (or 698ppm) lower. The drift reported by the time resets has gone from +1930ppm (14.5s in 2:05:17) to +1233ppm (8.4s in 2:20:06) - which is 697ppm - fairly close to the change you made. (The PLL is running at +500ppm so the actual clock offset is 500ppm more than the "time reset" reports suggest. Having re-checked my maths, using both your "time reset" results, can you please try: sysctl machdep.acpi_timer_freq=3D3570847 That should result in a drift of close to zero (well within NTP's lock range of +/- 300ppm). >frequency: 500.000 ppm And this is definitely not good. >Not synced at all. Not good. :-/ >Perhaps I should give it more time? No. Once ntpd decides to continuously step, something is broken. I've done some double-checking and=20 On 2010-Feb-20 22:55:21 +0100, Torfinn Ingolfsen wrote: >This output looks ... wrong ... somehow to my eyes: =2E.. >Shouldn't ntpq and ntpdc be in agreement? I'm not sure which particular bits you are concerned about but ntpq reports delay/offset/jitter in msec whilst ntpdc reports them in sec. Note that I can't explain why the loopi offset is zero - ntpdc(8) states that this is the "last offset given to the loop filter by the packet processing code". For me it's non-zero but doesn't quite match the offset reported by 'ntpq -p'. --=20 Peter Jeremy --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuAv8cACgkQ/opHv/APuId2EwCgqxOQMM6WYfKNtGrFi61pxjYy 7jMAn38D/4KeLt2m+04N+rdnWuj0VL4U =1zTL -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 07:25:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1841D106566C for ; Sun, 21 Feb 2010 07:25:49 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0678FC0A for ; Sun, 21 Feb 2010 07:25:48 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Nj6CH-0005fP-Uh; Sun, 21 Feb 2010 09:25:45 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: <20100219191102.GA1045@icarus.home.lan> References: <20100219191102.GA1045@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Fri, 19 Feb 2010 11:11:02 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Feb 2010 09:25:45 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_8 -- NFSv3 credentials/permissions issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 07:25:49 -0000 > I'm willing to bet this is something simple I've overlooked, but I'm out > of ideas. Client is 8.0-RELEASE i386, server is 8.0-STABLE amd64 > (kernel/world 2010/01/16). NFS version used is v3. Server filesystem > is UFS2. at boot time, the NFS is V2!, if the server is FreeBSD it can be upgraded later in the boot progress to V3 > > Client configuration is off-kilter: it's a PXE booted machine. Initial > PXE booting uses TFTP, then switches to NFS to load the kernel and > kernel modules. The TFTP part works, with a caveat[1], but the NFS > portion fails. TFTP is as old as the Internet, so it mostly works, and security was in dipers, so the T for trivial also means un-secure :-) > > With NFS, I'm forced to change permissions on all the exported > files/directories to be 0644/0755 (specifically, setting other/global > read/write access) otherwise the client gets back "Permission denied". > The nfsd(8) man page implies that this shouldn't be necessary; adding > -mapall=nobody:nobody or -maproot=nobody doesn't fix things either. > why not use -maproot=root? by adding -ro, the client will be able to read but not modify. That's what we do here, the /etc is mounted via unionfs to a md, but that is yet another solution. > In the absence of -maproot and -mapall options, remote accesses by root > will result in using a credential of -2:-2. All other users will be > mapped to their remote credential. If a -maproot option is given, remote > access by root will be mapped to that credential instead of -2:-2. If a > -mapall option is given, all users (including root) will be mapped to > that credential in place of their own. > > Configuration data, tcpdump validation (client=192.168.1.140, > server=192.168.1.51), and syslog data is below. > > Ideas? > > [1]: TFTP works as long as the file its trying to request (in this case > /usr/local/freebsd8/boot/pxeboot) has its other/global read bit set, > otherwise EACCESS is returned; I had to look in the tftpd source to > figure this out. I'm not sure what the justification is there, given > that use of -s and/or -u switches credentials to user/group nobody... > only root can read a file with mode 0, so you need to set the read bit for any non root user. > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > > Relevant server configuration bits: > > /etc/rc.conf > ============== > rpcbind_enable="yes" > rpcbind_flags="-l" > mountd_enable="yes" > mountd_flags="-r -l" > nfs_server_enable="yes" > > /etc/exports > ============== > /usr/local/freebsd8 -network 192.168.1 -mask 255.255.255.0 > > Permissions > ============= > drwxr-xr-x 22 root wheel 512 Feb 6 12:25 / > drwxr-xr-x 17 root wheel 512 Feb 12 03:38 /usr > drwxr-xr-x 15 root wheel 512 Feb 19 10:41 /usr/local > drwx------ 5 nobody nobody 512 Feb 19 10:42 /usr/local/freebsd8 > drwx------ 7 nobody nobody 1024 Nov 21 08:11 /usr/local/freebsd8/boot > drwx------ 2 nobody nobody 12800 Nov 21 08:11 /usr/local/freebsd8/boot/kernel > -r-------- 1 nobody nobody 11492703 Nov 21 07:48 /usr/local/freebsd8/boot/kernel/kernel > > tcpdump > ========= > {...snipping TFTP portion...} > 10:57:20.601313 IP 192.168.1.140.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:30:48:71:60:6b, length 548 > 10:57:20.601442 IP 192.168.1.51.67 > 192.168.1.140.68: BOOTP/DHCP, Reply, length 323 > 10:57:20.601688 IP 192.168.1.140.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:30:48:71:60:6b, length 548 > 10:57:20.601782 IP 192.168.1.51.67 > 192.168.1.140.68: BOOTP/DHCP, Reply, length 323 > 10:57:20.613056 IP 192.168.1.140.1023 > 192.168.1.51.111: UDP, length 76 > 10:57:20.613369 IP 192.168.1.51.111 > 192.168.1.140.1023: UDP, length 28 > 10:57:20.613556 IP 192.168.1.140.1023 > 192.168.1.51.947: UDP, length 84 > 10:57:20.613921 IP 192.168.1.51.947 > 192.168.1.140.1023: UDP, length 60 > 10:57:20.614055 IP 192.168.1.140.1023 > 192.168.1.51.111: UDP, length 76 > 10:57:20.614291 IP 192.168.1.51.111 > 192.168.1.140.1023: UDP, length 28 > 10:57:20.614432 IP 192.168.1.140.4 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" > 10:57:20.614458 IP 192.168.1.51.2049 > 192.168.1.140.4: reply ok 28 lookup ERROR: Permission denied > 10:57:20.615436 IP 192.168.1.140.1022 > 192.168.1.51.947: UDP, length 84 > 10:57:20.615677 IP 192.168.1.51.947 > 192.168.1.140.1022: UDP, length 60 > 10:57:20.615806 IP 192.168.1.140.6 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" > 10:57:20.615824 IP 192.168.1.51.2049 > 192.168.1.140.6: reply ok 28 lookup ERROR: Permission denied > 10:57:20.615929 IP 192.168.1.140.1021 > 192.168.1.51.947: UDP, length 84 > 10:57:20.616164 IP 192.168.1.51.947 > 192.168.1.140.1021: UDP, length 60 > 10:57:20.616308 IP 192.168.1.140.8 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" > 10:57:20.616327 IP 192.168.1.51.2049 > 192.168.1.140.8: reply ok 28 lookup ERROR: Permission denied > 10:57:20.616428 IP 192.168.1.140.1020 > 192.168.1.51.947: UDP, length 84 > 10:57:20.616660 IP 192.168.1.51.947 > 192.168.1.140.1020: UDP, length 60 > {...repeat until client gives up...} > > Feb 19 10:57:20 icarus dhcpd: DHCPDISCOVER from 00:30:48:71:60:6b via em0 > Feb 19 10:57:20 icarus dhcpd: DHCPOFFER on 192.168.1.140 to 00:30:48:71:60:6b via em0 > Feb 19 10:57:20 icarus dhcpd: DHCPREQUEST for 192.168.1.140 (192.168.1.51) from 00:30:48:71:60:6b via em0 > Feb 19 10:57:20 icarus dhcpd: DHCPACK on 192.168.1.140 to 00:30:48:71:60:6b via em0 > Feb 19 10:57:20 icarus rpcbind: connect from 192.168.1.140 to getport/addr(mountd) > Feb 19 10:57:20 icarus mountd[1474]: mount request succeeded from 192.168.1.140 for /usr/local/freebsd8 > Feb 19 10:57:20 icarus rpcbind: connect from 192.168.1.140 to getport/addr(nfs) > Feb 19 10:57:20 icarus mountd[1474]: mount request succeeded from 192.168.1.140 for /usr/local/freebsd8 > Feb 19 10:57:21 icarus last message repeated 34 times > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 07:46:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4DC451065742 for ; Sun, 21 Feb 2010 07:46:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by mx1.freebsd.org (Postfix) with ESMTP id 33E0E8FC0A for ; Sun, 21 Feb 2010 07:46:07 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta15.emeryville.ca.mail.comcast.net with comcast id kXcc1d0021afHeLAFXm8a7; Sun, 21 Feb 2010 07:46:08 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta17.emeryville.ca.mail.comcast.net with comcast id kXm71d0073S48mS8dXm8DG; Sun, 21 Feb 2010 07:46:08 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id E271C1E301A; Sat, 20 Feb 2010 23:46:06 -0800 (PST) Date: Sat, 20 Feb 2010 23:46:06 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100221074606.GA49241@icarus.home.lan> References: <20100219191102.GA1045@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: RELENG_8 -- NFSv3 credentials/permissions issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 07:46:08 -0000 On Sun, Feb 21, 2010 at 09:25:45AM +0200, Daniel Braniss wrote: > > I'm willing to bet this is something simple I've overlooked, but I'm out > > of ideas. Client is 8.0-RELEASE i386, server is 8.0-STABLE amd64 > > (kernel/world 2010/01/16). NFS version used is v3. Server filesystem > > is UFS2. > at boot time, the NFS is V2!, if the server is FreeBSD it can be upgraded > later in the boot progress to V3 > > > > Client configuration is off-kilter: it's a PXE booted machine. Initial > > PXE booting uses TFTP, then switches to NFS to load the kernel and > > kernel modules. The TFTP part works, with a caveat[1], but the NFS > > portion fails. > TFTP is as old as the Internet, so it mostly works, and security was in dipers, > so the T for trivial also means un-secure :-) > > > > With NFS, I'm forced to change permissions on all the exported > > files/directories to be 0644/0755 (specifically, setting other/global > > read/write access) otherwise the client gets back "Permission denied". > > The nfsd(8) man page implies that this shouldn't be necessary; adding > > -mapall=nobody:nobody or -maproot=nobody doesn't fix things either. > > > why not use -maproot=root? > by adding -ro, the client will be able to read but not modify. > That's what we do here, the /etc is mounted via unionfs to a md, but > that is yet another solution. I'll have to try that (shouldn't take me long), but I remember messing with -maproot and -mapall both and wasn't able to get anywhere. I'll try again and report back. > > Configuration data, tcpdump validation (client=192.168.1.140, > > server=192.168.1.51), and syslog data is below. > > > > Ideas? > > > > [1]: TFTP works as long as the file its trying to request (in this case > > /usr/local/freebsd8/boot/pxeboot) has its other/global read bit set, > > otherwise EACCESS is returned; I had to look in the tftpd source to > > figure this out. I'm not sure what the justification is there, given > > that use of -s and/or -u switches credentials to user/group nobody... > > > only root can read a file with mode 0, so you need to set the read bit for > any non root user. I'm not sure if you're referring to NFS here, or my TFTP comment. My TFTP comment should be discussed elsewhere -- it's broken/odd behaviour, but the workaround for TFTP (to set the file permissions to 0644 for read) I'm fine with -- it's TFTP! :-) With regards to NFS: none of the files below are mode 0000. The request made via NFS should have gotten "translated" to being done by nobody:nobody on the NFS server, since there's no -mapall or -maproot line in the exports; user nobody has read access to everything shown below, so "Permission denied" makes no sense. > > Permissions > > ============= > > drwxr-xr-x 22 root wheel 512 Feb 6 12:25 / > > drwxr-xr-x 17 root wheel 512 Feb 12 03:38 /usr > > drwxr-xr-x 15 root wheel 512 Feb 19 10:41 /usr/local > > drwx------ 5 nobody nobody 512 Feb 19 10:42 /usr/local/freebsd8 > > drwx------ 7 nobody nobody 1024 Nov 21 08:11 /usr/local/freebsd8/boot > > drwx------ 2 nobody nobody 12800 Nov 21 08:11 /usr/local/freebsd8/boot/kernel > > -r-------- 1 nobody nobody 11492703 Nov 21 07:48 /usr/local/freebsd8/boot/kernel/kernel > > > > tcpdump > > ========= > > {...snipping TFTP portion...} > > 10:57:20.601313 IP 192.168.1.140.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:30:48:71:60:6b, length 548 > > 10:57:20.601442 IP 192.168.1.51.67 > 192.168.1.140.68: BOOTP/DHCP, Reply, length 323 > > 10:57:20.601688 IP 192.168.1.140.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:30:48:71:60:6b, length 548 > > 10:57:20.601782 IP 192.168.1.51.67 > 192.168.1.140.68: BOOTP/DHCP, Reply, length 323 > > 10:57:20.613056 IP 192.168.1.140.1023 > 192.168.1.51.111: UDP, length 76 > > 10:57:20.613369 IP 192.168.1.51.111 > 192.168.1.140.1023: UDP, length 28 > > 10:57:20.613556 IP 192.168.1.140.1023 > 192.168.1.51.947: UDP, length 84 > > 10:57:20.613921 IP 192.168.1.51.947 > 192.168.1.140.1023: UDP, length 60 > > 10:57:20.614055 IP 192.168.1.140.1023 > 192.168.1.51.111: UDP, length 76 > > 10:57:20.614291 IP 192.168.1.51.111 > 192.168.1.140.1023: UDP, length 28 > > 10:57:20.614432 IP 192.168.1.140.4 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" > > 10:57:20.614458 IP 192.168.1.51.2049 > 192.168.1.140.4: reply ok 28 lookup ERROR: Permission denied > > 10:57:20.615436 IP 192.168.1.140.1022 > 192.168.1.51.947: UDP, length 84 > > 10:57:20.615677 IP 192.168.1.51.947 > 192.168.1.140.1022: UDP, length 60 > > 10:57:20.615806 IP 192.168.1.140.6 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" > > 10:57:20.615824 IP 192.168.1.51.2049 > 192.168.1.140.6: reply ok 28 lookup ERROR: Permission denied > > 10:57:20.615929 IP 192.168.1.140.1021 > 192.168.1.51.947: UDP, length 84 > > 10:57:20.616164 IP 192.168.1.51.947 > 192.168.1.140.1021: UDP, length 60 > > 10:57:20.616308 IP 192.168.1.140.8 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" > > 10:57:20.616327 IP 192.168.1.51.2049 > 192.168.1.140.8: reply ok 28 lookup ERROR: Permission denied > > 10:57:20.616428 IP 192.168.1.140.1020 > 192.168.1.51.947: UDP, length 84 > > 10:57:20.616660 IP 192.168.1.51.947 > 192.168.1.140.1020: UDP, length 60 > > {...repeat until client gives up...} -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 08:20:33 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49984106566B for ; Sun, 21 Feb 2010 08:20:33 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A99AA8FC1A for ; Sun, 21 Feb 2010 08:20:32 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o1L8KJHS039888 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 21 Feb 2010 08:20:27 GMT (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <4B80ECC3.1040200@infracaninophile.co.uk> Date: Sun, 21 Feb 2010 08:20:19 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100220225521.18586aaf.torfinn.ingolfsen@broadpark.no> <20100220234234.GB36973@icarus.home.lan> In-Reply-To: <20100220234234.GB36973@icarus.home.lan> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, SPF_FAIL autolearn=no version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on happy-idiot-talk.infracaninophile.co.uk Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 08:20:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20/02/2010 23:42, Jeremy Chadwick wrote: > For sake of example -- look at ntpq's "delay" column for each peer, and > then look at the same column but for ntpdc. You'll see that for ntpdc > they're divided by 1000 (presumably kern.hz rate): No -- those are just times measured in milliseconds (for ntpq) or seconds (for ntpdc). kern.hz doesn't come into it. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuA7MMACgkQ8Mjk52CukIymTACfV62sN6DC8TQjnxhqS7w5r89l m8MAn3vxDX8w2LpfA7ik67KXrhS2LY6G =eRg0 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 09:02:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 496A11065670 for ; Sun, 21 Feb 2010 09:02:30 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id F354F8FC18 for ; Sun, 21 Feb 2010 09:02:29 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KY600I3FP3X3L50@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Feb 2010 10:02:21 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KY6004RFP3X7LB0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Feb 2010 10:02:21 +0100 (CET) Date: Sun, 21 Feb 2010 10:02:21 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100221100221.e6809b9e.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100221050823.GB22670@server.vk2pj.dyndns.org> References: <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100221050823.GB22670@server.vk2pj.dyndns.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) 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 Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 09:02:30 -0000 On Sun, 21 Feb 2010 16:08:23 +1100 Peter Jeremy wrote: > That's definitely not good - though it's marginally better than before. > I have checked on a local machine and the timecounter frequency definitely > needs to be adjusted in the opposite direction to the ntpd drift. > > I think I see the problem: I suggested 3579545Hz - 2500ppm, which > gives an ACPI frequency of 3570596Hz. There was some miscommunication > and you have set an ACPI frequency of 3577045Hz which is 2500Hz (or > 698ppm) lower. The drift reported by the time resets has gone from > +1930ppm (14.5s in 2:05:17) to +1233ppm (8.4s in 2:20:06) - which is > 697ppm - fairly close to the change you made. (The PLL is running > at +500ppm so the actual clock offset is 500ppm more than the "time > reset" reports suggest. Very good info, it helps me understand more. Thanks! > Having re-checked my maths, using both your "time reset" results, can > you please try: > sysctl machdep.acpi_timer_freq=3570847 Ok, trying that now: root@kg-f2# sysctl machdep.acpi_timer_freq=3570847 machdep.acpi_timer_freq: 3577045 -> 3570847 root@kg-f2# /etc/rc.d/ntpd stop Stopping ntpd. root@kg-f2# rm /var/db/ntpd.drift root@kg-f2# /etc/rc.d/ntpd start Starting ntpd. > That should result in a drift of close to zero (well within NTP's > lock range of +/- 300ppm). Good. > No. Once ntpd decides to continuously step, something is broken. Aha, very good to know. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 09:54:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B08F1065672 for ; Sun, 21 Feb 2010 09:54:49 +0000 (UTC) (envelope-from technik@callooh.com) Received: from mail.callooh.com (chello084113233101.13.14.vie.surfer.at [84.113.233.101]) by mx1.freebsd.org (Postfix) with ESMTP id A89108FC19 for ; Sun, 21 Feb 2010 09:54:48 +0000 (UTC) Received: from zev.home.callooh.com (zev.home.callooh.com [192.168.1.2]) (authenticated bits=0) by mail.callooh.com (8.14.4/8.14.4) with ESMTP id o1L9gffY096943 for ; Sun, 21 Feb 2010 10:42:42 +0100 (CET) (envelope-from technik@callooh.com) Date: Sun, 21 Feb 2010 10:42:41 +0100 From: technik@callooh.com To: FreeBSD-STABLE Mailing List Message-ID: <20100221104241.7c0c7664@zev.home.callooh.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DCC-wuwien-Metrics: lyekka.home.callooh.com 1290; Body=1 Fuz1=1 Fuz2=1 X-Virus-Scanned: clamav-milter 0.95.3 at lyekka.home.callooh.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.callooh.com [192.168.1.1]); Sun, 21 Feb 2010 10:42:46 +0100 (CET) Subject: Intel Wifi Link 1000 - panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 09:54:49 -0000 today i upgraded to the latest stable from source, and tried to use the iwn driver, but when i `kldload if_iwn`: iwn0 mem 0xfeafe000-0xfeafffff irq 17 at device 0.0 on pci2 iwn: MIMO 1T2R, , address 00:00:00:00:00:00 panic: ieee80211_get_ratetable: not rate table for channel; freq 0 flag 0x0 cpuid = 1 ... no matter if i kldload iwn1000fw in advance or not .. is there something i could tweak to get the driver working, or is it just broken ? thanks for any response, reinhard -- Nobody can be exactly like me. Sometimes even I have trouble doing it. -- Tallulah Bankhead From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 10:02:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C742106566B for ; Sun, 21 Feb 2010 10:02:30 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 1A3118FC1D for ; Sun, 21 Feb 2010 10:02:29 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Nj8dw-0009FM-U1; Sun, 21 Feb 2010 12:02:28 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: <20100221074606.GA49241@icarus.home.lan> References: <20100219191102.GA1045@icarus.home.lan> <20100221074606.GA49241@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Sat, 20 Feb 2010 23:46:06 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Feb 2010 12:02:28 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_8 -- NFSv3 credentials/permissions issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 10:02:30 -0000 > On Sun, Feb 21, 2010 at 09:25:45AM +0200, Daniel Braniss wrote: > > > I'm willing to bet this is something simple I've overlooked, but I'm out > > > of ideas. Client is 8.0-RELEASE i386, server is 8.0-STABLE amd64 > > > (kernel/world 2010/01/16). NFS version used is v3. Server filesystem > > > is UFS2. > > at boot time, the NFS is V2!, if the server is FreeBSD it can be upgraded > > later in the boot progress to V3 > > > > > > Client configuration is off-kilter: it's a PXE booted machine. Initial > > > PXE booting uses TFTP, then switches to NFS to load the kernel and > > > kernel modules. The TFTP part works, with a caveat[1], but the NFS > > > portion fails. > > TFTP is as old as the Internet, so it mostly works, and security was in dipers, > > so the T for trivial also means un-secure :-) > > > > > > With NFS, I'm forced to change permissions on all the exported > > > files/directories to be 0644/0755 (specifically, setting other/global > > > read/write access) otherwise the client gets back "Permission denied". > > > The nfsd(8) man page implies that this shouldn't be necessary; adding > > > -mapall=nobody:nobody or -maproot=nobody doesn't fix things either. > > > > > why not use -maproot=root? > > by adding -ro, the client will be able to read but not modify. > > That's what we do here, the /etc is mounted via unionfs to a md, but > > that is yet another solution. > > I'll have to try that (shouldn't take me long), but I remember messing > with -maproot and -mapall both and wasn't able to get anywhere. I'll > try again and report back. > > > > Configuration data, tcpdump validation (client=192.168.1.140, > > > server=192.168.1.51), and syslog data is below. > > > > > > Ideas? > > > > > > [1]: TFTP works as long as the file its trying to request (in this case > > > /usr/local/freebsd8/boot/pxeboot) has its other/global read bit set, > > > otherwise EACCESS is returned; I had to look in the tftpd source to > > > figure this out. I'm not sure what the justification is there, given > > > that use of -s and/or -u switches credentials to user/group nobody... > > > > > only root can read a file with mode 0, so you need to set the read bit for > > any non root user. > > I'm not sure if you're referring to NFS here, or my TFTP comment. My > TFTP comment should be discussed elsewhere -- it's broken/odd behaviour, > but the workaround for TFTP (to set the file permissions to 0644 for > read) I'm fine with -- it's TFTP! :-) > if the owner does not have read permition, it wont be able to read the file, no matter that the other read bits are enabled. % date > 0 % chmod 04 0 % cat 0 cat: 0: Permission denied % chmod 040 0 % cat 0 cat: 0: Permission denied % chmod 0400 0 % cat 0 Sun Feb 21 11:47:32 IST 2010 % this answers the TFTP problem. > With regards to NFS: none of the files below are mode 0000. The request > made via NFS should have gotten "translated" to being done by > nobody:nobody on the NFS server, since there's no -mapall or -maproot > line in the exports; user nobody has read access to everything shown > below, so "Permission denied" makes no sense. > as I mentioned before/above, maybe not so clearly, the initial NFS transactions are done via NFS/V2 - which is problematic/broken[1], and so probably the access permitions are not exactly what we expect. [1]: rm /any-file in a read-only exported fs will hang the client > > > Permissions > > > ============= > > > drwxr-xr-x 22 root wheel 512 Feb 6 12:25 / > > > drwxr-xr-x 17 root wheel 512 Feb 12 03:38 /usr > > > drwxr-xr-x 15 root wheel 512 Feb 19 10:41 /usr/local > > > drwx------ 5 nobody nobody 512 Feb 19 10:42 /usr/local/freebsd8 > > > drwx------ 7 nobody nobody 1024 Nov 21 08:11 /usr/local/freebsd8/boot > > > drwx------ 2 nobody nobody 12800 Nov 21 08:11 /usr/local/freebsd8/boot/kernel > > > -r-------- 1 nobody nobody 11492703 Nov 21 07:48 /usr/local/freebsd8/boot/kernel/kernel > > > > > > tcpdump > > > ========= > > > {...snipping TFTP portion...} > > > 10:57:20.601313 IP 192.168.1.140.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:30:48:71:60:6b, length 548 > > > 10:57:20.601442 IP 192.168.1.51.67 > 192.168.1.140.68: BOOTP/DHCP, Reply, length 323 > > > 10:57:20.601688 IP 192.168.1.140.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:30:48:71:60:6b, length 548 > > > 10:57:20.601782 IP 192.168.1.51.67 > 192.168.1.140.68: BOOTP/DHCP, Reply, length 323 > > > 10:57:20.613056 IP 192.168.1.140.1023 > 192.168.1.51.111: UDP, length 76 > > > 10:57:20.613369 IP 192.168.1.51.111 > 192.168.1.140.1023: UDP, length 28 > > > 10:57:20.613556 IP 192.168.1.140.1023 > 192.168.1.51.947: UDP, length 84 > > > 10:57:20.613921 IP 192.168.1.51.947 > 192.168.1.140.1023: UDP, length 60 > > > 10:57:20.614055 IP 192.168.1.140.1023 > 192.168.1.51.111: UDP, length 76 > > > 10:57:20.614291 IP 192.168.1.51.111 > 192.168.1.140.1023: UDP, length 28 > > > 10:57:20.614432 IP 192.168.1.140.4 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" > > > 10:57:20.614458 IP 192.168.1.51.2049 > 192.168.1.140.4: reply ok 28 lookup ERROR: Permission denied > > > 10:57:20.615436 IP 192.168.1.140.1022 > 192.168.1.51.947: UDP, length 84 > > > 10:57:20.615677 IP 192.168.1.51.947 > 192.168.1.140.1022: UDP, length 60 > > > 10:57:20.615806 IP 192.168.1.140.6 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" > > > 10:57:20.615824 IP 192.168.1.51.2049 > 192.168.1.140.6: reply ok 28 lookup ERROR: Permission denied > > > 10:57:20.615929 IP 192.168.1.140.1021 > 192.168.1.51.947: UDP, length 84 > > > 10:57:20.616164 IP 192.168.1.51.947 > 192.168.1.140.1021: UDP, length 60 > > > 10:57:20.616308 IP 192.168.1.140.8 > 192.168.1.51.2049: 100 lookup fh 1197,150310/6618112 "boot" > > > 10:57:20.616327 IP 192.168.1.51.2049 > 192.168.1.140.8: reply ok 28 lookup ERROR: Permission denied > > > 10:57:20.616428 IP 192.168.1.140.1020 > 192.168.1.51.947: UDP, length 84 > > > 10:57:20.616660 IP 192.168.1.51.947 > 192.168.1.140.1020: UDP, length 60 > > > {...repeat until client gives up...} > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 10:24:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D87E21065670 for ; Sun, 21 Feb 2010 10:24:05 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id BD6BE8FC12 for ; Sun, 21 Feb 2010 10:24:05 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta06.emeryville.ca.mail.comcast.net with comcast id kaPo1d0010FhH24A6aQ6wc; Sun, 21 Feb 2010 10:24:06 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta08.emeryville.ca.mail.comcast.net with comcast id kaQ51d0043S48mS8UaQ5VK; Sun, 21 Feb 2010 10:24:06 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 35C6D1E301A; Sun, 21 Feb 2010 02:24:04 -0800 (PST) Date: Sun, 21 Feb 2010 02:24:04 -0800 From: Jeremy Chadwick To: Daniel Braniss Message-ID: <20100221102404.GA52396@icarus.home.lan> References: <20100219191102.GA1045@icarus.home.lan> <20100221074606.GA49241@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_8 -- NFSv3 credentials/permissions issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 10:24:05 -0000 On Sun, Feb 21, 2010 at 12:02:28PM +0200, Daniel Braniss wrote: > > I'm not sure if you're referring to NFS here, or my TFTP comment. My > > TFTP comment should be discussed elsewhere -- it's broken/odd behaviour, > > but the workaround for TFTP (to set the file permissions to 0644 for > > read) I'm fine with -- it's TFTP! :-) > > > if the owner does not have read permition, it wont be able to read the file, > no matter that the other read bits are enabled. > > % date > 0 > % chmod 04 0 > % cat 0 > cat: 0: Permission denied > % chmod 040 0 > % cat 0 > cat: 0: Permission denied > % chmod 0400 0 > % cat 0 > Sun Feb 21 11:47:32 IST 2010 > % > this answers the TFTP problem. Actually it doesn't. Are you familiar with C? If so, have a look at this piece of the source code (src/libexec/tftpd/tftpd.c): 586 int 587 validate_access(char **filep, int mode) 588 { ... 618 if (stat(filename, &stbuf) < 0) 619 return (errno == ENOENT ? ENOTFOUND : EACCESS); 620 if ((stbuf.st_mode & S_IFMT) != S_IFREG) 621 return (ENOTFOUND); 622 if (mode == RRQ) { 623 if ((stbuf.st_mode & S_IROTH) == 0) 624 return (EACCESS); 625 } else { 626 if ((stbuf.st_mode & S_IWOTH) == 0) 627 return (EACCESS); 628 } ... 694 return (0); 695 } This function is called whenever there's a request of any sort via TFTP (such as file retrieval (read) or file storage (write)). In this context, RRQ = "read request". The above code explicitly requires the global/other read (or write, if the request is to write data) bit be set on the files being requested/written to, otherwise EACCESS ("Access Denied") is returned to the client. This is *regardless* of who owns the file. See the stat(2) man page for verification of S_IROTH and S_IWOTH bits. This is justified *unless* UID switching is present -- meaning, if the -s option (and/or -u) is used. If -s is used but no -u is specified, the daemon switches to user "nobody" by default. But regardless of what user the daemon switches to, its code still explicitly requires the global read or global write bits be set on the files. IMHO, the above permissions checks should be removed if -s is in effect. > > With regards to NFS: none of the files below are mode 0000. The request > > made via NFS should have gotten "translated" to being done by > > nobody:nobody on the NFS server, since there's no -mapall or -maproot > > line in the exports; user nobody has read access to everything shown > > below, so "Permission denied" makes no sense. > > > as I mentioned before/above, maybe not so clearly, the initial NFS transactions > are done via NFS/V2 - which is problematic/broken[1], and so probably > the access permitions are not exactly what we expect. > > [1]: rm /any-file in a read-only exported fs will hang the client > > > > > Permissions > > > > ============= > > > > drwxr-xr-x 22 root wheel 512 Feb 6 12:25 / > > > > drwxr-xr-x 17 root wheel 512 Feb 12 03:38 /usr > > > > drwxr-xr-x 15 root wheel 512 Feb 19 10:41 /usr/local > > > > drwx------ 5 nobody nobody 512 Feb 19 10:42 /usr/local/freebsd8 > > > > drwx------ 7 nobody nobody 1024 Nov 21 08:11 /usr/local/freebsd8/boot > > > > drwx------ 2 nobody nobody 12800 Nov 21 08:11 /usr/local/freebsd8/boot/kernel > > > > -r-------- 1 nobody nobody 11492703 Nov 21 07:48 /usr/local/freebsd8/boot/kernel/kernel Okay, so then you're saying it's a bug of some sort in NFSv2, not NFSv3. But the above (and below, see tcpdump) files are not attempting to be removed nor written to -- they're attempting to be read. Should I file a PR for this problem? IMHO, it's a pretty serious oversight (it effectively means user/group ownership means jack squat with NFSv2). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 11:52:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC335106566B for ; Sun, 21 Feb 2010 11:52:34 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id A17F68FC15 for ; Sun, 21 Feb 2010 11:52:34 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NjAMT-000ATg-6G; Sun, 21 Feb 2010 13:52:33 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jeremy Chadwick In-reply-to: <20100221102404.GA52396@icarus.home.lan> References: <20100219191102.GA1045@icarus.home.lan> <20100221074606.GA49241@icarus.home.lan> <20100221102404.GA52396@icarus.home.lan> Comments: In-reply-to Jeremy Chadwick message dated "Sun, 21 Feb 2010 02:24:04 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 21 Feb 2010 13:52:33 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_8 -- NFSv3 credentials/permissions issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 11:52:35 -0000 > On Sun, Feb 21, 2010 at 12:02:28PM +0200, Daniel Braniss wrote: > > > I'm not sure if you're referring to NFS here, or my TFTP comment. My > > > TFTP comment should be discussed elsewhere -- it's broken/odd behaviour, > > > but the workaround for TFTP (to set the file permissions to 0644 for > > > read) I'm fine with -- it's TFTP! :-) > > > > > if the owner does not have read permition, it wont be able to read the file, > > no matter that the other read bits are enabled. > > > > % date > 0 > > % chmod 04 0 > > % cat 0 > > cat: 0: Permission denied > > % chmod 040 0 > > % cat 0 > > cat: 0: Permission denied > > % chmod 0400 0 > > % cat 0 > > Sun Feb 21 11:47:32 IST 2010 > > % > > this answers the TFTP problem. > > Actually it doesn't. Are you familiar with C? If so, have a look at > this piece of the source code (src/libexec/tftpd/tftpd.c): > > 586 int > 587 validate_access(char **filep, int mode) > 588 { > ... > 618 if (stat(filename, &stbuf) < 0) > 619 return (errno == ENOENT ? ENOTFOUND : EACCESS); > 620 if ((stbuf.st_mode & S_IFMT) != S_IFREG) > 621 return (ENOTFOUND); > 622 if (mode == RRQ) { > 623 if ((stbuf.st_mode & S_IROTH) == 0) > 624 return (EACCESS); > 625 } else { > 626 if ((stbuf.st_mode & S_IWOTH) == 0) > 627 return (EACCESS); > 628 } > ... > 694 return (0); > 695 } > > This function is called whenever there's a request of any sort via TFTP > (such as file retrieval (read) or file storage (write)). In this > context, RRQ = "read request". > > The above code explicitly requires the global/other read (or write, if > the request is to write data) bit be set on the files being > requested/written to, otherwise EACCESS ("Access Denied") is returned to > the client. This is *regardless* of who owns the file. See the stat(2) > man page for verification of S_IROTH and S_IWOTH bits. > > This is justified *unless* UID switching is present -- meaning, if the > -s option (and/or -u) is used. If -s is used but no -u is specified, > the daemon switches to user "nobody" by default. But regardless of what > user the daemon switches to, its code still explicitly requires the > global read or global write bits be set on the files. > > IMHO, the above permissions checks should be removed if -s is in effect. > the code is only usefull if running as root (and questionable too). I agree, the code is useless, it should use access(2), but tftpd predates it :-( > > > With regards to NFS: none of the files below are mode 0000. The request > > > made via NFS should have gotten "translated" to being done by > > > nobody:nobody on the NFS server, since there's no -mapall or -maproot > > > line in the exports; user nobody has read access to everything shown > > > below, so "Permission denied" makes no sense. > > > > > as I mentioned before/above, maybe not so clearly, the initial NFS transactions > > are done via NFS/V2 - which is problematic/broken[1], and so probably > > the access permitions are not exactly what we expect. > > > > [1]: rm /any-file in a read-only exported fs will hang the client > > > > > > > Permissions > > > > > ============= > > > > > drwxr-xr-x 22 root wheel 512 Feb 6 12:25 / > > > > > drwxr-xr-x 17 root wheel 512 Feb 12 03:38 /usr > > > > > drwxr-xr-x 15 root wheel 512 Feb 19 10:41 /usr/local > > > > > drwx------ 5 nobody nobody 512 Feb 19 10:42 /usr/local/freebsd8 > > > > > drwx------ 7 nobody nobody 1024 Nov 21 08:11 /usr/local/freebsd8/boot > > > > > drwx------ 2 nobody nobody 12800 Nov 21 08:11 /usr/local/freebsd8/boot/kernel > > > > > -r-------- 1 nobody nobody 11492703 Nov 21 07:48 /usr/local/freebsd8/boot/kernel/kernel > > Okay, so then you're saying it's a bug of some sort in NFSv2, not NFSv3. > yes > But the above (and below, see tcpdump) files are not attempting to be > removed nor written to -- they're attempting to be read. I mentioned the rm bug to show that there is at least a well known problem, and your problem seems to point to yet another one. > Should I file a PR for this problem? IMHO, it's a pretty serious > oversight (it effectively means user/group ownership means jack squat > with NFSv2). well, V2 is quiet dead, and I doubt anyone is willing to look into it, what would be nice if pxeboot is upgraded to use NFS/V3 - before it becomes obsolete too :-) danny From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 12:41:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA1181065672 for ; Sun, 21 Feb 2010 12:41:19 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mx.techwires.net (mx.techwires.net [IPv6:2001:4d88:100f:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 82CA08FC19 for ; Sun, 21 Feb 2010 12:41:19 +0000 (UTC) Received: from maja.lab.techwires.net (dslb-088-065-058-156.pools.arcor-ip.net [88.65.58.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bschmidt) by mx.techwires.net (Postfix) with ESMTPSA id 8179D17B64; Sun, 21 Feb 2010 13:41:17 +0100 (CET) Received: from maja.lab.techwires.net (localhost [127.0.0.1]) by maja.lab.techwires.net (8.14.4/8.14.4) with ESMTP id o1LCfFic001919; Sun, 21 Feb 2010 13:41:15 +0100 (CET) (envelope-from bschmidt@techwires.net) Received: (from bschmidt@localhost) by maja.lab.techwires.net (8.14.4/8.14.4/Submit) id o1LCfDsY001918; Sun, 21 Feb 2010 13:41:13 +0100 (CET) (envelope-from bschmidt@techwires.net) X-Authentication-Warning: maja.lab.techwires.net: bschmidt set sender to bschmidt@techwires.net using -f From: Bernhard Schmidt To: freebsd-stable@freebsd.org Date: Sun, 21 Feb 2010 13:41:13 +0100 User-Agent: KMail/1.12.4 (FreeBSD/9.0-CURRENT; KDE/4.3.5; amd64; ; ) References: <20100221104241.7c0c7664@zev.home.callooh.com> In-Reply-To: <20100221104241.7c0c7664@zev.home.callooh.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201002211341.13756.bschmidt@techwires.net> Cc: technik@callooh.com Subject: Re: Intel Wifi Link 1000 - panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 12:41:20 -0000 On Sunday 21 February 2010 10:42:41 technik@callooh.com wrote: > today i upgraded to the latest stable from source, and tried to use the > iwn driver, but when i `kldload if_iwn`: > > iwn0 mem 0xfeafe000-0xfeafffff irq 17 at > device 0.0 on pci2 > iwn: MIMO 1T2R, , address 00:00:00:00:00:00 > panic: ieee80211_get_ratetable: not rate table for channel; freq 0 flag > 0x0 > cpuid = 1 > ... > > no matter if i kldload iwn1000fw in advance or not .. > > is there something i could tweak to get the driver working, or is it > just broken ? > > thanks for any response, > reinhard There is a fix for that in head, r203934. I will MFC that in a couple of days. http://svn.freebsd.org/viewvc/base/head/sys/dev/iwn/if_iwn.c?view=patch&r1=202986&r2=203934&pathrev=203934 -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 16:36:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CB861065670 for ; Sun, 21 Feb 2010 16:36:30 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id D84DB8FC18 for ; Sun, 21 Feb 2010 16:36:29 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KY700FN8A4JJV40@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Feb 2010 17:36:19 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KY700CUAA4J1E10@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Sun, 21 Feb 2010 17:36:19 +0100 (CET) Date: Sun, 21 Feb 2010 17:36:19 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100221173619.2470aa85.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100221050823.GB22670@server.vk2pj.dyndns.org> References: <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100221050823.GB22670@server.vk2pj.dyndns.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) 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 Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 16:36:30 -0000 On Sun, 21 Feb 2010 16:08:23 +1100 Peter Jeremy wrote: > Having re-checked my maths, using both your "time reset" results, can > you please try: > sysctl machdep.acpi_timer_freq=3570847 > That should result in a drift of close to zero (well within NTP's > lock range of +/- 300ppm). And a few hours later: from /var/log/messages: Feb 21 09:54:50 kg-f2 ntpd[55452]: ntpd 4.2.4p5-a (1) Feb 21 09:59:10 kg-f2 ntpd[55453]: kernel time sync status change 2001 More info: root@kg-f2# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *kg-omni1.kg4.no 78.157.115.4 3 u 31 64 377 0.174 -10.253 0.160 root@kg-f2# ntpdc -c loopi -c sysi offset: -0.010253 s frequency: 6.744 ppm poll adjust: -30 watchdog timer: 47 s system peer: kg-omni1.kg4.no system peer mode: client leap indicator: 00 stratum: 4 precision: -18 root distance: 0.02956 s root dispersion: 0.06795 s reference ID: [10.1.10.1] reference time: cf2bdf36.f8820aef Sun, Feb 21 2010 17:35:02.970 system flags: auth monitor ntp kernel stats jitter: 0.000153 s stability: 0.000 ppm broadcastdelay: 0.003998 s authdelay: 0.000000 s Problem solved. Thanks a lot. -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 19:30:01 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA9E61065679 for ; Sun, 21 Feb 2010 19:30:01 +0000 (UTC) (envelope-from technik@callooh.com) Received: from mail.callooh.com (chello084113233101.13.14.vie.surfer.at [84.113.233.101]) by mx1.freebsd.org (Postfix) with ESMTP id 7285B8FC15 for ; Sun, 21 Feb 2010 19:30:00 +0000 (UTC) Received: from zev.home.callooh.com (zev.home.callooh.com [192.168.1.2]) (authenticated bits=0) by mail.callooh.com (8.14.4/8.14.4) with ESMTP id o1LJTxp5006802 for ; Sun, 21 Feb 2010 20:29:59 +0100 (CET) (envelope-from technik@callooh.com) Date: Sun, 21 Feb 2010 20:29:59 +0100 From: technik@callooh.com To: freebsd-stable@freebsd.org Message-ID: <20100221202959.257bd60d@zev.home.callooh.com> In-Reply-To: <201002211341.13756.bschmidt@techwires.net> References: <20100221104241.7c0c7664@zev.home.callooh.com> <201002211341.13756.bschmidt@techwires.net> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-DCC-URT-Metrics: lyekka.home.callooh.com 1060; Body=1 Fuz1=1 Fuz2=1 X-Virus-Scanned: clamav-milter 0.95.3 at lyekka.home.callooh.com X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.callooh.com [192.168.1.1]); Sun, 21 Feb 2010 20:29:59 +0100 (CET) Subject: Re: Intel Wifi Link 1000 - panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 19:30:02 -0000 Am Sun, 21 Feb 2010 13:41:13 +0100 schrieb Bernhard Schmidt : > On Sunday 21 February 2010 10:42:41 technik@callooh.com wrote: > > today i upgraded to the latest stable from source, and tried to use > > the iwn driver, but when i `kldload if_iwn`: > > > > iwn0 mem 0xfeafe000-0xfeafffff irq 17 > > at device 0.0 on pci2 > > iwn: MIMO 1T2R, , address 00:00:00:00:00:00 > > panic: ieee80211_get_ratetable: not rate table for channel; freq 0 > > flag 0x0 > > cpuid = 1 > > ... > > > > no matter if i kldload iwn1000fw in advance or not .. > > > > is there something i could tweak to get the driver working, or is it > > just broken ? > > > > thanks for any response, > > reinhard > > > There is a fix for that in head, r203934. I will MFC that in a couple > of days. > > http://svn.freebsd.org/viewvc/base/head/sys/dev/iwn/if_iwn.c?view=patch&r1=202986&r2=203934&pathrev=203934 > yes, it works. great !!! thank you. br, reinhard From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 19:40:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C96061065672 for ; Sun, 21 Feb 2010 19:40:02 +0000 (UTC) (envelope-from dmagda@ee.ryerson.ca) Received: from toq11-srv.bellnexxia.net (toq11.bellnexxia.net [209.226.175.118]) by mx1.freebsd.org (Postfix) with ESMTP id 71ABD8FC08 for ; Sun, 21 Feb 2010 19:40:02 +0000 (UTC) Received: from toip5.srvr.bell.ca ([209.226.175.88]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20100221192929.DDVA11823.tomts16-srv.bellnexxia.net@toip5.srvr.bell.ca> for ; Sun, 21 Feb 2010 14:29:29 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEBACITgUtMQR9h/2dsb2JhbAAH1VWEawSDFQ Received: from bas1-toronto09-1279336289.dsl.bell.ca (HELO [192.168.1.103]) ([76.65.31.97]) by toip5.srvr.bell.ca with ESMTP; 21 Feb 2010 14:29:04 -0500 Message-Id: From: David Magda To: Peter Jeremy In-Reply-To: <20100221173619.2470aa85.torfinn.ingolfsen@broadpark.no> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 21 Feb 2010 14:29:28 -0500 References: <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100221050823.GB22670@server.vk2pj.dyndns.org> <20100221173619.2470aa85.torfinn.ingolfsen@broadpark.no> X-Mailer: Apple Mail (2.936) Cc: FreeBSD Stable Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 19:40:02 -0000 On Feb 21, 2010, at 11:36, Torfinn Ingolfsen wrote: > On Sun, 21 Feb 2010 16:08:23 +1100 Peter Jeremy > wrote: > >> Having re-checked my maths, using both your "time reset" results, can >> you please try: >> sysctl machdep.acpi_timer_freq=3570847 >> That should result in a drift of close to zero (well within NTP's >> lock range of +/- 300ppm). > > And a few hours later: from /var/log/messages: > Feb 21 09:54:50 kg-f2 ntpd[55452]: ntpd 4.2.4p5-a (1) > Feb 21 09:59:10 kg-f2 ntpd[55453]: kernel time sync status change 2001 > > More info: > root@kg-f2# ntpq -p > remote refid st t when poll reach delay > offset jitter > ========================================================== > *kg-omni1.kg4.no 78.157.115.4 3 u 31 64 377 0.174 > -10.253 0.160 > root@kg-f2# ntpdc -c loopi -c sysi > offset: -0.010253 s > frequency: 6.744 ppm > poll adjust: -30 > watchdog timer: 47 s [...] For future reference, how does the math work? How do you go from taking a timer number: $ sysctl machdep.acpi_timer_freq machdep.acpi_timer_freq: 3577045 And the ntpd(8) time reset log entries to adjust the frequency? Or do you use the PPM output of the ntpdc(8) command? I'm not quite sure I understand what happened here. :) From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 19:50:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B33DA106566B for ; Sun, 21 Feb 2010 19:50:55 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 4B1768FC0A for ; Sun, 21 Feb 2010 19:50:54 +0000 (UTC) Received: by bwz8 with SMTP id 8so1262757bwz.3 for ; Sun, 21 Feb 2010 11:50:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.24.139 with SMTP id v11mr1221153bkb.121.1266781847738; Sun, 21 Feb 2010 11:50:47 -0800 (PST) X-Originating-IP: [213.146.115.42] In-Reply-To: References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> <20100220202108.e1dd1b74.torfinn.ingolfsen@broadpark.no> <20100220193718.GA33214@icarus.home.lan> <20100220224959.c424dd9e.torfinn.ingolfsen@broadpark.no> <20100220233546.GA36973@icarus.home.lan> Date: Sun, 21 Feb 2010 20:50:47 +0100 Message-ID: From: "C. P. Ghost" To: Jeremy Chadwick Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 19:50:55 -0000 On Sun, Feb 21, 2010 at 4:12 AM, C. P. Ghost wrote: > On Sun, Feb 21, 2010 at 12:35 AM, Jeremy Chadwick wrote: >> >> Some Linux users have reported AHCI-related issues with the SB600 >> southbridge, but the core of the problem turned out to be MSI on certain >> AMD northbridges (specifically RS480, RS400, and RS200). > > Just one more data point. > > I have a machine with similar hardware: an MSI K9A2GM-FIH motherboard: > http://eu.msi.com/index.php?func=proddesc&maincat_no=1&prod_no=1436 > with an AMD 780G chipset and AMD SB700 SATA controller, > and I experienced freezes after switching to AHCI. > > Those freezes happened e.g. after some sustained random disk activity, > followed by starting 'dvdisaster'. Then the HDD LED started to blink > slooooowwwwly, every 10 seconds on, then off and again. No more disk > activity on the aha0 controller was possible. The system remained responsive > as long as it didn't involve disk activity (i.e. pings, mouse, keyboard etc.., > but not starting new processes). I just had a new crash with these symptoms, again exactly when starting 'dvdisaster'. dmesg then shows a lot of those: ahcich0: Timeout on slot 20 ahcich0: is 04000000 cs fff00007 ss fff00007 tfd 451 serr 00400000 ahcich0: port is not ready (timeout 10000ms) tfd = 00000480 repeating for multiple ports with different values, but every time with tfd = 00000480, whatever that may be. Obviously, the 10000ms timeout corresponds to the 10 seconds period of the HDD LED going on and off when the machine is in that state. I didn't test this yet with msi disabled: % sysctl -a | grep msi hw.bce.msi_enable: 1 hw.pci.honor_msi_blacklist: 1 hw.pci.enable_msix: 1 hw.pci.enable_msi: 1 hw.drm.msi: 1 Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 20:18:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A57EF106566B for ; Sun, 21 Feb 2010 20:18:07 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id EDA9F8FC0C for ; Sun, 21 Feb 2010 20:18:05 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1LKHhYN014070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2010 07:17:43 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1LKHgfe009084; Mon, 22 Feb 2010 07:17:42 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1LKHgQU009083; Mon, 22 Feb 2010 07:17:42 +1100 (EST) (envelope-from peter) Date: Mon, 22 Feb 2010 07:17:42 +1100 From: Peter Jeremy To: Torfinn Ingolfsen Message-ID: <20100221201742.GA8860@server.vk2pj.dyndns.org> References: <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100221050823.GB22670@server.vk2pj.dyndns.org> <20100221173619.2470aa85.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline In-Reply-To: <20100221173619.2470aa85.torfinn.ingolfsen@broadpark.no> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 20:18:07 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-21 17:36:19 +0100, Torfinn Ingolfsen wrote: >*kg-omni1.kg4.no 78.157.115.4 3 u 31 64 377 0.174 -10.253 0= =2E160 >root@kg-f2# ntpdc -c loopi -c sysi >offset: -0.010253 s >frequency: 6.744 ppm That looks much healthier though it doesn't explain why your system clock is ~2500ppm out to start with. You may get one further small (~128msec) time step as part of ntpd's PLL calibration. Over time (probably a couple of days from scratch), the "poll" rate should increase to 1024. If it doesn't, it may indicate that your system clock stability isn't very good or you have excessive jitter in your reference. --=20 Peter Jeremy --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuBlOYACgkQ/opHv/APuIeNcwCgphHfK/TkxNH9Ton+FpaJLBHI ie0Anjx1YPX6XnuFpW/dtoHUxH0YhPN0 =fLGL -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 21:54:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81B411065676 for ; Sun, 21 Feb 2010 21:54:38 +0000 (UTC) (envelope-from me@pollux.local.net) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id E5CD88FC16 for ; Sun, 21 Feb 2010 21:54:36 +0000 (UTC) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id B48D64C8111 for ; Sun, 21 Feb 2010 22:54:32 +0100 (CET) Received: from pollux.local.net (che78-3-82-246-30-233.fbx.proxad.net [82.246.30.233]) by smtp4-g21.free.fr (Postfix) with ESMTP id CDF024C803A for ; Sun, 21 Feb 2010 22:54:29 +0100 (CET) Received: by pollux.local.net (Postfix, from userid 2000) id 8CE321CD50; Sun, 21 Feb 2010 22:54:29 +0100 (CET) Delivered-To: unknown Received: from pop.free.fr (212.27.48.3) by pollux.local.net with POP3; 18 Feb 2010 17:32:31 -0000 Delivered-To: free.fr-hawei@free.fr Received: (qmail 17410 invoked from network); 18 Feb 2010 15:25:31 -0000 Received: from mx28-g26.free.fr (HELO qmta07.emeryville.ca.mail.comcast.net) (212.27.42.90) by mrelay1-g25.free.fr with SMTP; 18 Feb 2010 15:25:31 -0000 Received: from qmta07.emeryville.ca.mail.comcast.net ([76.96.30.64]) by mx1-g20.free.fr (MXproxy) for hawei@free.fr ; Thu, 18 Feb 2010 16:32:05 +0100 (CET) X-ProXaD-SC: state=HAM score=0 Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta07.emeryville.ca.mail.comcast.net with comcast id jTA91d00D1vN32cA7TY40S; Thu, 18 Feb 2010 15:32:04 +0000 Received: from stargazer.midnightbsd.org ([70.91.226.201]) by omta22.emeryville.ca.mail.comcast.net with comcast id jTaC1d00K4MLobJ8iTaERb; Thu, 18 Feb 2010 15:34:15 +0000 Received: from [192.168.0.42] (75-151-13-201-Michigan.hfc.comcastbusiness.net [75.151.13.201]) (authenticated bits=0) by stargazer.midnightbsd.org (8.14.4/8.14.4) with ESMTP id o1IFVtjh060489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 18 Feb 2010 10:32:00 -0500 (EST) (envelope-from luke@foolishgames.com) X-Authentication-Warning: stargazer.midnightbsd.org: Host 75-151-13-201-Michigan.hfc.comcastbusiness.net [75.151.13.201] claimed to be [192.168.0.42] Message-ID: <4B7D5D6A.1090004@foolishgames.com> Date: Thu, 18 Feb 2010 10:31:54 -0500 From: Lucas Holt User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Harald Weis References: <20100218152601.GA3076@pollux.local.net> In-Reply-To: <20100218152601.GA3076@pollux.local.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (stargazer.midnightbsd.org [70.91.226.201]); Thu, 18 Feb 2010 10:32:00 -0500 (EST) Resent-From: Harald Weis Resent-Date: Sun, 21 Feb 2010 22:54:29 +0100 Resent-To: freebsd-stable@freebsd.org Resent-Message-Id: <20100221215429.8CE321CD50@pollux.local.net> Cc: Subject: Re: Incorrect super block X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 21:54:38 -0000 Harald Weis wrote: > Has anybody encountered the following problem ? > > Mac OS X does recognize FreeBSD partitions on USB disks, but doesn't > want to mount them because ``Incorrect super block''. > This is extremely annoying for my ``client'' because he relies on dayly > backups on USB keys. Is there a solution ? > > Thank you in advance. > You could use another file system such as Fat32 or NTFS (fuse ntfs from ports). OS X can read both of those. Apple has been moving away from UFS support in OS X for awhile; snow leopard is quite stale on this front. Luke From owner-freebsd-stable@FreeBSD.ORG Sun Feb 21 23:42:41 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB1A31065679 for ; Sun, 21 Feb 2010 23:42:41 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-yx0-f199.google.com (mail-yx0-f199.google.com [209.85.210.199]) by mx1.freebsd.org (Postfix) with ESMTP id 43BA28FC17 for ; Sun, 21 Feb 2010 23:42:40 +0000 (UTC) Received: by yxe37 with SMTP id 37so2533993yxe.27 for ; Sun, 21 Feb 2010 15:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=4LF6KQaUyTTX9KP2QDCzz6hsiMTtPo3X6SqCkNan4lM=; b=StqMlNRxV6g/NKwsdoZ+gI6nW+zGaNhvVcKPfx2lUQ9RcnYRjIGrkvhebAhJ5uX2tC N72De/8gFl2wHkM4EnlTRdejaB4NU8SReW7ICNYbxViB62nqgtZNCHhQ8tpOXe6Ls/pP NR8wOwxuwYcSKr5crXpBQ0UMq8sCioCSpLJFI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=vQdTWmB92RM/pkxbi+VTxrlNT4TcAxyAq5YOwVkKDC34ruBS0GTCMqW3Q+kS3kBl2E sMPTjXQO+pP/eXeDuXQagzNecP49R5VYgGX2vBRytTsM/3qZSJq6U93gCPTf4sn7osTM WgM1JjJW32kO5/mMeNVnQE7otheJ24v0r/tqM= Received: by 10.151.89.35 with SMTP id r35mr2376744ybl.183.1266795754919; Sun, 21 Feb 2010 15:42:34 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 8sm1462870yxg.42.2010.02.21.15.42.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Feb 2010 15:42:33 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 21 Feb 2010 15:41:53 -0800 From: Pyun YongHyeon Date: Sun, 21 Feb 2010 15:41:53 -0800 To: Slawa Olhovchenkov Message-ID: <20100221234153.GA1251@michelle.cdnetworks.com> References: <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> <20100219200647.GK11675@michelle.cdnetworks.com> <20100219201359.GU55307@zxy.spb.ru> <20100219211201.GL11675@michelle.cdnetworks.com> <20100220214450.GV55307@zxy.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100220214450.GV55307@zxy.spb.ru> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2010 23:42:41 -0000 On Sun, Feb 21, 2010 at 12:44:50AM +0300, Slawa Olhovchenkov wrote: > On Fri, Feb 19, 2010 at 01:12:01PM -0800, Pyun YongHyeon wrote: > > > Normally you should not have any FCS errors, it could be related > > with signal quality and these errors might not be correctly > > counted. > > I can't check cable and switch counters on bge1 before Feb 24. > > > > 3. packets don't lost on sources at Aug'09 > > > > Since I don't have BCM5704 hardware it's hard to find which > > revision may affect to this issue. Could you narrow down which > > revision number started showing the issue? > > I am don't update source between Aug'09 and Feb 16. > There were many bge(4) changes in that time frame. So it's hard to find which commit is guilty for the packet drop issue. If you can narrow down possible changes that might affect the issue that could help me a lot. You can do binary searching technique for the SVN revisions to know possible candidates. http://svn.freebsd.org/viewvc/base/head/sys/dev/bge/if_bge.c > 4. Packets don't lost immediately after reboot. > > PS: I got kernel panic. > I think this is the same crash(NULL pointer dereference in m_copym(9)) as you reported and I think this means the patch I posted did not help to fix the panic issue. > === > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x18 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff802eb3b7 > stack pointer = 0x28:0xffffff80001c66e0 > frame pointer = 0x28:0xffffff8 01c6740 > code segment = base 0x0, limi 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 724 (named) > [thread pid 724 tid 100051 ] > Stopped at m_copym+0x37: movl 0x18(%r12),%eax > db> panic > panic: from debugger > cpuid = 0 > Uptime: 1d5h55m33s > Physical memory: 2039 MB > Dumping 1448 MB: 1433 1417 1401 From owner-freebsd-stable@FreeBSD.ORG Mon Feb 22 05:12:18 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 881481065692 for ; Mon, 22 Feb 2010 05:12:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 12F138FC13 for ; Mon, 22 Feb 2010 05:12:17 +0000 (UTC) Received: (qmail 32527 invoked by uid 399); 22 Feb 2010 05:12:17 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Feb 2010 05:12:17 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B82122E.9050304@FreeBSD.org> Date: Sun, 21 Feb 2010 21:12:14 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-questions@FreeBSD.org X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Plans for BIND and DNSSEC readiness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dougb@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, 22 Feb 2010 05:12:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 I've made a post to -arch regarding my plans for BIND in the base, along with some information about getting ready for DNSSEC, including the upcoming signing of the root zone. You can find the message at http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html. If you have any feedback regarding any of these topics, please follow up to that thread. Regards, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAkuCEi4ACgkQyIakK9Wy8PtaZwCdGN6NljqTwHUxSQB3lf1T59j8 jpIAn20tJdy2h0ykeJwAQ8iWc32wUQ05 =uzZ5 -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 22 07:18:50 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94CFE106566B for ; Mon, 22 Feb 2010 07:18:50 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id 01E138FC16 for ; Mon, 22 Feb 2010 07:18:49 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NjSZ5-0002Lb-AX; Mon, 22 Feb 2010 10:18:47 +0300 Date: Mon, 22 Feb 2010 10:18:47 +0300 From: Slawa Olhovchenkov To: Pyun YongHyeon Message-ID: <20100222071847.GX55307@zxy.spb.ru> References: <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> <20100219200647.GK11675@michelle.cdnetworks.com> <20100219201359.GU55307@zxy.spb.ru> <20100219211201.GL11675@michelle.cdnetworks.com> <20100220214450.GV55307@zxy.spb.ru> <20100221234153.GA1251@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100221234153.GA1251@michelle.cdnetworks.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 07:18:50 -0000 On Sun, Feb 21, 2010 at 03:41:53PM -0800, Pyun YongHyeon wrote: > On Sun, Feb 21, 2010 at 12:44:50AM +0300, Slawa Olhovchenkov wrote: > > On Fri, Feb 19, 2010 at 01:12:01PM -0800, Pyun YongHyeon wrote: > > > > > Normally you should not have any FCS errors, it could be related > > > with signal quality and these errors might not be correctly > > > counted. > > > > I can't check cable and switch counters on bge1 before Feb 24. > > > > > > 3. packets don't lost on sources at Aug'09 > > > > > > Since I don't have BCM5704 hardware it's hard to find which > > > revision may affect to this issue. Could you narrow down which > > > revision number started showing the issue? > > > > I am don't update source between Aug'09 and Feb 16. > > > > There were many bge(4) changes in that time frame. So it's hard to > find which commit is guilty for the packet drop issue. If you can > narrow down possible changes that might affect the issue that could > help me a lot. You can do binary searching technique for the SVN > revisions to know possible candidates. > http://svn.freebsd.org/viewvc/base/head/sys/dev/bge/if_bge.c How I can do this? I don't work w/ svn before and don't know optimal way for one file. From owner-freebsd-stable@FreeBSD.ORG Mon Feb 22 09:11:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D822106566B for ; Mon, 22 Feb 2010 09:11:07 +0000 (UTC) (envelope-from perryh@pluto.rain.com) Received: from agora.rdrop.com (unknown [IPv6:2607:f678:1010::34]) by mx1.freebsd.org (Postfix) with ESMTP id 613618FC08 for ; Mon, 22 Feb 2010 09:11:07 +0000 (UTC) Received: from agora.rdrop.com (66@localhost [127.0.0.1]) by agora.rdrop.com (8.13.1/8.12.7) with ESMTP id o1M9B2tr040700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Feb 2010 01:11:02 -0800 (PST) (envelope-from perryh@pluto.rain.com) Received: (from uucp@localhost) by agora.rdrop.com (8.13.1/8.12.9/Submit) with UUCP id o1M9B2J9040699; Mon, 22 Feb 2010 01:11:02 -0800 (PST) Received: from fbsd61 by pluto.rain.com (4.1/SMI-4.1-pluto-M2060407) id AA18998; Mon, 22 Feb 10 01:06:03 PST Date: Mon, 22 Feb 2010 01:02:54 -0800 From: perryh@pluto.rain.com To: peterjeremy@acm.org Message-Id: <4b82483e.5OXNba8+J2F18v3D%perryh@pluto.rain.com> References: <20100212132947.eb2af3d0.torfinn.ingolfsen@broadpark.no> <20100212131117.GA51905@icarus.home.lan> <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100221050823.GB22670@server.vk2pj.dyndns.org> In-Reply-To: <20100221050823.GB22670@server.vk2pj.dyndns.org> User-Agent: nail 11.25 7/29/05 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 09:11:07 -0000 Peter Jeremy wrote: > ... Once ntpd decides to continuously step, something is broken. Is there some reason why, as long as it is not yet synced, ntpd should not do this sort of calculation and rate correction itself rather than insist on having a human perform the calculation and enter the adjustment? From owner-freebsd-stable@FreeBSD.ORG Mon Feb 22 10:13:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 787641065672 for ; Mon, 22 Feb 2010 10:13:30 +0000 (UTC) (envelope-from me@pollux.local.net) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id 16D4B8FC23 for ; Mon, 22 Feb 2010 10:13:28 +0000 (UTC) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 3B4974C8157 for ; Mon, 22 Feb 2010 11:13:24 +0100 (CET) Received: from pollux.local.net (che78-3-82-246-30-233.fbx.proxad.net [82.246.30.233]) by smtp4-g21.free.fr (Postfix) with ESMTP id 53A4B4C809B for ; Mon, 22 Feb 2010 11:13:22 +0100 (CET) Received: by pollux.local.net (Postfix, from userid 2000) id 1ED801CD80; Mon, 22 Feb 2010 11:13:22 +0100 (CET) Date: Mon, 22 Feb 2010 11:13:22 +0100 From: Harald To: freebsd-stable@freebsd.org Message-ID: <20100222101322.GA1641@pollux.local.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20100218152601.GA3076@pollux.local.net> <4b7e53e9.ncAxiSQAvpijczMn%perryh@pluto.rain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4b7e53e9.ncAxiSQAvpijczMn%perryh@pluto.rain.com> User-Agent: Mutt/1.4.2.3i Subject: Re: Incorrect super block X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 10:13:30 -0000 On Fri, Feb 19, 2010 at 01:03:37AM -0800, perryh@pluto.rain.com wrote: > Ivan Voras wrote: > > On 02/18/10 16:26, Harald Weis wrote: > > > Has anybody encountered the following problem ? > > > > > > Mac OS X does recognize FreeBSD partitions on USB disks, but > > > doesn't want to mount them because ``Incorrect super block''. > > > This is extremely annoying for my ``client'' because he relies > > > on dayly backups on USB keys. Is there a solution ? > > > > Are you using UFS1 or UFS2? If one, try the other :) > > This is not the first time I've heard of one OS having problems with > another OS' instantiation of UFS. For the particular application at > hand, I'd use tar(1) to collect the files into a single stream and > write the tarfile onto a USB key formatted as FAT32. OS X should > have no trouble reading a FreeBSD tarfile. Many thanks for all replies, on- and off-list. I'll do the various trials (ufs1, fat32, etc.) as soon as possible. Triggered by the off-list post, I've understood from sysutils/fusefs-ntfs/pkg-descr that ntfs doesn't preserve file ownerships and access rights. I'm afraid this is also true for fat32. If that is confirmed ntfs and fat32 are useless in combination with rsync(1), which leaves indeed only tar(1) and fat32|ntfs :-( With the permission of the author I have bounced the off-list reply. The list seems to have filtered it. So here it is: === Date: Thu, 18 Feb 2010 10:31:54 -0500 From: Lucas Holt Subject: Re: Incorrect super block To: Harald Weis Harald Weis wrote: >Has anybody encountered the following problem ? > >Mac OS X does recognize FreeBSD partitions on USB disks, but doesn't >want to mount them because ``Incorrect super block''. >This is extremely annoying for my ``client'' because he relies on dayly >backups on USB keys. Is there a solution ? > >Thank you in advance. > You could use another file system such as Fat32 or NTFS (fuse ntfs from ports). OS X can read both of those. Apple has been moving away from UFS support in OS X for awhile; snow leopard is quite stale on this front. Luke === Thanks again. I'll report a.s.a.p. the outcome of the ufs1 experiment. Harald From owner-freebsd-stable@FreeBSD.ORG Mon Feb 22 11:18:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F28F4106568B for ; Mon, 22 Feb 2010 11:18:14 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 7D18B8FC1E for ; Mon, 22 Feb 2010 11:18:14 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1MBIA9o018994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Feb 2010 22:18:11 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1MBIAfk013696; Mon, 22 Feb 2010 22:18:10 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1MBIAdv013695; Mon, 22 Feb 2010 22:18:10 +1100 (EST) (envelope-from peter) Date: Mon, 22 Feb 2010 22:18:10 +1100 From: Peter Jeremy To: perryh@pluto.rain.com Message-ID: <20100222111810.GD12891@server.vk2pj.dyndns.org> References: <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100221050823.GB22670@server.vk2pj.dyndns.org> <4b82483e.5OXNba8+J2F18v3D%perryh@pluto.rain.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KN5l+BnMqAQyZLvT" Content-Disposition: inline In-Reply-To: <4b82483e.5OXNba8+J2F18v3D%perryh@pluto.rain.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 11:18:15 -0000 --KN5l+BnMqAQyZLvT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-22 01:02:54 -0800, perryh@pluto.rain.com wrote: >Peter Jeremy wrote: > >> ... Once ntpd decides to continuously step, something is broken. > >Is there some reason why, as long as it is not yet synced, ntpd >should not do this sort of calculation and rate correction itself >rather than insist on having a human perform the calculation and >enter the adjustment? ntpd _does_ do this sort of calculation but the NTP algorithms bound the PLL adjustment to +/-500ppm. RFC1305 suggests that a reasonable tolerance for "board-mounted, uncompensated quartz- crystal oscillators" is 100ppm and therefore the +/-500ppm bound is reasonable (see the RFC for the gory maths). In this case, the op's clock was ~2500ppm slow - well outside the NTP tolerance. It was therefore necessary to change the nominal timecounter frequency to bring it into lock range. I do not believe it is reasonable for ntpd to do this by itself: - It should very rarely be needed since NTP should be able to compensate for normal tolerances. - The actual local clock source and how to alter the kernel's idea of its nominal frequency is outside the purview of NTP. - Giving ntpd free reign over the timecounter frequency runs the real risk of ntpd rendering the system unusable if ntpd becomes confused (or is mislead) about the time. Note that FreeBSD/i386 and /amd64 include 4 different possible timecounters, only 3 of which can be tweaked. Other FreeBSD architectures will have different timecounters. Other OSs may have completely different mechanisms for handling the local clock source. Trying to embed knowledge of all these different clock sources into ntpd would be unrealistic. I look after over 100 assorted Unix hosts at home and work (HP AlphaServers and Proliants, various Sun servers, Dell and whitebox PCs and various laptops) and the worst driftrates I have seen previously are: - Sun T-2000 servers have a design flaw in the clock spectrum spreading so it appears to be ~250ppm fast. Sun fixed this with a kernel patch that increases the nominal clock frequency. - A Sun V20z is just over 100ppm out - I have tweaked the relevant timecounter to compensate for this (to avoid triggering my NTP frequency error alarms). - 4 assorted Sun hosts that run 55-60ppm out. At least based on my sample, the only hosts that were anywhere near ntpd's tolerance limits were acknowledged to have a design problem and the vendor provided a fix. IMO, this is a better approach than trying to make ntpd omniscient. --=20 Peter Jeremy --KN5l+BnMqAQyZLvT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuCZ/IACgkQ/opHv/APuIcbMwCgrMm5mmxhAdIXWfJfwO95jcBP 0WIAoLCFa8rQeTcv+JHDZ6xD1FIzrzhk =dS3Y -----END PGP SIGNATURE----- --KN5l+BnMqAQyZLvT-- From owner-freebsd-stable@FreeBSD.ORG Mon Feb 22 11:41:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 358D6106568F for ; Mon, 22 Feb 2010 11:41:07 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id 1792D8FC0A for ; Mon, 22 Feb 2010 11:41:06 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta03.emeryville.ca.mail.comcast.net with comcast id kzgp1d0061Y3wxoA3zh7wN; Mon, 22 Feb 2010 11:41:07 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id kzh61d0073S48mS8bzh6cX; Mon, 22 Feb 2010 11:41:07 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8228E1E301A; Mon, 22 Feb 2010 03:41:05 -0800 (PST) Date: Mon, 22 Feb 2010 03:41:05 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100222114105.GA96234@icarus.home.lan> References: <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100221050823.GB22670@server.vk2pj.dyndns.org> <4b82483e.5OXNba8+J2F18v3D%perryh@pluto.rain.com> <20100222111810.GD12891@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100222111810.GD12891@server.vk2pj.dyndns.org> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 11:41:07 -0000 On Mon, Feb 22, 2010 at 10:18:10PM +1100, Peter Jeremy wrote: > On 2010-Feb-22 01:02:54 -0800, perryh@pluto.rain.com wrote: > >Peter Jeremy wrote: > > > >> ... Once ntpd decides to continuously step, something is broken. > > > >Is there some reason why, as long as it is not yet synced, ntpd > >should not do this sort of calculation and rate correction itself > >rather than insist on having a human perform the calculation and > >enter the adjustment? > > ntpd _does_ do this sort of calculation but the NTP algorithms > bound the PLL adjustment to +/-500ppm. RFC1305 suggests that > a reasonable tolerance for "board-mounted, uncompensated quartz- > crystal oscillators" is 100ppm and therefore the +/-500ppm bound > is reasonable (see the RFC for the gory maths). > > In this case, the op's clock was ~2500ppm slow - well outside > the NTP tolerance. It was therefore necessary to change the > nominal timecounter frequency to bring it into lock range. I > do not believe it is reasonable for ntpd to do this by itself: > - It should very rarely be needed since NTP should be able to > compensate for normal tolerances. > - The actual local clock source and how to alter the kernel's > idea of its nominal frequency is outside the purview of NTP. > - Giving ntpd free reign over the timecounter frequency runs > the real risk of ntpd rendering the system unusable if ntpd > becomes confused (or is mislead) about the time. > > Note that FreeBSD/i386 and /amd64 include 4 different possible > timecounters, only 3 of which can be tweaked. Other FreeBSD > architectures will have different timecounters. Other OSs may > have completely different mechanisms for handling the local > clock source. Trying to embed knowledge of all these different > clock sources into ntpd would be unrealistic. > > I look after over 100 assorted Unix hosts at home and work (HP > AlphaServers and Proliants, various Sun servers, Dell and whitebox PCs > and various laptops) and the worst driftrates I have seen previously > are: > - Sun T-2000 servers have a design flaw in the clock spectrum > spreading so it appears to be ~250ppm fast. Sun fixed this > with a kernel patch that increases the nominal clock frequency. > - A Sun V20z is just over 100ppm out - I have tweaked the > relevant timecounter to compensate for this (to avoid triggering > my NTP frequency error alarms). > - 4 assorted Sun hosts that run 55-60ppm out. > > At least based on my sample, the only hosts that were anywhere near > ntpd's tolerance limits were acknowledged to have a design problem > and the vendor provided a fix. IMO, this is a better approach than > trying to make ntpd omniscient. A question with regards to the latter systems you mentioned (though I'm speaking generally and not specifically with regards to those H/W models), as I want to make sure I understand correctly: ntpd under normal operation (not +/- 500ppm) "figure out" on its own the average amount of drift, which is what ntpd.drift is for, correct? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Mon Feb 22 13:40:57 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 830551065670 for ; Mon, 22 Feb 2010 13:40:57 +0000 (UTC) (envelope-from ukrzilla@gmail.com) Received: from mail-ew0-f225.google.com (mail-ew0-f225.google.com [209.85.219.225]) by mx1.freebsd.org (Postfix) with ESMTP id 12B4B8FC12 for ; Mon, 22 Feb 2010 13:40:56 +0000 (UTC) Received: by ewy25 with SMTP id 25so1745180ewy.3 for ; Mon, 22 Feb 2010 05:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aQ4d6GcJz06GbzHqkRFnQwEoNLam+PthxSIxU7UI/FU=; b=ne0FOSxI7AvexDzspTN4nwpe0WFUsfsbnnvVtOEGiKqpsDaVHs7/swIJNt1S7ZlWac Q6FUsHmIFd3aLrfYhO9Y8gAgluS+nspdoMMXG9A0lRneyqI/tU5aMYKAf1rFliZNiP+E 6BUU1ZahiKMA6mU6ey8K1b4W2csehE12sH1jo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=djj/ULcgou3pM5mxDZBQ7HjMcIaARxT8FJKspjj1Lmp1MegRu2BiUQ1F/wrJLwMKGA iSfI97S+z4NvZROER6L1vFeXRYWATJaUaXAi+SqDg5EaTd4lSX2IUGYdbL/mCn6j+uST dAgnvRN8BWPrPyNvlq//jspnbpIcVg4ECppQA= MIME-Version: 1.0 Received: by 10.216.162.142 with SMTP id y14mr2993362wek.192.1266844637686; Mon, 22 Feb 2010 05:17:17 -0800 (PST) In-Reply-To: <20100219201359.GU55307@zxy.spb.ru> References: <20100218193612.GB11675@michelle.cdnetworks.com> <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> <20100219200647.GK11675@michelle.cdnetworks.com> <20100219201359.GU55307@zxy.spb.ru> Date: Mon, 22 Feb 2010 15:17:17 +0200 Message-ID: <794030a71002220517l435f76f8pac47a6422050d509@mail.gmail.com> From: Denis Lamanov To: Slawa Olhovchenkov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Pyun YongHyeon , Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 13:40:57 -0000 I see same trouble (lost packets after 4 day uptime and reboot) :( dev.bge.0.stats.rx.FCSErrors: 18 2010/2/19 Slawa Olhovchenkov > On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote: > > > > > > dev.bge.1.stats.rx.Fragments: 1 > > > > You received a frame that is less than 64 bytes with a bad FCS. > > > > > dev.bge.1.stats.rx.UcastPkts: 2956515 > > > dev.bge.1.stats.rx.MulticastPkts: 0 > > > dev.bge.1.stats.rx.FCSErrors: 18 > > > > You have a lot of FCS errors here. > > Please double check cabling. If the statistics counter is right, > > sender is guilty or you have bad cabling issues here. > > 1. lost packets much more 18. I think hundreds, or thousands. > 2. packets lost on both (bge0 & bge1) interfaces > 3. packets don't lost on sources at Aug'09 > _______________________________________________ > 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 Feb 22 13:49:02 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F0BE10656A3 for ; Mon, 22 Feb 2010 13:49:02 +0000 (UTC) (envelope-from ukrzilla@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by mx1.freebsd.org (Postfix) with ESMTP id 28AE78FC08 for ; Mon, 22 Feb 2010 13:49:01 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 9so565937eyd.9 for ; Mon, 22 Feb 2010 05:48:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UoAhFvLSEkeqLQKnXScvbKpDZSJGN4dJif/M/neaCiA=; b=m5ggl0L33rUSsIdUnmnj5deTxB7nv1sjzfCugT1XCrlv6N3cQWF1ALoyBlZlrpRYxC JBkIUYkYckPUwxCsCRhQgNDu4HLdRYbRwl8Q5hvJxK2vu4AGGEZfILU2Z6T2U3YcJ8ta fEGGhSO4ZptVnNcK8FJRsBjO1byiwWMi2Rylc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U5TQRdCQfDkmBDWU3h7BtQueYR2+gGKAQoV79zlz0Wy8/WDHzAZMvvFLxA9NYZJryF pkH8O5fE6ExymUmnxdt2Go1a1NH6J7wggTPRB/gOGcZtyrSEBuqV2QOSVs3j6xs7iqvB 9r5qsZmf2Ej1t2biu6k7+k2Uv8CQLia1ckxoY= MIME-Version: 1.0 Received: by 10.216.180.85 with SMTP id i63mr841493wem.119.1266844787521; Mon, 22 Feb 2010 05:19:47 -0800 (PST) In-Reply-To: <20100219211201.GL11675@michelle.cdnetworks.com> References: <20100218212428.GJ55307@zxy.spb.ru> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> <20100219200647.GK11675@michelle.cdnetworks.com> <20100219201359.GU55307@zxy.spb.ru> <20100219211201.GL11675@michelle.cdnetworks.com> Date: Mon, 22 Feb 2010 15:19:47 +0200 Message-ID: <794030a71002220519x1bb79549qb894d3321ce2642d@mail.gmail.com> From: Denis Lamanov To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Nick Rogers , stable@freebsd.org, Slawa Olhovchenkov Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 13:49:02 -0000 vpn2# sysctl dev.bge.0.stats dev.bge.0.stats.FramesDroppedDueToFilters: 0 dev.bge.0.stats.DmaWriteQueueFull: 0 dev.bge.0.stats.DmaWriteHighPriQueueFull: 0 dev.bge.0.stats.NoMoreRxBDs: 0 dev.bge.0.stats.InputDiscards: 0 dev.bge.0.stats.InputErrors: 0 dev.bge.0.stats.RecvThresholdHit: 36622 dev.bge.0.stats.DmaReadQueueFull: 17 dev.bge.0.stats.DmaReadHighPriQueueFull: 0 dev.bge.0.stats.SendDataCompQueueFull: 0 dev.bge.0.stats.RingSetSendProdIndex: 116130 dev.bge.0.stats.RingStatusUpdate: 79240 dev.bge.0.stats.Interrupts: 79240 dev.bge.0.stats.AvoidedInterrupts: 0 dev.bge.0.stats.SendThresholdHit: 0 dev.bge.0.stats.rx.Octets: 132390898 dev.bge.0.stats.rx.Fragments: 0 dev.bge.0.stats.rx.UcastPkts: 117696 dev.bge.0.stats.rx.MulticastPkts: 1 dev.bge.0.stats.rx.FCSErrors: 41 dev.bge.0.stats.rx.AlignmentErrors: 0 dev.bge.0.stats.rx.xonPauseFramesReceived: 0 dev.bge.0.stats.rx.xoffPauseFramesReceived: 0 dev.bge.0.stats.rx.ControlFramesReceived: 0 dev.bge.0.stats.rx.xoffStateEntered: 0 dev.bge.0.stats.rx.FramesTooLong: 0 dev.bge.0.stats.rx.Jabbers: 0 dev.bge.0.stats.rx.UndersizePkts: 0 dev.bge.0.stats.rx.inRangeLengthError: 0 dev.bge.0.stats.rx.outRangeLengthError: 0 dev.bge.0.stats.tx.Octets: 125971311 dev.bge.0.stats.tx.Collisions: 0 dev.bge.0.stats.tx.XonSent: 0 dev.bge.0.stats.tx.XoffSent: 0 dev.bge.0.stats.tx.flowControlDone: 0 dev.bge.0.stats.tx.InternalMacTransmitErrors: 0 dev.bge.0.stats.tx.SingleCollisionFrames: 0 dev.bge.0.stats.tx.MultipleCollisionFrames: 0 dev.bge.0.stats.tx.DeferredTransmissions: 0 dev.bge.0.stats.tx.ExcessiveCollisions: 0 dev.bge.0.stats.tx.LateCollisions: 0 dev.bge.0.stats.tx.UcastPkts: 115417 dev.bge.0.stats.tx.MulticastPkts: 0 dev.bge.0.stats.tx.BroadcastPkts: 0 dev.bge.0.stats.tx.CarrierSenseErrors: 0 dev.bge.0.stats.tx.Discards: 0 dev.bge.0.stats.tx.Errors: 0 2010/2/19 Pyun YongHyeon > On Fri, Feb 19, 2010 at 11:13:59PM +0300, Slawa Olhovchenkov wrote: > > On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote: > > > > > > > > > dev.bge.1.stats.rx.Fragments: 1 > > > > > > You received a frame that is less than 64 bytes with a bad FCS. > > > > > > > dev.bge.1.stats.rx.UcastPkts: 2956515 > > > > dev.bge.1.stats.rx.MulticastPkts: 0 > > > > dev.bge.1.stats.rx.FCSErrors: 18 > > > > > > You have a lot of FCS errors here. > > > Please double check cabling. If the statistics counter is right, > > > sender is guilty or you have bad cabling issues here. > > > > 1. lost packets much more 18. I think hundreds, or thousands. > > 2. packets lost on both (bge0 & bge1) interfaces > > If you see the MAC statistics counter, you have the following > number of status updates and interrupts. Both numbers are same > which means the controller didn't lost interrupts for state > updates. > dev.bge.0.stats.RingStatusUpdate: 950302 > dev.bge.0.stats.Interrupts: 950302 > and > dev.bge.1.stats.RingStatusUpdate: 5518912 > dev.bge.1.stats.Interrupts: 5518912 > > You received 582767 unicast packets and lost 0 packet for bge0. > dev.bge.0.stats.rx.UcastPkts: 582767 > And you also received 2956515 unicast packets and lost 19 packets > for bge1. > dev.bge.1.stats.rx.Fragments: 1 > dev.bge.1.stats.rx.UcastPkts: 2956515 > dev.bge.1.stats.rx.FCSErrors: 18 > I don't see such a large number packet drops from these MAC > statistics unless upper stack drops received packets. > I fixed some counter updates which were ignored in previous > releases so you may happen to see lost counters in recent version. > > Normally you should not have any FCS errors, it could be related > with signal quality and these errors might not be correctly > counted. > > > 3. packets don't lost on sources at Aug'09 > > Since I don't have BCM5704 hardware it's hard to find which > revision may affect to this issue. Could you narrow down which > revision number started showing the issue? > _______________________________________________ > 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 Feb 22 15:40:55 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A57871065679 for ; Mon, 22 Feb 2010 15:40:55 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [194.58.105.35]) by mx1.freebsd.org (Postfix) with ESMTP id EDA3E8FC19 for ; Mon, 22 Feb 2010 15:40:54 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NjaOz-0008WM-6Q; Mon, 22 Feb 2010 18:40:53 +0300 Date: Mon, 22 Feb 2010 18:40:53 +0300 From: Slawa Olhovchenkov To: Pyun YongHyeon Message-ID: <20100222154053.GC29362@zxy.spb.ru> References: <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> <20100219200647.GK11675@michelle.cdnetworks.com> <20100219201359.GU55307@zxy.spb.ru> <20100219211201.GL11675@michelle.cdnetworks.com> <20100220214450.GV55307@zxy.spb.ru> <20100221234153.GA1251@michelle.cdnetworks.com> <20100222071847.GX55307@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100222071847.GX55307@zxy.spb.ru> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Nick Rogers , stable@freebsd.org Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 15:40:55 -0000 On Mon, Feb 22, 2010 at 10:18:47AM +0300, Slawa Olhovchenkov wrote: > On Sun, Feb 21, 2010 at 03:41:53PM -0800, Pyun YongHyeon wrote: > > > On Sun, Feb 21, 2010 at 12:44:50AM +0300, Slawa Olhovchenkov wrote: > > > On Fri, Feb 19, 2010 at 01:12:01PM -0800, Pyun YongHyeon wrote: > > > > > > > Normally you should not have any FCS errors, it could be related > > > > with signal quality and these errors might not be correctly > > > > counted. > > > > > > I can't check cable and switch counters on bge1 before Feb 24. > > > > > > > > 3. packets don't lost on sources at Aug'09 > > > > > > > > Since I don't have BCM5704 hardware it's hard to find which > > > > revision may affect to this issue. Could you narrow down which > > > > revision number started showing the issue? > > > > > > I am don't update source between Aug'09 and Feb 16. > > > > > > > There were many bge(4) changes in that time frame. So it's hard to > > find which commit is guilty for the packet drop issue. If you can > > narrow down possible changes that might affect the issue that could > > help me a lot. You can do binary searching technique for the SVN > > revisions to know possible candidates. > > http://svn.freebsd.org/viewvc/base/head/sys/dev/bge/if_bge.c > > How I can do this? > I don't work w/ svn before and don't know optimal way for one file. mail# rm sys/dev/bge/* mail# svn checkout -r 201697 svn://svn.freebsd.org/base/stable/8/sys/dev/bge/ sys/dev/bge A sys/dev/bge/if_bgereg.h A sys/dev/bge/if_bge.c Checked out revision 201697. mail# make -DNO_CLEAN -DKERNFAST buildkernel ===> bge (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MAIL -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/bge/../../dev/bge/if_bge.c ld -d -warn-common -r -d -o if_bge.ko.debug if_bge.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_bge.ko.debug export_syms | xargs -J% objcopy % if_bge.ko.debug objcopy --only-keep-debug if_bge.ko.debug if_bge.ko.symbols objcopy --strip-debug --add-gnu-debuglink=if_bge.ko.symbols if_bge.ko.debug if_bge.ko ===> mii (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/MAIL/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/MAIL -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/mii/../../dev/mii/brgphy.c ld -d -warn-common -r -d -o miibus.ko.debug acphy.o amphy.o atphy.o axphy.o bmtphy.o brgphy.o ciphy.o e1000phy.o exphy.o gentbi.o icsphy.o inphy.o ip1000phy.o jmphy.o lxtphy.o miibus_if.o mii.o mii_physubr.o mlphy.o nsgphy.o nsphy.o nsphyter.o pnaphy.o qsphy.o rgephy.o rlphy.o ruephy.o tdkphy.o tlphy.o truephy.o ukphy.o ukphy_subr.o xmphy.o echo mii_mediachg mii_phy_probe mii_phy_reset mii_pollstat mii_tick > export_syms awk -f /usr/src/sys/conf/kmod_syms.awk miibus.ko.debug export_syms | xargs -J% objcopy % miibus.ko.debug objcopy --only-keep-debug miibus.ko.debug miibus.ko.symbols objcopy --strip-debug --add-gnu-debuglink=miibus.ko.symbols miibus.ko.debug miibus.ko From owner-freebsd-stable@FreeBSD.ORG Mon Feb 22 18:15:48 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 353E3106566C for ; Mon, 22 Feb 2010 18:15:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f189.google.com (mail-pz0-f189.google.com [209.85.222.189]) by mx1.freebsd.org (Postfix) with ESMTP id F089B8FC0C for ; Mon, 22 Feb 2010 18:15:47 +0000 (UTC) Received: by pzk27 with SMTP id 27so173876pzk.27 for ; Mon, 22 Feb 2010 10:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=LhX3mt1dAmA85psJUWLHa+Ozx/4CwXppjMLh4Yy2MM8=; b=xnrjVr1VW1DftYlEcC83OhXS/PSjx1LKgdFAvXMz6sqe1PoKLwUZVI4acjjO9ZphVk zggUh80FASbuUje81gulrkBODoYKLwERy4GUUxvJBrchhwLPD7PlWLwoYvoR8t18ktEJ /E3hgllsc1lXgoeyp/fGKzRj/JCcw2JAoboMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=aBKE7sF6bEnBwKQ4cU+22WhMnXs9aDvg/gplyant8089a8a1EJjMqqKT2/u3ZZutei nBRF2DHnsGp5utVl+UKoa8NhR+joRSXhyjWxj5oqIIJUncfEIxXm5qvyO/ZRAkq49i2F K64irS7AyHObA+lXMfF2ELLMqJ6KDo/qXWlfI= Received: by 10.143.153.24 with SMTP id f24mr739737wfo.307.1266862543302; Mon, 22 Feb 2010 10:15:43 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm161349pzk.7.2010.02.22.10.15.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 22 Feb 2010 10:15:42 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 22 Feb 2010 10:15:05 -0800 From: Pyun YongHyeon Date: Mon, 22 Feb 2010 10:15:05 -0800 To: Denis Lamanov Message-ID: <20100222181505.GF1251@michelle.cdnetworks.com> References: <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> <20100219200647.GK11675@michelle.cdnetworks.com> <20100219201359.GU55307@zxy.spb.ru> <794030a71002220517l435f76f8pac47a6422050d509@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <794030a71002220517l435f76f8pac47a6422050d509@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: Nick Rogers , stable@freebsd.org, Slawa Olhovchenkov Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 18:15:48 -0000 On Mon, Feb 22, 2010 at 03:17:17PM +0200, Denis Lamanov wrote: > I see same trouble (lost packets after 4 day uptime and reboot) :( > > dev.bge.0.stats.rx.FCSErrors: 18 > You also have PCIX BCM5704 controller? What FreeBSD version do you use? > 2010/2/19 Slawa Olhovchenkov > > > On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote: > > > > > > > > > dev.bge.1.stats.rx.Fragments: 1 > > > > > > You received a frame that is less than 64 bytes with a bad FCS. > > > > > > > dev.bge.1.stats.rx.UcastPkts: 2956515 > > > > dev.bge.1.stats.rx.MulticastPkts: 0 > > > > dev.bge.1.stats.rx.FCSErrors: 18 > > > > > > You have a lot of FCS errors here. > > > Please double check cabling. If the statistics counter is right, > > > sender is guilty or you have bad cabling issues here. > > > > 1. lost packets much more 18. I think hundreds, or thousands. > > 2. packets lost on both (bge0 & bge1) interfaces > > 3. packets don't lost on sources at Aug'09 > > _______________________________________________ > > 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 Feb 22 18:19:38 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82161106566B for ; Mon, 22 Feb 2010 18:19:38 +0000 (UTC) (envelope-from ukrzilla@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id 0E66C8FC15 for ; Mon, 22 Feb 2010 18:19:37 +0000 (UTC) Received: by ewy3 with SMTP id 3so2690660ewy.13 for ; Mon, 22 Feb 2010 10:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OMRCXWmklX5WSESOq98LtRis1c1jJI8qSo5xvwPgtpo=; b=lUzpCjRauhWktXZ2wucw69czCev/Lr+MMtVYP5kTVVrbQap56B1K23vHYh8vxzBrz3 PXQUtGyAqrHVHW7hIJeR6FtjbcLqILqwRu3fWqZt2DPgn2matsp9kHxyviDg/2WsmMwT oVU3PovbbTGquVZLCiGYC7bcqCL+SS3Uxp6/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DGq2j3iKVn7WkqPf8hQVDe/TYabPmCHSC3xjNoV7Six4QNmcMjHFvLymWPjWSKmgB+ RYNQFUWl1Ab30t7DStUv7JVSGMUeMBLsH/sLYwaSozkek5nBu2D0NZrIEh1zXY2nwD1Z hR8sqiPGVOxafWgxZBHMasA8oZBekQIVSa+Wg= MIME-Version: 1.0 Received: by 10.216.162.142 with SMTP id y14mr3243447wek.192.1266862772644; Mon, 22 Feb 2010 10:19:32 -0800 (PST) In-Reply-To: <20100222181505.GF1251@michelle.cdnetworks.com> References: <20100218213213.GD11675@michelle.cdnetworks.com> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> <20100219200647.GK11675@michelle.cdnetworks.com> <20100219201359.GU55307@zxy.spb.ru> <794030a71002220517l435f76f8pac47a6422050d509@mail.gmail.com> <20100222181505.GF1251@michelle.cdnetworks.com> Date: Mon, 22 Feb 2010 20:19:32 +0200 Message-ID: <794030a71002221019mdd2eb76xada55ce04bf3593c@mail.gmail.com> From: Denis Lamanov To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Nick Rogers , stable@freebsd.org, Slawa Olhovchenkov Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 18:19:38 -0000 Yes, PCIX BCM5704 FreeBSD vpn2 8.0-STABLE FreeBSD 8.0-STABLE #1 r204028: Thu Feb 18 08:29:42 EET 2010 admin@vpn2:/usr/obj/usr/src/sys/GENERIC i386 2010/2/22 Pyun YongHyeon > On Mon, Feb 22, 2010 at 03:17:17PM +0200, Denis Lamanov wrote: > > I see same trouble (lost packets after 4 day uptime and reboot) :( > > > > dev.bge.0.stats.rx.FCSErrors: 18 > > > > You also have PCIX BCM5704 controller? What FreeBSD version do you > use? > > > 2010/2/19 Slawa Olhovchenkov > > > > > On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote: > > > > > > > > > > > > dev.bge.1.stats.rx.Fragments: 1 > > > > > > > > You received a frame that is less than 64 bytes with a bad FCS. > > > > > > > > > dev.bge.1.stats.rx.UcastPkts: 2956515 > > > > > dev.bge.1.stats.rx.MulticastPkts: 0 > > > > > dev.bge.1.stats.rx.FCSErrors: 18 > > > > > > > > You have a lot of FCS errors here. > > > > Please double check cabling. If the statistics counter is right, > > > > sender is guilty or you have bad cabling issues here. > > > > > > 1. lost packets much more 18. I think hundreds, or thousands. > > > 2. packets lost on both (bge0 & bge1) interfaces > > > 3. packets don't lost on sources at Aug'09 > > > _______________________________________________ > > > 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 Feb 22 19:36:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36EAF10656A7; Mon, 22 Feb 2010 19:36:16 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 05A168FC1A; Mon, 22 Feb 2010 19:36:16 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 9280F46B2D; Mon, 22 Feb 2010 14:36:15 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2F35E8A01F; Mon, 22 Feb 2010 14:36:03 -0500 (EST) From: John Baldwin To: Attilio Rao Date: Mon, 22 Feb 2010 12:02:29 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20100120; KDE/4.3.1; amd64; ; ) References: <179b97fb1001270941m2d8e9c8au20abc798c16b9c11@mail.gmail.com> <3bbf2fe11002201419v52b249ccg8d82c8ae747cf318@mail.gmail.com> In-Reply-To: <3bbf2fe11002201419v52b249ccg8d82c8ae747cf318@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002221202.29747.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 22 Feb 2010 14:36:03 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.3 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Brandon Gooch , freebsd-fs@freebsd.org, freebsd-emulation@freebsd.org, stable-list freebsd Subject: Re: ZFS and sh(1) panic: spin lock [lock addr] (smp rendezvous) held by [sh(1) proc tid] too long X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 19:36:16 -0000 On Saturday 20 February 2010 5:19:39 pm Attilio Rao wrote: > 2010/1/27 Brandon Gooch : > > The machine, a Dell Optiplex 755, has been locking up recently. The > > situation usually occurs while using VirtualBox (running a 64-bit > > Windows 7 instance) and doing anything else in another xterm (such as > > rebuilding a port). I've been unable to reliably reproduce it (I'm in > > an X session and the machine will not panic "properly"). > > > > However, while rebuilding Xorg today at ttyv0 and runnning > > VBoxHeadless on ttyv1, I managed to trigger what I believe is the > > lockup. > > > > I've attached a textdump in hopes that someone may be able to take a > > look and provide clues or instruction on debugging this. > > I think that jhb@ saw a similar problem while working on nVidia driver > or the like. > Not sure if he made any progress to debug this. That was due to a weird bug where I was accidentally zero'ing the local APIC due to a then-bug in sg_pager.c (it was forcing the VM system to clear the pages it mapped by accident). That should not be the explanation for this. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Mon Feb 22 23:14:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C0FC106566C for ; Mon, 22 Feb 2010 23:14:11 +0000 (UTC) (envelope-from boheme@gmail.com) Received: from mail-qy0-f173.google.com (mail-qy0-f173.google.com [209.85.221.173]) by mx1.freebsd.org (Postfix) with ESMTP id 2A9EA8FC08 for ; Mon, 22 Feb 2010 23:14:10 +0000 (UTC) Received: by qyk4 with SMTP id 4so2129178qyk.8 for ; Mon, 22 Feb 2010 15:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=PQQM8GqlfjmhH66wD+tE8nOuMHznRCi2q9e8b1osLrw=; b=L7HYSs6WNkAyFiQJYHjGcDy1YmKd3slXjjv2/HiYYaMmUh1X3ox3/sXziyUA1ZT4i5 asgPQzGzARQliK+wwwKrDczUhZ9VvUwT55Y2QOLNM7s8nI9PAA15Vc7b/Uq4DKNzD17W /fv+cH6l6F1NfCkJfhbzM4eVCKUyyT/5Mdisg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=CDLBL+iTumtc+UeifZaFMGljCal/dPr/Rqx4LLm1RgKcai6Ik57Lr6qZ3iHwnjsLTy 501nZU6CyPWzXDXC2nd6NH2t0ZWsVNxrEbRTeYqwHDRbP8+vHv85Oyy4B9UlDl5+jChr ptamyXz1xL3scZQFlmNGSPcgqNp6bYUgMysU8= MIME-Version: 1.0 Received: by 10.224.86.129 with SMTP id s1mr6391099qal.197.1266879119515; Mon, 22 Feb 2010 14:51:59 -0800 (PST) In-Reply-To: <20100218152601.GA3076@pollux.local.net> References: <20100218152601.GA3076@pollux.local.net> Date: Mon, 22 Feb 2010 14:51:59 -0800 Message-ID: From: Chris Knight To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: Incorrect super block X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2010 23:14:11 -0000 This problem is caused by a big-endian, little-endian difference between the OSX implementation of UFS and the FreeBSD implementation. http://forums.macosxhints.com/showthread.php?t=86385 I solved this problem for myself by installing MacFuse -Chris On Thu, Feb 18, 2010 at 7:26 AM, Harald Weis wrote: > Has anybody encountered the following problem ? > > Mac OS X does recognize FreeBSD partitions on USB disks, but doesn't > want to mount them because ``Incorrect super block''. > This is extremely annoying for my ``client'' because he relies on dayly > backups on USB keys. Is there a solution ? > > Thank you in advance. > -- > Harald Weis > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 01:16:21 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8DAE1065697; Tue, 23 Feb 2010 01:16:21 +0000 (UTC) (envelope-from root@ips.gov.au) Received: from gatekeeper.ips.gov.au (ns.ips.gov.au [138.24.1.34]) by mx1.freebsd.org (Postfix) with SMTP id 843BF8FC1C; Tue, 23 Feb 2010 01:16:20 +0000 (UTC) Received: from gpo.dmz.ips.gov.au (gpo.dmz.ips.gov.au [138.24.8.4]) by gatekeeper.ips.gov.au (Postfix) with ESMTP id 3609D22864; Tue, 23 Feb 2010 12:01:06 +1100 (EST) Received: from localhost (localhost.dmz.ips.gov.au [127.0.0.1]) by gpo.dmz.ips.gov.au (Postfix) with ESMTP id 2F6D47E87F; Tue, 23 Feb 2010 12:01:06 +1100 (EST) X-Virus-Scanned: amavisd-new at ips.gov.au Received: from gpo.dmz.ips.gov.au ([127.0.0.1]) by localhost (gpo.dmz.ips.gov.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+l99QSMqBMk; Tue, 23 Feb 2010 12:01:05 +1100 (EST) Received: by gpo.dmz.ips.gov.au (Postfix, from userid 0) id F2EDF7E8CD; Tue, 23 Feb 2010 12:00:31 +1100 (EST) X-Original-To: "colin@ips.gov.au"@bcc.invalid Delivered-To: "colin@ips.gov.au"@bcc.invalid Received: from localhost (localhost.dmz.ips.gov.au [127.0.0.1]) by gpo.dmz.ips.gov.au (Postfix) with ESMTP id 81D037E85D; Mon, 22 Feb 2010 16:14:32 +1100 (EST) X-Virus-Scanned: amavisd-new at ips.gov.au Received: from gpo.dmz.ips.gov.au ([127.0.0.1]) by localhost (gpo.dmz.ips.gov.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5A4S8Nkb5td; Mon, 22 Feb 2010 16:14:30 +1100 (EST) Received: from gatekeeper.ips.gov.au (gatekeeper.dmz.ips.gov.au [138.24.8.1]) by gpo.dmz.ips.gov.au (Postfix) with ESMTP id 127F57E85C for ; Mon, 22 Feb 2010 16:14:30 +1100 (EST) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by gatekeeper.ips.gov.au (Postfix) with SMTP id AADD92283E for ; Mon, 22 Feb 2010 16:14:28 +1100 (EST) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C50211586B8; Mon, 22 Feb 2010 05:12:36 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6A6CD106581D; Mon, 22 Feb 2010 05:12:33 +0000 (UTC) (envelope-from owner-freebsd-questions@freebsd.org) Delivered-To: freebsd-questions@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EA2E106568F for ; Mon, 22 Feb 2010 05:12:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1059E8FC12 for ; Mon, 22 Feb 2010 05:12:17 +0000 (UTC) Received: (qmail 32527 invoked by uid 399); 22 Feb 2010 05:12:17 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Feb 2010 05:12:17 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B82122E.9050304@FreeBSD.org> Date: Sun, 21 Feb 2010 21:12:14 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-questions@FreeBSD.org X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-questions@freebsd.org Errors-To: owner-freebsd-questions@freebsd.org Cc: Subject: Plans for BIND and DNSSEC readiness X-BeenThere: freebsd-stable@freebsd.org Reply-To: dougb@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 01:16:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 I've made a post to -arch regarding my plans for BIND in the base, along with some information about getting ready for DNSSEC, including the upcoming signing of the root zone. You can find the message at http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html. If you have any feedback regarding any of these topics, please follow up to that thread. Regards, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAkuCEi4ACgkQyIakK9Wy8PtaZwCdGN6NljqTwHUxSQB3lf1T59j8 jpIAn20tJdy2h0ykeJwAQ8iWc32wUQ05 =uzZ5 -----END PGP SIGNATURE----- _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 01:16:28 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F2151065695; Tue, 23 Feb 2010 01:16:28 +0000 (UTC) (envelope-from root@ips.gov.au) Received: from gatekeeper.ips.gov.au (ns.ips.gov.au [138.24.1.34]) by mx1.freebsd.org (Postfix) with SMTP id 2B9EF8FC0A; Tue, 23 Feb 2010 01:16:26 +0000 (UTC) Received: from gpo.dmz.ips.gov.au (gpo.dmz.ips.gov.au [138.24.8.4]) by gatekeeper.ips.gov.au (Postfix) with ESMTP id C71EB2283F; Tue, 23 Feb 2010 11:58:00 +1100 (EST) Received: from localhost (localhost.dmz.ips.gov.au [127.0.0.1]) by gpo.dmz.ips.gov.au (Postfix) with ESMTP id BDF877E861; Tue, 23 Feb 2010 11:58:00 +1100 (EST) X-Virus-Scanned: amavisd-new at ips.gov.au Received: from gpo.dmz.ips.gov.au ([127.0.0.1]) by localhost (gpo.dmz.ips.gov.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yq+I-bj7XXEk; Tue, 23 Feb 2010 11:57:58 +1100 (EST) Received: by gpo.dmz.ips.gov.au (Postfix, from userid 0) id 0B8F87E87D; Tue, 23 Feb 2010 11:57:55 +1100 (EST) X-Original-To: "colin@ips.gov.au"@bcc.invalid Delivered-To: "colin@ips.gov.au"@bcc.invalid Received: from localhost (localhost.dmz.ips.gov.au [127.0.0.1]) by gpo.dmz.ips.gov.au (Postfix) with ESMTP id 81D037E85D; Mon, 22 Feb 2010 16:14:32 +1100 (EST) X-Virus-Scanned: amavisd-new at ips.gov.au Received: from gpo.dmz.ips.gov.au ([127.0.0.1]) by localhost (gpo.dmz.ips.gov.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5A4S8Nkb5td; Mon, 22 Feb 2010 16:14:30 +1100 (EST) Received: from gatekeeper.ips.gov.au (gatekeeper.dmz.ips.gov.au [138.24.8.1]) by gpo.dmz.ips.gov.au (Postfix) with ESMTP id 127F57E85C for ; Mon, 22 Feb 2010 16:14:30 +1100 (EST) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by gatekeeper.ips.gov.au (Postfix) with SMTP id AADD92283E for ; Mon, 22 Feb 2010 16:14:28 +1100 (EST) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C50211586B8; Mon, 22 Feb 2010 05:12:36 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 6A6CD106581D; Mon, 22 Feb 2010 05:12:33 +0000 (UTC) (envelope-from owner-freebsd-questions@freebsd.org) Delivered-To: freebsd-questions@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EA2E106568F for ; Mon, 22 Feb 2010 05:12:18 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1059E8FC12 for ; Mon, 22 Feb 2010 05:12:17 +0000 (UTC) Received: (qmail 32527 invoked by uid 399); 22 Feb 2010 05:12:17 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Feb 2010 05:12:17 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B82122E.9050304@FreeBSD.org> Date: Sun, 21 Feb 2010 21:12:14 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-questions@FreeBSD.org X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-questions@freebsd.org Errors-To: owner-freebsd-questions@freebsd.org Cc: Subject: Plans for BIND and DNSSEC readiness X-BeenThere: freebsd-stable@freebsd.org Reply-To: dougb@FreeBSD.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 01:16:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 I've made a post to -arch regarding my plans for BIND in the base, along with some information about getting ready for DNSSEC, including the upcoming signing of the root zone. You can find the message at http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html. If you have any feedback regarding any of these topics, please follow up to that thread. Regards, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAkuCEi4ACgkQyIakK9Wy8PtaZwCdGN6NljqTwHUxSQB3lf1T59j8 jpIAn20tJdy2h0ykeJwAQ8iWc32wUQ05 =uzZ5 -----END PGP SIGNATURE----- _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 01:35:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9258106566C for ; Tue, 23 Feb 2010 01:35:28 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 819928FC0A for ; Tue, 23 Feb 2010 01:35:28 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.4/8.14.4) with ESMTP id o1N1ZMJZ020186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 23 Feb 2010 12:35:23 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1266888923; bh=o0z5T8U+sqEtLu6PFtj2NSoMXP86QfuZU1alkTNDBrM=; h=Date:From:To:Subject:Message-ID:Mime-Version:Content-Type; b=sIhC8Vp0zXMYypH0dLVy1ufcJoTzkPbWoD4weUbF2tnM0vhypyp3PwZgepjncOpsm 4z269bXoVoGJTC1qa4z7AYj68fQ2MLQjhMMRFccbBXOp7YJz1vBnxMXnNOXQG24uNS cEJP3LLEaH6lG/PNFkDj7eltmdEguNsidUkJCu9w= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id o1N1ZMVI008119 for ; Tue, 23 Feb 2010 12:35:22 +1100 (AEDT) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id o1N1ZMiB008118 for freebsd-stable@freebsd.org; Tue, 23 Feb 2010 12:35:22 +1100 (AEDT) (envelope-from john) Date: Tue, 23 Feb 2010 12:35:22 +1100 From: John Marshall To: freebsd-stable@freebsd.org Message-ID: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: sleep(3) sometimes too sleepy on FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 01:35:29 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Environment: sendmail 8.14.4 on FreeBSD 8.0-RELEASE-p2 Since upgrading a few local servers to FreeBSD 8.0-RELEASE (and subsequently 8.0-RELEASE-p2), I have been seeing VERY intermittent problems with sendmail persistent queue runners. One or more queue runners will fail to wake up (having been told to sleep for either 1 or 5 seconds) and mail accumulates in their queue group queues. I have only seen this about 4 times but at least once on each of the three 8.0 servers. I've been seeing something like one occurrence per fortnight overall. The first few times I re-started sendmail. On Saturday I spent longer looking at it. - attached to each of the stuck queue runner processes via gdb to try to see where they were stuck - backtraces from both process were identical and looked sane - attached to a happy queue runner process and got an identical backtrace - exited gdb and discovered that the stuck queue runners had woken up and flushed their queues! The stuck queue runner processes had been stuck for several hours (judging by the timestamps on the queued mail messages) but the gdb attach apparently woke them up! PROCESS STATES BEFORE DEBUG (stuck runners are in 'I' state) PID TT STAT TIME COMMAND 80298 ?? Ss 0:17.68 sendmail: accepting connections (sendmail) 80299 ?? I 0:46.62 sendmail: running queue: /var/spool/mqueue/qd1/df= (sendmail) 80300 ?? I 0:08.83 sendmail: running queue: /var/spool/mqueue/mby/df= (sendmail) 80301 ?? S 0:31.58 sendmail: running queue: /var/spool/mqueue/oz/df = (sendmail) 80302 ?? S 0:30.71 sendmail: running queue: /var/spool/mqueue/rw2/df= (sendmail) 80303 ?? S 0:33.29 sendmail: running queue: /var/spool/mqueue/hold/d= f (sendmail) 80304 ?? S 0:30.55 sendmail: running queue: /var/spool/mqueue/pgp/df= (sendmail) BACKTRACE OF STUCK PROCESS 80299 (gdb) bt #0 0x28346547 in sigsuspend () from /lib/libc.so.7 #1 0x28344e98 in sigpause () from /lib/libc.so.7 #2 0x2833be3e in pause () from /lib/libc.so.7 #3 0x080cc7c8 in sleep () #4 0x08099c51 in run_work_group () #5 0x08099ebf in runqueue () #6 0x0805538d in main () BACKTRACE OF HAPPY PROCESS 80301 (gdb) bt #0 0x28346547 in sigsuspend () from /lib/libc.so.7 #1 0x28344e98 in sigpause () from /lib/libc.so.7 #2 0x2833be3e in pause () from /lib/libc.so.7 #3 0x080cc7c8 in sleep () #4 0x08099c51 in run_work_group () #5 0x08099ebf in runqueue () #6 0x0805538d in main () PROCESS STATES AFTER DEBUG PID TT STAT TIME COMMAND 80298 ?? Ss 0:17.69 sendmail: accepting connections (sendmail) 80299 ?? S 0:46.66 sendmail: running queue: /var/spool/mqueue/qd1/df= (sendmail) 80300 ?? S 0:08.85 sendmail: running queue: /var/spool/mqueue/mby/df= (sendmail) 80301 ?? S 0:31.60 sendmail: running queue: /var/spool/mqueue/oz/df = (sendmail) 80302 ?? S 0:30.73 sendmail: running queue: /var/spool/mqueue/rw2/df= (sendmail) 80303 ?? S 0:33.32 sendmail: running queue: /var/spool/mqueue/hold/d= f (sendmail) 80304 ?? S 0:30.58 sendmail: running queue: /var/spool/mqueue/pgp/df= (sendmail) SENDMAIL DETAILS Version 8.14.4 Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF STARTTLS USERDB XDEBUG /usr/sbin/sendmail: libsasl2.so.2 =3D> /usr/local/lib/libsasl2.so.2 (0x28154000) libssl.so.7 =3D> /usr/local/lib/libssl.so.7 (0x2816a000) libcrypto.so.7 =3D> /usr/local/lib/libcrypto.so.7 (0x281ad000) libutil.so.8 =3D> /lib/libutil.so.8 (0x282f2000) libc.so.7 =3D> /lib/libc.so.7 (0x28300000) libz.so.5 =3D> /lib/libz.so.5 (0x2840c000) I posted about this in comp.mail.sendmail and was told... > sleep() should be one of these calls: >=20 > if (njobs =3D=3D 0 && WorkGrp[wgrp].wg_lowqintvl < MIN_SLEEP_TIME) > sleep(MIN_SLEEP_TIME); > else if (WorkGrp[wgrp].wg_lowqintvl <=3D 0) > sleep(QueueIntvl > 0 ? QueueIntvl : MIN_SLEEP_TIME); > else > sleep(WorkGrp[wgrp].wg_lowqintvl); >=20 > Unless you have a really large value for one of these, the process > should continue after a while. The above code snippet is from sendmail/queue.c which fixes MIN_SLEEP_TIME at 5. QueueIntvl defaults to 1. wg_lowqintvl defaults to 0. I have not set any configuration or runtime options to override these defaults, so my persistent queue runners should be sleeping for either 1s or 5s only (not hours!). --=20 John Marshall --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuDMNoACgkQw/tAaKKahKIFTACgohNDxeGmLeaHydAUp56bE4mY vDgAn2a5UxA0It3kCLdq8VtH09/6ZqjF =SZw7 -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 04:53:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63A401065676 for ; Tue, 23 Feb 2010 04:53:40 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail14.syd.optusnet.com.au (mail14.syd.optusnet.com.au [211.29.132.195]) by mx1.freebsd.org (Postfix) with ESMTP id DF6768FC14 for ; Tue, 23 Feb 2010 04:53:39 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail14.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1N4rSjp006183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 15:53:29 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1N4rQvc043066; Tue, 23 Feb 2010 15:53:26 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1N4rQom043065; Tue, 23 Feb 2010 15:53:26 +1100 (EST) (envelope-from peter) Date: Tue, 23 Feb 2010 15:53:26 +1100 From: Peter Jeremy To: David Magda Message-ID: <20100223045326.GA40307@server.vk2pj.dyndns.org> References: <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100221050823.GB22670@server.vk2pj.dyndns.org> <20100221173619.2470aa85.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD Stable Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 04:53:40 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-21 14:29:28 -0500, David Magda wrote: >For future reference, how does the math work? How do you go from =20 >taking a timer number: > > $ sysctl machdep.acpi_timer_freq > machdep.acpi_timer_freq: 3577045 > >And the ntpd(8) time reset log entries to adjust the frequency? Or do =20 >you use the PPM output of the ntpdc(8) command? > >I'm not quite sure I understand what happened here. :) I'm using a combination of the ACPI frequency, time reset logs and PLL frequency reported by the op: On 2010-Feb-20 22:32:01 +0100, Torfinn Ingolfsen wrote: >root@kg-f2# sysctl machdep.acpi_timer_freq >machdep.acpi_timer_freq: 3577045 >root@kg-f2# tvlm >Feb 20 20:06:41 kg-f2 ntpd[942]: kernel time sync status change 2001 >Feb 20 20:21:49 kg-f2 ntpd[942]: time reset +1.118880 s >Feb 20 20:37:53 kg-f2 ntpd[942]: time reset +1.188538 s >Feb 20 20:53:03 kg-f2 ntpd[942]: time reset +1.121903 s >Feb 20 21:09:00 kg-f2 ntpd[942]: time reset +1.179924 s >Feb 20 21:24:57 kg-f2 ntpd[942]: time reset +1.178490 s >Feb 20 21:39:58 kg-f2 ntpd[942]: time reset +1.110647 s >Feb 20 21:55:53 kg-f2 ntpd[942]: time reset +1.177292 s >Feb 20 22:11:44 kg-f2 ntpd[942]: time reset +1.172358 s >Feb 20 22:26:48 kg-f2 ntpd[942]: time reset +1.114350 s =2E.. >root@kg-f2# ntpdc -c loopi -c sysi >offset: 0.000000 s >frequency: 500.000 ppm Together with the assumptions that the system clock is stable (ie the rate of drift is constant) and the syslog entries occurred at precisely the times reported. If the former assumption isn't true (which was a distinct possibility given the size of error) then ntpd isn't going to work. If he latter assumption is incorrect then the calculated clock skew will be incorrect - but hopefully enough to bring it into ntpd capture range to allow later tweaking. If ntpd cannot slew the local clock sufficiently, it will step the clock roughly every 900 seconds, hence the regular "time reset" messages. Since we are assuming a stable clock, we can accumulate the offsets in multiple reset messages to give a cumulative offset. For the above figures, the clock drift (sum of "time reset" messages) totals ~10.36 seconds over a period of 2:20:07 (the difference between the "kernel time sync" and last "time reset" message). [Note that I somehow mistranscribed both the offset and duration in my last mail - apologies for the confusion this might have caused]. 10.36s in 2:20:07 =3D=3D 10.36/8407 ~=3D 1.233e-3 or 1233ppm. Thus ntpd is reporting that the system clock is still 1233ppm slow, even with ntpd pulling the system clock by its maximum of 500ppm. Adding these gives a total clock error of 1733ppm. The nominal clock frequency used by the timecounter is 3577045Hz. In order to calculate the actual clock frequency, we need to subtract the clock error (1733ppm) from this frequency: 3577045Hz * (1 - 1733e-6) =3D 3570846Hz (I rounded the clock error differently previously and got 3570847Hz). --=20 Peter Jeremy --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuDX0YACgkQ/opHv/APuIerNACfd+IeQWVrQv9uLrVCjFGItV6H RU8Amwc2v1gTylP+0CcoZs5GxTeymSCM =0cN3 -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 08:06:30 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02F9F1065693 for ; Tue, 23 Feb 2010 08:06:30 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by mx1.freebsd.org (Postfix) with ESMTP id DC5FE8FC17 for ; Tue, 23 Feb 2010 08:06:29 +0000 (UTC) Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta05.emeryville.ca.mail.comcast.net with comcast id lL6V1d0021GXsucA5L6WNM; Tue, 23 Feb 2010 08:06:30 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta07.emeryville.ca.mail.comcast.net with comcast id lL6V1d00U3S48mS8TL6VK6; Tue, 23 Feb 2010 08:06:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5B5D41E301A; Tue, 23 Feb 2010 00:06:28 -0800 (PST) Date: Tue, 23 Feb 2010 00:06:28 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100223080628.GA22397@icarus.home.lan> References: <4B6228EF.5050400@laposte.net> <201001290802.o0T829sd050043@lurza.secnetix.de> <20100129090357.GA38872@icarus.home.lan> <4B71F0A3.6020401@laposte.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B71F0A3.6020401@laposte.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-standards@freebsd.org Subject: Re: su password prompt to stdout instead of /dev/tty X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 08:06:30 -0000 On Wed, Feb 10, 2010 at 12:32:51AM +0100, Cyrille Lefevre wrote: > Jeremy Chadwick a crit : > > > >OpenPAM is des@'s responsibility. Has anyone brought this up to him? > > still no answer from des@ ! any idea ? I don't know what's going on. He's around/active[1], but this must not be high on his priority list. [1]: http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009906.html -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 09:19:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA986106568B for ; Tue, 23 Feb 2010 09:19:55 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail12.syd.optusnet.com.au (mail12.syd.optusnet.com.au [211.29.132.193]) by mx1.freebsd.org (Postfix) with ESMTP id 35E458FC13 for ; Tue, 23 Feb 2010 09:19:54 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail12.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1N9Jqp6017066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 20:19:53 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1N9Jmi7061163; Tue, 23 Feb 2010 20:19:48 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1N9Jlml061162; Tue, 23 Feb 2010 20:19:47 +1100 (EST) (envelope-from peter) Date: Tue, 23 Feb 2010 20:19:47 +1100 From: Peter Jeremy To: Jeremy Chadwick Message-ID: <20100223091947.GA44123@server.vk2pj.dyndns.org> References: <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100221050823.GB22670@server.vk2pj.dyndns.org> <4b82483e.5OXNba8+J2F18v3D%perryh@pluto.rain.com> <20100222111810.GD12891@server.vk2pj.dyndns.org> <20100222114105.GA96234@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <20100222114105.GA96234@icarus.home.lan> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 09:19:55 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Feb-22 03:41:05 -0800, Jeremy Chadwick w= rote: >ntpd under normal operation (not +/- 500ppm) "figure out" on its own the >average amount of drift, which is what ntpd.drift is for, correct? Yes. It takes a long time for ntpd to characterise the local system clock. Once it does so, it stores the calculated drift in ntp.drift and updates it every hour or so. This means that when ntpd is restarted, it can immediately set its PLL to a reasonably close value, rather than starting from scratch. --=20 Peter Jeremy --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuDnbMACgkQ/opHv/APuIfE5wCePr4FejMFiw4RDV4Wii3xWqtI sFsAnRInukSAgdJXdHtKnaKn13dmsltk =nPGv -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 09:36:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B0761065679 for ; Tue, 23 Feb 2010 09:36:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id A94258FC0A for ; Tue, 23 Feb 2010 09:36:21 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o1N9aGC1043775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Feb 2010 11:36:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o1N9aGVh050589 for ; Tue, 23 Feb 2010 11:36:16 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o1N9aG3t050588 for freebsd-stable@freebsd.org; Tue, 23 Feb 2010 11:36:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 23 Feb 2010 11:36:16 +0200 From: Kostik Belousov To: freebsd-stable@freebsd.org Message-ID: <20100223093616.GO50403@deviant.kiev.zoral.com.ua> References: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5KObZtj3Gjpm0OUY" Content-Disposition: inline In-Reply-To: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Subject: Re: sleep(3) sometimes too sleepy on FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 09:36:23 -0000 --5KObZtj3Gjpm0OUY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 23, 2010 at 12:35:22PM +1100, John Marshall wrote: > Environment: sendmail 8.14.4 on FreeBSD 8.0-RELEASE-p2 >=20 > Since upgrading a few local servers to FreeBSD 8.0-RELEASE (and > subsequently 8.0-RELEASE-p2), I have been seeing VERY intermittent > problems with sendmail persistent queue runners. One or more queue > runners will fail to wake up (having been told to sleep for either 1 or > 5 seconds) and mail accumulates in their queue group queues. >=20 > I have only seen this about 4 times but at least once on each of the > three 8.0 servers. I've been seeing something like one occurrence per > fortnight overall. The first few times I re-started sendmail. On > Saturday I spent longer looking at it. >=20 > - attached to each of the stuck queue runner processes via gdb to > try to see where they were stuck > - backtraces from both process were identical and looked sane > - attached to a happy queue runner process and got an identical > backtrace > - exited gdb and discovered that the stuck queue runners had woken > up and flushed their queues! >=20 > The stuck queue runner processes had been stuck for several hours > (judging by the timestamps on the queued mail messages) but the gdb > attach apparently woke them up! >=20 > PROCESS STATES BEFORE DEBUG (stuck runners are in 'I' state) >=20 > PID TT STAT TIME COMMAND > 80298 ?? Ss 0:17.68 sendmail: accepting connections (sendmail) > 80299 ?? I 0:46.62 sendmail: running queue: /var/spool/mqueue/qd1/= df (sendmail) > 80300 ?? I 0:08.83 sendmail: running queue: /var/spool/mqueue/mby/= df (sendmail) > 80301 ?? S 0:31.58 sendmail: running queue: /var/spool/mqueue/oz/d= f (sendmail) > 80302 ?? S 0:30.71 sendmail: running queue: /var/spool/mqueue/rw2/= df (sendmail) > 80303 ?? S 0:33.29 sendmail: running queue: /var/spool/mqueue/hold= /df (sendmail) > 80304 ?? S 0:30.55 sendmail: running queue: /var/spool/mqueue/pgp/= df (sendmail) >=20 > BACKTRACE OF STUCK PROCESS 80299 >=20 > (gdb) bt > #0 0x28346547 in sigsuspend () from /lib/libc.so.7 > #1 0x28344e98 in sigpause () from /lib/libc.so.7 > #2 0x2833be3e in pause () from /lib/libc.so.7 > #3 0x080cc7c8 in sleep () > #4 0x08099c51 in run_work_group () > #5 0x08099ebf in runqueue () > #6 0x0805538d in main () >=20 > BACKTRACE OF HAPPY PROCESS 80301 >=20 > (gdb) bt > #0 0x28346547 in sigsuspend () from /lib/libc.so.7 > #1 0x28344e98 in sigpause () from /lib/libc.so.7 > #2 0x2833be3e in pause () from /lib/libc.so.7 > #3 0x080cc7c8 in sleep () > #4 0x08099c51 in run_work_group () > #5 0x08099ebf in runqueue () > #6 0x0805538d in main () >=20 > PROCESS STATES AFTER DEBUG >=20 > PID TT STAT TIME COMMAND > 80298 ?? Ss 0:17.69 sendmail: accepting connections (sendmail) > 80299 ?? S 0:46.66 sendmail: running queue: /var/spool/mqueue/qd1/= df (sendmail) > 80300 ?? S 0:08.85 sendmail: running queue: /var/spool/mqueue/mby/= df (sendmail) > 80301 ?? S 0:31.60 sendmail: running queue: /var/spool/mqueue/oz/d= f (sendmail) > 80302 ?? S 0:30.73 sendmail: running queue: /var/spool/mqueue/rw2/= df (sendmail) > 80303 ?? S 0:33.32 sendmail: running queue: /var/spool/mqueue/hold= /df (sendmail) > 80304 ?? S 0:30.58 sendmail: running queue: /var/spool/mqueue/pgp/= df (sendmail) >=20 > SENDMAIL DETAILS >=20 > Version 8.14.4 > Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 > NAMED_BIND NETINET NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF > STARTTLS USERDB XDEBUG >=20 > /usr/sbin/sendmail: > libsasl2.so.2 =3D> /usr/local/lib/libsasl2.so.2 (0x28154000) > libssl.so.7 =3D> /usr/local/lib/libssl.so.7 (0x2816a000) > libcrypto.so.7 =3D> /usr/local/lib/libcrypto.so.7 (0x281ad000) > libutil.so.8 =3D> /lib/libutil.so.8 (0x282f2000) > libc.so.7 =3D> /lib/libc.so.7 (0x28300000) > libz.so.5 =3D> /lib/libz.so.5 (0x2840c000) >=20 > I posted about this in comp.mail.sendmail and was told... >=20 > > sleep() should be one of these calls: > >=20 > > if (njobs =3D=3D 0 && WorkGrp[wgrp].wg_lowqintvl < MIN_SLEEP_TI= ME) > > sleep(MIN_SLEEP_TIME); > > else if (WorkGrp[wgrp].wg_lowqintvl <=3D 0) > > sleep(QueueIntvl > 0 ? QueueIntvl : MIN_SLEEP_TIME); > > else > > sleep(WorkGrp[wgrp].wg_lowqintvl); > >=20 > > Unless you have a really large value for one of these, the process > > should continue after a while. >=20 > The above code snippet is from sendmail/queue.c which fixes > MIN_SLEEP_TIME at 5. QueueIntvl defaults to 1. wg_lowqintvl defaults > to 0. I have not set any configuration or runtime options to override > these defaults, so my persistent queue runners should be sleeping for > either 1s or 5s only (not hours!). I think the best way to collect the data would be ktrace the queue runners, preferrably starting the ktrace before they are stuck. --5KObZtj3Gjpm0OUY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuDoY8ACgkQC3+MBN1Mb4gGwACg1LUYnPIOmnFJ3QUdcyhU0qzy 7E8AoNXDtvy2Y8zoVd3cnR2Hm19lqwib =kO8c -----END PGP SIGNATURE----- --5KObZtj3Gjpm0OUY-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 10:28:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A1CC106566C for ; Tue, 23 Feb 2010 10:28:03 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id CDAFB8FC14 for ; Tue, 23 Feb 2010 10:28:02 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.4/8.14.4) with ESMTP id o1NARtNx043030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 23 Feb 2010 21:27:56 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1266920876; bh=10g0Vny9b16XLkEyj710jw52N9MbaIM7r99XaYpkfgY=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=Qs50N9xPEg9OHB3VzW7CYC0DhfJ8a+XHSukZzg7hBzFwZm1QrYJLY16yNNc4ONMwQ toE4FypDD9yUuqYKMWh5zCJF8Q+sue0BrJoenDUfLOSlvBsTfIB7HADqMlWyVDKXd2 pnG575D7LcxrxFzM6LhO2cAfB3ubaw5VJysLY0cE= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id o1NARtrL009769 for ; Tue, 23 Feb 2010 21:27:55 +1100 (AEDT) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id o1NARsiO009768 for freebsd-stable@freebsd.org; Tue, 23 Feb 2010 21:27:54 +1100 (AEDT) (envelope-from john) Date: Tue, 23 Feb 2010 21:27:54 +1100 From: John Marshall To: freebsd-stable@freebsd.org Message-ID: <20100223102754.GG2303@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org References: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> <20100223093616.GO50403@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline In-Reply-To: <20100223093616.GO50403@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: sleep(3) sometimes too sleepy on FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 10:28:03 -0000 --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 23 Feb 2010, 11:36 +0200, Kostik Belousov wrote: > On Tue, Feb 23, 2010 at 12:35:22PM +1100, John Marshall wrote: > > Environment: sendmail 8.14.4 on FreeBSD 8.0-RELEASE-p2 > >=20 > > Since upgrading a few local servers to FreeBSD 8.0-RELEASE (and > > subsequently 8.0-RELEASE-p2), I have been seeing VERY intermittent > > problems with sendmail persistent queue runners. One or more queue > > runners will fail to wake up (having been told to sleep for either 1 or > > 5 seconds) and mail accumulates in their queue group queues. > I think the best way to collect the data would be ktrace the queue runner= s, > preferrably starting the ktrace before they are stuck. OK. I've started a ktrace for the sendmail process group on each of the three servers. I'll re-start the ktrace each day until a problem appears (could be another couple of weeks). Thank you. --=20 John Marshall --lEGEL1/lMxI0MVQ2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuDraoACgkQw/tAaKKahKI+YgCdHCIClt0gLzX2aaeWB2OiWzdu oJYAn0REyOgKqSm8q3fzcJbrpywU4DeM =304N -----END PGP SIGNATURE----- --lEGEL1/lMxI0MVQ2-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 10:40:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C775B106566B for ; Tue, 23 Feb 2010 10:40:37 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 51BD98FC17 for ; Tue, 23 Feb 2010 10:40:36 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1NAeZwi044303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 11:40:35 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B83B0A2.1030008@omnilan.de> Date: Tue, 23 Feb 2010 11:40:34 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig70A3E3E4E79FB027359A9710" Subject: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 10:40:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig70A3E3E4E79FB027359A9710 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I'm frequently getting my machine locked with ahcichX timeouts: ahcich2: Timeout on slot 0 ahcich2: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd c0 serr=20 00000000 ahcich2: Timeout on slot 8 ahcich2: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr=20 00000000 ahcich2: Timeout on slot 8 ahcich2: is 00000000 cs fffff07f ss ffffff7f rs ffffff7f tfd c0 serr=20 00000000 =2E.. This happens when backup over GbE overloads ZFS/HDD capabilities. I reduced vfs.zfs.txg.timeout to 1 to prevent the machine from locking=20 up almost immediately, but from it still happens. When I don't use ahci but ataahci (the old driver if I understand things = correct) I also see the ZFS burst write congestion, but this doesn't=20 lead to controller timeouts, thus blocking the machine. Sometimes the machine recovers from the disk lock, but most often I have = to reboot. Kernel is from Feb. 19, so recent ahci improovements are active. Controller is ICH9R with 3 Samsung F3 SpinPoints. Any ideas how to work arround the hangs other than using the old ahci=20 driver? Thanks, -Harry --------------enig70A3E3E4E79FB027359A9710 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkuDsKMACgkQLDqVQ9VXb8iTCQCfcQHNwJd7i7Wk6rw1QMyGQETE NqsAoLAz8CAgMmSecAqi50A8bxknqVov =4ECQ -----END PGP SIGNATURE----- --------------enig70A3E3E4E79FB027359A9710-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 11:40:48 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 717C71065670 for ; Tue, 23 Feb 2010 11:40:48 +0000 (UTC) (envelope-from geo.liaskos@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 063788FC14 for ; Tue, 23 Feb 2010 11:40:47 +0000 (UTC) Received: by fxm23 with SMTP id 23so3610426fxm.3 for ; Tue, 23 Feb 2010 03:40:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=8HKhAsMH+mGTpA7ctk6kmFSwW13eAjl8bv2vqZy2r2w=; b=uA/QBI3VfcYhNxZEVEswl7fsyF+zuOaSYrlnCHgMkabp71dJdXLcPtJpTJD03f7jW0 aZ3ypmyFDeDWEajOBseBt3Xru2a+32LIraHu90BAdKJ8z1gSdCeLZ8pwLrfbgubn1RGI rbgt1aqXRleTgh12gL+WHFaVAox0tBPW2k6T0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LqUh8l7ej+bqZJ9Rxds4TyHg6QwnzLhb/KoutRe1/XIJLAhPwK1UJ3pVm9RRPoFuO4 uUtMY7BxtGbfeZUe+5VBsVwM1j57Th0iHgf0On82Pe8uV9w4rZX+0I0P71aZENa4Mgki mQJb3uaXo+auP9GHKd9NJV3Ydr+RjDf2R8WL4= MIME-Version: 1.0 Received: by 10.239.180.19 with SMTP id f19mr1764211hbg.35.1266923733900; Tue, 23 Feb 2010 03:15:33 -0800 (PST) In-Reply-To: <4B83B0A2.1030008@omnilan.de> References: <4B83B0A2.1030008@omnilan.de> Date: Tue, 23 Feb 2010 11:15:33 +0000 Message-ID: From: George Liaskos To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 11:40:48 -0000 I am having the same issue since Feb 20 which was my last update. ahcich1: Timeout on slot 3 ahcich1: is 00000000 cs 00000018 ss 00000000 rs 00000018 tfd d0 serr 00000000 ahcich1: Timeout on slot 5 ahcich1: is 00000000 cs 00000060 ss 00000000 rs 00000060 tfd d0 serr 00000000 ahcich1: Timeout on slot 7 ahcich1: is 00000000 cs 00000180 ss 00000000 rs 00000180 tfd d0 serr 00000000 ahcich1: Timeout on slot 9 ahcich1: is 00000000 cs 00000600 ss 00000000 rs 00000600 tfd d0 serr 00000000 > dmesg | grep ahci ahci0: port 0x1c40-0x1c47,0x1834-0x1837,0x1838-0x183f,0x1830-0x1833,0x1c20-0x1c3f mem 0xfc226000-0xfc2267ff irq 16 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 On Tue, Feb 23, 2010 at 10:40 AM, Harald Schmalzbauer wrote: > Hello, > > I'm frequently getting my machine locked with ahcichX timeouts: > ahcich2: Timeout on slot 0 > ahcich2: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd c0 serr > 00000000 > ahcich2: Timeout on slot 8 > ahcich2: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr > 00000000 > ahcich2: Timeout on slot 8 > ahcich2: is 00000000 cs fffff07f ss ffffff7f rs ffffff7f tfd c0 serr > 00000000 > ... > > This happens when backup over GbE overloads ZFS/HDD capabilities. > I reduced vfs.zfs.txg.timeout to 1 to prevent the machine from locking up > almost immediately, but from it still happens. > When I don't use ahci but ataahci (the old driver if I understand things > correct) I also see the ZFS burst write congestion, but this doesn't lead to > controller timeouts, thus blocking the machine. > > Sometimes the machine recovers from the disk lock, but most often I have to > reboot. > > Kernel is from Feb. 19, so recent ahci improovements are active. > Controller is ICH9R with 3 Samsung F3 SpinPoints. > > Any ideas how to work arround the hangs other than using the old ahci > driver? > > Thanks, > > -Harry > > From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 10:16:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 145A4106566B for ; Tue, 23 Feb 2010 10:16:02 +0000 (UTC) (envelope-from agurin@mail.ru) Received: from fallback1.mail.ru (fallback1.mail.ru [94.100.176.18]) by mx1.freebsd.org (Postfix) with ESMTP id C10DF8FC12 for ; Tue, 23 Feb 2010 10:16:01 +0000 (UTC) Received: from f284.mail.ru (f284.mail.ru [217.69.128.251]) by fallback1.mail.ru (mPOP.Fallback_MX) with ESMTP id A521E18B2B8 for ; Tue, 23 Feb 2010 13:03:08 +0300 (MSK) Received: from mail by f284.mail.ru with local id 1Njrbf-00021P-00 for freebsd-stable@freebsd.org; Tue, 23 Feb 2010 13:03:07 +0300 Received: from [82.193.120.213] by win.mail.ru with HTTP; Tue, 23 Feb 2010 13:03:07 +0300 From: =?koi8-r?Q?=F3=C1=CE=C5=CB_=E7=D5=D2=C9=CE?= To: freebsd-stable@freebsd.org Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [82.193.120.213] Date: Tue, 23 Feb 2010 13:03:07 +0300 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: X-Spam: Not detected X-Mras: Ok X-Mailman-Approved-At: Tue, 23 Feb 2010 12:30:43 +0000 Subject: FreeBSD 8.0-STABLE freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?koi8-r?Q?=F3=C1=CE=C5=CB_=E7=D5=D2=C9=CE?= List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 10:16:02 -0000 FreeBSD freeze After update few weeks ago freebsd began to freeze from time to time. Can't find any reason in logs or other way. System may halt after an hour of work, or may work few days. Before halt it may respond to shell commands very-very slow.... MB: MSI P45 NEO3-FR. BIOS ATA configured as AHCI. JMicron ATA controller is disabled. % uname -a FreeBSD wk.kiev.ua 8.0-STABLE FreeBSD 8.0-STABLE #3 r204163: Sun Feb 21 10:07:59 EET 2010 root@wk.kiev.ua:/usr/obj/usr/src/sys/GNRDBG amd64 Kernel Config: http://xdevs.com/wk/kernel_config.txt dmesg output: http://xdevs.com/wk/dmesg.txt panic: _mtx_lock_sleep: recursed on non-recursive mutex ATA state lock @ /usr/sys/dev/ata/ata-all.c:334 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at 0xffffffff801e05c5a = db_trace_self_wrapper+0x2a panic() at 0xffffffff8058d692 = panic+0x182 _mtx_lock_sleep() at 0xffffffff8057ec52 = _mtx_lock_sleep+0x152 _mtx_lock_flags() at 0xffffffff8057ed41 = _mtx_lock_flags+exe1 ata_reinit() at 0xffffffff802723f3 = ata_reinit+0xb3 ata_conn_event() at 0xffffffff80272b7e = ata_conn_event+0xe3 taskqueue_run() at 0xffffffff805c9e01 = taskqueue_run+0x91 taskqueue_thread_loop() at 0xffffffff805c9f8f = taskqueue_thread_loop+0x3f fork_exit() at 0xffffffff80564f3a = fork_exit+0x12a fork_trampoline() at 0xffffffff8085b84e = fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff80000b9d30, rbp = 0 --- Uptime: 19s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort VOP_STRATEGY: bp in not locked but should be From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 13:46:41 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B76F1065670; Tue, 23 Feb 2010 13:46:41 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EC9A58FC08; Tue, 23 Feb 2010 13:46:39 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA24637; Tue, 23 Feb 2010 15:46:37 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B83DC3C.4080201@icyb.net.ua> Date: Tue, 23 Feb 2010 15:46:36 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: =?KOI8-R?Q?=F3=C1=CE=C5=CB_=E7=D5=D2=C9=CE?= References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: FreeBSD 8.0-STABLE freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 13:46:41 -0000 on 23/02/2010 12:03 said the following: > FreeBSD freeze > > After update few weeks ago freebsd began to freeze from time to time. Can't find any reason in logs or other way. System may halt after an hour of work, or may work few days. Before halt it may respond to shell commands very-very slow.... > > MB: MSI P45 NEO3-FR. BIOS ATA configured as AHCI. JMicron ATA controller is disabled. > > % uname -a > FreeBSD wk.kiev.ua 8.0-STABLE FreeBSD 8.0-STABLE #3 r204163: Sun Feb 21 10:07:59 EET 2010 root@wk.kiev.ua:/usr/obj/usr/src/sys/GNRDBG amd64 > > Kernel Config: http://xdevs.com/wk/kernel_config.txt > dmesg output: http://xdevs.com/wk/dmesg.txt > > > panic: _mtx_lock_sleep: recursed on non-recursive mutex ATA state lock @ /usr/sys/dev/ata/ata-all.c:334 > > cpuid = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at 0xffffffff801e05c5a = db_trace_self_wrapper+0x2a > panic() at 0xffffffff8058d692 = panic+0x182 > _mtx_lock_sleep() at 0xffffffff8057ec52 = _mtx_lock_sleep+0x152 > _mtx_lock_flags() at 0xffffffff8057ed41 = _mtx_lock_flags+exe1 > ata_reinit() at 0xffffffff802723f3 = ata_reinit+0xb3 > ata_conn_event() at 0xffffffff80272b7e = ata_conn_event+0xe3 > taskqueue_run() at 0xffffffff805c9e01 = taskqueue_run+0x91 > taskqueue_thread_loop() at 0xffffffff805c9f8f = taskqueue_thread_loop+0x3f > fork_exit() at 0xffffffff80564f3a = fork_exit+0x12a > fork_trampoline() at 0xffffffff8085b84e = fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff80000b9d30, rbp = 0 --- > Uptime: 19s > Cannot dump. Device not defined or unavailable. > Automatic reboot in 15 seconds - press a key on the console to abort > VOP_STRATEGY: bp in not locked but should be I believe that this a (well known?) bug in ata driver: state_mtx is not initialized as recursive, but is used as such. E.g. it is locked in ata_conn_event and then ata_reinit locks it again. Of course, an external condition is needed to trigger ata_conn_event in the first place. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 14:47:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D73B1065670 for ; Tue, 23 Feb 2010 14:47:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by mx1.freebsd.org (Postfix) with ESMTP id 27A5F8FC13 for ; Tue, 23 Feb 2010 14:47:57 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so1042756fga.13 for ; Tue, 23 Feb 2010 06:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=7n9TvNfRcd07j9ly1BnU0yZlSR67QJi9DA9e3R4VCYc=; b=cx/Z5PCjRgXMgXOE7TWx8NKM5txefmgiMwfnDtX5gdVSTKD7Q/uE/J52NYNV565aUg 2owA0AhcRo7nvPJFAy7MT7An0kalz92KZuzwgw+4TJO5BseCIGmTcsls9meN5iwBpEYW WkPdIiTPaVC6CH2FHtBcKP5CYGyChusethN7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=b45LW4NTjtA4/IunJJIf3ZJp/aZrY6qs9KWY6emCy7pR3Z4SPxSJ8axlXyti881sNc Uw4OhpGOmUiF2VCgO0gpKJ5oaIgYxqG68zz4cWKJtZKRkGdhvhbbs6wCzCrPAJolb3Rx klJSkxoSuJB35vxgVFi//QK6O1vA8vjz+sGEk= Received: by 10.86.20.8 with SMTP id 8mr2270095fgt.38.1266936471316; Tue, 23 Feb 2010 06:47:51 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 14sm2496292fxm.5.2010.02.23.06.47.49 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 06:47:50 -0800 (PST) Sender: Alexander Motin Message-ID: <4B83EA94.5060704@FreeBSD.org> Date: Tue, 23 Feb 2010 16:47:48 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: =?KOI8-R?Q?=F3=C1=CE=C5=CB_=E7=D5=D2=C9=CE?= References: <4B83DC3C.4080201@icyb.net.ua> In-Reply-To: <4B83DC3C.4080201@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: multipart/mixed; boundary="------------040900030406090405080203" Cc: freebsd-stable@freebsd.org, Andriy Gapon Subject: Re: FreeBSD 8.0-STABLE freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 14:47:58 -0000 This is a multi-part message in MIME format. --------------040900030406090405080203 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Andriy Gapon wrote: > on 23/02/2010 12:03 said the following: >> FreeBSD freeze >> >> After update few weeks ago freebsd began to freeze from time to time. Can't find any reason in logs or other way. System may halt after an hour of work, or may work few days. Before halt it may respond to shell commands very-very slow.... >> >> MB: MSI P45 NEO3-FR. BIOS ATA configured as AHCI. JMicron ATA controller is disabled. >> >> % uname -a >> FreeBSD wk.kiev.ua 8.0-STABLE FreeBSD 8.0-STABLE #3 r204163: Sun Feb 21 10:07:59 EET 2010 root@wk.kiev.ua:/usr/obj/usr/src/sys/GNRDBG amd64 >> >> Kernel Config: http://xdevs.com/wk/kernel_config.txt >> dmesg output: http://xdevs.com/wk/dmesg.txt >> >> >> panic: _mtx_lock_sleep: recursed on non-recursive mutex ATA state lock @ /usr/sys/dev/ata/ata-all.c:334 >> >> cpuid = 1 >> KDB: stack backtrace: >> db_trace_self_wrapper() at 0xffffffff801e05c5a = db_trace_self_wrapper+0x2a >> panic() at 0xffffffff8058d692 = panic+0x182 >> _mtx_lock_sleep() at 0xffffffff8057ec52 = _mtx_lock_sleep+0x152 >> _mtx_lock_flags() at 0xffffffff8057ed41 = _mtx_lock_flags+exe1 >> ata_reinit() at 0xffffffff802723f3 = ata_reinit+0xb3 >> ata_conn_event() at 0xffffffff80272b7e = ata_conn_event+0xe3 >> taskqueue_run() at 0xffffffff805c9e01 = taskqueue_run+0x91 >> taskqueue_thread_loop() at 0xffffffff805c9f8f = taskqueue_thread_loop+0x3f >> fork_exit() at 0xffffffff80564f3a = fork_exit+0x12a >> fork_trampoline() at 0xffffffff8085b84e = fork_trampoline+0xe >> --- trap 0, rip = 0, rsp = 0xffffff80000b9d30, rbp = 0 --- >> Uptime: 19s >> Cannot dump. Device not defined or unavailable. >> Automatic reboot in 15 seconds - press a key on the console to abort >> VOP_STRATEGY: bp in not locked but should be > > I believe that this a (well known?) bug in ata driver: state_mtx is not > initialized as recursive, but is used as such. > E.g. it is locked in ata_conn_event and then ata_reinit locks it again. > Of course, an external condition is needed to trigger ata_conn_event in the first > place. Looks like my fault. Attached patch should fix that. But if you need really working hot-plug (and many other tasty things) - look to the new CAM-based ATA implementation. -- Alexander Motin --------------040900030406090405080203 Content-Type: text/plain; name="reinit.lock.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="reinit.lock.patch" --- ata-all.c.prev 2010-02-23 09:17:04.000000000 +0200 +++ ata-all.c 2010-02-23 16:23:49.000000000 +0200 @@ -289,15 +289,13 @@ static void ata_conn_event(void *context, int dummy) { device_t dev = (device_t)context; - struct ata_channel *ch = device_get_softc(dev); #ifdef ATA_CAM + struct ata_channel *ch = device_get_softc(dev); union ccb *ccb; -#endif mtx_lock(&ch->state_mtx); ata_reinit(dev); mtx_unlock(&ch->state_mtx); -#ifdef ATA_CAM if ((ccb = xpt_alloc_ccb()) == NULL) return; if (xpt_create_path(&ccb->ccb_h.path, NULL, @@ -307,6 +305,8 @@ ata_conn_event(void *context, int dummy) return; } xpt_rescan(ccb); +#else + ata_reinit(dev); #endif } --------------040900030406090405080203-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 15:10:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E49401065679 for ; Tue, 23 Feb 2010 15:10:18 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 714CC8FC17 for ; Tue, 23 Feb 2010 15:10:17 +0000 (UTC) Received: by fxm23 with SMTP id 23so3835999fxm.3 for ; Tue, 23 Feb 2010 07:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=6wZBze8iGSaVNY/bd4Z57phfFM2UGe9F3pggrD5GYFs=; b=wMcqpaoUtxKcggrmYJ5lxIXJble48JkfplHIMFmUXMB5NJ0+u99IN3ppeVfWOJFsKV lTgYeXyPu3insmRLVeQRFb2fCQvXiXRbvU17Rl4kZ/V5C+BGinhWDBpTIzZjazb2avRr eBqLs2pMc8Ktg8D6KJ02FrtjklhwZUo4pxOjA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=vhuBaYj6zedq72r3yuEBvunv0GUbS22l3vnUdLJLlTmjCa8AVfbpMiBh34WwrDGQCA /nHhfsi4kKqb+/hq8CmfJlB81FrSVjhEqPtxInS2begemLnMgErBNCdHwDkaWhdsrk85 esRIXZF8EoRIiTldWqQ59yR15wu+0ssRQGBlA= Received: by 10.223.15.133 with SMTP id k5mr1525182faa.39.1266937814615; Tue, 23 Feb 2010 07:10:14 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm2499779fxm.0.2010.02.23.07.10.13 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 07:10:14 -0800 (PST) Sender: Alexander Motin Message-ID: <4B83EFD4.8050403@FreeBSD.org> Date: Tue, 23 Feb 2010 17:10:12 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Harald Schmalzbauer References: <1266934981.00222684.1266922202@10.7.7.3> In-Reply-To: <1266934981.00222684.1266922202@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 15:10:19 -0000 Harald Schmalzbauer wrote: > I'm frequently getting my machine locked with ahcichX timeouts: > ahcich2: Timeout on slot 0 > ahcich2: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd c0 serr > 00000000 > ahcich2: Timeout on slot 8 > ahcich2: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr > 00000000 > ahcich2: Timeout on slot 8 > ahcich2: is 00000000 cs fffff07f ss ffffff7f rs ffffff7f tfd c0 serr > 00000000 > ... Looking that is (Interrupt status) is zero and `rs == cs | ss` (running command bitmasks in driver and hardware), controller doesn't report command completion. Looking on TFD status 0xc0 with BUSY bit set, I would suppose that either disk stuck in command processing for some reason, or controller missed command completion status. Have you noticed 30 second (default ATA timeout) pause before timeout message printed? Just want to be sure that driver waited enough before give up. > This happens when backup over GbE overloads ZFS/HDD capabilities. > I reduced vfs.zfs.txg.timeout to 1 to prevent the machine from locking > up almost immediately, but from it still happens. > When I don't use ahci but ataahci (the old driver if I understand things > correct) I also see the ZFS burst write congestion, but this doesn't > lead to controller timeouts, thus blocking the machine. > > Sometimes the machine recovers from the disk lock, but most often I have > to reboot. How it looks when it doesn't? Can you send me full log messages? > Kernel is from Feb. 19, so recent ahci improovements are active. > Controller is ICH9R with 3 Samsung F3 SpinPoints. > > Any ideas how to work arround the hangs other than using the old ahci > driver? Old ataahci driver wasn't using NCQ. NCQ may trigger some bugs in drive firmware or expose some protocol inconsistencies. I would recommend you to search for some errata for your drive and possibly firmware update. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 15:50:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A5A210656A7 for ; Tue, 23 Feb 2010 15:50:27 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 284CD8FC1D for ; Tue, 23 Feb 2010 15:50:26 +0000 (UTC) Received: by fxm23 with SMTP id 23so3879457fxm.3 for ; Tue, 23 Feb 2010 07:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=NCU8TFnu0WH1EmCR7Sfjb9fB6UGj8QTauFXX0FDt7mw=; b=SM8ezyt157PQB8m2dlFxhfhvXicb2aVMIM2MDSBcotC0K50XKMdT1CDd6r6Ue9ckA1 XKK4iMHNoAuuNuxZ6YHdOrgvCitGoeRq3efUTES4Q01hUicHJGfvDeTQsKrJgx4yi92K e6pwrbtfZa/cild1XkW+XOJKe/AS6UaxdD9C8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BJT1gD8HPEVK1+FLV+Mw2NRz9sytdkNPMSwLY9Lz37Qih/CW4JARJCq2FGGYZpeDUV RGAHGJ1L1M55FAykCPb8KsVpAvGXqVGqsNMXFSL844YLcidlJcvgNJ9kZ7QGU1IJwOna d6yKWvdB2SMytx4ck2TKoZ8TqznxDaGmsMH3I= Received: by 10.223.75.155 with SMTP id y27mr267365faj.79.1266940221108; Tue, 23 Feb 2010 07:50:21 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 13sm2547384fxm.6.2010.02.23.07.50.20 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 07:50:20 -0800 (PST) Sender: Alexander Motin Message-ID: <4B83F93A.4030805@FreeBSD.org> Date: Tue, 23 Feb 2010 17:50:18 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: George Liaskos References: <1266934981.00222684.1266922202@10.7.7.3> <1266938581.00222692.1266925802@10.7.7.3> In-Reply-To: <1266938581.00222692.1266925802@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Harald Schmalzbauer , freebsd-stable@freebsd.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 15:50:27 -0000 George Liaskos wrote: > I am having the same issue since Feb 20 which was my last update. Which version was before? > ahcich1: Timeout on slot 3 > ahcich1: is 00000000 cs 00000018 ss 00000000 rs 00000018 tfd d0 serr 00000000 > ahcich1: Timeout on slot 5 > ahcich1: is 00000000 cs 00000060 ss 00000000 rs 00000060 tfd d0 serr 00000000 > ahcich1: Timeout on slot 7 > ahcich1: is 00000000 cs 00000180 ss 00000000 rs 00000180 tfd d0 serr 00000000 > ahcich1: Timeout on slot 9 > ahcich1: is 00000000 cs 00000600 ss 00000000 rs 00000600 tfd d0 serr 00000000 Situation looks alike, except it is CD drive and so without NCQ. I am still don't see bugs from driver side here. Do you see delays before timeout messages? You may try to enable verbose kernel messages to get some more info. >> dmesg | grep ahci > ahci0: port > 0x1c40-0x1c47,0x1834-0x1837,0x1838-0x183f,0x1830-0x1833,0x1c20-0x1c3f > mem 0xfc226000-0xfc2267ff irq 16 at device 31.2 on pci0 > ahci0: [ITHREAD] > ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier not supported > ahcich0: at channel 0 on ahci0 > ahcich0: [ITHREAD] > ahcich1: at channel 1 on ahci0 > ahcich1: [ITHREAD] > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 Show this also with verbose. > On Tue, Feb 23, 2010 at 10:40 AM, Harald Schmalzbauer > wrote: >> Hello, >> >> I'm frequently getting my machine locked with ahcichX timeouts: >> ahcich2: Timeout on slot 0 >> ahcich2: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd c0 serr >> 00000000 >> ahcich2: Timeout on slot 8 >> ahcich2: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr >> 00000000 >> ahcich2: Timeout on slot 8 >> ahcich2: is 00000000 cs fffff07f ss ffffff7f rs ffffff7f tfd c0 serr >> 00000000 >> ... >> >> This happens when backup over GbE overloads ZFS/HDD capabilities. >> I reduced vfs.zfs.txg.timeout to 1 to prevent the machine from locking up >> almost immediately, but from it still happens. >> When I don't use ahci but ataahci (the old driver if I understand things >> correct) I also see the ZFS burst write congestion, but this doesn't lead to >> controller timeouts, thus blocking the machine. >> >> Sometimes the machine recovers from the disk lock, but most often I have to >> reboot. >> >> Kernel is from Feb. 19, so recent ahci improovements are active. >> Controller is ICH9R with 3 Samsung F3 SpinPoints. >> >> Any ideas how to work arround the hangs other than using the old ahci >> driver? -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 16:08:05 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DEE7106566C; Tue, 23 Feb 2010 16:08:05 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id B07998FC1B; Tue, 23 Feb 2010 16:08:04 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1NG83Hf048778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 17:08:03 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B83FD62.2020407@omnilan.de> Date: Tue, 23 Feb 2010 17:08:02 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Alexander Motin References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> In-Reply-To: <4B83EFD4.8050403@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4B8E4FCE8276EE64A2F3CC38" Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:08:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B8E4FCE8276EE64A2F3CC38 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Motin schrieb am 23.02.2010 16:10 (localtime): > Harald Schmalzbauer wrote: >> I'm frequently getting my machine locked with ahcichX timeouts: >> ahcich2: Timeout on slot 0 >> ahcich2: is 00000000 cs 00000001 ss 00000000 rs 00000001 tfd c0 serr >> 00000000 >> ahcich2: Timeout on slot 8 >> ahcich2: is 00000000 cs 00000100 ss 00000000 rs 00000100 tfd c0 serr >> 00000000 >> ahcich2: Timeout on slot 8 >> ahcich2: is 00000000 cs fffff07f ss ffffff7f rs ffffff7f tfd c0 serr >> 00000000 >> ... >=20 > Looking that is (Interrupt status) is zero and `rs =3D=3D cs | ss` (run= ning > command bitmasks in driver and hardware), controller doesn't report > command completion. Looking on TFD status 0xc0 with BUSY bit set, I > would suppose that either disk stuck in command processing for some > reason, or controller missed command completion status. >=20 > Have you noticed 30 second (default ATA timeout) pause before timeout > message printed? Just want to be sure that driver waited enough before > give up. Yes, there is some pause between the occurance of the hang and the first = timeout message. But I can't tell you exactly if it's 30 seconds. I=20 guess rather more than 30 sec. >> This happens when backup over GbE overloads ZFS/HDD capabilities. >> I reduced vfs.zfs.txg.timeout to 1 to prevent the machine from locking= >> up almost immediately, but from it still happens. >> When I don't use ahci but ataahci (the old driver if I understand thin= gs >> correct) I also see the ZFS burst write congestion, but this doesn't >> lead to controller timeouts, thus blocking the machine. >> >> Sometimes the machine recovers from the disk lock, but most often I ha= ve >> to reboot. >=20 > How it looks when it doesn't? Can you send me full log messages? Unfortunately not. That happened only once (which I recognized), 3 days=20 ago and messages got turned over 5 times since then... But I have some messages from 02/15, with kernel from january. Usually=20 the messages continue to pop up until I reset the machine. This time=20 there were only the three above, even after waiting half an hour (had to = go on site). The old messages: ahcich2: Timeout on slot 20 ahcich2: is 00000000 cs ff07ffff ss fff7ffff rs fff7ffff tfd c0 serr=20 00000000 ahcich4: Timeout on slot 24 ahcich4: is 00000000 cs f07fffff ss ff7fffff rs ff7fffff tfd c0 serr=20 00000000 ahcich2: Timeout on slot 17 ahcich2: is 00000000 cs fff9ffff ss ffffffff rs ffffffff tfd c0 serr=20 00000000 ahcich4: Timeout on slot 20 ahcich4: is 00000000 cs 00300000 ss 00000000 rs 00300000 tfd c0 serr=20 00000000 ahcich2: Timeout on slot 15 ahcich2: is 00000000 cs fff87fff ss ffffffff rs ffffffff tfd c0 serr=20 00000000 ahcich4: Timeout on slot 22 ahcich4: is 00000000 cs fc0fffff ss ffcfffff rs ffcfffff tfd c0 serr=20 00000000 ahcich2: Timeout on slot 13 ahcich2: is 00000000 cs ffff1fff ss ffffffff rs ffffffff tfd c0 serr=20 00000000 ahcich4: Timeout on slot 16 ahcich4: is 00000000 cs 00010000 ss 00000000 rs 00010000 tfd c0 serr=20 00000000 ahcich2: Timeout on slot 11 ahcich2: is 00000000 cs ffffc7ff ss ffffffff rs ffffffff tfd c0 serr=20 00000000 ahcich4: Timeout on slot 16 ahcich4: is 00000000 cs 00000000 ss 00010000 rs 00010000 tfd 40 serr=20 00000000 Maybe it's helpful to you. Since I haven't seen the hang after=20 upgrading, although doing extensive network transfer tests, I thought it = vanished and haven't kept logs safe... >> Kernel is from Feb. 19, so recent ahci improovements are active. >> Controller is ICH9R with 3 Samsung F3 SpinPoints. >> >> Any ideas how to work arround the hangs other than using the old ahci >> driver? >=20 > Old ataahci driver wasn't using NCQ. NCQ may trigger some bugs in drive= > firmware or expose some protocol inconsistencies. I would recommend you= > to search for some errata for your drive and possibly firmware update. Sounds reasonable. How can I disable NCQ with new ahci? I guess if it's a HDD firmware issue with NCQ the hang shouldn't happen=20 when NCQ is disabled. Btw, I found camcontrol cmd ada0 -a "EF 85 00 00 00 00 00 00 00 00 00=20 00" for disabling APM and another one for disabling AAM. I did that for=20 my drives. Is there a wiki where we can place such valuable commands? Thanks, -Harry --------------enig4B8E4FCE8276EE64A2F3CC38 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkuD/WMACgkQLDqVQ9VXb8hgRgCeJo/dUvVw3mzgwXf/JPjh245g 230An31KgZM6DP+Jy95EgfvnkhXOAm0F =b+YU -----END PGP SIGNATURE----- --------------enig4B8E4FCE8276EE64A2F3CC38-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 16:19:03 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1A79C1065672 for ; Tue, 23 Feb 2010 16:19:03 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 9BC5A8FC12 for ; Tue, 23 Feb 2010 16:19:02 +0000 (UTC) Received: by fxm23 with SMTP id 23so3910335fxm.3 for ; Tue, 23 Feb 2010 08:18:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=9lVfgIfaHxtDCaoClHEaetHwxF7ptB5G0IP3nPYD2Zk=; b=LUPEhVlXSA5k1FE1xoO5fWyjXd/7NXMVB2MgN2BG4OiVK0APApxi5Jf1Jb2B5C11fy 6DvsTHnQcGyW2iTfghi0171qZHgzaaIhlIldliYkfLyprF2BgafV7EIGaQORl/+3TndU F3MGzo0oHw3vUhnHh/51cQ91Sy7vuhjWTPJg4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=ZFi6FmEkkNK7OMQ3Br43zLSVwZi+54a0FQ372D0uNloijL5nH/MLJB/IyJRU0kg1XS lF21ALnhiaOxLZDTwx5alQXJeZbq1gaflZNLsRxIkpr0w1TjB8TNGcRbpsU65nUlYRd2 CU401afO9DJbhUsUSXWZTyV2xm/0i2PFhIisU= Received: by 10.223.77.136 with SMTP id g8mr1593302fak.10.1266941938891; Tue, 23 Feb 2010 08:18:58 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm2581040fxm.8.2010.02.23.08.18.57 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 08:18:57 -0800 (PST) Sender: Alexander Motin Message-ID: <4B83FFEF.7010509@FreeBSD.org> Date: Tue, 23 Feb 2010 18:18:55 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Harald Schmalzbauer References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B83FD62.2020407@omnilan.de> In-Reply-To: <4B83FD62.2020407@omnilan.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:19:04 -0000 Harald Schmalzbauer wrote: > Maybe it's helpful to you. Since I haven't seen the hang after > upgrading, although doing extensive network transfer tests, I thought it > vanished and haven't kept logs safe... Enabling verbose kernel messages may give a bit more info. >>> Kernel is from Feb. 19, so recent ahci improovements are active. >>> Controller is ICH9R with 3 Samsung F3 SpinPoints. >>> >>> Any ideas how to work arround the hangs other than using the old ahci >>> driver? >> >> Old ataahci driver wasn't using NCQ. NCQ may trigger some bugs in drive >> firmware or expose some protocol inconsistencies. I would recommend you >> to search for some errata for your drive and possibly firmware update. > > Sounds reasonable. > How can I disable NCQ with new ahci? There is no user-level control for this yet. It can be done via writing quirk for this specific device in ata_xpt.c, or via commenting setting ADA_FLAG_CAN_NCQ flag in ata_da.c, or by adding AHCI_Q_NONCQ quirk for your controller in ahci.c. > I guess if it's a HDD firmware issue with NCQ the hang shouldn't happen > when NCQ is disabled. Just for case of real I/O timeout, run full surface test with SMART. > Btw, I found camcontrol cmd ada0 -a "EF 85 00 00 00 00 00 00 00 00 00 > 00" for disabling APM and another one for disabling AAM. I did that for > my drives. Is there a wiki where we can place such valuable commands? Probably not. It is just ATA commands, taken from ATA specification, but definitely it is not very easy way. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 16:22:51 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC4AE106568D for ; Tue, 23 Feb 2010 16:22:51 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 68FC28FC1C for ; Tue, 23 Feb 2010 16:22:51 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NjxX8-0002uv-20 for freebsd-stable@freebsd.org; Tue, 23 Feb 2010 18:22:50 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 23 Feb 2010 18:22:50 +0200 From: Daniel Braniss Message-ID: Subject: ahcich3: Timeout on slot 0 ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 16:22:51 -0000 hi, with latest 8-stable, I can't boot since it's stuck with: ... ahci0: port 0xb880-0xb887,0xb800-0xb803,0xb48 0-0xb487,0xb400-0xb403,0xb080-0xb09f mem 0xfe7fa800-0xfe7fafff irq 22 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 4 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 5 on ahci0 ahcich3: [ITHREAD] ... umass0:4:0:-1: Attached to scbus4 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI status: Check Condition (probe0:umass-sim0:0:0:0): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 (probe0:umass-sim0:0:0:1): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:1): SCSI status: Check Condition (probe0:umass-sim0:0:0:1): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:2): TEST UNIT READY. CDB: 0 40 0 0 0 0 (probe0:umass-sim0:0:0:2): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:2): SCSI status: Check Condition (probe0:umass-sim0:0:0:2): SCSI sense: NOT READY asc:3a,0 (Medium not present) (probe0:umass-sim0:0:0:3): TEST UNIT READY. CDB: 0 60 0 0 0 0 (probe0:umass-sim0:0:0:3): CAM status: SCSI Status Error (probe0:umass-sim0:0:0:3): SCSI status: Check Condition (probe0:umass-sim0:0:0:3): SCSI sense: NOT READY asc:3a,0 (Medium not present) ahcich3: Timeout on slot 0 ahcich3: is 00000000 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr 00000000 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ahcich3: Timeout on slot 0 ahcich3: is 00000000 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr 00000000 ahcich3: Timeout on slot 0 ahcich3: is 00000000 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr 00000000 run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config ... with a slightly older kernel all is ok. ... Trying to mount root from nfs: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): Unretryable error da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present the only wierd thing I see, is the Trying to mount root from nfs: which does not happen in the failing kernel. danny From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 17:11:51 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FE591065670; Tue, 23 Feb 2010 17:11:51 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id B22E88FC08; Tue, 23 Feb 2010 17:11:50 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1NHBnpr049564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 18:11:49 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B840C54.3010304@omnilan.de> Date: Tue, 23 Feb 2010 18:11:48 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Alexander Motin References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B83FD62.2020407@omnilan.de> <4B83FFEF.7010509@FreeBSD.org> In-Reply-To: <4B83FFEF.7010509@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig77CB4EBBA6A071FCCD91FB34" Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 17:11:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig77CB4EBBA6A071FCCD91FB34 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Motin schrieb am 23.02.2010 17:18 (localtime): =2E.. >> I guess if it's a HDD firmware issue with NCQ the hang shouldn't happe= n >> when NCQ is disabled. >=20 > Just for case of real I/O timeout, run full surface test with SMART. Unfortunately I couldn't find new firmware from Samsung, although one=20 drive shows version 1AG01113 while the other two have 1AG01118. But the=20 timeout happened at different channels, so it's not one certain disk... One understanding question: If the drive doesn't complete a command,=20 regardless if it's due to a firmware bug, a disk surface error or=20 whatever, is there no way for the driver to terminate the request and=20 take the drive offline after some time? This would be a very important=20 behaviour for me. It doesn't make sense building RAIDz storage when a=20 failing drive hangs the complete machine, even if the system partitions=20 are on a complete different SSD. >> Btw, I found camcontrol cmd ada0 -a "EF 85 00 00 00 00 00 00 00 00 00 >> 00" for disabling APM and another one for disabling AAM. I did that fo= r >> my drives. Is there a wiki where we can place such valuable commands? >=20 > Probably not. It is just ATA commands, taken from ATA specification, bu= t > definitely it is not very easy way. Hmm, I saw some FreeBSD wikis, but I don't know if there's the _one_=20 official. I'll see if there's a possibility to leave some usefull hint's = for such purposes. Thanks, -Harry --------------enig77CB4EBBA6A071FCCD91FB34 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkuEDFUACgkQLDqVQ9VXb8iUdACfTBUWKqbolilNuKYOecpv6/Yq 1SwAoJh++wPFLWL9kAwXar20TEZA3f1l =W23z -----END PGP SIGNATURE----- --------------enig77CB4EBBA6A071FCCD91FB34-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 17:30:06 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5034F106568B; Tue, 23 Feb 2010 17:30:06 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 0014D8FC12; Tue, 23 Feb 2010 17:30:05 +0000 (UTC) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 94EC12C2C59; Tue, 23 Feb 2010 11:30:05 -0600 (CST) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i8ZQ99ceqq94; Tue, 23 Feb 2010 11:29:57 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 4CE752C2AD0; Tue, 23 Feb 2010 11:29:57 -0600 (CST) Message-ID: <4B841093.2000402@cs.rice.edu> Date: Tue, 23 Feb 2010 11:29:55 -0600 From: Alan Cox User-Agent: Thunderbird 2.0.0.23 (X11/20100102) MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B72D94A.8030509@icyb.net.ua> <4B72E93C.80102@icyb.net.ua> <9bbcef731002101003r203f5189xf139700a0d48afa0@mail.gmail.com> <4B72F67F.4000209@icyb.net.ua> <9bbcef731002101026k5007075cqf97fc80404ac3fa7@mail.gmail.com> <4B72FC55.2090508@icyb.net.ua> <9bbcef731002101038r1ac04141t505216816489376f@mail.gmail.com> <20100210184623.GA78851@icarus.home.lan> <4B741B7D.1030306@icyb.net.ua> <4B744EB2.3070108@cs.rice.edu> In-Reply-To: <4B744EB2.3070108@cs.rice.edu> Content-Type: multipart/mixed; boundary="------------000801090609000506030801" Cc: alc@freebsd.org, Andriy Gapon , Jeremy Chadwick , Ivan Voras Subject: Re: Strange problem with 8-stable, VMWare vSphere 4 & AMD CPUs (unexpected shutdowns) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 17:30:06 -0000 This is a multi-part message in MIME format. --------------000801090609000506030801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Alan Cox wrote: > The next public revision guide from AMD will contain an errata (383) > that documents the bug. However, it doesn't really tell us anything > that we didn't already know. Could someone on this list please test the attached patch in an amd64 FreeBSD 8 guest running on vSphere 4 with an AMD Family 10h processor underneath? Before testing the patch, remove the manual setting of vm.pmap.pg_ps_enabled="0" from /boot/loader.conf. After booting the virtual machine, please run "sysctl vm.pmap.pg_ps_enabled" to verify that superpage promotion has been automatically disabled. Thanks, Alan --------------000801090609000506030801 Content-Type: text/plain; name="vm_guest.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="vm_guest.patch" Index: amd64/amd64/pmap.c =================================================================== --- amd64/amd64/pmap.c (revision 204175) +++ amd64/amd64/pmap.c (working copy) @@ -686,6 +686,15 @@ pmap_init(void) pv_entry_high_water = 9 * (pv_entry_max / 10); /* + * Disable large page mappings by default if the kernel is running in + * a virtual machine on an AMD Family 10h processor. This is a work- + * around for Erratum 383. + */ + if (vm_guest == VM_GUEST_VM && cpu_vendor_id == CPU_VENDOR_AMD && + CPUID_TO_FAMILY(cpu_id) == 0x10) + pg_ps_enabled = 0; + + /* * Are large page mappings enabled? */ TUNABLE_INT_FETCH("vm.pmap.pg_ps_enabled", &pg_ps_enabled); Index: kern/subr_param.c =================================================================== --- kern/subr_param.c (revision 204175) +++ kern/subr_param.c (working copy) @@ -74,10 +74,6 @@ __FBSDID("$FreeBSD$"); #define MAXFILES (maxproc * 2) #endif -/* Values of enum VM_GUEST members are used as indices in - * vm_guest_sysctl_names */ -enum VM_GUEST { VM_GUEST_NO = 0, VM_GUEST_VM, VM_GUEST_XEN }; - static int sysctl_kern_vm_guest(SYSCTL_HANDLER_ARGS); int hz; Index: sys/systm.h =================================================================== --- sys/systm.h (revision 204175) +++ sys/systm.h (working copy) @@ -45,6 +45,10 @@ #include #include /* for people using printf mainly */ +/* Values of enum VM_GUEST members are used as indices in + * vm_guest_sysctl_names */ +enum VM_GUEST { VM_GUEST_NO = 0, VM_GUEST_VM, VM_GUEST_XEN }; + extern int cold; /* nonzero if we are doing a cold boot */ extern int rebooting; /* boot() has been called. */ extern const char *panicstr; /* panic message */ @@ -63,6 +67,7 @@ extern int bootverbose; /* nonzero to print verbo extern int maxusers; /* system tune hint */ extern int ngroups_max; /* max # of supplemental groups */ +extern int vm_guest; /* Running as virtual machine guest? */ #ifdef INVARIANTS /* The option is always available */ #define KASSERT(exp,msg) do { \ --------------000801090609000506030801-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 17:35:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EED23106566B for ; Tue, 23 Feb 2010 17:35:52 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 79B598FC08 for ; Tue, 23 Feb 2010 17:35:52 +0000 (UTC) Received: by fxm23 with SMTP id 23so20920fxm.3 for ; Tue, 23 Feb 2010 09:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=BCy/3iJ1GKX7MmlXyHH2NCcGqVJqH78MKp3LC7PU94g=; b=EtUE5Z93QHF/OMyvCajuZWSNQmZlenw6qmjDe9GRuy6zdTIHRyrV/+7szrgHPqdupY 8xhbFHkX88FXzaWHmsuYVv3imODz0Rwtk+Yr78O3Zc4325kJObCJrQ5ufQYSYrT3iTEI 5P2r8izlB6UmnwBvu6x6USgW2UYwpDiXmcNo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=UzXfol0aLT/+PMiV5vgtrcq3I3V5WWqvpEj8FmDnKxHr3VZdqGQmeobA/mUfi3G/Yg FIIW1GlKociUBUmBTxiNe6xcOY13AZAy97iYgEGAnk9ANRnPwEnWDg3M5zi7TXgOvp2z u69iMpROLUk2pMzHT/GyagrhvOyFPpRB5sBpk= Received: by 10.223.17.155 with SMTP id s27mr7574913faa.13.1266946546322; Tue, 23 Feb 2010 09:35:46 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm2644037fxm.8.2010.02.23.09.35.45 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 09:35:45 -0800 (PST) Sender: Alexander Motin Message-ID: <4B8411EE.5030909@FreeBSD.org> Date: Tue, 23 Feb 2010 19:35:42 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Harald Schmalzbauer References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B83FD62.2020407@omnilan.de> <4B83FFEF.7010509@FreeBSD.org> <4B840C54.3010304@omnilan.de> In-Reply-To: <4B840C54.3010304@omnilan.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 17:35:53 -0000 Harald Schmalzbauer wrote: > Alexander Motin schrieb am 23.02.2010 17:18 (localtime): > ... >>> I guess if it's a HDD firmware issue with NCQ the hang shouldn't happen >>> when NCQ is disabled. >> >> Just for case of real I/O timeout, run full surface test with SMART. > > Unfortunately I couldn't find new firmware from Samsung, although one > drive shows version 1AG01113 while the other two have 1AG01118. But the > timeout happened at different channels, so it's not one certain disk... > > One understanding question: If the drive doesn't complete a command, > regardless if it's due to a firmware bug, a disk surface error or > whatever, is there no way for the driver to terminate the request and > take the drive offline after some time? This would be a very important > behaviour for me. It doesn't make sense building RAIDz storage when a > failing drive hangs the complete machine, even if the system partitions > are on a complete different SSD. That's what timeouts are used for. When timeout detected, driver resets device and reports error to upper layer. After receiving error, CAM reinitializes device. If device is completely dead, reinitialization will fail and device will be dropped immediately. If device is still alive, reinit succeed and CAM will retry command again. If all retries failed, error reported to the GEOM layer and then possibly to file system. I have no idea how RAIDZ behaves in such case. May be after few such errors it should drop that device out of array. Timeout is a worst possible case for any device, as it takes too much time and doesn't give any recovery information. Half-dead case is worst possible case of timeout. It is difficult to say what which way is better: drop last drive from degraded array and lost all info, or retry forever. There is probably no right answer. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 17:44:43 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C37C11065676; Tue, 23 Feb 2010 17:44:43 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 47C068FC17; Tue, 23 Feb 2010 17:44:42 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1NHifMA049975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 18:44:42 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B841409.5070603@omnilan.de> Date: Tue, 23 Feb 2010 18:44:41 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Alexander Motin References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B83FD62.2020407@omnilan.de> <4B83FFEF.7010509@FreeBSD.org> <4B840C54.3010304@omnilan.de> <4B8411EE.5030909@FreeBSD.org> In-Reply-To: <4B8411EE.5030909@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigCFB73A95EE6E0D03F848B0F4" Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 17:44:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCFB73A95EE6E0D03F848B0F4 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Motin schrieb am 23.02.2010 18:35 (localtime): =2E.. >> One understanding question: If the drive doesn't complete a command, >> regardless if it's due to a firmware bug, a disk surface error or >> whatever, is there no way for the driver to terminate the request and >> take the drive offline after some time? This would be a very important= >> behaviour for me. It doesn't make sense building RAIDz storage when a >> failing drive hangs the complete machine, even if the system partition= s >> are on a complete different SSD. >=20 > That's what timeouts are used for. When timeout detected, driver resets= > device and reports error to upper layer. After receiving error, CAM > reinitializes device. If device is completely dead, reinitialization > will fail and device will be dropped immediately. If device is still > alive, reinit succeed and CAM will retry command again. If all retries > failed, error reported to the GEOM layer and then possibly to file > system. I have no idea how RAIDZ behaves in such case. May be after few= > such errors it should drop that device out of array. >=20 > Timeout is a worst possible case for any device, as it takes too much > time and doesn't give any recovery information. Half-dead case is worst= > possible case of timeout. It is difficult to say what which way is > better: drop last drive from degraded array and lost all info, or retry= > forever. There is probably no right answer. I see. Thanks a lot for clarification. Before getting the machine onsite I did some ZFS tests like removing one = disk when cvs checkout was running. I can remember that ZFS hadn't showed the removed drive as offline, but=20 there was no hang. The pool was degraded and after reinserting and=20 rebooting I could resilver the pool. I couldn't manage to get it=20 consistent without rebooting, but I accepted that since I would have to=20 walk on site for changing the drive any way. I'll restore the default vfs.zfs.txg.timeout=3D30, so the hang can be=20 easily reproduced and see if I can 'camcontrol stop' the drive. Do you=20 think I can get usefull information with that test? Thanks, -Harry --------------enigCFB73A95EE6E0D03F848B0F4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkuEFAkACgkQLDqVQ9VXb8h4MwCfUKBtFqeqn+MqktUGTsTRqV2T H7gAn3Ki2R5zTt0Zv65fn0yrpmaDqQ9F =2cn/ -----END PGP SIGNATURE----- --------------enigCFB73A95EE6E0D03F848B0F4-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 18:14:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 849BD1065679 for ; Tue, 23 Feb 2010 18:14:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4938FC0C for ; Tue, 23 Feb 2010 18:14:57 +0000 (UTC) Received: by fxm23 with SMTP id 23so64482fxm.3 for ; Tue, 23 Feb 2010 10:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Pyfb+PxEESI2yXTzNUe+X41oQCr0YJXEqVnphsQON5s=; b=ih4jarrgJffVf40tcvV0o01zkywF8kHN+3JRZw7mUgQ97n0Ilyp/yBtiP2ffOCXbXu pyvVvLxR1BGBvd9X+PLMI7DV7RWjx2J4j1PyIWXyYF59zstUkeX3ET5ztt1hZgFjLvBE +kKETEkYD7tUiewvyjctgBHsUwt4PIrEnIoRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=C1iI+QxW/ARjdqnMNSoYKTELavFWt0cyNuWkTrjnW8mu5lVhCPVu3B8NlgBb/clByu 6oGEaofaqGJVS9qZk0KSihL13XkngdhoVgKxriVl8MYxVYyKlf6k1QsSGyva34kcjso1 lRBB5ZPvcWqbIKWU8PwY3ZCBCq40rE9QnfjNk= Received: by 10.223.7.11 with SMTP id b11mr1509550fab.95.1266948893171; Tue, 23 Feb 2010 10:14:53 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2645833fxm.3.2010.02.23.10.14.51 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 10:14:52 -0800 (PST) Sender: Alexander Motin Message-ID: <4B841B19.3020106@FreeBSD.org> Date: Tue, 23 Feb 2010 20:14:49 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Harald Schmalzbauer References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B83FD62.2020407@omnilan.de> <4B83FFEF.7010509@FreeBSD.org> <4B840C54.3010304@omnilan.de> <4B8411EE.5030909@FreeBSD.org> <4B841409.5070603@omnilan.de> In-Reply-To: <4B841409.5070603@omnilan.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 18:14:58 -0000 Harald Schmalzbauer wrote: > Alexander Motin schrieb am 23.02.2010 18:35 (localtime): > ... >>> One understanding question: If the drive doesn't complete a command, >>> regardless if it's due to a firmware bug, a disk surface error or >>> whatever, is there no way for the driver to terminate the request and >>> take the drive offline after some time? This would be a very important >>> behaviour for me. It doesn't make sense building RAIDz storage when a >>> failing drive hangs the complete machine, even if the system partitions >>> are on a complete different SSD. >> >> That's what timeouts are used for. When timeout detected, driver resets >> device and reports error to upper layer. After receiving error, CAM >> reinitializes device. If device is completely dead, reinitialization >> will fail and device will be dropped immediately. If device is still >> alive, reinit succeed and CAM will retry command again. If all retries >> failed, error reported to the GEOM layer and then possibly to file >> system. I have no idea how RAIDZ behaves in such case. May be after few >> such errors it should drop that device out of array. >> >> Timeout is a worst possible case for any device, as it takes too much >> time and doesn't give any recovery information. Half-dead case is worst >> possible case of timeout. It is difficult to say what which way is >> better: drop last drive from degraded array and lost all info, or retry >> forever. There is probably no right answer. > > I see. Thanks a lot for clarification. > Before getting the machine onsite I did some ZFS tests like removing one > disk when cvs checkout was running. As soon as ahci driver supports hot plug, removing device is not completely correct test from driver perspective. Driver detects device remove on interrupt from controller, and CAM drops it immediately without waiting for timeouts. If you want a bit more correct test - enable power management on respective ahci port. Enabled power management disables hot-plug mechanisms, so there are more chances to get command timeout. But when CAM will try to reinit removed device - it will destroy it immediately. > I can remember that ZFS hadn't showed the removed drive as offline, but > there was no hang. The pool was degraded and after reinserting and > rebooting I could resilver the pool. I couldn't manage to get it > consistent without rebooting, but I accepted that since I would have to > walk on site for changing the drive any way. That's question to ZFS. CAM and GEOM destroying/creating device automatically and fast enough. > I'll restore the default vfs.zfs.txg.timeout=30, so the hang can be > easily reproduced and see if I can 'camcontrol stop' the drive. Do you > think I can get usefull information with that test? Stop won't work for ATA devices. It is SCSI command. And all it does - stops spindle. It won't destroy device. AFAIK there is no method in CAM now to manually disable some device on-flight. If some device half-died, the best way is to mechanically disconnect it. It will help CAM to recover as fast as possible. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 19:10:52 2010 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E69011065670; Tue, 23 Feb 2010 19:10:52 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 4E8198FC08; Tue, 23 Feb 2010 19:10:51 +0000 (UTC) Received: from [172.21.1.29] (akima-win.flintsbach.schmalzbauer.de [172.21.1.29]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1NJAlu9051002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2010 20:10:51 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) X-Authentication-Warning: smtp.dmz.omnilan.net: Host akima-win.flintsbach.schmalzbauer.de [172.21.1.29] claimed to be [172.21.1.29] Message-ID: <4B842830.7030004@omnilan.de> Date: Tue, 23 Feb 2010 20:10:40 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: Alexander Motin References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B83FD62.2020407@omnilan.de> <4B83FFEF.7010509@FreeBSD.org> <4B840C54.3010304@omnilan.de> <4B8411EE.5030909@FreeBSD.org> <4B841409.5070603@omnilan.de> <4B841B19.3020106@FreeBSD.org> In-Reply-To: <4B841B19.3020106@FreeBSD.org> X-Enigmail-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3E52EEC1C7E6E2147CFD3E5F" Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 19:10:53 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3E52EEC1C7E6E2147CFD3E5F Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Am 23.02.2010 19:14, schrieb Alexander Motin: =2E.. >> I can remember that ZFS hadn't showed the removed drive as offline, bu= t >> there was no hang. The pool was degraded and after reinserting and >> rebooting I could resilver the pool. I couldn't manage to get it >> consistent without rebooting, but I accepted that since I would have t= o >> walk on site for changing the drive any way. >=20 > That's question to ZFS. CAM and GEOM destroying/creating device > automatically and fast enough. >=20 >> I'll restore the default vfs.zfs.txg.timeout=3D30, so the hang can be >> easily reproduced and see if I can 'camcontrol stop' the drive. Do you= >> think I can get usefull information with that test? >=20 > Stop won't work for ATA devices. It is SCSI command. And all it does - > stops spindle. It won't destroy device. AFAIK there is no method in CAM= > now to manually disable some device on-flight. If some device half-died= , > the best way is to mechanically disconnect it. It will help CAM to > recover as fast as possible. Thank you very much again. I wasn't aware of that. I thought 'camcontrol stop' is similar to 'atacontrol detach'. It's important for me te be able to manage my systems rmotely, so I need to stay with the old ataahci driver. The detach feature has been life-saver several times for me, especially with IDE disks. I often had drives going nuts and detach/attach with gmirror/graid3 rebuild always solved the problem. I expect to see also SATA drive oddities (maybe like now) when they replace the old ide servers. One last quick question: I read about a new feature adopting old ata to cam. Do you have a link to useful information? Or will a mailman search list all useful info. Thanks, -Harry --------------enig3E52EEC1C7E6E2147CFD3E5F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuEKDkACgkQLDqVQ9VXb8g0zQCfedeiuAHTVcSI+yCrfkD6dQF1 bUAAoLAOPf+iCxgn7vyrUU+SD7ArlWpu =6YyT -----END PGP SIGNATURE----- --------------enig3E52EEC1C7E6E2147CFD3E5F-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 19:14:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7A3E106568D; Tue, 23 Feb 2010 19:14:04 +0000 (UTC) (envelope-from geo.liaskos@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 49F0E8FC1D; Tue, 23 Feb 2010 19:14:03 +0000 (UTC) Received: by fxm23 with SMTP id 23so128736fxm.3 for ; Tue, 23 Feb 2010 11:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LHvO6pgeUVDU+ZEgIgYIQdkbcZT18xHztibKnaNPOfY=; b=HZ8kCvFYvjLmnckiyTsx9aK/4ojspQVuR64mTg1iW/S1ugy6sD8dQYvzeiXJQDG6jE nwEBERp/YxYL4C+0f0StUP2M9qsWNgCuF7QH6HWDKoepo0zLxNq3BOHCUIvLUwIOA4UP uf6keCn+tquay1S5MoS8AE8IRstdUKIuUlbKQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cufgtsYbseQjm4HKjyhdJhkaTh3UEEePoD60EaRuXfR4BGJOju0iU3aHxHtRSylFaa dSwSUjt7r86BPxXEPH+E0YmDGi8iGGBlHEM6LVohrg9Bn5Feu+B1/HBQMSonnTeSeUl0 kj6ky8dbS5UOgchYWEIBZxJea8CUIhVDAkTtg= MIME-Version: 1.0 Received: by 10.239.188.129 with SMTP id p1mr1741229hbh.190.1266952437007; Tue, 23 Feb 2010 11:13:57 -0800 (PST) In-Reply-To: <4B83F93A.4030805@FreeBSD.org> References: <1266934981.00222684.1266922202@10.7.7.3> <1266938581.00222692.1266925802@10.7.7.3> <4B83F93A.4030805@FreeBSD.org> Date: Tue, 23 Feb 2010 19:13:55 +0000 Message-ID: From: George Liaskos To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-stable@freebsd.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 19:14:04 -0000 I booted my old kernel (was from Feb 13) and i had the same issue. The timeout occurs when i try to burn CDs with the k3b application, after some queries i found this thread: http://www.pubbs.net/kde/200910/40852/ I have no problem burning CDs with cdrecord so i guess this must be an error at the application level as described. This is the verbose message i get. ahcich1: Timeout on slot 2 ahcich1: is 00000000 cs 0000000c ss 00000000 rs 0000000c tfd d0 serr 00000000 ahcich1: AHCI reset... ahcich1: hardware reset ... ahcich1: SATA connect time=0ms status=00000113 ahcich1: ready wait time=25ms ahcich1: AHCI reset done: device found If this case is of any interest for further debugging let me know. Regards and sorry for the noise. On Tue, Feb 23, 2010 at 3:50 PM, Alexander Motin wrote: > George Liaskos wrote: >> I am having the same issue since Feb 20 which was my last update. > > Which version was before? > >> ahcich1: Timeout on slot 3 >> ahcich1: is 00000000 cs 00000018 ss 00000000 rs 00000018 tfd d0 serr 00000000 >> ahcich1: Timeout on slot 5 >> ahcich1: is 00000000 cs 00000060 ss 00000000 rs 00000060 tfd d0 serr 00000000 >> ahcich1: Timeout on slot 7 >> ahcich1: is 00000000 cs 00000180 ss 00000000 rs 00000180 tfd d0 serr 00000000 >> ahcich1: Timeout on slot 9 >> ahcich1: is 00000000 cs 00000600 ss 00000000 rs 00000600 tfd d0 serr 00000000 > > Situation looks alike, except it is CD drive and so without NCQ. I am > still don't see bugs from driver side here. Do you see delays before > timeout messages? > > You may try to enable verbose kernel messages to get some more info. > >>> dmesg | grep ahci >> ahci0: port >> 0x1c40-0x1c47,0x1834-0x1837,0x1838-0x183f,0x1830-0x1833,0x1c20-0x1c3f >> mem 0xfc226000-0xfc2267ff irq 16 at device 31.2 on pci0 >> ahci0: [ITHREAD] >> ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier not supported >> ahcich0: at channel 0 on ahci0 >> ahcich0: [ITHREAD] >> ahcich1: at channel 1 on ahci0 >> ahcich1: [ITHREAD] >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> cd0 at ahcich1 bus 0 scbus1 target 0 lun 0 > > Show this also with verbose. From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 19:27:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54AD6106566C for ; Tue, 23 Feb 2010 19:27:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id D17B08FC0C for ; Tue, 23 Feb 2010 19:27:25 +0000 (UTC) Received: by fxm23 with SMTP id 23so143357fxm.3 for ; Tue, 23 Feb 2010 11:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=4GSZHlFvtX10mZULhBDOXI2mS7FsG45+A4um08qn5Og=; b=EmCUZnskG4khGiZjaVUWzSMvMY6kQD2GeoUCxR5Lt6lcIy+REsPIAk6dMycOXhiBfv 2r8B87UeOVtDD76opFq4VfYcYU5CF8306BrXmrjCvqswpSa4h1UUedkrsMjwIOZzkwjz KJutfS4kcTyEqfwBAqIyCqwqHk2xijxJUpgvc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=tPI0C1CI0hF3uNMhiXPXt4Rr4oIf7RVWAQ8rtN7eS/jXHdZDcTZfie5eT5wr/QMY3+ VZA2cRfuBxYpUelpGKH0vx41NiO/eXnh1Uvi6caYq94+o3SyMrmHTfkkycqmL6dkEM/C WVjbzUtmNjT8PWF8MMdKFPrAThl0xJJwG6dVg= Received: by 10.223.100.129 with SMTP id y1mr9171332fan.15.1266953239241; Tue, 23 Feb 2010 11:27:19 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm2712007fxm.15.2010.02.23.11.27.18 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 11:27:18 -0800 (PST) Sender: Alexander Motin Message-ID: <4B842C14.4030306@FreeBSD.org> Date: Tue, 23 Feb 2010 21:27:16 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Harald Schmalzbauer References: <1266934981.00222684.1266922202@10.7.7.3> <4B83EFD4.8050403@FreeBSD.org> <4B83FD62.2020407@omnilan.de> <4B83FFEF.7010509@FreeBSD.org> <4B840C54.3010304@omnilan.de> <4B8411EE.5030909@FreeBSD.org> <4B841409.5070603@omnilan.de> <4B841B19.3020106@FreeBSD.org> <4B842830.7030004@omnilan.de> In-Reply-To: <4B842830.7030004@omnilan.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 19:27:26 -0000 Harald Schmalzbauer wrote: > Am 23.02.2010 19:14, schrieb Alexander Motin: >>> I'll restore the default vfs.zfs.txg.timeout=30, so the hang can be >>> easily reproduced and see if I can 'camcontrol stop' the drive. Do you >>> think I can get usefull information with that test? >> Stop won't work for ATA devices. It is SCSI command. And all it does - >> stops spindle. It won't destroy device. AFAIK there is no method in CAM >> now to manually disable some device on-flight. If some device half-died, >> the best way is to mechanically disconnect it. It will help CAM to >> recover as fast as possible. > > Thank you very much again. I wasn't aware of that. I thought 'camcontrol > stop' is similar to 'atacontrol detach'. > It's important for me te be able to manage my systems rmotely, so I need > to stay with the old ataahci driver. The detach feature has been > life-saver several times for me, especially with IDE disks. I often had > drives going nuts and detach/attach with gmirror/graid3 rebuild always > solved the problem. I expect to see also SATA drive oddities (maybe like > now) when they replace the old ide servers. gmirror and graid3 allow you to remove failed component from array, add new or resync without detaching devices from the system. I don't see problem there, sufficient to migrate back. > One last quick question: I read about a new feature adopting old ata to > cam. Do you have a link to useful information? Or will a mailman search > list all useful info. It's really simple. Add `options ATA_CAM` to the kernel and you are there. Everything the same as with loading ahci(4) (adX -> adaX, acdX -> cdX, ...), just without NCQ. Then you could remove all ata(4) peripheral device drivers from the kernel, as they become useless. atacontrol is also deprecated in this mode. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 19:35:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8C311065679 for ; Tue, 23 Feb 2010 19:35:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 7990E8FC1D for ; Tue, 23 Feb 2010 19:35:36 +0000 (UTC) Received: by mail-fx0-f223.google.com with SMTP id 23so151721fxm.3 for ; Tue, 23 Feb 2010 11:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=MgSal+LLmOUM7ZYbu3dod2Xzs4ds2hmZS50W/JFEiaU=; b=DqTbUS6mFYCMDiWDSCDnFYNgDdjCeB8+97x284evsQWukmq6CObPFUnAsIO54iHir7 W36kpeVnFl79uj1ZQ64BuHejS89I+uJoMOIf/LOD4GFCvBUFLM5upaXCFDgCmxWj3a91 0LTHLutJC1I3eLEqx3DYnkdD1ruFX3FATbu+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=sFUF2rmgnDn1jOtkI4bydnBVP7SpygcIxPCFN0CLVAc8laAZpTpDF2ZTbYGGfEo58a Jtz7WZUDvZIP5r4ph+0ipNEoyzI+TImn5/bKIrNgKsuhrlonL/Mv7kshBc0S/yL+dVa1 6tQURSqxWsD8rEptPnCePng+rpr2+TdMITRWc= Received: by 10.223.1.5 with SMTP id 5mr9771175fad.87.1266953736168; Tue, 23 Feb 2010 11:35:36 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm2720090fxm.4.2010.02.23.11.35.35 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 11:35:35 -0800 (PST) Sender: Alexander Motin Message-ID: <4B842E05.1060700@FreeBSD.org> Date: Tue, 23 Feb 2010 21:35:33 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Daniel Braniss References: <1266952985.00222809.1266942602@10.7.7.3> In-Reply-To: <1266952985.00222809.1266942602@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ahcich3: Timeout on slot 0 ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 19:35:37 -0000 Daniel Braniss wrote: > with latest 8-stable, I can't boot since it's stuck with: > the only wierd thing I see, is the > Trying to mount root from nfs: > which does not happen in the failing kernel. Could you show full verbose boot messages? -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 21:13:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF5011065672 for ; Tue, 23 Feb 2010 21:13:11 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5B2E48FC1B for ; Tue, 23 Feb 2010 21:13:10 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.4/8.14.4) with ESMTP id o1NLD7oW076274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 24 Feb 2010 08:13:07 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1266959587; bh=P5mF0Ey53DKfzr3baN0EYemKqsvYgna+UP8H8IHoCuo=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=rdl/vsU7lZxEsItzmI8DQOghACyEALTzIGRhVkwXgVW87CjJ5NBZG0V405Ld1OpQR F9vlAwZ6y44EXza5XNMHmPkL5GFWX9Jt61oMeMCpe89iFZOc09GrHPLV3P7JEinrb1 E0KwMXA/3hJWs7srwF5Cus/7Jy238qBIBcXJvivI= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id o1NLD6bH012858 for ; Wed, 24 Feb 2010 08:13:06 +1100 (AEDT) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id o1NLD6dl012857 for freebsd-stable@freebsd.org; Wed, 24 Feb 2010 08:13:06 +1100 (AEDT) (envelope-from john) Date: Wed, 24 Feb 2010 08:13:06 +1100 From: John Marshall To: freebsd-stable@freebsd.org Message-ID: <20100223211306.GI2303@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org References: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> <20100223093616.GO50403@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9Ek0hoCL9XbhcSqy" Content-Disposition: inline In-Reply-To: <20100223093616.GO50403@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: sleep(3) sometimes too sleepy on FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 21:13:11 -0000 --9Ek0hoCL9XbhcSqy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 23 Feb 2010, 11:36 +0200, Kostik Belousov wrote: > On Tue, Feb 23, 2010 at 12:35:22PM +1100, John Marshall wrote: > > Environment: sendmail 8.14.4 on FreeBSD 8.0-RELEASE-p2 > >=20 > > Since upgrading a few local servers to FreeBSD 8.0-RELEASE (and > > subsequently 8.0-RELEASE-p2), I have been seeing VERY intermittent > > problems with sendmail persistent queue runners. One or more queue > > runners will fail to wake up (having been told to sleep for either 1 or > > 5 seconds) and mail accumulates in their queue group queues. > >=20 > > I have only seen this about 4 times but at least once on each of the > > three 8.0 servers. I've been seeing something like one occurrence per > > fortnight overall. The first few times I re-started sendmail. On > > Saturday I spent longer looking at it. >=20 > I think the best way to collect the data would be ktrace the queue runner= s, > preferrably starting the ktrace before they are stuck. OK. I've caught one of them (different server from Saturday). PID TT STAT TIME COMMAND 48501 ?? Ss 0:14.77 sendmail: accepting connections (sendmail) 48502 ?? S 1:00.24 sendmail: running queue: /var/spool/mqueue/qd1/df= (sendmail) 48503 ?? S 0:38.11 sendmail: running queue: /var/spool/mqueue/mby/df= (sendmail) 48504 ?? I 0:27.34 sendmail: running queue: /var/spool/mqueue/oz/df = (sendmail) 48505 ?? S 0:37.59 sendmail: running queue: /var/spool/mqueue/rw2/df= (sendmail) 48506 ?? S 0:34.93 sendmail: running queue: /var/spool/mqueue/hold/d= f (sendmail) My ktrace file was created with 'ktrace -g 48501'. I have the result of 'kdump -R -p 48504' available at: The affected queue group was empty. I have redirected messages for that domain to a different queue group so that I can leave that queue runner stuck. --=20 John Marshall --9Ek0hoCL9XbhcSqy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuEROIACgkQw/tAaKKahKKSWgCcDNneP07yDQBrWMjQENXgajSw 5O0AnjwZvc8wqLZ4MMKqD6dLZVpPqRQ4 =8gY4 -----END PGP SIGNATURE----- --9Ek0hoCL9XbhcSqy-- From owner-freebsd-stable@FreeBSD.ORG Tue Feb 23 22:03:46 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BFB61065692; Tue, 23 Feb 2010 22:03:46 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 981798FC1E; Tue, 23 Feb 2010 22:03:45 +0000 (UTC) Received: by bwz8 with SMTP id 8so3217702bwz.3 for ; Tue, 23 Feb 2010 14:03:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.33.147 with SMTP id h19mr4920025bkd.210.1266962615582; Tue, 23 Feb 2010 14:03:35 -0800 (PST) X-Originating-IP: [213.146.115.42] In-Reply-To: References: <4B83B0A2.1030008@omnilan.de> Date: Tue, 23 Feb 2010 23:03:35 +0100 Message-ID: From: "C. P. Ghost" To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Alexander Motin Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2010 22:03:46 -0000 On Tue, Feb 23, 2010 at 12:15 PM, George Liaskos wrote: > I am having the same issue since Feb 20 which was my last update. > > ahcich1: Timeout on slot 3 > ahcich1: is 00000000 cs 00000018 ss 00000000 rs 00000018 tfd d0 serr 00000000 > ahcich1: Timeout on slot 5 > ahcich1: is 00000000 cs 00000060 ss 00000000 rs 00000060 tfd d0 serr 00000000 > ahcich1: Timeout on slot 7 > ahcich1: is 00000000 cs 00000180 ss 00000000 rs 00000180 tfd d0 serr 00000000 > ahcich1: Timeout on slot 9 > ahcich1: is 00000000 cs 00000600 ss 00000000 rs 00000600 tfd d0 serr 00000000 Just for the record, I have similar AHCI problems: http://docs.freebsd.org/cgi/mid.cgi?d74eb87c1002201912jaa4b519s494f5508c046e66a http://docs.freebsd.org/cgi/mid.cgi?d74eb87c1002211150iec5e7c0pa36d297e0852aaee FreeBSD phenom.cordula.ws 8.0-STABLE FreeBSD 8.0-STABLE #0 r200471: Sun Dec 13 16:07:46 CET 2009 root@phenom.cordula.ws:/usr/obj/usr/src/sys/GENERIC amd64 Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 00:57:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66E261065673 for ; Wed, 24 Feb 2010 00:57:24 +0000 (UTC) (envelope-from pgollucci@p6m7g8.com) Received: from exhub015-2.exch015.msoutlookonline.net (exhub015-2.exch015.msoutlookonline.net [207.5.72.94]) by mx1.freebsd.org (Postfix) with ESMTP id 549BF8FC12 for ; Wed, 24 Feb 2010 00:57:24 +0000 (UTC) Received: from philip.hq.rws (174.79.184.239) by smtpx15.msoutlookonline.net (207.5.72.103) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 23 Feb 2010 16:57:23 -0800 Message-ID: <4B847972.7060702@p6m7g8.com> Date: Wed, 24 Feb 2010 00:57:22 +0000 From: "Philip M. Gollucci" Organization: P6M7G8 Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.7) Gecko/20100220 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: ASF Infra Private Subject: dell 2950 + mpt + stable/8 boot hangs X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 00:57:24 -0000 Hi All, [please keep the infra-private list in the replies] We've recently attached a external JBOD, Storform D53J, to a dell pe 2950 via PCI-e cards (using the mpt driver). This works fine on stable/7@r197719 [1] despite being before some mfc's of mptutil work from scottl. When booting stable/8@204185 the boot hangs [2] Whats more, is if we disconnect the array physically, we're able to boot [3] the stable/8 kernel and even use the array from a chroot'ed install of the stable/8 userland [sudo camcontrol rescan all, and some zpool stuff] We've already seen this suggestion on google /boot/loader.conf: hw.pci.mcfg=0 which didn't help. Additionally, the following pr might be relevant but we haven't tried it yet. http://people.freebsd.org/~linimon/studies/prs/prs_for_tag_regression.html http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/142263 disabling acpi Thoughts ? [1] - http://people.apache.org/~pgollucci/ERIS/dmesg.boot.7 [2] - http://people.apache.org/~pgollucci/ERIS/eris.bmp [3] - http://people.apache.org/~pgollucci/ERIS/dmesg.boot.8 ------------------------------------------------------------------------ 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer, FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 01:47:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5572E106564A for ; Wed, 24 Feb 2010 01:47:26 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 4AC348FC26 for ; Wed, 24 Feb 2010 01:47:25 +0000 (UTC) Received: (qmail invoked by alias); 24 Feb 2010 01:47:23 -0000 Received: from e181215196.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [85.181.215.196] by mail.gmx.com (mp-eu005) with SMTP; 24 Feb 2010 02:47:23 +0100 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX1+AIxIkRuOA41m1NRhpyMlA7RWchpP+9nbC4GwbMw v1pYzsrhZirwPt Received: by myhost.mydomain.de (Postfix, from userid 1001) id 92DCE9089; Wed, 24 Feb 2010 02:47:22 +0100 (CET) From: Christof Schulze To: freebsd-stable@freebsd.org Date: Wed, 24 Feb 2010 02:47:16 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.5; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1948443.5yg1p2rgaz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201002240247.22141.christof.schulze@gmx.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.46000000000000002 Subject: intel h55 chipset + 8_RELENG X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 01:47:26 -0000 --nextPart1948443.5yg1p2rgaz Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello world, I also have a board with the H55 chipset (see below for dmesg, uname -a and= =20 pciconf -lv). The specific board is an Intel DH55HC The network interface card - I tried with em - will not attach to a driver = and=20 the intel driver for Xorg does not recognize the graphics chip of the core = i5. All in all it is rather unpleasant. What might be a different problem is th= at=20 the driver for a 3com3c905B and for a Realtek RTL8139 will not attach eithe= r. I am not sure what information is missing but I sure would love to use the= =20 network card in there. Video is yet a different story. Regards Christof =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D uname -a: =46reeBSD eri 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Feb 24 08:33:43 CET 201= 0 =20 root@eri:/usr/obj/usr/src/sys/GENERIC amd64 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D dmesg: Copyright (c) 1992-2010 The FreeBSD Project. =20 Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 = =20 The Regents of the University of California. All rights reserved. = =20 =46reeBSD is a registered trademark of The FreeBSD Foundation. =20 =46reeBSD 8.0-STABLE #0: Wed Feb 24 08:33:43 CET 2010 =20 root@eri:/usr/obj/usr/src/sys/GENERIC amd64 =20 Timecounter "i8254" frequency 1193182 Hz quality 0 =20 CPU: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz (3325.02-MHz K8-class= =20 CPU) =20 Origin =3D "GenuineIntel" Id =3D 0x20652 Stepping =3D 2 =20 Features=3D0xbfebfbff = =20 Features2=3D0x298e3ff,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,C= X16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,> =20 AMD Features=3D0x28100800 =20 AMD Features2=3D0x1 =20 TSC: P-state invariant =20 real memory =3D 8589934592 (8192 MB) =20 avail memory =3D 8109768704 (7734 MB) =20 ACPI APIC Table: =20 =46reeBSD/SMP: Multiprocessor System Detected: 4 CPUs =20 =46reeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads =20 cpu0 (BSP): APIC ID: 0 =20 cpu1 (AP): APIC ID: 1 =20 cpu2 (AP): APIC ID: 4 =20 cpu3 (AP): APIC ID: 5 =20 ACPI Warning: 32/64X FACS address mismatch in FADT - CB626E40/ =20 0CB626D40, using 32 (20100121/tbfadt-586) =20 ioapic0 irqs 0-23 on motherboard =20 kbd1 at kbdmux0 =20 acpi0: on motherboard =20 acpi0: [ITHREAD] =20 acpi0: Power Button (fixed) =20 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 =20 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 =20 Timecounter "HPET" frequency 14318180 Hz quality 900 =20 pcib0: port 0xcf8-0xcff on acpi0 =20 pci0: on pcib0 =20 vgapci0: port 0xf100-0xf107 mem=20 0xfe000000-0xfe3fffff,0xd0000000-0xdfffffff irq 16 at device 2.0 on pci0 = =20 pci0: at device 22.0 (no driver attached) =20 atapci0: port=20 0xf0f0-0xf0f7,0xf0e0-0xf0e3,0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0bf irq 1= 8=20 at device 22.2 on pci0 atapci0: [ITHREAD] =20 ata2: on atapci0 =20 ata2: [ITHREAD] =20 ata3: on atapci0 =20 ata3: [ITHREAD] =20 pci0: at device 22.3 (no driver attached) =20 pci0: at device 25.0 (no driver attached) =20 ehci0: mem 0xfe527000-0xfe5273ff irq 1= 6=20 at device 26.0 on pci0 =20 ehci0: [ITHREAD] =20 usbus0: EHCI version 1.0 =20 usbus0: on ehci0 =20 hdac0: mem 0xfe520000-0xfe523f= ff=20 irq 22 at device 27.0 on pci0 =20 hdac0: HDA Driver Revision: 20100122_0141 =20 hdac0: [ITHREAD] =20 pcib1: irq 17 at device 28.0 on pci0 =20 pci1: on pcib1 =20 pcib2: irq 17 at device 28.4 on pci0 =20 pci2: on pcib2 =20 ehci1: mem 0xfe526000-0xfe5263ff irq 2= 3=20 at device 29.0 on pci0 =20 ehci1: [ITHREAD] =20 usbus1: EHCI version 1.0 =20 usbus1: on ehci1 =20 pcib3: at device 30.0 on pci0 =20 pci3: on pcib3 =20 ahc0: port 0xe000-0xe0ff mem 0xfe408000-0xfe408= fff=20 irq 18 at device 2.0 on pci3 =20 ahc0: [ITHREAD] =20 aic7870: Single Channel A, SCSI Id=3D7, 16/253 SCBs =20 isab0: at device 31.0 on pci0 =20 isa0: on isab0 =20 ahci0: port=20 0xf090-0xf097,0xf080-0xf083,0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f mem=20 0xfe525000-0xfe5257ff irq 19 at device 31.2 on pci0 = =20 ahci0: [ITHREAD] =20 ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported=20 ahcich0: at channel 0 on ahci0 =20 ahcich0: [ITHREAD] =20 ahcich1: at channel 1 on ahci0 =20 ahcich1: [ITHREAD] =20 ahcich2: at channel 2 on ahci0 =20 ahcich2: [ITHREAD] =20 ahcich3: at channel 3 on ahci0 =20 ahcich3: [ITHREAD] =20 ahcich4: at channel 4 on ahci0 =20 ahcich4: [ITHREAD] =20 ahcich5: at channel 5 on ahci0 =20 ahcich5: [ITHREAD] =20 pci0: at device 31.3 (no driver attached) =20 acpi_button0: on acpi0 =20 atrtc0: port 0x70-0x71 irq 8 on acpi0 =20 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 =20 kbd0 at atkbd0 =20 atkbd0: [GIANT-LOCKED] =20 atkbd0: [ITHREAD] =20 cpu0: on acpi0 =20 est0: on cpu0 =20 p4tcc0: on cpu0 =20 cpu1: on acpi0 =20 est1: on cpu1 =20 p4tcc1: on cpu1 =20 cpu2: on acpi0 =20 est2: on cpu2 =20 p4tcc2: on cpu2 =20 cpu3: on acpi0 =20 est3: on cpu3 =20 p4tcc3: on cpu3 =20 orm0: at iomem 0xcd000-0xcf7ff on isa0 =20 sc0: at flags 0x100 on isa0 =20 sc0: VGA <16 virtual consoles, flags=3D0x300> =20 vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 = =20 ppc0: cannot reserve I/O port range =20 ZFS filesystem version 3 =20 ZFS storage pool version 14 =20 Timecounters tick every 10.000 msec =20 hdac0: HDA Codec #0: Realtek ALC888 =20 hdac0: HDA Codec #3: Intel (Unknown) =20 ahc0: Someone reset channel A =20 pcm0: at cad 0 nid 1 on hdac0 =20 pcm1: at cad 0 nid 1 on hdac0 =20 pcm2: at cad 0 nid 1 on hdac0 =20 pcm3: at cad 0 nid 1 on hdac0 =20 pcm4: at cad 3 nid 1 on hdac0 = =20 usbus0: 480Mbps High Speed USB v2.0 =20 usbus1: 480Mbps High Speed USB v2.0 =20 ugen0.1: at usbus0 =20 uhub0: on usbus0 = =20 ugen1.1: at usbus1 =20 uhub1: on usbus1 = =20 uhub0: 3 ports with 3 removable, self powered =20 uhub1: 3 ports with 3 removable, self powered =20 ugen0.2: at usbus0 =20 uhub2: on= =20 usbus0 =20 ugen1.2: at usbus1 =20 uhub3: on= =20 usbus1 =20 uhub2: 6 ports with 6 removable, self powered =20 uhub3: 6 ports with 6 removable, self powered =20 ugen1.3: at usbus1 =20 ums0: on usbus1 = =20 ums0: 16 buttons and [XYZ] coordinates ID=3D0 =20 uhid0: on usbus1= =20 ugen1.4: at usbus1 =20 uaudio0: o= n=20 usbus1 =20 uaudio0: No playback! =20 uaudio0: Record: 16000 Hz, 1 ch, 16-bit S-LE PCM format =20 uaudio0: No midi sequencer =20 pcm5: on uaudio0 =20 ada0 at ahcich0 bus 0 scbus1 target 0 lun 0 =20 ada0: ATA-6 SATA 1.x device =20 ada0: 150.000MB/s transfers (SATA 1.x, UDMA5, PIO 8192bytes) =20 ada0: 78533MB (160836480 512 byte sectors: 16H 63S/T 16383C) =20 ada1 at ahcich1 bus 0 scbus2 target 0 lun 0 =20 ada1: ATA-7 SATA 2.x device =20 ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) =20 ada1: Command Queueing enabled =20 ada1: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) =20 ada2 at ahcich2 bus 0 scbus3 target 0 lun 0 =20 ada2: ATA-7 SATA 2.x device =20 ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) =20 ada2: Command Queueing enabled =20 ada2: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) =20 ada3 at ahcich3 bus 0 scbus4 target 0 lun 0 =20 ada3: ATA-7 SATA 2.x device =20 ada3: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada3: Command Queueing enabled ada3: 238475MB (488397168 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Trying to mount root from zfs:zroot WARNING: TMPFS is considered to be a highly experimental feature in FreeBSD. ugen0.3: at usbus0 umass0: on= =20 usbus0 umass0: SCSI over Bulk-Only; quirks =3D 0x0000 umass0:7:0:-1: Attached to scbus7 da0 at umass-sim0 bus 0 scbus7 target 0 lun 0 da0: < Spaceloop 4GB 5.00> Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 4040MB (8274944 512 byte sectors: 255H 63S/T 515C) =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 pciconf -lv hostb0@pci0:0:0:0: class=3D0x060000 card=3D0x00378086 chip=3D0x0040808= 6=20 rev=3D0x12 hdr=3D0x00 =20 vendor =3D 'Intel Corporation' =20 class =3D bridge =20 subclass =3D HOST-PCI =20 vgapci0@pci0:0:2:0: class=3D0x030000 card=3D0x00378086 chip=3D0x0042808= 6=20 rev=3D0x12 hdr=3D0x00 =20 vendor =3D 'Intel Corporation' =20 class =3D display =20 subclass =3D VGA =20 none0@pci0:0:22:0: class=3D0x078000 card=3D0x00378086 chip=3D0x3b64808= 6=20 rev=3D0x06 hdr=3D0x00 =20 vendor =3D 'Intel Corporation' =20 class =3D simple comms =20 atapci0@pci0:0:22:2: class=3D0x010185 card=3D0x00378086 chip=3D0x3b66808= 6=20 rev=3D0x06 hdr=3D0x00 =20 vendor =3D 'Intel Corporation' =20 class =3D mass storage =20 subclass =3D ATA =20 none1@pci0:0:22:3: class=3D0x070002 card=3D0x00378086 chip=3D0x3b67808= 6=20 rev=3D0x06 hdr=3D0x00 =20 vendor =3D 'Intel Corporation' =20 class =3D simple comms =20 subclass =3D UART =20 none2@pci0:0:25:0: class=3D0x020000 card=3D0x00378086 chip=3D0x10f0808= 6=20 rev=3D0x06 hdr=3D0x00 =20 vendor =3D 'Intel Corporation' =20 class =3D network =20 subclass =3D ethernet =20 ehci0@pci0:0:26:0: class=3D0x0c0320 card=3D0x00378086 chip=3D0x3b3c808= 6=20 rev=3D0x06 hdr=3D0x00 =20 vendor =3D 'Intel Corporation' =20 class =3D serial bus =20 subclass =3D USB =20 hdac0@pci0:0:27:0: class=3D0x040300 card=3D0x00378086 chip=3D0x3b56808= 6=20 rev=3D0x06 hdr=3D0x00 =20 vendor =3D 'Intel Corporation' =20 class =3D multimedia =20 subclass =3D HDA =20 pcib1@pci0:0:28:0: class=3D0x060400 card=3D0x00378086 chip=3D0x3b42808= 6=20 rev=3D0x06 hdr=3D0x01 =20 vendor =3D 'Intel Corporation' =20 class =3D bridge =20 subclass =3D PCI-PCI =20 pcib2@pci0:0:28:4: class=3D0x060400 card=3D0x00378086 chip=3D0x3b4a808= 6=20 rev=3D0x06 hdr=3D0x01 =20 vendor =3D 'Intel Corporation' =20 class =3D bridge =20 subclass =3D PCI-PCI =20 ehci1@pci0:0:29:0: class=3D0x0c0320 card=3D0x00378086 chip=3D0x3b34808= 6=20 rev=3D0x06 hdr=3D0x00 =20 vendor =3D 'Intel Corporation' =20 class =3D serial bus =20 subclass =3D USB =20 pcib3@pci0:0:30:0: class=3D0x060401 card=3D0x00378086 chip=3D0x244e808= 6=20 rev=3D0xa6 hdr=3D0x01 =20 vendor =3D 'Intel Corporation' =20 device =3D '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface= to=20 PCI Bridge' =20 class =3D bridge =20 subclass =3D PCI-PCI =20 isab0@pci0:0:31:0: class=3D0x060100 card=3D0x00378086 chip=3D0x3b06808= 6=20 rev=3D0x06 hdr=3D0x00 =20 vendor =3D 'Intel Corporation' =20 class =3D bridge =20 subclass =3D PCI-ISA ahci0@pci0:0:31:2: class=3D0x010601 card=3D0x00378086 chip=3D0x3b22808= 6=20 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' device =3D 'IBEX AHCI Controller(6Port)' class =3D mass storage subclass =3D SATA none3@pci0:0:31:3: class=3D0x0c0500 card=3D0x00378086 chip=3D0x3b30808= 6=20 rev=3D0x06 hdr=3D0x00 vendor =3D 'Intel Corporation' class =3D serial bus subclass =3D SMBus ahc0@pci0:3:2:0: class=3D0x010000 card=3D0x00000000 chip=3D0x7178900= 4=20 rev=3D0x00 hdr=3D0x00 vendor =3D 'Adaptec Inc' device =3D 'Fast/Fast-Wide SCSI Ctrlr (AHA-2940/2940W)' class =3D mass storage subclass =3D SCSI =2D-=20 () ascii ribbon campaign - against html e-mail=20 /\ www.asciiribbon.org - against proprietary attachments --nextPart1948443.5yg1p2rgaz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEABECAAYFAkuEhSkACgkQpZfyPAmdZJkVywCdGG72eZoMfigBm9+jrRhLfeV/ zI8AoOLhIfrFfscDrAZt7pLbP7MnUh/Z =5oJn -----END PGP SIGNATURE----- --nextPart1948443.5yg1p2rgaz-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 02:13:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C825D106566C for ; Wed, 24 Feb 2010 02:13:28 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gx0-f211.google.com (mail-gx0-f211.google.com [209.85.217.211]) by mx1.freebsd.org (Postfix) with ESMTP id 762098FC12 for ; Wed, 24 Feb 2010 02:13:28 +0000 (UTC) Received: by gxk3 with SMTP id 3so943855gxk.13 for ; Tue, 23 Feb 2010 18:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=u28CBqDP0uMOtOUtk4DcWPWQ2kEQXLCxRvJ0iSJTXeo=; b=Qv2kopvzRGqNTaR2y0C5LhNKuWAnEqbRr8EKMV2ftbQCjnpfh37KBkEnEbRpXmu56M 52lgNoLavw7zFO8+eGo6eKujsQiiMgbkgG5Xz+1PKuZLdYKvEZ2gUWWIpXTbDnwAldt/ 9VqAcucBisDsPx3vRHHa7U7naYSc63ewC+WEk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=nGtgHVKR6JV21y55/KgFu8p3VtZswDYm3QjTmUVfCYtklmlxtH71cv4O5qmmuxAPmG BbLzcl12cWhh9yMtxGizAfbI6i83w+Oru61XDz8hXrP3I0k9ZryBKSpKV0Rdo03z1L6z CJ3apvPTXu/kZxTWuKSdGkHOcqej0HC6xC3Wo= Received: by 10.150.119.13 with SMTP id r13mr1465683ybc.238.1266977601933; Tue, 23 Feb 2010 18:13:21 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 4sm521691yxd.34.2010.02.23.18.13.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 18:13:20 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 23 Feb 2010 18:12:42 -0800 From: Pyun YongHyeon Date: Tue, 23 Feb 2010 18:12:42 -0800 To: Christof Schulze Message-ID: <20100224021242.GL1251@michelle.cdnetworks.com> References: <201002240247.22141.christof.schulze@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201002240247.22141.christof.schulze@gmx.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: intel h55 chipset + 8_RELENG X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 02:13:28 -0000 On Wed, Feb 24, 2010 at 02:47:16AM +0100, Christof Schulze wrote: > Hello world, > > I also have a board with the H55 chipset (see below for dmesg, uname -a and > pciconf -lv). > The specific board is an Intel DH55HC > > > The network interface card - I tried with em - will not attach to a driver and > the intel driver for Xorg does not recognize the graphics chip of the core i5. > All in all it is rather unpleasant. What might be a different problem is that > the driver for a 3com3c905B and for a Realtek RTL8139 will not attach either. > > I am not sure what information is missing but I sure would love to use the > network card in there. Video is yet a different story. > > Regards > > Christof > > =============== > uname -a: > FreeBSD eri 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Feb 24 08:33:43 CET 2010 > root@eri:/usr/obj/usr/src/sys/GENERIC amd64 > [...] > none2@pci0:0:25:0: class=0x020000 card=0x00378086 chip=0x10f08086 > rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet It seems the support for i5 chipset was made in r200243. But it seems it wasn't MFCed to stable/8. I guess you can download files in sys/dev/e1000/* of HEAD and can built it on stable/8. From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 04:14:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E18B106564A for ; Wed, 24 Feb 2010 04:14:26 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5728FC13 for ; Wed, 24 Feb 2010 04:14:25 +0000 (UTC) Received: by bwz8 with SMTP id 8so3391786bwz.3 for ; Tue, 23 Feb 2010 20:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=uA3GTMG5RQUrLMVVJfnLZV0fQNIAgHY6HSU0KctNyAg=; b=wIcvH0flA1H3CUYUK9rEkIRcyMgBn9ZoKEQ5ju1g4cI9UOdxBG1KxfQDxV9uTluo1G PHW1XzmEhgipzIbxtoZZH+yjNej/jcQ1NvfDP19enqWY4oJ5xHgbPokabTaRSZZNJk+c rPf8F1K9VouCi5GgjlT/u9w8HE0JuHAfhlSWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lW7agzOLmx2qSLeijctH0ZHm7Qa58x3Ha8lD8u1iL3YMXyqdV/Rzep6jgxKfEkaHSh 3rKFZIP/DVK8gtb85AKxOnOXIQGkKFPxwnwuzp8YT0SMutuTmED8QZc5nc0uaVJsNZOw 0hMN/wWgKpL/DRUgO5q7Mwpj7Tm4unu6M01c8= MIME-Version: 1.0 Received: by 10.204.135.215 with SMTP id o23mr5051026bkt.140.1266984859984; Tue, 23 Feb 2010 20:14:19 -0800 (PST) In-Reply-To: <20100224021242.GL1251@michelle.cdnetworks.com> References: <201002240247.22141.christof.schulze@gmx.com> <20100224021242.GL1251@michelle.cdnetworks.com> Date: Tue, 23 Feb 2010 20:14:19 -0800 Message-ID: <2a41acea1002232014t708f321atb99a4eca99f8e8b6@mail.gmail.com> From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Christof Schulze , freebsd-stable@freebsd.org Subject: Re: intel h55 chipset + 8_RELENG X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 04:14:26 -0000 Yes, my bad, its going to get MFC'd soon... The driver in HEAD will work on 8 BTW. Jack On Tue, Feb 23, 2010 at 6:12 PM, Pyun YongHyeon wrote: > On Wed, Feb 24, 2010 at 02:47:16AM +0100, Christof Schulze wrote: > > Hello world, > > > > I also have a board with the H55 chipset (see below for dmesg, uname -a > and > > pciconf -lv). > > The specific board is an Intel DH55HC > > > > > > The network interface card - I tried with em - will not attach to a > driver and > > the intel driver for Xorg does not recognize the graphics chip of the > core i5. > > All in all it is rather unpleasant. What might be a different problem is > that > > the driver for a 3com3c905B and for a Realtek RTL8139 will not attach > either. > > > > I am not sure what information is missing but I sure would love to use > the > > network card in there. Video is yet a different story. > > > > Regards > > > > Christof > > > > =============== > > uname -a: > > FreeBSD eri 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Feb 24 08:33:43 CET > 2010 > > root@eri:/usr/obj/usr/src/sys/GENERIC amd64 > > > > [...] > > > > none2@pci0:0:25:0: class=0x020000 card=0x00378086 chip=0x10f08086 > > rev=0x06 hdr=0x00 > > vendor = 'Intel Corporation' > > class = network > > subclass = ethernet > > It seems the support for i5 chipset was made in r200243. But it > seems it wasn't MFCed to stable/8. I guess you can download files > in sys/dev/e1000/* of HEAD and can built it on stable/8. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 04:45:26 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF9A2106566B for ; Wed, 24 Feb 2010 04:45:26 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 692CF8FC15 for ; Wed, 24 Feb 2010 04:45:26 +0000 (UTC) Received: by fxm23 with SMTP id 23so579184fxm.3 for ; Tue, 23 Feb 2010 20:45:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=NVYzY0Qab4enw4hVGz9uZ+o34nh4z85BoZqdwJIUAkM=; b=T8hPQ+8I291MKRsPXcG5F7EYZJZJi15ODCXekhlnCJS1x5Y5HRzEKLS4s/u5bTWxTm uCnqcbJgvnzkGnTG+AN04kcbvq+mv0q+NIIXkjkpzUT6jznPlnnJ8Ryer7UzN+9eveLp o6723HYb/zWjaCc7DeFJFZxFYF6Oyd2rPu+Gc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=YE54voUiKncc9pRQQGJ/1wZDP1RNKEc9vc0NU8HtxEdagd0uRzhCALd/S8N7Y5js/Z jDH5NeM/ivqMM9qSVUYpG2i2HIm/y8BvNerjFRgH5pwBF4+eH9NKKSOiqkJWUChILD/M vr590yFYKChFwTm2cJcVRgs6lCHI92WVTzbI4= Received: by 10.223.164.165 with SMTP id e37mr10521730fay.43.1266986721338; Tue, 23 Feb 2010 20:45:21 -0800 (PST) Received: from mavbook.mavhome.dp.ua (95-109-130-32.dialup.umc.net.ua [95.109.130.32]) by mx.google.com with ESMTPS id 14sm3018586fxm.1.2010.02.23.20.45.18 (version=SSLv3 cipher=RC4-MD5); Tue, 23 Feb 2010 20:45:20 -0800 (PST) Sender: Alexander Motin Message-ID: <4B84AED9.70303@FreeBSD.org> Date: Wed, 24 Feb 2010 06:45:13 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: "C. P. Ghost" References: <4B83B0A2.1030008@omnilan.de> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 04:45:27 -0000 C. P. Ghost wrote: > On Tue, Feb 23, 2010 at 12:15 PM, George Liaskos wrote: >> I am having the same issue since Feb 20 which was my last update. >> >> ahcich1: Timeout on slot 3 >> ahcich1: is 00000000 cs 00000018 ss 00000000 rs 00000018 tfd d0 serr 00000000 >> ahcich1: Timeout on slot 5 >> ahcich1: is 00000000 cs 00000060 ss 00000000 rs 00000060 tfd d0 serr 00000000 >> ahcich1: Timeout on slot 7 >> ahcich1: is 00000000 cs 00000180 ss 00000000 rs 00000180 tfd d0 serr 00000000 >> ahcich1: Timeout on slot 9 >> ahcich1: is 00000000 cs 00000600 ss 00000000 rs 00000600 tfd d0 serr 00000000 > > Just for the record, I have similar AHCI problems: > > http://docs.freebsd.org/cgi/mid.cgi?d74eb87c1002201912jaa4b519s494f5508c046e66a > http://docs.freebsd.org/cgi/mid.cgi?d74eb87c1002211150iec5e7c0pa36d297e0852aaee > > FreeBSD phenom.cordula.ws 8.0-STABLE FreeBSD 8.0-STABLE #0 r200471: > Sun Dec 13 16:07:46 CET 2009 > root@phenom.cordula.ws:/usr/obj/usr/src/sys/GENERIC > amd64 This can be different problem, fixed in 8-STABLE r203890 on 2010-02-14. -- Alexander Motin From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 07:37:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26EEA106566B; Wed, 24 Feb 2010 07:37:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 5545D8FC0C; Wed, 24 Feb 2010 07:37:02 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NkBno-000DZA-Bs; Wed, 24 Feb 2010 09:37:00 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Alexander Motin In-reply-to: <4B842E05.1060700@FreeBSD.org> References: <1266952985.00222809.1266942602@10.7.7.3> <4B842E05.1060700@FreeBSD.org> Comments: In-reply-to Alexander Motin message dated "Tue, 23 Feb 2010 21:35:33 +0200." Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_1266997001_822950" Date: Wed, 24 Feb 2010 09:37:00 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: ahcich3: Timeout on slot 0 ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 07:37:04 -0000 This is a multipart MIME message. --==_Exmh_1266997001_822950 Content-Type: text/plain; charset=us-ascii > Daniel Braniss wrote: > > with latest 8-stable, I can't boot since it's stuck with: > > > the only wierd thing I see, is the > > Trying to mount root from nfs: > > which does not happen in the failing kernel. > > Could you show full verbose boot messages? here it comes ... --==_Exmh_1266997001_822950 Content-Type: text/plain ; name="out1"; charset=us-ascii Content-Description: out1 Content-Disposition: attachment; filename="out1" GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009ec00 SMAP type=02 base=000000000009ec00 len=0000000000001400 SMAP type=02 base=00000000000e4000 len=000000000001c000 SMAP type=01 base=0000000000100000 len=000000007f580000 SMAP type=03 base=000000007f680000 len=000000000000e000 SMAP type=04 base=000000007f68e000 len=0000000000052000 SMAP type=02 base=000000007f6e0000 len=0000000000020000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000fff00000 len=0000000000100000 Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #0 r1589: Tue Feb 23 09:10:52 IST 2010 danny@sunfire:/r+d/obj/sunfire/r+d/stable/8/sys/HUJI amd64 Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80e8f000. Preloaded elf obj module "/boot/kernel/ahci.ko" at 0xffffffff80e8f1c0. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2999958570 Hz CPU: Intel(R) Core(TM)2 Duo CPU E6850 @ 3.00GHz (2999.96-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff Features2=0xe3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009afff, 630784 bytes (154 pages) 0x0000000000ebd000 - 0x000000007ba66fff, 2059051008 bytes (502698 pages) avail memory = 2046427136 (1951 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 ULE: setup cpu 0 ULE: setup cpu 1 ACPI: RSDP 0xfb790 00014 (v0 ACPIAM) ACPI: RSDT 0x7f680000 00040 (v1 _ASUS_ Notebook 10000829 MSFT 00000097) ACPI: FACP 0x7f680200 00084 (v2 A_M_I_ OEMFACP 10000829 MSFT 00000097) ACPI: DSDT 0x7f6805c0 087ED (v1 A0827 A0827000 00000000 INTL 20060113) ACPI: FACS 0x7f68e000 00040 ACPI: APIC 0x7f680390 0006C (v1 A_M_I_ OEMAPIC 10000829 MSFT 00000097) ACPI: MCFG 0x7f680400 0003C (v1 A_M_I_ OEMMCFG 10000829 MSFT 00000097) ACPI: SLIC 0x7f680440 00176 (v1 _ASUS_ Notebook 10000829 MSFT 00000097) ACPI: OEMB 0x7f68e040 00081 (v1 A_M_I_ AMI_OEM 10000829 MSFT 00000097) ACPI: HPET 0x7f688db0 00038 (v1 A_M_I_ OEMHPET 10000829 MSFT 00000097) ACPI: GSCI 0x7f68e0d0 02024 (v1 A_M_I_ GMCHSCI 10000829 MSFT 00000097) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x0001000f pcm: 0x00010400 wlan: <802.11 Link Layer> kbd: new array size 4 kbd1 at kbdmux0 nfslock: pseudo-device mem: null: random: io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: <_ASUS_ Notebook> on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] ACPI: Executed 1 blocks of module-level executable AML code acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff8000006000 pa 0x4000 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.IELK.RXA0 -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \_SB_.PCI0.SBRG.PIX0 -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7f600000 (3) failed ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 5 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 11 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 10 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 3 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 3 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 15 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 15 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 14 N 0 3 4 5 6 7 10 11 12 14 15 Validation 0 14 N 0 3 4 5 6 7 10 11 12 14 15 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 14 15 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 4 hz: 14318180 opts: legacy_route 64-bit Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x29c0, revid=0x02 domain=0, 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=0x29c2, revid=0x02 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 32, base 0xfe900000, size 19, enabled map[14]: type I/O Port, range 32, base 0xcc00, size 3, enabled map[18]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, enabled map[1c]: type Memory, range 32, base 0xfe800000, size 20, enabled pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x29c3, revid=0x02 domain=0, bus=0, slot=2, func=1 class=03-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe980000, size 19, enabled found-> vendor=0x8086, dev=0x2937, revid=0x02 domain=0, bus=0, slot=26, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 map[20]: type I/O Port, range 32, base 0xc480, size 5, enabled pcib0: matched entry for 0.26.INTA pcib0: slot 26 INTA hardwired to IRQ 16 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc480 found-> vendor=0x8086, dev=0x2938, revid=0x02 domain=0, bus=0, slot=26, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=3 map[20]: type I/O Port, range 32, base 0xc800, size 5, enabled pcib0: matched entry for 0.26.INTB pcib0: slot 26 INTB hardwired to IRQ 21 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc800 found-> vendor=0x8086, dev=0x2939, revid=0x02 domain=0, bus=0, slot=26, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 map[20]: type I/O Port, range 32, base 0xc880, size 5, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc880 found-> vendor=0x8086, dev=0x293c, revid=0x02 domain=0, bus=0, slot=26, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe7fbc00, size 10, enabled pcib0: matched entry for 0.26.INTC pcib0: slot 26 INTC hardwired to IRQ 18 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfe7fbc00 found-> vendor=0x8086, dev=0x293e, revid=0x02 domain=0, bus=0, slot=27, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=15 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfe7f4000, size 14, enabled pcib0: matched entry for 0.27.INTA pcib0: slot 27 INTA hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2940, revid=0x02 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0106, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2948, revid=0x02 domain=0, bus=0, slot=28, func=4 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0105, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x2934, revid=0x02 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 map[20]: type I/O Port, range 32, base 0xc000, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc000 found-> vendor=0x8086, dev=0x2935, revid=0x02 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 map[20]: type I/O Port, range 32, base 0xc080, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc080 found-> vendor=0x8086, dev=0x2936, revid=0x02 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 map[20]: type I/O Port, range 32, base 0xc400, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc400 found-> vendor=0x8086, dev=0x293a, revid=0x02 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=14 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfe7fb800, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 23 unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfe7fb800 found-> vendor=0x8086, dev=0x244e, revid=0x92 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2918, revid=0x02 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2923, revid=0x02 domain=0, bus=0, slot=31, func=2 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=15 powerspec 3 supports D0 D3 current D0 MSI supports 16 messages map[10]: type I/O Port, range 32, base 0xb880, size 3, enabled map[14]: type I/O Port, range 32, base 0xb800, size 2, enabled map[18]: type I/O Port, range 32, base 0xb480, size 3, enabled map[1c]: type I/O Port, range 32, base 0xb400, size 2, enabled map[20]: type I/O Port, range 32, base 0xb080, size 5, enabled map[24]: type Memory, range 32, base 0xfe7fa800, size 11, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 22 found-> vendor=0x8086, dev=0x2930, revid=0x02 domain=0, bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 map[10]: type Memory, range 64, base 0xfe7fb400, size 8, enabled map[20]: type I/O Port, range 32, base 0x400, size 5, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 18 vgapci0: port 0xcc00-0xcc07 mem 0xfe900000-0xfe97ffff,0xd0000000-0xdfffffff,0xfe800000-0xfe8fffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 vgapci0: Reserved 0x10000000 bytes for rid 0x18 type 3 at 0xd0000000 vgapci0: Reserved 0x80000 bytes for rid 0x10 type 3 at 0xfe900000 vgapci0: Reserved 0x100000 bytes for rid 0x1c type 3 at 0xfe800000 agp0: detected 7164k stolen memory agp0: aperture size is 256M vgapci1: mem 0xfe980000-0xfe9fffff at device 2.1 on pci0 uhci0: port 0xc480-0xc49f irq 16 at device 26.0 on pci0 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 49 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xc800-0xc81f irq 21 at device 26.1 on pci0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 50 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xc880-0xc89f irq 18 at device 26.2 on pci0 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 51 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xfe7fbc00-0xfe7fbfff irq 18 at device 26.7 on pci0 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pci0: at device 27.0 (no driver attached) pcib1: irq 17 at device 28.0 on pci0 pcib1: domain 0 pcib1: secondary bus 2 pcib1: subordinate bus 2 pcib1: I/O decode 0x0-0x0 pcib1: prefetched decode 0xfdf00000-0xfdffffff pci2: on pcib1 pci2: domain=0, physical bus=2 pcib2: irq 17 at device 28.4 on pci0 pcib2: domain 0 pcib2: secondary bus 1 pcib2: subordinate bus 1 pcib2: I/O decode 0xd000-0xdfff pcib2: no prefetched decode pci1: on pcib2 pci1: domain=0, physical bus=1 found-> vendor=0x197b, dev=0x2368, revid=0x00 domain=0, bus=1, slot=0, func=0 class=01-01-85, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=8 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xdc00, size 3, enabled pcib2: requested I/O range 0xdc00-0xdc07: in range map[14]: type I/O Port, range 32, base 0xd880, size 2, enabled pcib2: requested I/O range 0xd880-0xd883: in range map[18]: type I/O Port, range 32, base 0xd800, size 3, enabled pcib2: requested I/O range 0xd800-0xd807: in range map[1c]: type I/O Port, range 32, base 0xd480, size 2, enabled pcib2: requested I/O range 0xd480-0xd483: in range map[20]: type I/O Port, range 32, base 0xd400, size 4, enabled pcib2: requested I/O range 0xd400-0xd40f: in range pcib2: matched entry for 1.0.INTA pcib2: slot 0 INTA hardwired to IRQ 16 atapci0: port 0xdc00-0xdc07,0xd880-0xd883,0xd800-0xd807,0xd480-0xd483,0xd400-0xd40f irq 16 at device 0.0 on pci1 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xd400 atapci0: [MPSAFE] atapci0: [ITHREAD] ata2: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xdc00 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xd880 ata2: reset tp1 mask=03 ostat0=60 ostat1=70 ata2: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata2: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata2: reset tp2 stat0=20 stat1=30 devices=0x0 ata2: [MPSAFE] ata2: [ITHREAD] uhci3: port 0xc000-0xc01f irq 23 at device 29.0 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 52 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus4: on uhci3 uhci4: port 0xc080-0xc09f irq 19 at device 29.1 on pci0 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 53 uhci4: [MPSAFE] uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0xc400-0xc41f irq 18 at device 29.2 on pci0 uhci5: [MPSAFE] uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xfe7fb800-0xfe7fbbff irq 23 at device 29.7 on pci0 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib3: at device 30.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xe000-0xefff pcib3: memory decode 0xfea00000-0xfebfffff pcib3: no prefetched decode pcib3: Subtractively decoded bridge. pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x8086, dev=0x1079, revid=0x03 domain=0, bus=3, slot=1, func=0 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xfebc0000, size 17, enabled pcib3: requested memory range 0xfebc0000-0xfebdffff: good map[18]: type Memory, range 64, base 0xfeb00000, size 18, enabled pcib3: requested memory range 0xfeb00000-0xfeb3ffff: good map[20]: type I/O Port, range 32, base 0xe880, size 6, enabled pcib3: requested I/O range 0xe880-0xe8bf: in range pcib3: matched entry for 3.1.INTA pcib3: slot 1 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x1079, revid=0x03 domain=0, bus=3, slot=1, func=1 class=02-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0017, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xfebe0000, size 17, enabled pcib3: requested memory range 0xfebe0000-0xfebfffff: good map[18]: type Memory, range 64, base 0xfeb80000, size 18, enabled pcib3: requested memory range 0xfeb80000-0xfebbffff: good map[20]: type I/O Port, range 32, base 0xec00, size 6, enabled pcib3: requested I/O range 0xec00-0xec3f: in range pcib3: matched entry for 3.1.INTB pcib3: slot 1 INTB hardwired to IRQ 18 found-> vendor=0x1106, dev=0x3044, revid=0xc0 domain=0, bus=3, slot=2, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0017, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x20 (8000 ns) intpin=a, irq=10 powerspec 2 supports D0 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfeabf800, size 11, enabled pcib3: requested memory range 0xfeabf800-0xfeabffff: good map[14]: type I/O Port, range 32, base 0xe800, size 7, enabled pcib3: requested I/O range 0xe800-0xe87f: in range pcib3: matched entry for 3.2.INTA pcib3: slot 2 INTA hardwired to IRQ 20 em0: port 0xe880-0xe8bf mem 0xfebc0000-0xfebdffff,0xfeb00000-0xfeb3ffff irq 17 at device 1.0 on pci3 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfebc0000 em0: Reserved 0x40 bytes for rid 0x20 type 4 at 0xe880 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 54 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:04:23:d7:75:16 em1: port 0xec00-0xec3f mem 0xfebe0000-0xfebfffff,0xfeb80000-0xfebbffff irq 18 at device 1.1 on pci3 em1: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfebe0000 em1: Reserved 0x40 bytes for rid 0x20 type 4 at 0xec00 em1: [FILTER] em1: bpf attached em1: Ethernet address: 00:04:23:d7:75:17 fwohci0: port 0xe800-0xe87f mem 0xfeabf800-0xfeabffff irq 20 at device 2.0 on pci3 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfeabf800 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 55 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:01:63:a0:cd fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xc0ddc0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:d8:63:a0:cd fwe0: bpf attached fwe0: Ethernet address: 02:11:d8:63:a0:cd fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:11:d8:00:01:63:a0:cd @ 0xfffe00000000, S400, maxrec 2048 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xb880-0xb887,0xb800-0xb803,0xb480-0xb487,0xb400-0xb403,0xb080-0xb09f mem 0xfe7fa800-0xfe7fafff irq 22 at device 31.2 on pci0 ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfe7fa800 ahci0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 64 ahci0: using IRQ 256 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.20 with 4 3Gbps ports, Port Multiplier supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd CCC EM eSATA 4ports ahci0: Caps2: ahci0: EM Caps: ALHD XMT SMB LED ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich0: Caps: HPCP ahcich1: at channel 1 on ahci0 ahcich1: [MPSAFE] ahcich1: [ITHREAD] ahcich1: Caps: HPCP ahcich2: at channel 4 on ahci0 ahcich2: [MPSAFE] ahcich2: [ITHREAD] ahcich2: Caps: HPCP ahcich3: at channel 5 on ahci0 ahcich3: [MPSAFE] ahcich3: [ITHREAD] ahcich3: Caps: pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 56 fdc0: [FILTER] ppc0: using extended I/O port range ppc0: SPP ECP ECP+EPP ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 57 ppc0: [MPSAFE] ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached plip0: [MPSAFE] plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [MPSAFE] lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 58 uart0: [FILTER] uart0: fast interrupt uart0: console (115200,n,8,1) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 59 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [OEMB] - DC, should be CF (20100121/tbutils-354) ACPI: SSDT 0x7f690100 001D2 (v1 AMI CPU1PM 00000001 INTL 20060113) cpu0: switching to generic Cx mode est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 ACPI: SSDT 0x7f6902e0 00143 (v1 AMI CPU2PM 00000001 INTL 20060113) est1: on cpu1 p4tcc1: on cpu1 ex_isa_identify() ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xcb800-0xcc7ff,0xcc800-0xcd7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 131877 -> 100000 procfs registered lapic: Divisor 2, Frequency 166664367 Hz Timecounter "TSC" frequency 2999958570 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached hptrr: no controller detected. ata2: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 Identifying devices: 00000000 ata2: New devices: 00000000 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout ahcich0: AHCI reset... ahcich0: SATA connect time=0ms status=00000123 ahcich0: ready wait time=10ms ahcich0: AHCI reset done: device found (aprobe0:ahcich0:0:15:0): SIGNATURE: 0000 (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 ahcich1: AHCI reset... ahcich1: SATA connect timeout status=00000000 ahcich1: AHCI reset done: phy reset found no device ahcich2: AHCI reset... ahcich2: SATA connect timeout status=00000000 ahcich2: AHCI reset done: phy reset --==_Exmh_1266997001_822950-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 07:38:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53EFC1065670 for ; Wed, 24 Feb 2010 07:38:34 +0000 (UTC) (envelope-from torfinn.ingolfsen@broadpark.no) Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by mx1.freebsd.org (Postfix) with ESMTP id 0B46F8FC12 for ; Wed, 24 Feb 2010 07:38:33 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with ESMTP id <0KYC000JR579IS90@bgo1smout1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 24 Feb 2010 08:37:57 +0100 (CET) Received: from kg-v2.kg4.no ([80.203.92.186]) by bgo1sminn1.broadpark.no (Sun Java(tm) System Messaging Server 6.3-3.01 (built Jul 12 2007; 32bit)) with SMTP id <0KYC009JC57874C0@bgo1sminn1.broadpark.no> for freebsd-stable@freebsd.org; Wed, 24 Feb 2010 08:37:57 +0100 (CET) Date: Wed, 24 Feb 2010 08:37:56 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100224083756.03d8fe99.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100221201742.GA8860@server.vk2pj.dyndns.org> References: <20100212174452.2140cd72.torfinn.ingolfsen@broadpark.no> <20100217194927.e3ec60ae.torfinn.ingolfsen@broadpark.no> <20100217200322.da66c9f8.torfinn.ingolfsen@broadpark.no> <20100218205458.GA78560@server.vk2pj.dyndns.org> <20100218231223.ec6b9fa8.torfinn.ingolfsen@broadpark.no> <20100219003844.acdaa866.torfinn.ingolfsen@broadpark.no> <20100220015351.GB81639@server.vk2pj.dyndns.org> <20100220223201.178e67dd.torfinn.ingolfsen@broadpark.no> <20100221050823.GB22670@server.vk2pj.dyndns.org> <20100221173619.2470aa85.torfinn.ingolfsen@broadpark.no> <20100221201742.GA8860@server.vk2pj.dyndns.org> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) 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 Subject: Re: ntpd struggling to keep up - how to fix? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 07:38:34 -0000 On Mon, 22 Feb 2010 07:17:42 +1100 Peter Jeremy wrote: > On 2010-Feb-21 17:36:19 +0100, Torfinn Ingolfsen wrote: > Over time (probably a couple of days from scratch), the "poll" rate > should increase to 1024. If it doesn't, it may indicate that your Like so: root@kg-f2# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *kg-omni1.kg4.no 192.121.13.58 3 u 564 1024 377 0.163 3.018 3.196 -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 07:54:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E389106564A for ; Wed, 24 Feb 2010 07:54:02 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 1C83A8FC08 for ; Wed, 24 Feb 2010 07:54:01 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o1O7rxrR002622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Feb 2010 18:54:00 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o1O7rxaH062181; Wed, 24 Feb 2010 18:53:59 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o1O7rxKR062180; Wed, 24 Feb 2010 18:53:59 +1100 (EST) (envelope-from peter) Date: Wed, 24 Feb 2010 18:53:59 +1100 From: Peter Jeremy To: freebsd-stable@freebsd.org Message-ID: <20100224075359.GA61876@server.vk2pj.dyndns.org> References: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: gshapiro@freebsd.org Subject: Re: sleep(3) sometimes too sleepy on FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 07:54:02 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Updates following some off-line discussions and debugging with John on IRC. I've cc'd gshapiro@ because the problem appears to be sendmail, rather than the FreeBSD kernel. On 2010-Feb-23 12:35:22 +1100, John Marshall wrote: >Environment: sendmail 8.14.4 on FreeBSD 8.0-RELEASE-p2 Note that this is stock ISC sendmail, not the sendmail in either the base system or the port. >I posted about this in comp.mail.sendmail and was told... > >> sleep() should be one of these calls: >>=20 >> if (njobs =3D=3D 0 && WorkGrp[wgrp].wg_lowqintvl < MIN_SLEEP_TIM= E) >> sleep(MIN_SLEEP_TIME); >> else if (WorkGrp[wgrp].wg_lowqintvl <=3D 0) >> sleep(QueueIntvl > 0 ? QueueIntvl : MIN_SLEEP_TIME); >> else >> sleep(WorkGrp[wgrp].wg_lowqintvl); Whilst it's true that the code calls sleep(), it's not calling sleep(3) in the FreeBSD libc. Instead it's calling a sleep() defined in libsm/clock.c - which is a horrible maze of #ifdefs. John has pre-processed that code and the result it at: http://www.riverwillow.net.au/~john/sm/clock.preprocessed At a quick look, the code is broken: sm_seteventm() generates a one-off timer using setitimer(2), which will send SIGALRM when it expires. sm_releasesignal() then unblocks SIGALRM. In theory, the SIGALRM could be delivered anywhere after the (!SmSleepDone) test and before pause() is called - in which case, the signal is lost and pause() will sleep forever. On 2010-Feb-24 08:13:06 +1100, John Marshall wrote: >My ktrace file was created with 'ktrace -g 48501'. I have the result of >'kdump -R -p 48504' available at: > > The syscall pattern near the end of this file is significantly different =66rom that elsewhere in the file - with gettimeofday(), sigprocmask() and sigsuspend() looping fairly rapidly. Interestingly, sigsuspend() is returning EINTR but no signal is reported. I'm not sure what could cause this. This syscall pattern looks like the while() loop in sendmail's sleep(), though it does appear that the loop is exited on that occasion but not on the following occasion (though the reason for this behaviour is unclear). Overall, it appears that there is a race condition in sendmail and something in the 8.0 signal handling appears to make this race easier to lose. Going back to the original clock.c source code, the other thing that is obvious is the HAVE_NANOSLEEP block - if this was active, sleep() would call nanosleep(2) and the whole signal mess would be avoided. It's not clear when that code was added but clock.c has not been touched for many years. In the sendmail in FreeBSD-8.0, there is no other reference to HAVE_NANOSLEEP within sendmail. sendmail 8.14.4 (in 8-STABLE) has HAVE_NANOSLEEP enabled on Solaris 11 only. Is there any reason why HAVE_NANOSLEEP is not defined for FreeBSD? Looking back through the commit logs, nanosleep(2) was implemented in sys/kern/kern_time.c v1.23 on Thu May 8 14:16:25 1997 UTC - that's just before RELENG_2_2. --=20 Peter Jeremy --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuE2xcACgkQ/opHv/APuIc1oACgnsnkJg0LUt/QFHWuKMQGKFl5 cpkAn1emZlO8CO0dn21kIEM3qi61kuid =zPnc -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 10:23:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21B8E106566B for ; Wed, 24 Feb 2010 10:23:16 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7FB8FC19 for ; Wed, 24 Feb 2010 10:23:15 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1OANBau026000 for ; Wed, 24 Feb 2010 11:23:12 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 79CA124 for ; Wed, 24 Feb 2010 11:23:11 +0100 (CET) Date: Wed, 24 Feb 2010 11:23:11 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: freebsd-stable@freebsd.org Message-Id: <20100224112311.73ac53f6.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.24.100933 Subject: nss_ldap and multiple group memberships X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 10:23:16 -0000 Hi all, Is anyone here using nss_ldap and can successfully get it to work with multiple group memberships? I would really like to get this to work here, but I only get the primary group: penumbra# id gekueh uid=1030(gekueh) gid=1012(aei) groups=1012(aei) getent group comes up with the complete group list. ldapsearch reports three groups with member:-lines for my user. Somehow nss does not pick this up. Any ideas? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 10:39:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8DD3C106566C for ; Wed, 24 Feb 2010 10:39:50 +0000 (UTC) (envelope-from hausen@punkt.de) Received: from kagate.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.freebsd.org (Postfix) with ESMTP id 18CF98FC0C for ; Wed, 24 Feb 2010 10:39:49 +0000 (UTC) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by kagate1.punkt.de with ESMTP id o1OAdmED086156; Wed, 24 Feb 2010 11:39:48 +0100 (CET) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.14.2/8.14.2) with ESMTP id o1OAdmsV078058; Wed, 24 Feb 2010 11:39:48 +0100 (CET) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.14.2/8.14.2/Submit) id o1OAdmh9078057; Wed, 24 Feb 2010 11:39:48 +0100 (CET) (envelope-from ry93) Date: Wed, 24 Feb 2010 11:39:48 +0100 From: "Patrick M. Hausen" To: Gerrit =?iso-8859-1?Q?K=FChn?= Message-ID: <20100224103947.GA75442@hugo10.ka.punkt.de> References: <20100224112311.73ac53f6.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5vNYLRcllDrimb99" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100224112311.73ac53f6.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-stable@freebsd.org Subject: Re: nss_ldap and multiple group memberships X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 10:39:50 -0000 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Hi, all, On Wed, Feb 24, 2010 at 11:23:11AM +0100, Gerrit Khn wrote: > Is anyone here using nss_ldap and can successfully get it to work with > multiple group memberships? I would really like to get this to work here, > but I only get the primary group: > > penumbra# id gekueh > uid=1030(gekueh) gid=1012(aei) groups=1012(aei) [ry93@devel ~]$ uname -a FreeBSD devel.intern.punkt.de 7.2-RELEASE-p6 FreeBSD 7.2-RELEASE-p6 #0: Mon Feb 22 16:17:54 CET 2010 root@nanobsd.ka.punkt.de:/var/home/nanobsd/obj/dl320-devel/usr/src/sys/GENERIC amd64 [ry93@devel ~]$ pkg_info | grep ldap nss_ldap-1.264_3 RFC 2307 NSS module openldap-client-2.4.21 Open source LDAP client implementation pam_ldap-1.8.5 A pam module for authenticating with LDAP [ry93@devel ~]$ id uid=10093(ry93) gid=10001(intern) groups=10001(intern),0(wheel) LDAP server is Active Directory on Windows 2003 R2. What precisely do you need? Ah, heck, I'll just attach my config files right away. nss_ldap.conf is just a symlink to ldap.conf. I do not remember where that '?one' came from and what precisely it does. Voodoo I copied from some obscure "Howto", I figure. I'd appreciate some feedback on that part ;-) Best regards, HTH, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 info@punkt.de http://www.punkt.de Gf: Jrgen Egeling AG Mannheim 108285 --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="nsswitch.conf" # # nsswitch.conf(5) - name service switch configuration file # $FreeBSD: src/etc/nsswitch.conf,v 1.1.8.1 2009/04/15 03:14:26 kensmith Exp $ # group: cache files ldap hosts: files dns networks: files passwd: cache files ldap shells: files services: compat services_compat: nis protocols: files rpc: files --5vNYLRcllDrimb99 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ldap.conf" uri ldap://pdc.intern.punkt.de base DC=intern,DC=punkt,DC=de ldap_version 3 binddn *** bindpw *** scope sub idle_timelimit 60 pam_login_attribute msSFU30Name pam_filter objectclass=User pam_password ad nss_map_objectclass posixAccount User nss_map_objectclass posixGroup Group nss_base_passwd ou=Mitarbeiter,dc=intern,dc=punkt,dc=de?one nss_base_group ou=Unixgruppen,dc=intern,dc=punkt,dc=de?one nss_map_attribute uid msSFU30Name nss_map_attribute gecos name nss_map_attribute userPassword unixUserPassword nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute uniqueMember member nss_map_attribute cn sAMAccountName nss_map_attribute uniquemember msSFU30PosixMember --5vNYLRcllDrimb99-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 10:58:14 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A2831065675 for ; Wed, 24 Feb 2010 10:58:14 +0000 (UTC) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (gate6.infracaninophile.co.uk [IPv6:2001:8b0:151:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id A1C1C8FC0C for ; Wed, 24 Feb 2010 10:58:13 +0000 (UTC) Received: from seedling.black-earth.co.uk (seedling.black-earth.co.uk [81.187.76.163]) (authenticated bits=0) by smtp.infracaninophile.co.uk (8.14.4/8.14.4) with ESMTP id o1OAw89X048857 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 24 Feb 2010 10:58:08 GMT (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <4B850640.80103@infracaninophile.co.uk> Date: Wed, 24 Feb 2010 10:58:08 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <20100224112311.73ac53f6.gerrit@pmp.uni-hannover.de> <20100224103947.GA75442@hugo10.ka.punkt.de> In-Reply-To: <20100224103947.GA75442@hugo10.ka.punkt.de> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, SPF_FAIL,T_KHOP_PGP_INLINE autolearn=no version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on happy-idiot-talk.infracaninophile.co.uk Subject: Re: nss_ldap and multiple group memberships X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 10:58:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/02/2010 10:39, Patrick M. Hausen wrote: > I do not remember where that '?one' came from and what precisely > it does. Voodoo I copied from some obscure "Howto", I figure. > I'd appreciate some feedback on that part ;-) It sets the scope of the LDAP search to the direct children of the search base: ie it only goes one layer into the hierarchy. Alternatives are ?base -- just search the base object or ?sub -- (the default) search the entire hierarchy rooted from the search base. Cheers, Matthew - -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuFBkAACgkQ8Mjk52CukIwq9ACfa5AZ/9dorJ55/p4NEPvvhcGJ XdUAn01BiQ0eYKKAFM3PBnj2ovwMRuLP =J1Jt -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 11:21:49 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A7A0106564A; Wed, 24 Feb 2010 11:21:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id CF7F18FC1A; Wed, 24 Feb 2010 11:21:48 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o1OBLdcU076731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Feb 2010 13:21:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o1OBLdhY089561; Wed, 24 Feb 2010 13:21:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o1OBLdcO089560; Wed, 24 Feb 2010 13:21:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Feb 2010 13:21:39 +0200 From: Kostik Belousov To: Peter Jeremy Message-ID: <20100224112139.GT50403@deviant.kiev.zoral.com.ua> References: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> <20100224075359.GA61876@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EvPGq5x6n2a0k3dQ" Content-Disposition: inline In-Reply-To: <20100224075359.GA61876@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: gshapiro@freebsd.org, freebsd-stable@freebsd.org Subject: Re: sleep(3) sometimes too sleepy on FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 11:21:49 -0000 --EvPGq5x6n2a0k3dQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 24, 2010 at 06:53:59PM +1100, Peter Jeremy wrote: > Updates following some off-line discussions and debugging with John on > IRC. I've cc'd gshapiro@ because the problem appears to be sendmail, > rather than the FreeBSD kernel. >=20 > On 2010-Feb-23 12:35:22 +1100, John Marshall wrote: > >Environment: sendmail 8.14.4 on FreeBSD 8.0-RELEASE-p2 >=20 > Note that this is stock ISC sendmail, not the sendmail in either the > base system or the port. >=20 > >I posted about this in comp.mail.sendmail and was told... > > > >> sleep() should be one of these calls: > >>=20 > >> if (njobs =3D=3D 0 && WorkGrp[wgrp].wg_lowqintvl < MIN_SLEEP_T= IME) > >> sleep(MIN_SLEEP_TIME); > >> else if (WorkGrp[wgrp].wg_lowqintvl <=3D 0) > >> sleep(QueueIntvl > 0 ? QueueIntvl : MIN_SLEEP_TIME); > >> else > >> sleep(WorkGrp[wgrp].wg_lowqintvl); >=20 > Whilst it's true that the code calls sleep(), it's not calling > sleep(3) in the FreeBSD libc. Instead it's calling a sleep() defined > in libsm/clock.c - which is a horrible maze of #ifdefs. >=20 > John has pre-processed that code and the result it at: > http://www.riverwillow.net.au/~john/sm/clock.preprocessed >=20 > At a quick look, the code is broken: sm_seteventm() generates a > one-off timer using setitimer(2), which will send SIGALRM when it > expires. sm_releasesignal() then unblocks SIGALRM. In theory, the > SIGALRM could be delivered anywhere after the (!SmSleepDone) test and > before pause() is called - in which case, the signal is lost and > pause() will sleep forever. >=20 > On 2010-Feb-24 08:13:06 +1100, John Marshall wrote: > >My ktrace file was created with 'ktrace -g 48501'. I have the result of > >'kdump -R -p 48504' available at: > > > > I get 'kdump: data too short' on RELENG_8/i386. >=20 > The syscall pattern near the end of this file is significantly different > from that elsewhere in the file - with gettimeofday(), sigprocmask() and > sigsuspend() looping fairly rapidly. Interestingly, sigsuspend() is > returning EINTR but no signal is reported. I'm not sure what could > cause this. Is this 8.0-RELEASE ? Please note that kern_sigsuspend() code was changed in HEAD/RELENG_8 after 8.0 release. >=20 > This syscall pattern looks like the while() loop in sendmail's sleep(), > though it does appear that the loop is exited on that occasion but not > on the following occasion (though the reason for this behaviour is > unclear). --EvPGq5x6n2a0k3dQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuFC8MACgkQC3+MBN1Mb4hengCg3jU3kelZFdq/8eNvLWvMgqjf uLAAn3ras5iou1NHpL5OPQzsI0Tic828 =DrdN -----END PGP SIGNATURE----- --EvPGq5x6n2a0k3dQ-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 11:44:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2CA5F1065679 for ; Wed, 24 Feb 2010 11:44:43 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by mx1.freebsd.org (Postfix) with ESMTP id F2C688FC0A for ; Wed, 24 Feb 2010 11:44:42 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta12.emeryville.ca.mail.comcast.net with comcast id lnfa1d0011Y3wxoACnkjF2; Wed, 24 Feb 2010 11:44:43 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id lnki1d0033S48mS8bnkiGA; Wed, 24 Feb 2010 11:44:43 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 30C9E1E301A; Wed, 24 Feb 2010 03:44:41 -0800 (PST) Date: Wed, 24 Feb 2010 03:44:41 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100224114441.GA57760@icarus.home.lan> References: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> <20100224075359.GA61876@server.vk2pj.dyndns.org> <20100224112139.GT50403@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100224112139.GT50403@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: sleep(3) sometimes too sleepy on FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 11:44:43 -0000 On Wed, Feb 24, 2010 at 01:21:39PM +0200, Kostik Belousov wrote: > On Wed, Feb 24, 2010 at 06:53:59PM +1100, Peter Jeremy wrote: > > Updates following some off-line discussions and debugging with John on > > IRC. I've cc'd gshapiro@ because the problem appears to be sendmail, > > rather than the FreeBSD kernel. > > > > On 2010-Feb-23 12:35:22 +1100, John Marshall wrote: > > >Environment: sendmail 8.14.4 on FreeBSD 8.0-RELEASE-p2 > > > > Note that this is stock ISC sendmail, not the sendmail in either the > > base system or the port. > > > > >I posted about this in comp.mail.sendmail and was told... > > > > > >> sleep() should be one of these calls: > > >> > > >> if (njobs == 0 && WorkGrp[wgrp].wg_lowqintvl < MIN_SLEEP_TIME) > > >> sleep(MIN_SLEEP_TIME); > > >> else if (WorkGrp[wgrp].wg_lowqintvl <= 0) > > >> sleep(QueueIntvl > 0 ? QueueIntvl : MIN_SLEEP_TIME); > > >> else > > >> sleep(WorkGrp[wgrp].wg_lowqintvl); > > > > Whilst it's true that the code calls sleep(), it's not calling > > sleep(3) in the FreeBSD libc. Instead it's calling a sleep() defined > > in libsm/clock.c - which is a horrible maze of #ifdefs. > > > > John has pre-processed that code and the result it at: > > http://www.riverwillow.net.au/~john/sm/clock.preprocessed > > > > At a quick look, the code is broken: sm_seteventm() generates a > > one-off timer using setitimer(2), which will send SIGALRM when it > > expires. sm_releasesignal() then unblocks SIGALRM. In theory, the > > SIGALRM could be delivered anywhere after the (!SmSleepDone) test and > > before pause() is called - in which case, the signal is lost and > > pause() will sleep forever. > > > > On 2010-Feb-24 08:13:06 +1100, John Marshall wrote: > > >My ktrace file was created with 'ktrace -g 48501'. I have the result of > > >'kdump -R -p 48504' available at: > > > > > > > I get 'kdump: data too short' on RELENG_8/i386. Is the OP's machine amd64? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 12:20:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D84421065674 for ; Wed, 24 Feb 2010 12:20:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 508F98FC1A for ; Wed, 24 Feb 2010 12:20:54 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o1OCKjeg086801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Feb 2010 14:20:45 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o1OCKjrg090109; Wed, 24 Feb 2010 14:20:45 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o1OCKj3W090108; Wed, 24 Feb 2010 14:20:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Feb 2010 14:20:45 +0200 From: Kostik Belousov To: Jeremy Chadwick , Peter Jeremy Message-ID: <20100224122045.GU50403@deviant.kiev.zoral.com.ua> References: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> <20100224075359.GA61876@server.vk2pj.dyndns.org> <20100224112139.GT50403@deviant.kiev.zoral.com.ua> <20100224114441.GA57760@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VRppCkiwz5ce4F2G" Content-Disposition: inline In-Reply-To: <20100224114441.GA57760@icarus.home.lan> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-stable@freebsd.org Subject: Re: sleep(3) sometimes too sleepy on FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 12:20:56 -0000 --VRppCkiwz5ce4F2G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 24, 2010 at 03:44:41AM -0800, Jeremy Chadwick wrote: > On Wed, Feb 24, 2010 at 01:21:39PM +0200, Kostik Belousov wrote: > > On Wed, Feb 24, 2010 at 06:53:59PM +1100, Peter Jeremy wrote: > > > Updates following some off-line discussions and debugging with John on > > > IRC. I've cc'd gshapiro@ because the problem appears to be sendmail, > > > rather than the FreeBSD kernel. > > >=20 > > > On 2010-Feb-23 12:35:22 +1100, John Marshall wrote: > > > >Environment: sendmail 8.14.4 on FreeBSD 8.0-RELEASE-p2 > > >=20 > > > Note that this is stock ISC sendmail, not the sendmail in either the > > > base system or the port. > > >=20 > > > >I posted about this in comp.mail.sendmail and was told... > > > > > > > >> sleep() should be one of these calls: > > > >>=20 > > > >> if (njobs =3D=3D 0 && WorkGrp[wgrp].wg_lowqintvl < MIN_SLE= EP_TIME) > > > >> sleep(MIN_SLEEP_TIME); > > > >> else if (WorkGrp[wgrp].wg_lowqintvl <=3D 0) > > > >> sleep(QueueIntvl > 0 ? QueueIntvl : MIN_SLEEP_TIME= ); > > > >> else > > > >> sleep(WorkGrp[wgrp].wg_lowqintvl); > > >=20 > > > Whilst it's true that the code calls sleep(), it's not calling > > > sleep(3) in the FreeBSD libc. Instead it's calling a sleep() defined > > > in libsm/clock.c - which is a horrible maze of #ifdefs. > > >=20 > > > John has pre-processed that code and the result it at: > > > http://www.riverwillow.net.au/~john/sm/clock.preprocessed > > >=20 > > > At a quick look, the code is broken: sm_seteventm() generates a > > > one-off timer using setitimer(2), which will send SIGALRM when it > > > expires. sm_releasesignal() then unblocks SIGALRM. In theory, the > > > SIGALRM could be delivered anywhere after the (!SmSleepDone) test and > > > before pause() is called - in which case, the signal is lost and > > > pause() will sleep forever. > > >=20 > > > On 2010-Feb-24 08:13:06 +1100, John Marshall wrote: > > > >My ktrace file was created with 'ktrace -g 48501'. I have the resul= t of > > > >'kdump -R -p 48504' available at: > > > > > > > > > > I get 'kdump: data too short' on RELENG_8/i386. >=20 > Is the OP's machine amd64? No, apparently, the this is indeed output of kdump, as advertised. It was me who misinterpreted it as ktrace. Regarding sigsuspend() returning EINTR without delivering any signal, could it be that the sendmail process was debugged ? --VRppCkiwz5ce4F2G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuFGZ0ACgkQC3+MBN1Mb4jZLQCeJ6MaJTuHG8gXN0EFcw9TqIYZ T/8AoJJKUHb/2ob+LQijeFn02MbrV5bY =mCpo -----END PGP SIGNATURE----- --VRppCkiwz5ce4F2G-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 12:41:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55D4C106566B for ; Wed, 24 Feb 2010 12:41:07 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id C6C068FC17 for ; Wed, 24 Feb 2010 12:41:06 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.4/8.14.4) with ESMTP id o1OCf2ZF031164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 24 Feb 2010 23:41:03 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1267015263; bh=DgUR3Dki9nZVqV/fYO7EfHaXqbeapXCPFxReTJzt7p0=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=zuFnVM2rMgemDy2vGGw18ApM63jcu5KSGKrjV/PP7N7+r3PRnShii2MCRWX/FPcc0 LUCP5koQ/3yw2rUXjMHA9FkqMunEtc9L/SoqrsMgdbChQ4yhvgp+7mEFqxCHXYUzuo 6LLUdbQOI3s5KZycS+PSCb9xm5f8ysbH63X50rYo= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id o1OCf1TT015783 for ; Wed, 24 Feb 2010 23:41:01 +1100 (AEDT) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id o1OCf1uI015782 for freebsd-stable@freebsd.org; Wed, 24 Feb 2010 23:41:01 +1100 (AEDT) (envelope-from john) Date: Wed, 24 Feb 2010 23:41:01 +1100 From: John Marshall To: freebsd-stable@freebsd.org Message-ID: <20100224124101.GC14464@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org References: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> <20100224075359.GA61876@server.vk2pj.dyndns.org> <20100224112139.GT50403@deviant.kiev.zoral.com.ua> <20100224114441.GA57760@icarus.home.lan> <20100224122045.GU50403@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ" Content-Disposition: inline In-Reply-To: <20100224122045.GU50403@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: sleep(3) sometimes too sleepy on FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 12:41:07 -0000 --rwEMma7ioTxnRzrJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 24 Feb 2010, 14:20 +0200, Kostik Belousov wrote: > On Wed, Feb 24, 2010 at 03:44:41AM -0800, Jeremy Chadwick wrote: > > On Wed, Feb 24, 2010 at 01:21:39PM +0200, Kostik Belousov wrote: > > > On Wed, Feb 24, 2010 at 06:53:59PM +1100, Peter Jeremy wrote: > > > > Updates following some off-line discussions and debugging with John= on > > > > IRC. I've cc'd gshapiro@ because the problem appears to be sendmai= l, > > > > rather than the FreeBSD kernel. > > > >=20 > > > > On 2010-Feb-23 12:35:22 +1100, John Marshall wrote: > > > > >Environment: sendmail 8.14.4 on FreeBSD 8.0-RELEASE-p2 > > > >=20 > > > > Note that this is stock ISC sendmail, not the sendmail in either the > > > > base system or the port. > > > >=20 > > > > >I posted about this in comp.mail.sendmail and was told... > > > > > > > > > >> sleep() should be one of these calls: > > > > >>=20 > > > > >> if (njobs =3D=3D 0 && WorkGrp[wgrp].wg_lowqintvl < MIN_S= LEEP_TIME) > > > > >> sleep(MIN_SLEEP_TIME); > > > > >> else if (WorkGrp[wgrp].wg_lowqintvl <=3D 0) > > > > >> sleep(QueueIntvl > 0 ? QueueIntvl : MIN_SLEEP_TI= ME); > > > > >> else > > > > >> sleep(WorkGrp[wgrp].wg_lowqintvl); > > > >=20 > > > > Whilst it's true that the code calls sleep(), it's not calling > > > > sleep(3) in the FreeBSD libc. Instead it's calling a sleep() defin= ed > > > > in libsm/clock.c - which is a horrible maze of #ifdefs. > > > >=20 > > > > John has pre-processed that code and the result it at: > > > > http://www.riverwillow.net.au/~john/sm/clock.preprocessed > > > >=20 > > > > At a quick look, the code is broken: sm_seteventm() generates a > > > > one-off timer using setitimer(2), which will send SIGALRM when it > > > > expires. sm_releasesignal() then unblocks SIGALRM. In theory, the > > > > SIGALRM could be delivered anywhere after the (!SmSleepDone) test a= nd > > > > before pause() is called - in which case, the signal is lost and > > > > pause() will sleep forever. > > > >=20 > > > > On 2010-Feb-24 08:13:06 +1100, John Marshall wrote: > > > > >My ktrace file was created with 'ktrace -g 48501'. I have the res= ult of > > > > >'kdump -R -p 48504' available at: > > > > > > > > > > > Regarding sigsuspend() returning EINTR without delivering any signal, > could it be that the sendmail process was debugged ? No. I didn't touch the process with anything this time. There was no debugger in use on the system. That was how I found the process first thing this morning so I sent off the kdump output. The process stayed in the same state until I rebooted the system this afternoon to install a kernel with debug symbols and options. I have done the same on the other two servers, so I can dig deeper for you next time. I am running ktrace on the sendmail process group on all three servers waiting to catch the next one. By the way, all three are i386 with SMP. --=20 John Marshall --rwEMma7ioTxnRzrJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuFHl0ACgkQw/tAaKKahKJRdgCfRxvijTaEMlWR1EJxbQbAhio1 Ki8AnAs43Q+xKJLF00Eb6LFqodfUwQJe =xIJd -----END PGP SIGNATURE----- --rwEMma7ioTxnRzrJ-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 15:00:24 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 282971065673; Wed, 24 Feb 2010 15:00:24 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id F35F08FC1C; Wed, 24 Feb 2010 15:00:22 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA16547; Wed, 24 Feb 2010 17:00:15 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B853EFF.9040406@icyb.net.ua> Date: Wed, 24 Feb 2010 17:00:15 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20100211) MIME-Version: 1.0 To: George Liaskos References: <1266934981.00222684.1266922202@10.7.7.3> <1266938581.00222692.1266925802@10.7.7.3> <4B83F93A.4030805@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: ahcich timeouts, only with ahci, not with ataahci X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 15:00:24 -0000 on 23/02/2010 21:13 George Liaskos said the following: > I booted my old kernel (was from Feb 13) and i had the same issue. > > The timeout occurs when i try to burn CDs with the k3b application, > after some queries i found this thread: > http://www.pubbs.net/kde/200910/40852/ > > I have no problem burning CDs with cdrecord so i guess this must be an > error at the application level as described. > > This is the verbose message i get. > > ahcich1: Timeout on slot 2 > ahcich1: is 00000000 cs 0000000c ss 00000000 rs 0000000c tfd d0 serr 00000000 > ahcich1: AHCI reset... > ahcich1: hardware reset ... > ahcich1: SATA connect time=0ms status=00000113 > ahcich1: ready wait time=25ms > ahcich1: AHCI reset done: device found > > If this case is of any interest for further debugging let me know. > > Regards and sorry for the noise. k3b FreeBSD code has known bugs, it issues wrong SCSI commands in some cases. I submitted my patches to k3b upstream developer, but they are not included still. -- Andriy Gapon From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 16:38:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 929A41065676 for ; Wed, 24 Feb 2010 16:38:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 15CC48FC17 for ; Wed, 24 Feb 2010 16:38:21 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o1OGc4ls016675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Feb 2010 18:38:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o1OGc4iI091694 for ; Wed, 24 Feb 2010 18:38:04 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id o1OGc3V7091693 for freebsd-stable@freebsd.org; Wed, 24 Feb 2010 18:38:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Feb 2010 18:38:03 +0200 From: Kostik Belousov To: freebsd-stable@freebsd.org Message-ID: <20100224163803.GW50403@deviant.kiev.zoral.com.ua> References: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> <20100224075359.GA61876@server.vk2pj.dyndns.org> <20100224112139.GT50403@deviant.kiev.zoral.com.ua> <20100224114441.GA57760@icarus.home.lan> <20100224122045.GU50403@deviant.kiev.zoral.com.ua> <20100224124101.GC14464@rwpc12.mby.riverwillow.net.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iASP2QDfFF5MN+I5" Content-Disposition: inline In-Reply-To: <20100224124101.GC14464@rwpc12.mby.riverwillow.net.au> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Subject: Re: sleep(3) sometimes too sleepy on FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 16:38:23 -0000 --iASP2QDfFF5MN+I5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 24, 2010 at 11:41:01PM +1100, John Marshall wrote: > On Wed, 24 Feb 2010, 14:20 +0200, Kostik Belousov wrote: > > On Wed, Feb 24, 2010 at 03:44:41AM -0800, Jeremy Chadwick wrote: > > > On Wed, Feb 24, 2010 at 01:21:39PM +0200, Kostik Belousov wrote: > > > > On Wed, Feb 24, 2010 at 06:53:59PM +1100, Peter Jeremy wrote: > > > > > Updates following some off-line discussions and debugging with Jo= hn on > > > > > IRC. I've cc'd gshapiro@ because the problem appears to be sendm= ail, > > > > > rather than the FreeBSD kernel. > > > > >=20 > > > > > On 2010-Feb-23 12:35:22 +1100, John Marshall wrote: > > > > > >Environment: sendmail 8.14.4 on FreeBSD 8.0-RELEASE-p2 > > > > >=20 > > > > > Note that this is stock ISC sendmail, not the sendmail in either = the > > > > > base system or the port. > > > > >=20 > > > > > >I posted about this in comp.mail.sendmail and was told... > > > > > > > > > > > >> sleep() should be one of these calls: > > > > > >>=20 > > > > > >> if (njobs =3D=3D 0 && WorkGrp[wgrp].wg_lowqintvl < MIN= _SLEEP_TIME) > > > > > >> sleep(MIN_SLEEP_TIME); > > > > > >> else if (WorkGrp[wgrp].wg_lowqintvl <=3D 0) > > > > > >> sleep(QueueIntvl > 0 ? QueueIntvl : MIN_SLEEP_= TIME); > > > > > >> else > > > > > >> sleep(WorkGrp[wgrp].wg_lowqintvl); > > > > >=20 > > > > > Whilst it's true that the code calls sleep(), it's not calling > > > > > sleep(3) in the FreeBSD libc. Instead it's calling a sleep() def= ined > > > > > in libsm/clock.c - which is a horrible maze of #ifdefs. > > > > >=20 > > > > > John has pre-processed that code and the result it at: > > > > > http://www.riverwillow.net.au/~john/sm/clock.preprocessed > > > > >=20 > > > > > At a quick look, the code is broken: sm_seteventm() generates a > > > > > one-off timer using setitimer(2), which will send SIGALRM when it > > > > > expires. sm_releasesignal() then unblocks SIGALRM. In theory, t= he > > > > > SIGALRM could be delivered anywhere after the (!SmSleepDone) test= and > > > > > before pause() is called - in which case, the signal is lost and > > > > > pause() will sleep forever. > > > > >=20 > > > > > On 2010-Feb-24 08:13:06 +1100, John Marshall wrote: > > > > > >My ktrace file was created with 'ktrace -g 48501'. I have the r= esult of > > > > > >'kdump -R -p 48504' available at: > > > > > > > > > > > > >=20 > > Regarding sigsuspend() returning EINTR without delivering any signal, > > could it be that the sendmail process was debugged ? >=20 > No. I didn't touch the process with anything this time. There was no > debugger in use on the system. That was how I found the process first > thing this morning so I sent off the kdump output. >=20 > The process stayed in the same state until I rebooted the system this > afternoon to install a kernel with debug symbols and options. I have > done the same on the other two servers, so I can dig deeper for you next > time. I am running ktrace on the sendmail process group on all three > servers waiting to catch the next one. By the way, all three are i386 > with SMP. Kernel debugging is not much needed at this stage. I would be interested if you tried latest RELENG_8 kernel, in regard the sigsuspend(2) returning with EINTR without a signal delivered. Our pause(3) as is has two problems not related to the issue you see. One is that it uses sigcompat(3) routines, bringing them into namespace when pause is used. Second, that is a consequence of first, is that realtime signals are blocked during pause(3). While testing this patch, I noted that kill(1) cannot send realtime signals to the processes. The usual race with pause() is there, it cannot be solved. diff --git a/bin/kill/kill.c b/bin/kill/kill.c index bb9982e..8ee1d85 100644 --- a/bin/kill/kill.c +++ b/bin/kill/kill.c @@ -108,7 +108,7 @@ main(int argc, char *argv[]) numsig =3D strtol(*argv, &ep, 10); if (!**argv || *ep) errx(1, "illegal signal number: %s", *argv); - if (numsig < 0 || numsig >=3D sys_nsig) + if (numsig < 0) nosig(*argv); } else nosig(*argv); diff --git a/lib/libc/gen/pause.c b/lib/libc/gen/pause.c index 00bf833..51706cf 100644 --- a/lib/libc/gen/pause.c +++ b/lib/libc/gen/pause.c @@ -33,8 +33,10 @@ static char sccsid[] =3D "@(#)pause.c 8.1 (Berkeley) 6/4= /93"; #include __FBSDID("$FreeBSD$"); =20 +#include "namespace.h" #include #include +#include "un-namespace.h" =20 /* * Backwards compatible pause. @@ -42,7 +44,11 @@ __FBSDID("$FreeBSD$"); int __pause(void) { - return sigpause(sigblock(0L)); + sigset_t oset; + + if (_sigprocmask(SIG_BLOCK, NULL, &oset) =3D=3D -1) + return (-1); + return (_sigsuspend(&oset)); } __weak_reference(__pause, pause); __weak_reference(__pause, _pause); --iASP2QDfFF5MN+I5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuFVeoACgkQC3+MBN1Mb4hyQwCg5bvyjvb5DRs23f+qq+1KNfaa zw8An3UoqbAuQbPZ1SN4lg0KWvvgM5Q8 =25ul -----END PGP SIGNATURE----- --iASP2QDfFF5MN+I5-- From owner-freebsd-stable@FreeBSD.ORG Wed Feb 24 16:52:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 327B5106564A for ; Wed, 24 Feb 2010 16:52:04 +0000 (UTC) (envelope-from faber@zod.isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id 158BC8FC13 for ; Wed, 24 Feb 2010 16:52:03 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.3/8.14.3) with ESMTP id o1OGq3PU010727 for ; Wed, 24 Feb 2010 08:52:03 -0800 (PST) (envelope-from faber@zod.isi.edu) Received: (from faber@localhost) by zod.isi.edu (8.14.3/8.14.3/Submit) id o1OGq3vY010726 for freebsd-stable@freebsd.org; Wed, 24 Feb 2010 08:52:03 -0800 (PST) (envelope-from faber) Date: Wed, 24 Feb 2010 08:52:03 -0800 From: Ted Faber To: freebsd-stable@freebsd.org Message-ID: <20100224165203.GA10423@zod.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber Subject: resume slow on Thinkpad T42 FreeBSD 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2010 16:52:04 -0000 --7iMSBzlTiPOCCT2k Content-Type: multipart/mixed; boundary="FCuugMFkClbJLl1L" Content-Disposition: inline --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm running a recent (yesterday) FreeBSD 8-STABLE on my T42. When I resume from suspend the fan starts screen returns immediately (to text mode) and then the system idles for about a minute until it shakes itself awake. The keyboard LEDs cycle, the disk runs and X returns. I don't recall this stutter under FreeBSD 7. I've tried both settings of hw.acpi.reset_video and neither helps (nor hurts). BIOS is also upgraded to the most recent and the stutter occurred with before and after the upgrade. I have attached a trace of a boot -v going through the cycle. The t_delta entries happen after the machine wakes but before it restores itself. There'a also sometimes a message from acpi_ec0 saying that the EC woke up before the sleep event, but I wasn't able to capture it during this trace. Any help would be appreciated, and I'm happy to provide more data on request. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --FCuugMFkClbJLl1L Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.v" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #26: Tue Feb 23 17:40:06 PST 2010 root@praxis.lunabase.org:/usr/obj/usr/src/sys/GENERIC i386 Preloaded elf kernel "/boot/kernel/kernel" at 0xc101b000. Preloaded elf module "/boot/kernel/snd_ich.ko" at 0xc101b1a8. Preloaded elf module "/boot/kernel/sound.ko" at 0xc101b254. Preloaded elf module "/boot/kernel/acpi_ibm.ko" at 0xc101b300. Preloaded elf module "/boot/modules/video4bsd.ko" at 0xc101b3b0. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1698567746 Hz CPU: Intel(R) Pentium(R) M processor 1.70GHz (1698.57-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x6d6 Stepping =3D 6 Features=3D0xafe9f9bf Features2=3D0x180 Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries Data TLB: 4 KB Pages, 4-way set associative, 128 entries Instruction TLB: 4 MB pages, fully associative, 2 entries 2nd-level cache: 2-MB, 8-way set associative, 64-byte line size 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size Data TLB: 4 MB Pages, 4-way set associative, 8 entries 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size real memory =3D 1610612736 (1536 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001426000 - 0x000000005e412fff, 1560203264 bytes (380909 pages) avail memory =3D 1558867968 (1486 MB) bios32: Found BIOS32 Service Directory header at 0xc00f6d20 bios32: Entry =3D 0xfd750 (c00fd750) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xfd6e0+0x1f6 pnpbios: Found PnP BIOS data at 0xc00f6da0 pnpbios: Entry =3D f0000:b616 Rev =3D 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: ULE: setup cpu 0 video4bsd: /dev/video0..9, /dev/video_daemon0..9 snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [10= 24] feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 feeder_ra= te_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device io: kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 ACPI: RSDP 0xf6d70 00024 (v2 IBM ) ACPI: XSDT 0x5ff6a672 0004C (v1 IBM TP-1R 00003230 LTP 00000000) ACPI: FACP 0x5ff6a700 000F4 (v3 IBM TP-1R 00003230 IBM 00000001) ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20100121/tbfadt-62= 5) ACPI Warning: Optional field Gpe1Block has zero address or length: 0= 102C/0 (20100121/tbfadt-655) ACPI: DSDT 0x5ff6a8e7 0C530 (v1 IBM TP-1R 00003230 MSFT 0100000E) ACPI: FACS 0x5ff78000 00040 ACPI: SSDT 0x5ff6a8b4 00033 (v1 IBM TP-1R 00003230 MSFT 0100000E) ACPI: ECDT 0x5ff76e17 00052 (v1 IBM TP-1R 00003230 IBM 00000001) ACPI: TCPA 0x5ff76e69 00032 (v1 IBM TP-1R 00003230 PTL 00000001) ACPI: BOOT 0x5ff76fd8 00028 (v1 IBM TP-1R 00003230 LTP 00000001) npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] acpi0: [ITHREAD] acpi_ec0: port 0x62,0x66 on acpi0 pci_open(1): mode 1 addr port (0x0cf8) is 0x8000f904 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there (id=3D33408086) pcibios: BIOS version 2.10 AcpiOsDerivePciId: \\_SB_.PCI0.MHCS -> bus 0 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.PCI1.CBS0.CBUS -> bus 2 dev 0 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.PCI1.CBS1.CBUS -> bus 2 dev 0 func 1 AcpiOsDerivePciId: \\_SB_.PCI0.USB7.U7CS -> bus 0 dev 29 func 7 acpi0: Power Button (fixed) acpi0: wakeup code va 0xc4cb9000 pa 0x1000 atpic: Programming IRQ9 as level/low AcpiOsDerivePciId: \\_SB_.PCI0.LPC_.LPCS -> bus 0 dev 31 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 5ff00000 (3) failed ACPI timer: 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 1/0 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 Validation 0 255 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 Validation 0 255 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 9 10 11 Validation 0 255 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 9 10 11 Validation 0 11 N 0 3 4 5 6 7 9 10 11 After Disable 0 255 N 0 3 4 5 6 7 9 10 11 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI: Found matching pin for 0.29.INTA at func 0: 11 ACPI: Found matching pin for 0.29.INTB at func 1: 11 ACPI: Found matching pin for 0.29.INTC at func 2: 11 ACPI: Found matching pin for 0.29.INTD at func 7: 11 ACPI: Found matching pin for 0.31.INTA at func 1: 255 ACPI: Found matching pin for 0.31.INTB at func 3: 11 pci0: on pcib0 pci0: domain=3D0, physical bus=3D0 found-> vendor=3D0x8086, dev=3D0x3340, revid=3D0x03 domain=3D0, bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x2090, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xd0000000, size 28, ena= bled found-> vendor=3D0x8086, dev=3D0x3341, revid=3D0x03 domain=3D0, bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x00a0, cachelnsz=3D0 (dwords) lattimer=3D0x60 (2880 ns), mingnt=3D0x0c (3000 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x24c2, revid=3D0x01 domain=3D0, bus=3D0, slot=3D29, func=3D0 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 map[20]: type I/O Port, range 32, base 0x1800, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.LNKA:0) pcib0: slot 29 INTA routed to irq 11 via \\_SB_.LNKA unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1800 found-> vendor=3D0x8086, dev=3D0x24c4, revid=3D0x01 domain=3D0, bus=3D0, slot=3D29, func=3D1 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[20]: type I/O Port, range 32, base 0x1820, size 5, enabled pcib0: matched entry for 0.29.INTB (src \\_SB_.LNKD:0) pcib0: slot 29 INTB routed to irq 11 via \\_SB_.LNKD unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1820 found-> vendor=3D0x8086, dev=3D0x24c7, revid=3D0x01 domain=3D0, bus=3D0, slot=3D29, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dc, irq=3D11 map[20]: type I/O Port, range 32, base 0x1840, size 5, enabled pcib0: matched entry for 0.29.INTC (src \\_SB_.LNKC:0) pcib0: slot 29 INTC routed to irq 11 via \\_SB_.LNKC unknown: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1840 found-> vendor=3D0x8086, dev=3D0x24cd, revid=3D0x01 domain=3D0, bus=3D0, slot=3D29, func=3D7 class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dd, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xc0000000, size 10, enabled pcib0: matched entry for 0.29.INTD (src \\_SB_.LNKH:0) pcib0: slot 29 INTD routed to irq 11 via \\_SB_.LNKH unknown: Reserved 0x400 bytes for rid 0x10 type 3 at 0xc0000000 found-> vendor=3D0x8086, dev=3D0x2448, revid=3D0x81 domain=3D0, bus=3D0, slot=3D30, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x8080, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x24cc, revid=3D0x01 domain=3D0, bus=3D0, slot=3D31, func=3D0 class=3D06-01-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x000f, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x24ca, revid=3D0x01 domain=3D0, bus=3D0, slot=3D31, func=3D1 class=3D01-01-8a, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D255 map[20]: type I/O Port, range 32, base 0x1860, size 4, enabled map[24]: type Memory, range 32, base 0, size 10, memory disabled found-> vendor=3D0x8086, dev=3D0x24c3, revid=3D0x01 domain=3D0, bus=3D0, slot=3D31, func=3D3 class=3D0c-05-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0001, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 map[20]: type I/O Port, range 32, base 0x1880, size 5, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB:0) pcib0: slot 31 INTB routed to irq 11 via \\_SB_.LNKB found-> vendor=3D0x8086, dev=3D0x24c5, revid=3D0x01 domain=3D0, bus=3D0, slot=3D31, func=3D5 class=3D04-01-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x1c00, size 8, enabled map[14]: type I/O Port, range 32, base 0x18c0, size 6, enabled map[18]: type Memory, range 32, base 0xc0000c00, size 9, enabled map[1c]: type Memory, range 32, base 0xc0000800, size 8, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB:0) pcib0: slot 31 INTB routed to irq 11 via \\_SB_.LNKB found-> vendor=3D0x8086, dev=3D0x24c6, revid=3D0x01 domain=3D0, bus=3D0, slot=3D31, func=3D6 class=3D07-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Db, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0x2400, size 8, enabled map[14]: type I/O Port, range 32, base 0x2000, size 7, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB:0) pcib0: slot 31 INTB routed to irq 11 via \\_SB_.LNKB agp0: on hostb0 hostb0: Reserved 0x10000000 bytes for rid 0x10 type 3 at 0xd0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x3000-0x3fff pcib1: memory decode 0xc0100000-0xc01fffff pcib1: prefetched decode 0xe0000000-0xe7ffffff ACPI: Found matching pin for 1.0.INTA at func 0: 11 pci1: on pcib1 pci1: domain=3D0, physical bus=3D1 found-> vendor=3D0x1002, dev=3D0x4c57, revid=3D0x00 domain=3D0, bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0387, statreg=3D0x02b0, cachelnsz=3D8 (dwords) lattimer=3D0x42 (1980 ns), mingnt=3D0x08 (2000 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xe0000000, size 27, ena= bled pcib1: requested memory range 0xe0000000-0xe7ffffff: good map[14]: type I/O Port, range 32, base 0x3000, size 8, enabled pcib1: requested I/O range 0x3000-0x30ff: in range map[18]: type Memory, range 32, base 0xc0100000, size 16, enabled pcib1: requested memory range 0xc0100000-0xc010ffff: good pcib1: matched entry for 1.0.INTA (src \\_SB_.LNKA:0) pcib1: slot 0 INTA routed to irq 11 via \\_SB_.LNKA vgapci0: port 0x3000-0x30ff mem 0xe0000000-0xe7fff= fff,0xc0100000-0xc010ffff irq 11 at device 0.0 on pci1 uhci0: port 0x1800-0x181f irq 1= 1 at device 29.0 on pci0 uhci0: [MPSAFE] uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x1820-0x183f irq 1= 1 at device 29.1 on pci0 uhci1: [MPSAFE] uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x1840-0x185f irq 1= 1 at device 29.2 on pci0 uhci2: [MPSAFE] uhci2: [ITHREAD] usbus2: on uhci2 ehci0: mem 0xc0000000-0xc0000= 3ff irq 11 at device 29.7 on pci0 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pcib2: at device 30.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 8 pcib2: I/O decode 0x4000-0x8fff pcib2: memory decode 0xc0200000-0xcfffffff pcib2: prefetched decode 0xe8000000-0xefffffff pcib2: Subtractively decoded bridge. ACPI: Found matching pin for 2.0.INTA at func 0: 11 ACPI: Found matching pin for 2.0.INTB at func 1: 11 ACPI: Found matching pin for 2.1.INTA at func 0: 11 ACPI: Found matching pin for 2.2.INTA at func 0: 11 pci2: on pcib2 pci2: domain=3D0, physical bus=3D2 found-> vendor=3D0x104c, dev=3D0xac46, revid=3D0x01 domain=3D0, bus=3D2, slot=3D0, func=3D0 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xc0 (48000 ns), maxlat=3D0x03 (750 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xb0000000, size 12, enabled pcib2: requested memory range 0xb0000000-0xb0000fff: good pcib2: matched entry for 2.0.INTA (src \\_SB_.LNKA:0) pcib2: slot 0 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=3D0x104c, dev=3D0xac46, revid=3D0x01 domain=3D0, bus=3D2, slot=3D0, func=3D1 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0107, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xc0 (48000 ns), maxlat=3D0x03 (750 ns) intpin=3Db, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xb1000000, size 12, enabled pcib2: requested memory range 0xb1000000-0xb1000fff: good pcib2: matched entry for 2.0.INTB (src \\_SB_.LNKB:0) pcib2: slot 0 INTB routed to irq 11 via \\_SB_.LNKB found-> vendor=3D0x8086, dev=3D0x101e, revid=3D0x03 domain=3D0, bus=3D2, slot=3D1, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0117, statreg=3D0x0230, cachelnsz=3D8 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0xff (63750 ns), maxlat=3D0x00 (0 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xc0240000, size 17, enabled pcib2: requested memory range 0xc0240000-0xc025ffff: good map[14]: type Memory, range 32, base 0xc0200000, size 16, enabled pcib2: requested memory range 0xc0200000-0xc020ffff: good map[18]: type I/O Port, range 32, base 0x8000, size 6, enabled pcib2: requested I/O range 0x8000-0x803f: in range pcib2: matched entry for 2.1.INTA (src \\_SB_.LNKA:0) pcib2: slot 1 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=3D0x168c, dev=3D0x1014, revid=3D0x01 domain=3D0, bus=3D2, slot=3D2, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0116, statreg=3D0x0290, cachelnsz=3D8 (dwords) lattimer=3D0x50 (2400 ns), mingnt=3D0x0a (2500 ns), maxlat=3D0x1c (7000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xc0210000, size 16, enabled pcib2: requested memory range 0xc0210000-0xc021ffff: good pcib2: matched entry for 2.2.INTA (src \\_SB_.LNKC:0) pcib2: slot 2 INTA routed to irq 11 via \\_SB_.LNKC cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 o= n pci2 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xb0000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: [FILTER] cbb0: PCI Configuration space: 0x00: 0xac46104c 0x02100107 0x06070001 0x00824008=20 0x10: 0xb0000000 0x020000a0 0xb0050302 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc=20 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b=20 0x40: 0x05521014 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x0840d071 0x040a0000 0x000f0000 0x01d21b22=20 0x90: 0x416402c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 cbb1: mem 0xb1000000-0xb1000fff irq 11 at device 0.1 o= n pci2 cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xb1000000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] cbb1: [FILTER] cbb1: PCI Configuration space: 0x00: 0xac46104c 0x02100107 0x06070001 0x00824008=20 0x10: 0xb1000000 0x020000a0 0xb0080602 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc=20 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740020b=20 0x40: 0x05521014 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x0840d071 0x040a0000 0x000f0000 0x01d21b22=20 0x90: 0x416402c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 em0: port 0x8000-0x803f mem 0= xc0240000-0xc025ffff,0xc0200000-0xc020ffff irq 11 at device 1.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xc0240000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0x8000 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:11:25:af:f8:9b ath0: mem 0xc0210000-0xc021ffff irq 11 at device 2.0 on pci2 ath0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xc0210000 ath0: [MPSAFE] ath0: [ITHREAD] ath0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps ath0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps ath0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbp= s 36Mbps 48Mbps 54Mbps ath0: AR5212 mac 5.6 RF5111 phy 4.1 ath0: Use hw queue 1 for WME_AC_BE traffic ath0: Use hw queue 0 for WME_AC_BK traffic ath0: Use hw queue 2 for WME_AC_VI traffic ath0: Use hw queue 3 for WME_AC_VO traffic ath0: Use hw queue 8 for CAB traffic ath0: Use hw queue 9 for beacons isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x1860-0x186f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1860 ata0: 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=3D03 ostat0=3D50 ostat1=3D00 ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ata0: [MPSAFE] ata0: [ITHREAD] ata1: 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=3D03 ostat0=3D50 ostat1=3D00 ata1: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1: stat1=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x10000 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 31.3 (no driver attached) pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xc0000c0= 0-0xc0000dff,0xc0000800-0xc00008ff irq 11 at device 31.5 on pci0 pcm0: Reserved 0x200 bytes for rid 0x18 type 3 at 0xc0000c00 pcm0: Reserved 0x100 bytes for rid 0x1c type 3 at 0xc0000800 pcm0: [MPSAFE] pcm0: [ITHREAD] pcm0: pcm0: Codec features headphone, 20 bit DAC, 5 bit master volume, no 3D Ster= eo Enhancement pcm0: Primary codec extended features variable rate PCM, AMAP, reserved 4 pcm0: ac97 codec dac ready count: 0 pcm0: Mixer "vol": pcm0: Mixer "pcm": pcm0: Mixer "line": pcm0: Mixer "mic": pcm0: Mixer "cd": pcm0: Mixer "rec": pcm0: Mixer "igain": pcm0: Mixer "ogain": pcm0: Mixer "line1": pcm0: Mixer "phin": pcm0: Mixer "phout": pcm0: clone manager: deadline=3D750ms flags=3D0x8000001e pcm0: sndbuf_setmap 213c000, 4000; 0xe5528000 -> 213c000 pcm0: sndbuf_setmap 2140000, 4000; 0xe552c000 -> 2140000 pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x54ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0047 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 ppc0: using extended I/O port range ppc0: SPP ppc0: port 0x3bc-0x3be irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [MPSAFE] ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached plip0: [MPSAFE] plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [MPSAFE] lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 battery0: on acpi0 acpi_acad0: on acpi0 acpi_ibm0: on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 1: ioport 0x1c00 alloc failed pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0x= d1fff,0xdc000-0xdffff,0xe0000-0xeffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0 failed to probe at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 uart0: failed to probe at port 0x3f8-0x3ff irq 4 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 101622 -> 100000 procfs registered Timecounter "TSC" frequency 1698567746 Hz quality 800 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached hptrr: no controller detected. ata0: Identifying devices: 00000001 ata0: New devices: 00000001 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ata0-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA100 cable=3D80 wire battery0: ad0: setting UDMA100 battery initialization start ad0: 38154MB at ata0-master UDMA100=20 ad0: 78140160 sectors [77520C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 acpi_acad0: acline initialization start ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 battery0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1: Identifying devices: 00010000 ata1: New devices: 00010000 ata1-master: pio=3DPIO4 wdma=3DWDMA2 udma=3DUDMA33 cable=3D40 wire acd0: setting UDMA33 GEOM: ad0s1: geometry does not match label (255h,63s !=3D 16h,63s). acd0: CDRW drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 4134KB/s (4134KB/s), 2048KB buffer, UD= MA33=20 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pcm0: measured ac97 link rate at 48000 Hz ATA PseudoRAID loaded Root mount waiting for: usbus3 usbus2 usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered Root mount waiting for: usbus3 Root mount waiting for: usbus3 uhub3: 6 ports with 6 removable, self powered Trying to mount root from ufs:/dev/label/root ct_to_ts([2010-02-24 02:59:39]) =3D 1266980379.000000000 start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered wlan0: bpf attached wlan0: bpf attached wlan0: Ethernet address: 00:05:4e:48:a4:d3 acd0: FAILURE - ATA_IDENTIFY status=3D51 error=3D4 LBA=3D0 splash: image decoder found: green_saver drm0: on vgapci0 vgapci0: Reserved 0x10000 bytes for rid 0x18 type 3 at 0xc0100000 vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xd0000000 256MB info: [drm] Initialized radeon 1.31.0 20080613 vgapci0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: Setting AGP v2 mode 4 info: [drm] Setting GART location based on new memory map info: [drm] Loading R100 Microcode info: [drm] writeback test succeeded in 2 usecs drm0: [MPSAFE] drm0: [ITHREAD] acpi_button0: sleep button pressed acpi_lid0: wake_prep enabled for \\_SB_.LID_ (S3) acpi_button0: wake_prep enabled for \\_SB_.SLPB (S3) pci0:1:0:0: Transition from D0 to D3 pci0:2:1:0: Transition from D0 to D3 pci0:2:2:0: Transition from D0 to D3 ct_to_ts([2010-02-24 03:00:27]) =3D 1266980427.000000000 vga0: saving 68 bytes of video state pci0:0:29:7: Transition from D0 to D3 pci0:0:31:5: Transition from D0 to D3 =3D=3D=3D=3D=3D=3D=3D=3D acpi_printcpu() debug dump =3D=3D=3D=3D=3D=3D=3D=3D gdt[0097:c0e112a0] idt[07ff:c0e19900] ldt[0050] tr[0048] efl[00080006] eax[0141e000] ebx[00000000] ecx[c141e000] edx[0141e000] esi[c5206100] edi[00080202] ebp[e7b5bb54] esp[e7b5bb34] cr0[8005003b] cr2[298fe000] cr3[0141e000] cr4[00000691] cs[0020] ds[0028] es[0028] fs[0008] gs[001b] ss[0028] =3D=3D=3D=3D=3D=3D=3D=3D acpi_printcpu() debug dump =3D=3D=3D=3D=3D=3D=3D=3D gdt[0097:c0e112a0] idt[07ff:c0e19900] ldt[0050] tr[0048] efl[00000002] eax[c59ddb01] ebx[00000000] ecx[00000004] edx[c59ddb90] esi[c5206100] edi[00080202] ebp[e7b5bb54] esp[e7b5bb34] cr0[8005003b] cr2[298fe000] cr3[0141e000] cr4[00000691] cs[0020] ds[0028] es[0028] fs[0008] gs[001b] ss[0028] acpi_lid0: run_prep cleaned up for \\_SB_.LID_ acpi_button0: run_prep cleaned up for \\_SB_.SLPB t_delta 15.fbd0cbf2eb820000 too short t_delta 15.fbd0cbf2eb820000 too short t_delta 16.09e0783237180000 too long ct_to_ts([2010-02-24 03:01:38]) =3D 1266980498.000000000 wakeup from sleeping state (slept 00:01:11) ata0: reiniting channel .. ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata0: stat0=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: stat1=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ad0: setting UDMA100 ata0: reinit done .. ata1: reiniting channel .. ata1: reset tp1 mask=3D03 ostat0=3D00 ostat1=3D00 ata1: stat0=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1: stat1=3D0x00 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D00 stat1=3D00 devices=3D0x10000 acd0: setting UDMA33 ata1: reinit done .. atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x54ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa battery0: battery initialization start battery0: battery initialization done, tried 1 times agp0: Setting AGP v2 mode 4 info: [drm] Loading R100 Microcode --FCuugMFkClbJLl1L-- --7iMSBzlTiPOCCT2k Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuFWTMACgkQaUz3f+Zf+Xt5+gCgwLslpSWSQU+xQkGenPTf7M+u Kh0AnigOveO9eQ4BN2NvhSAFAhUUl5eu =1vA3 -----END PGP SIGNATURE----- --7iMSBzlTiPOCCT2k-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 00:17:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CA79106566B for ; Thu, 25 Feb 2010 00:17:37 +0000 (UTC) (envelope-from brian.scott4@det.nsw.edu.au) Received: from up-mx1.det.nsw.edu.au (up-mx1.det.nsw.edu.au [153.107.41.147]) by mx1.freebsd.org (Postfix) with ESMTP id 9A84A8FC08 for ; Thu, 25 Feb 2010 00:17:36 +0000 (UTC) Received: from slppmxmm02.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-mx1.det.nsw.edu.au (8.13.8/8.13.8) with ESMTP id o1P0HXDB023281; Thu, 25 Feb 2010 11:17:34 +1100 Received: from itfexhub4.central.det.win (Not Verified[153.107.9.31]) by slppmxmm02.central.det.win with MailMarshal (v6, 5, 4, 7535) id ; Thu, 25 Feb 2010 11:17:33 +1100 Received: from ALF2.riverina.det.win ([172.18.8.18]) by itfexhub4.central.det.win with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Feb 2010 11:17:32 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Feb 2010 11:17:32 +1100 Message-ID: In-Reply-To: <20100224112311.73ac53f6.gerrit@pmp.uni-hannover.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: nss_ldap and multiple group memberships Thread-Index: Acq1O4sJRn9jMoUKT1aRlOi+9WIS+QAcNyVA References: <20100224112311.73ac53f6.gerrit@pmp.uni-hannover.de> From: "Scott, Brian" To: =?iso-8859-1?Q?Gerrit_K=FChn?= , X-OriginalArrivalTime: 25 Feb 2010 00:17:32.0846 (UTC) FILETIME=[ECB1CCE0:01CAB5AF] Cc: Subject: RE: nss_ldap and multiple group memberships X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 00:17:37 -0000 It depends on the type of group. There are at least two types of group ob= jects that you can use in LDAP but only one of them works. You need to us= e posixGroup objects for unix groups. As I remember it, these have member= Uid attributes for the member ids. These are simple unix identifiers. gro= upOfNames objects on the other hand have full distinguished names with 'm= ember' attributes and can't be used by nss_ldap. The idea is that posixGroup and posixAccount mimic the unix files so extr= action of the data is fast. If the software used a groupOfNames object th= en the returned member names would need to queried as additional transact= ions to find the uid's of those entries that had posixAccount information= . This is because the original authentication was done by pam_ldap and th= at just returned a UID to the system. If it returned the LDAP distinguish= ed name to the system, and if that could then be passed into nss_ldap it = would be possible to do the LDAP query in a single transaction. But then = that all breaks down if you authenticate with something else like GSSAPI.= =20If that was the case you would need to first search for the posixAccou= nt object of the authenticated user (&(objectClass=3DposixAccount)(uid=3D= 1001)) and then search for all the group of names containing that disting= uished name (&(objectClass=3DgroupOfNames)(member=3Duid=3Dbscott,ou=3DPeo= ple,dc=3Dnetlab,dc=3Dalbury,dc=3Dtafe)). That's two transactions and seem= s unnecessarily wasteful. Mind you, if it was an option I'd probably turn= =20it on. Brian -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freeb= sd.org] On Behalf Of Gerrit K=FChn Sent: Wednesday, 24 February 2010 9:23 PM To: freebsd-stable@freebsd.org Subject: nss_ldap and multiple group memberships Hi all, Is anyone here using nss_ldap and can successfully get it to work with mu= ltiple group memberships? I would really like to get this to work here, b= ut I only get the primary group: penumbra# id gekueh uid=3D1030(gekueh) gid=3D1012(aei) groups=3D1012(aei) getent group comes up with the complete group list. ldapsearch reports th= ree groups with member:-lines for my user. Somehow nss does not pick this= =20up. Any ideas? cu =20 Gerrit _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"= ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 00:21:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08B46106566C for ; Thu, 25 Feb 2010 00:21:12 +0000 (UTC) (envelope-from peter@simons-rock.edu) Received: from hedwig.simons-rock.edu (hedwig.simons-rock.edu [208.81.88.14]) by mx1.freebsd.org (Postfix) with ESMTP id C18928FC13 for ; Thu, 25 Feb 2010 00:21:11 +0000 (UTC) Received: from cesium.hyperfine.info (c2.8d.5646.static.theplanet.com [70.86.141.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hedwig.simons-rock.edu (Postfix) with ESMTP id E9AEF2BB33E; Wed, 24 Feb 2010 19:21:09 -0500 (EST) Date: Wed, 24 Feb 2010 19:21:08 -0500 From: "Peter C. Lai" To: "Scott, Brian" Message-ID: <20100225002107.GU4648@cesium.hyperfine.info> References: <20100224112311.73ac53f6.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Gerrit =?iso-8859-1?Q?K=FChn?= , freebsd-stable@freebsd.org Subject: Re: nss_ldap and multiple group memberships X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 00:21:12 -0000 Wow this is a really well written explanation. On 2010-02-25 11:17:32AM +1100, Scott, Brian wrote: > It depends on the type of group. There are at least two types of group ob= jects that you can use in LDAP but only one of them works. You need to use = posixGroup objects for unix groups. As I remember it, these have memberUid = attributes for the member ids. These are simple unix identifiers. groupOfNa= mes objects on the other hand have full distinguished names with 'member' a= ttributes and can't be used by nss_ldap. >=20 > The idea is that posixGroup and posixAccount mimic the unix files so extr= action of the data is fast. If the software used a groupOfNames object then= the returned member names would need to queried as additional transactions= to find the uid's of those entries that had posixAccount information. This= is because the original authentication was done by pam_ldap and that just = returned a UID to the system. If it returned the LDAP distinguished name to= the system, and if that could then be passed into nss_ldap it would be pos= sible to do the LDAP query in a single transaction. But then that all break= s down if you authenticate with something else like GSSAPI. If that was the= case you would need to first search for the posixAccount object of the aut= henticated user (&(objectClass=3DposixAccount)(uid=3D1001)) and then search= for all the group of names containing that distinguished name (&(objectCla= ss=3DgroupOfNames)(member=3Duid=3Dbscott,ou=3DPeople,dc=3Dnetlab,dc=3Dalbur= y,dc=3Dtafe)). That's two transactions and seems unnecessarily wasteful. Mi= nd you, if it was an option I'd probably turn it on. >=20 > Brian >=20 >=20 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freeb= sd.org] On Behalf Of Gerrit K=FChn > Sent: Wednesday, 24 February 2010 9:23 PM > To: freebsd-stable@freebsd.org > Subject: nss_ldap and multiple group memberships >=20 > Hi all, >=20 > Is anyone here using nss_ldap and can successfully get it to work with mu= ltiple group memberships? I would really like to get this to work here, but= I only get the primary group: >=20 > penumbra# id gekueh > uid=3D1030(gekueh) gid=3D1012(aei) groups=3D1012(aei) >=20 > getent group comes up with the complete group list. ldapsearch reports th= ree groups with member:-lines for my user. Somehow nss does not pick this u= p. Any ideas? >=20 >=20 > cu > Gerrit > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > ********************************************************************** > This message is intended for the addressee named and may contain > privileged information or confidential information or both. If you > are not the intended recipient please delete it and notify the sender. > ********************************************************************** > _______________________________________________ > 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 =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 Peter C. Lai | Bard College at Simon's Rock Systems Administrator | 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 =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 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 00:23:59 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2A901065673 for ; Thu, 25 Feb 2010 00:23:59 +0000 (UTC) (envelope-from freebsd-stable@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 8E3578FC16 for ; Thu, 25 Feb 2010 00:23:59 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1NkRWH-00072N-3L for freebsd-stable@freebsd.org; Thu, 25 Feb 2010 01:23:57 +0100 Received: from 78-1-147-61.adsl.net.t-com.hr ([78.1.147.61]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Feb 2010 01:23:57 +0100 Received: from ivoras by 78-1-147-61.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 25 Feb 2010 01:23:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: Ivan Voras Date: Thu, 25 Feb 2010 01:23:44 +0100 Lines: 30 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 78-1-147-61.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090612) In-Reply-To: Cc: freebsd-net@freebsd.org Subject: Re: 8-stable crashes in vmware (possible em driver issue?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 00:23:59 -0000 Ivan Voras wrote: > I have a fairly recent 8-stable machine running under VMWare ESXi 3.5 > (amd64 guest), which apparently crashes every few days from the same > causes: > > em0: discard frame w/o packet header > em0: discard frame w/o packet header > em0: discard frame w/o packet header > Panic string: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf > 0xffffff00490a6400 clashing In case someone is interested or has an idea - on this machine I have multiple crashed cores with similarily strange problems all connected with networking and/or the em driver: 1) em0: watchdog timeout -- resetting Fatal trap 12: page fault while in kernel mode current process = 0 (em0 taskq) 2) em0: watchdog timeout -- resetting Fatal trap 9: general protection fault while in kernel mode current process = 1219 (slapd) 3) em0: discard frame w/o packet header panic: sbdrop I'm scratching my head about the #2 above - I don't think trap#9 is usual. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 01:31:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D61C106564A; Thu, 25 Feb 2010 01:31:40 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6D8BF8FC16; Thu, 25 Feb 2010 01:31:39 +0000 (UTC) Received: by wwb22 with SMTP id 22so1767100wwb.13 for ; Wed, 24 Feb 2010 17:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=TX5cd4n6Xsv9PpHpXaxMAExcQoFiw+bXyw7yu/GRuqs=; b=R7bkZ4ZbQH8i/v8EYcaH5uRAoP+5hsC0pbu/zqX+PuY3zzBIgMEb7SFB/j0G/MH+H5 mKlIKTy3b3kz8BiDVhaLz7TuKY1keGCxkjf7p2i6lwJX1/JcVUceLVi3WkaE4fMAwHQz L4a2ZQn3is1QaHOfRp+3jnz3Sl7IcUxkbHLEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LT1ccVNNXzTiIM+zKrR92w8SNWe9dpNl+u8LbMmeKXGa6ILMTkUAuHzONiSZjZvUSK RWIZM1jjpoNBj8qJiZHBhPr7Yb9i2BxhWzw1lqL4nnpbd73P/lBg0FfU7sYMzVFK2dro IhHdoZuJfSfDvEvauNxXdkv3pHELo7Gu8/8Ds= MIME-Version: 1.0 Received: by 10.216.158.20 with SMTP id p20mr325969wek.55.1267061493370; Wed, 24 Feb 2010 17:31:33 -0800 (PST) In-Reply-To: References: Date: Wed, 24 Feb 2010 17:31:33 -0800 Message-ID: <2a41acea1002241731w723406c3q7ab9aa79a2f92af5@mail.gmail.com> From: Jack Vogel To: Ivan Voras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8-stable crashes in vmware (possible em driver issue?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 01:31:40 -0000 Hmmm, not sure what changes are in this, what if you use the 8.0 REL driver, does it still happen? Regards, Jack On Wed, Feb 24, 2010 at 4:23 PM, Ivan Voras wrote: > Ivan Voras wrote: > >> I have a fairly recent 8-stable machine running under VMWare ESXi 3.5 >> (amd64 guest), which apparently crashes every few days from the same causes: >> >> em0: discard frame w/o packet header >> em0: discard frame w/o packet header >> em0: discard frame w/o packet header >> Panic string: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf >> 0xffffff00490a6400 clashing >> > > In case someone is interested or has an idea - on this machine I have > multiple crashed cores with similarily strange problems all connected with > networking and/or the em driver: > > 1) > em0: watchdog timeout -- resetting > Fatal trap 12: page fault while in kernel mode > current process = 0 (em0 taskq) > > 2) > em0: watchdog timeout -- resetting > Fatal trap 9: general protection fault while in kernel mode > current process = 1219 (slapd) > > 3) > > em0: discard frame w/o packet header > panic: sbdrop > > I'm scratching my head about the #2 above - I don't think trap#9 is usual. > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 04:10:07 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E120106564A for ; Thu, 25 Feb 2010 04:10:07 +0000 (UTC) (envelope-from brian.scott4@det.nsw.edu.au) Received: from up-mx2.det.nsw.edu.au (up-mx2.det.nsw.edu.au [153.107.105.80]) by mx1.freebsd.org (Postfix) with ESMTP id E83F88FC13 for ; Thu, 25 Feb 2010 04:10:06 +0000 (UTC) Received: from slppmxmm01.central.det.win (extmail.det.nsw.edu.au [153.107.9.204]) by up-mx2.det.nsw.edu.au (8.13.8/8.13.8) with ESMTP id o1P4A4SQ004849; Thu, 25 Feb 2010 15:10:04 +1100 Received: from itfexhub4.central.det.win (Not Verified[153.107.9.31]) by slppmxmm01.central.det.win with MailMarshal (v6, 5, 4, 7535) id ; Thu, 25 Feb 2010 15:10:03 +1100 Received: from ALF2.riverina.det.win ([172.18.8.18]) by itfexhub4.central.det.win with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Feb 2010 15:10:03 +1100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Feb 2010 15:10:03 +1100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: nss_ldap and multiple group memberships Thread-Index: Acq1O4sJRn9jMoUKT1aRlOi+9WIS+QAcNyVAAAgm8sA= References: <20100224112311.73ac53f6.gerrit@pmp.uni-hannover.de> From: "Scott, Brian" To: =?iso-8859-1?Q?Gerrit_K=FChn?= , X-OriginalArrivalTime: 25 Feb 2010 04:10:03.0585 (UTC) FILETIME=[67FBA310:01CAB5D0] Cc: Subject: RE: nss_ldap and multiple group memberships X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 04:10:07 -0000 I hate people who contradict themselves with follow up emails. On this oc= casion however... Since writing my earlier email I've done some digging around. What I have= =20found is that nss_ldap can use uniqueMember attributes as an alternati= ve to memberUid attributes. The rub is that the standard structure for po= sixGroup doesn't allow combination with groupOfUniqueNames and groupOfUni= queNames isn't what it sounds like anyway, and uniqueMember is also not t= he attribute you should be using. However, if you were to tweak the schema for posixGroup to make it an aux= iliary class as per rfc2307bis (an expired proposal http://ietfreport.iso= c.org/idref/draft-howard-rfc2307bis/) and use a combination of posixGroup= =20and groupOfNames you could have member attributes (i.e. full Distingui= shed Names) as you member names. It looks like you may need to uncomment the line '#nss_map_attribute uniq= ueMember member' in your ldap.conf to then use the correct attribute name= . I haven't actually tried any of this but I might give it a try on a test = machine sometime in the next few weeks. I must say that I'm not a fan of = fiddling with a standard schema but the idea of using a single type of gr= oup (combined posixGroup/groupOfNames) for everything is extremely tempti= ng. Enjoy, Brian -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freeb= sd.org] On Behalf Of Scott, Brian Sent: Thursday, 25 February 2010 11:18 AM To: Gerrit K=FChn; freebsd-stable@freebsd.org Subject: RE: nss_ldap and multiple group memberships It depends on the type of group. There are at least two types of group ob= jects that you can use in LDAP but only one of them works. You need to us= e posixGroup objects for unix groups. As I remember it, these have member= Uid attributes for the member ids. These are simple unix identifiers. gro= upOfNames objects on the other hand have full distinguished names with 'm= ember' attributes and can't be used by nss_ldap. The idea is that posixGroup and posixAccount mimic the unix files so extr= action of the data is fast. If the software used a groupOfNames object th= en the returned member names would need to queried as additional transact= ions to find the uid's of those entries that had posixAccount information= . This is because the original authentication was done by pam_ldap and th= at just returned a UID to the system. If it returned the LDAP distinguish= ed name to the system, and if that could then be passed into nss_ldap it = would be possible to do the LDAP query in a single transaction. But then = that all breaks down if you authenticate with something else like GSSAPI.= =20If that was the case you would need to first search for the posixAccou= nt object of the authenticated user (&(objectClass=3DposixAccount)(uid=3D= 1001)) and then search for all the group of names containing that disting= uished name (&(objectClass=3DgroupOfNames)(member=3Duid=3Dbscott,ou=3DPeo= ple,dc=3Dnetlab,dc=3Dalbury,dc=3Dtafe)). That's two transactions and seem= s unnecessarily wasteful. Mind you, if it was an option I'd probably turn= =20it on. Brian -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freeb= sd.org] On Behalf Of Gerrit K=FChn Sent: Wednesday, 24 February 2010 9:23 PM To: freebsd-stable@freebsd.org Subject: nss_ldap and multiple group memberships Hi all, Is anyone here using nss_ldap and can successfully get it to work with mu= ltiple group memberships? I would really like to get this to work here, b= ut I only get the primary group: penumbra# id gekueh uid=3D1030(gekueh) gid=3D1012(aei) groups=3D1012(aei) getent group comes up with the complete group list. ldapsearch reports th= ree groups with member:-lines for my user. Somehow nss does not pick this= =20up. Any ideas? cu =20 Gerrit _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"= ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"= ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 06:18:25 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E7391065673 for ; Thu, 25 Feb 2010 06:18:25 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id C0A008FC17 for ; Thu, 25 Feb 2010 06:18:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o1P6IMfK054683; Thu, 25 Feb 2010 17:18:22 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 25 Feb 2010 17:18:22 +1100 (EST) From: Ian Smith To: Ted Faber In-Reply-To: <20100224165203.GA10423@zod.isi.edu> Message-ID: <20100225152711.M16250@sola.nimnet.asn.au> References: <20100224165203.GA10423@zod.isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: resume slow on Thinkpad T42 FreeBSD 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 06:18:25 -0000 On Wed, 24 Feb 2010, Ted Faber wrote: > I'm running a recent (yesterday) FreeBSD 8-STABLE on my T42. When I > resume from suspend the fan starts screen returns immediately (to text > mode) and then the system idles for about a minute until it shakes > itself awake. The keyboard LEDs cycle, the disk runs and X returns. Good to hear, Ted .. I thought it was just me :) Your symptoms appear entirely identical to mine as posted on Dec 13th to mobile@ and acpi@, see thread 'Thinkpad T23 60 second stall on resuming 8.0-RELEASE/i386' http://lists.freebsd.org/pipermail/freebsd-acpi/2009-December/006192.html Nate Lawson thought it an ATA rather than an ACPI problem and I assume he's likely right, but I've had too much $work (and too little solar power during an exceptionally wet summer) to follow it up. > I don't recall this stutter under FreeBSD 7. I've tried both settings > of hw.acpi.reset_video and neither helps (nor hurts). BIOS is also > upgraded to the most recent and the stutter occurred with before and > after the upgrade. I'd recently upgraded t23's BIOS too. Since then I took 7.0-RELEASE to 7.2-STABLE (28 Dec) and still have no such issue on 7, although the ATA messages on resume are marginally different. I haven't yet upgraded my 8.0-R to -STABLE; going by this it seems that's unlikely to help now. In case relevant, my ad0 is a 120GB Fujitsu MHV2120AH, but your TOSHIBA MK4026GAX looks more likely to be the original disk? > I have attached a trace of a boot -v going through the cycle. The > t_delta entries happen after the machine wakes but before it restores > itself. There'a also sometimes a message from acpi_ec0 saying that the > EC woke up before the sleep event, but I wasn't able to capture it > during this trace. In that post I mntioned some other symptoms regarding devd and "calcru: time went backwards .." messages, but I suspect those were side-effects. Once it resumes after the one-minute delay I've noticed no other issues, but can't claim to have spent much time exercising it. > Any help would be appreciated, and I'm happy to provide more data on > request. I've no time to spend on hunting this now, and know nothing about ATA anyway, assuming that's where the problem lies, but I'll be quick to test any suggested solution/s! cheers, Ian From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 06:48:15 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8CFC106566B for ; Thu, 25 Feb 2010 06:48:15 +0000 (UTC) (envelope-from jholland@fastsoft.com) Received: from hq-es.fastsoft.com (hq-es.fastsoft.com [38.102.243.86]) by mx1.freebsd.org (Postfix) with ESMTP id B24578FC19 for ; Thu, 25 Feb 2010 06:48:15 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Feb 2010 22:36:14 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: vfs deadlock during panic? Thread-Index: Acq15NQKnmTOc0pDQTek5XHiCaYQIw== From: "Jake Holland" To: Subject: vfs deadlock during panic? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 06:48:15 -0000 Hello, I'm running today's stable/8 -r 204294 on a Dell r610 (2 processors with 4 cores per processor). I have turned on WITNESS and DEBUG_VFS_LOCKS, because I've been trying to troubleshoot an occasional hang during panic, and I think I have reason to believe a vfs deadlock is occurring. Some details below. A little backstory, with some long-story-short: I first encountered a hang on panic in a well-hacked version of 7.0, with a bunch of random backports from various other freebsd branches. I wrote a module that would panic on request in a cpu-pinned thread, and over the course of many runs, it seemed to hang approximately every 20 panics, if it was on cpu 0. I did some research, and found a very promising-looking patch in stable/8 -r196198. I backported that, and it helped, but I still got a hang approximately every 50 panics. So I pulled down stable/8, and found I'm still getting hangs during panic, though I'm not certain it's the same problem. I turned on WITNESS and DEBUG_VFS_LOCKS, and I very frequently see lock order reversals under vfs, both with r203674 and r204294, which is from today (Feb 24, 2010). I saw very similar lock order reversals with release/8.0.0. (I changed vfs_badlock_ddb to 0 in kern/vfs_subr.c, because I hit LORs pretty early on basically every boot.) So much for the backstory. Here's 3 backtraces that I see from the serial port not long after most boots, from -r204294 of stable/8: 1. lock order reversal: 1st 0xffffff015641d578 ufs (ufs) @ ufs/ffs/ffs_snapshot.c:423 2nd 0xffffff819b4c28a8 bufwait (bufwait) @ kern/vfs_bio.c:2559 3rd 0xffffff0010433098 ufs (ufs) @ ufs/ffs/ffs_snapshot.c:544 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xd31 ffs_lock() at ffs_lock+0x9c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x57 ffs_snapshot() at ffs_snapshot+0x1bb0 ffs_mount() at ffs_mount+0x666 vfs_donmount() at vfs_donmount+0xcde nmount() at nmount+0x63 syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007affdc, rsp =3D 0x7fffffffe9b 8, rbp =3D 0x800a04d30 --- 2. lock order reversal: 1st 0xffffff819b4c28a8 bufwait (bufwait) @ kern/vfs_bio.c:2559 2nd 0xffffff0156305230 snaplk (snaplk) @ ufs/ffs/ffs_snapshot.c:793 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xd31 ffs_lock() at ffs_lock+0x9c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x57 ffs_snapshot() at ffs_snapshot+0x1a7d ffs_mount() at ffs_mount+0x666 vfs_donmount() at vfs_donmount+0xcde nmount() at nmount+0x63 syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (378, FreeBSD ELF64, nmount), rip =3D 0x8007affdc, rsp =3D 0x7fffffffe9b 8, rbp =3D 0x800a04d30 --- 3. lock order reversal: 1st 0xffffff0156305230 snaplk (snaplk) @ kern/vfs_vnops.c:296 2nd 0xffffff015641d578 ufs (ufs) @ ufs/ffs/ffs_snapshot.c:1587 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xd31 ffs_snapremove() at ffs_snapremove+0xe7 softdep_releasefile() at softdep_releasefile+0x139 ufs_inactive() at ufs_inactive+0x1a5 VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0xb5 vinactive() at vinactive+0x90 vputx() at vputx+0x2de vn_close() at vn_close+0x118 vn_closefile() at vn_closefile+0x5a _fdrop() at _fdrop+0x23 closef() at closef+0x5b kern_close() at kern_close+0x110 syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (6, FreeBSD ELF64, close), rip =3D 0x80084e94c, rsp =3D 0x7fffffffe9b8, rbp =3D 0 --- And another interesting observation. During one of my runs with -r203674 which hung on panic, I saw this: login: retry 5: 2010-02-23.15:35:35 (had 3 in crash) panic: /usr/src/sys/modules/ jpanic/jpanic.c:168 panic requested prio 16, cpu 0, delay 500, curcpu 0 cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 jpanic_thread() at jpanic_thread+0x191 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip =3D 0, rsp =3D 0xffffff825964ad30, rbp =3D 0 --- Uptime: 3m15s Physical memory: 24554 MB Dumping 2049 MB:VOP_STRATEGY: bp is not locked but should be VOP_STRATEGY: bp is not locked but should be 2034 2018 2002 1986 1970 1954 1938 1922 1906 1890 1874 1858 1842 1826 1810 1794 1778 1762 1746 1730 1714 1698 1682 1666 1650 1634 1618 1602 1586 1570 1554 1538 1522 1506 1490 1474 1458 1442 1426 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2Attempt to write outside dump device boundaries. ** DUMP FAILED (ERROR 6) ** (I get this error fairly often, by the way. Maybe 25% or so, to make a probably-wrong estimate. I don't think I only see hangs with this error, however.) It was hung here for something like 25 minutes, until I pressed the power button, when it dumped again, this time successfully, and gave me a core that showed the following backtrace: #0 doadump () at pcpu.h:223 #1 0xffffffff803debf3 in boot (howto=3D16644) at ../../../kern/kern_shutdown.c:416 #2 0xffffffff803df07c in panic (fmt=3DVariable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:579 #3 0xffffffff80454ed8 in bremfree (bp=3D0x0) at ../../../kern/vfs_bio.c:675 #4 0xffffffff8045afe5 in getblk (vp=3D0xffffff000be35000, = blkno=3D753600, size=3D16384, slpflag=3D0, slptimeo=3D0, flags=3D0) at ../../../kern/vfs_bio.c:2581 #5 0xffffffff8045b6cf in breadn (vp=3D0xffffff000be35000, = blkno=3DVariable "blkno" is not available. ) at ../../../kern/vfs_bio.c:800 #6 0xffffffff8045b83e in bread (vp=3DVariable "vp" is not available. ) at ../../../kern/vfs_bio.c:748 #7 0xffffffff80501c52 in ffs_update (vp=3D0xffffff0013268270, = waitfor=3D0) at ../../../ufs/ffs/ffs_inode.c:104 #8 0xffffffff8051eafe in ufs_inactive (ap=3DVariable "ap" is not available. ) at ../../../ufs/ufs/ufs_inode.c:158 #9 0xffffffff8060ad95 in VOP_INACTIVE_APV (vop=3D0xffffffff808a94a0, a=3D0xffffff80000878b0) at vnode_if.c:1863 #10 0xffffffff8046fc80 in vinactive (vp=3D0xffffff0013268270, td=3D0xffffff000b3b8ae0) at vnode_if.h:807 #11 0xffffffff8047101e in vputx (vp=3D0xffffff0013268270, func=3D2) at ../../../kern/vfs_subr.c:2214 #12 0xffffffff8047d2c8 in vn_close (vp=3D0xffffff0013268270, flags=3DVariable "flags" is not available. ) at ../../../kern/vfs_vnops.c:303 #13 0xffffffff8047d3ba in vn_closefile (fp=3D0xffffff00132c38c0, td=3D0xffffff000b3b8ae0) at ../../../kern/vfs_vnops.c:938 #14 0xffffffff803a95e3 in _fdrop (fp=3D0xffffff00132c38c0, td=3DVariable "td" is not available. ) at file.h:293 #15 0xffffffff803ab04b in closef (fp=3D0xffffff00132c38c0, td=3D0xffffff000b3b8ae0) at ../../../kern/kern_descrip.c:2117 #16 0xffffffff803ab630 in kern_close (td=3D0xffffff000b3b8ae0, fd=3D0) at ../../../kern/kern_descrip.c:1162 #17 0xffffffff805d0cd2 in syscall (frame=3D0xffffff8000087c80) at ../../../amd64/amd64/trap.c:1025 #18 0xffffffff805b6f21 in Xfast_syscall () at ../../../amd64/amd64/exception.S:373 #19 0x000000000045b64c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) That particular sequence of events is extremely rare; ordinarily the power button doesn't do anything from the hung state unless you hold it down long enough for a hard power-off. Based on these observations, I suspect that some kind of vfs thread-safety bug might be a key part of this hanging problem. I'm no vfs expert, so I'm a bit stuck. Can anyone help? I'm happy to answer any questions and provide any information I can. And my apologies if I've violated etiquette or if this is the wrong place for this (and if so, please correct me), I've never posted here before. Thank you. Jake From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 07:33:19 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFEE0106566B for ; Thu, 25 Feb 2010 07:33:19 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 734F58FC1A for ; Thu, 25 Feb 2010 07:33:19 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta11.emeryville.ca.mail.comcast.net with comcast id m7S41d0021vN32cAB7VzQR; Thu, 25 Feb 2010 07:29:59 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.emeryville.ca.mail.comcast.net with comcast id m7bq1d00C3S48mS8i7brYP; Thu, 25 Feb 2010 07:35:51 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 08B7B1E301A; Wed, 24 Feb 2010 23:33:18 -0800 (PST) Date: Wed, 24 Feb 2010 23:33:18 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100225073317.GA82327@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: vfs deadlock during panic? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 07:33:19 -0000 On Wed, Feb 24, 2010 at 10:36:14PM -0800, Jake Holland wrote: > I'm running today's stable/8 -r 204294 on a Dell r610 (2 processors with > 4 cores per processor). I have turned on WITNESS and DEBUG_VFS_LOCKS, > because I've been trying to troubleshoot an occasional hang during > panic, and I think I have reason to believe a vfs deadlock is occurring. > Some details below. > {snip} All the backtraces indicate UFS snapshots are being used, as in you're doing dump -L or mksnap_ffs. Is that the case? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 08:14:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D57DC106566C for ; Thu, 25 Feb 2010 08:14:05 +0000 (UTC) (envelope-from jholland@fastsoft.com) Received: from hq-es.fastsoft.com (hq-es.fastsoft.com [38.102.243.86]) by mx1.freebsd.org (Postfix) with ESMTP id BDDC38FC19 for ; Thu, 25 Feb 2010 08:14:05 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Feb 2010 00:14:04 -0800 Message-ID: In-Reply-To: <20100225073317.GA82327@icarus.home.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: vfs deadlock during panic? Thread-Index: Acq17P2HqgDeHy/bQtC5+FwnOKe37gAArmzg References: <20100225073317.GA82327@icarus.home.lan> From: "Jake Holland" To: Subject: RE: vfs deadlock during panic? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 08:14:05 -0000 > All the backtraces indicate UFS snapshots are being used, as in=20 > you're doing dump -L or mksnap_ffs. Is that the case? Not to my knowledge, but I'm not sure of everything that's happening during startup. The 3 I listed last time appear in the serial console, usually within 10s of the login prompt's first appearance after reboot. If I do more file operations, I typically see more such messages, but not every time. For example, I tried running umount on my /var/crash (mounted on /dev/mfid0s3d) and it gave me this: lock order reversal: 1st 0xffffff00104337e8 ufs (ufs) @ kern/vfs_mount.c:1204 2nd 0xffffff001045aa58 devfs (devfs) @ ufs/ffs/ffs_vfsops.c:1194 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xd31 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x57 ffs_flushfiles() at ffs_flushfiles+0xc5 softdep_flushfiles() at softdep_flushfiles+0x63 ffs_unmount() at ffs_unmount+0x2e1 dounmount() at dounmount+0x2e6 unmount() at unmount+0x27e syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (22, FreeBSD ELF64, unmount), rip =3D 0x80069f4bc, rsp =3D 0x7fffffffe2f 8, rbp =3D 0 --- But I got nothing when I ran mount -a afterwards. Then I ran vi on /etc/ports.conf and saw this: lock order reversal: 1st 0xffffff81983bd5b8 bufwait (bufwait) @ kern/vfs_bio.c:2559 2nd 0xffffff000bd2ac00 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x44 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x88b ufs_makeinode() at ufs_makeinode+0x2a7 VOP_CREATE_APV() at VOP_CREATE_APV+0xb3 vn_open_cred() at vn_open_cred+0x482 kern_openat() at kern_openat+0x179 syscall() at syscall+0x102 Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (5, FreeBSD ELF64, open), rip =3D 0x800ce075c, rsp =3D 0x7fffffffe0d8, r bp =3D 0xf --- But only the first time. Subsequently re-opening the same or another few arbitrary text files with vi did not produce any repeats. And on some occasions, nothing came up even on the first run of vi, though usually the first vi does give a similar stack. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 08:18:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C85AE106566C for ; Thu, 25 Feb 2010 08:18:50 +0000 (UTC) (envelope-from freegih@gmail.com) Received: from mail-gx0-f211.google.com (mail-gx0-f211.google.com [209.85.217.211]) by mx1.freebsd.org (Postfix) with ESMTP id 832E08FC08 for ; Thu, 25 Feb 2010 08:18:50 +0000 (UTC) Received: by gxk3 with SMTP id 3so1686613gxk.13 for ; Thu, 25 Feb 2010 00:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=xoeQNAnmrO6jsLPSB1CppVqyA8KdRJEOUquPcau7LMY=; b=E/KFq7B5oomHowJ2MurDbv6ZHGAJGaakLLbFnaJ6s0PRsWtScP89CTjNY49fLE73AW rNwr7S0QzP7xRZrfY/HlChE7PoyIfbMD0h7WqXPQNtoRFdi2LbiEYkESUrXdwUX/Q6Y9 wr5XAxkPujEND3C9xSBurq9XHZcEpJzcSEsWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=Vy7wYlBRXOZfim1cXlM9p+SxqfZfBUIG1ygzbiFoyz6N3EPArNSSxS/T0GFKgZACdx k9rkxkTtGkgnvvurR9LIONmLtpuJ7MJoTIR1HbRk4au7uoZaA+XsgQ3/sPqoNLbuowPn JRrdMAmFF2St4moNeFS8Hy0pF9enrOV+4ilz4= Received: by 10.101.184.7 with SMTP id l7mr1085330anp.125.1267084222919; Wed, 24 Feb 2010 23:50:22 -0800 (PST) Received: from ?192.168.1.23? ([221.179.0.11]) by mx.google.com with ESMTPS id 36sm1152376yxh.31.2010.02.24.23.50.20 (version=SSLv3 cipher=RC4-MD5); Wed, 24 Feb 2010 23:50:21 -0800 (PST) Message-ID: <4B862BB9.7080609@gmail.com> Date: Thu, 25 Feb 2010 15:50:17 +0800 From: jerry User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: wlan0 on my laptop freeze my system X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 08:18:50 -0000 Hi, I'm running 8 stable and I found the system freeze twice so long. when i try ifconfig wlan0 destroy , the system hang up and freeze, Or I try /etc/rc.d/netif restart, the same thing happend. I think the system freeze is because the interface wlan0, I had see the interface wlan0 would disappear itself!! and I saw "ioctl(SIOCGIFFLAGS) on wlan0: " message. I can not found any useful info for that,but i got some strange messages from dmesg: Feb 25 13:48:00 jerry wpa_supplicant[438]: CTRL-EVENT-SCAN-RESULTS Feb 25 13:50:22 jerry kernel: arp: 00:21:00:3c:9e:f8 is using my IP address 192.168.1.2 on wlan0! Feb 25 13:53:02 jerry wpa_supplicant[438]: CTRL-EVENT-SCAN-RESULTS Feb 25 13:55:22 jerry kernel: arp: 00:21:00:3c:9e:f8 is using my IP address 192.168.1.2 on wlan0! Feb 25 13:58:04 jerry wpa_supplicant[438]: CTRL-EVENT-SCAN-RESULTS Feb 25 14:03:07 jerry wpa_supplicant[438]: CTRL-EVENT-SCAN-RESULTS Feb 25 14:04:26 jerry wpa_supplicant[438]: Failed to disable WPA in the driver. Feb 25 14:04:27 jerry kernel: wlan0: link state changed to DOWN Feb 25 14:04:26 jerry dhclient[1580]: receive_packet failed on wlan0: Device not configured Feb 25 14:04:26 jerry dhclient[1580]: ioctl(SIOCGIFFLAGS) on wlan0: Operation not permitted Feb 25 14:04:26 jerry dhclient[1580]: Interface wlan0 no longer appears valid. Feb 25 14:04:26 jerry dhclient[1580]: No live interfaces to poll on - exiting. Feb 25 14:04:26 jerry dhclient[1580]: exiting. Feb 25 14:04:26 jerry dhclient[1491]: connection closed Feb 25 14:04:26 jerry dhclient[1491]: exiting. ----------- more info pciconf -lv: ath0@pci0:2:0:0: class=0x020000 card=0x0035168c chip=0x001c168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'HDAUDIOFUNC_01&VEN_1095&DEV_1392&SUBSYS_10280242&REV_1000 (USBVID_147E&PID_20165&B71A446&0&1)' class = network subclass = ethernet $ dmesg| grep ath ath0: mem 0xfd9f0000-0xfd9fffff irq 17 at device 0.0 on pci2 ath0: [ITHREAD] ath0: AR2425 mac 14.2 RF5424 phy 7.0 #rc.conf wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 08:31:23 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 679491065789 for ; Thu, 25 Feb 2010 08:31:23 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id E8D2A8FC08 for ; Thu, 25 Feb 2010 08:31:22 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1P8VFdN010847; Thu, 25 Feb 2010 09:31:17 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 5C0F2D8; Thu, 25 Feb 2010 09:31:15 +0100 (CET) Date: Thu, 25 Feb 2010 09:31:15 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: "Scott, Brian" Message-Id: <20100225093115.c5a83239.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <20100224112311.73ac53f6.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.25.82125 Cc: freebsd-stable@freebsd.org Subject: Re: nss_ldap and multiple group memberships X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 08:31:23 -0000 On Thu, 25 Feb 2010 11:17:32 +1100 "Scott, Brian" wrote about RE: nss_ldap and multiple group memberships: SB> It depends on the type of group. There are at least two types of group SB> objects that you can use in LDAP but only one of them works. You need SB> to use posixGroup objects for unix groups. As I remember it, these SB> have memberUid attributes for the member ids. These are simple unix SB> identifiers. groupOfNames objects on the other hand have full SB> distinguished names with 'member' attributes and can't be used by SB> nss_ldap. The server is running openldap under SLES and is not under my control. ldapsearch gives group entries like # lisa, group, aei.uni-hannover.de dn: cn=lisa,ou=group,dc=aei,dc=uni-hannover,dc=de cn: lisa displayName: lisa gidNumber: 1003 member: uid=gekueh,ou=people,dc=aei,dc=uni-hannover,dc=de So this would be the first case, I guess. SB> The idea is that posixGroup and posixAccount mimic the unix files so SB> extraction of the data is fast. If the software used a groupOfNames SB> object then the returned member names would need to queried as SB> additional transactions to find the uid's of those entries that had SB> posixAccount information. This is because the original authentication SB> was done by pam_ldap and that just returned a UID to the system. If it SB> returned the LDAP distinguished name to the system, and if that could SB> then be passed into nss_ldap it would be possible to do the LDAP query SB> in a single transaction. But then that all breaks down if you SB> authenticate with something else like GSSAPI. If that was the case you SB> would need to first search for the posixAccount object of the SB> authenticated user (&(objectClass=posixAccount)(uid=1001)) and then SB> search for all the group of names containing that distinguished name (& SB> (objectClass=groupOfNames) SB> (member=uid=bscott,ou=People,dc=netlab,dc=albury,dc=tafe)). That's two SB> transactions and seems unnecessarily wasteful. Mind you, if it was an SB> option I'd probably turn it on. Thanks for this fine explanation. I do not use GSS. However, I found the following configuration option in (nss) ldap.conf that helped me: nss_map_attribute uniqueMember member After commenting this in, everything seems to work fine: penumbra# id gekueh uid=1030(gekueh) gid=1012(aei) groups=1012(aei),1003(lisa) Maybe this could be mentioned somewhere in the documentation? I used to set up the client, but the information I got from this article were rather sparse and led me the wrong path more than once. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 08:35:39 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 111EA106566C for ; Thu, 25 Feb 2010 08:35:39 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 77F0C8FC0C for ; Thu, 25 Feb 2010 08:35:38 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1P8ZXlr010954; Thu, 25 Feb 2010 09:35:34 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 298E624; Thu, 25 Feb 2010 09:35:33 +0100 (CET) Date: Thu, 25 Feb 2010 09:35:33 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: "Scott, Brian" Message-Id: <20100225093533.13f0e393.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <20100224112311.73ac53f6.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.25.82125 Cc: freebsd-stable@freebsd.org Subject: Re: nss_ldap and multiple group memberships X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 08:35:39 -0000 On Thu, 25 Feb 2010 15:10:03 +1100 "Scott, Brian" wrote about RE: nss_ldap and multiple group memberships: SB> It looks like you may need to uncomment the line '#nss_map_attribute SB> uniqueMember member' in your ldap.conf to then use the correct SB> attribute name. Yes, that's exactly the solution here. I got this from reading the config files of a working Linux client that uses the same nss libraries. Thank you for your support! cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 09:05:04 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 556841065670 for ; Thu, 25 Feb 2010 09:05:04 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by mx1.freebsd.org (Postfix) with ESMTP id 045EF8FC0A for ; Thu, 25 Feb 2010 09:05:03 +0000 (UTC) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta13.westchester.pa.mail.comcast.net with comcast id m94q1d0070EZKEL5D954K8; Thu, 25 Feb 2010 09:05:04 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta01.westchester.pa.mail.comcast.net with comcast id m9531d00A3S48mS3M953t1; Thu, 25 Feb 2010 09:05:04 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 3D0FE1E301A; Thu, 25 Feb 2010 01:05:02 -0800 (PST) Date: Thu, 25 Feb 2010 01:05:02 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100225090502.GA84181@icarus.home.lan> References: <20100225073317.GA82327@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: vfs deadlock during panic? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 09:05:04 -0000 On Thu, Feb 25, 2010 at 12:14:04AM -0800, Jake Holland wrote: > > All the backtraces indicate UFS snapshots are being used, as in > > you're doing dump -L or mksnap_ffs. Is that the case? > > Not to my knowledge, but I'm not sure of everything that's happening > during startup. The 3 I listed last time appear in the serial console, > usually within 10s of the login prompt's first appearance after reboot. > If I do more file operations, I typically see more such messages, but > not every time. > > For example, I tried running umount on my /var/crash (mounted on > /dev/mfid0s3d) and it gave me this: > > lock order reversal: > 1st 0xffffff00104337e8 ufs (ufs) @ kern/vfs_mount.c:1204 > 2nd 0xffffff001045aa58 devfs (devfs) @ ufs/ffs/ffs_vfsops.c:1194 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > __lockmgr_args() at __lockmgr_args+0xd31 > vop_stdlock() at vop_stdlock+0x39 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b > _vn_lock() at _vn_lock+0x57 > ffs_flushfiles() at ffs_flushfiles+0xc5 > softdep_flushfiles() at softdep_flushfiles+0x63 > ffs_unmount() at ffs_unmount+0x2e1 > dounmount() at dounmount+0x2e6 > unmount() at unmount+0x27e > syscall() at syscall+0x102 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (22, FreeBSD ELF64, unmount), rip = 0x80069f4bc, rsp = > 0x7fffffffe2f > 8, rbp = 0 --- > > But I got nothing when I ran mount -a afterwards. > > > Then I ran vi on /etc/ports.conf and saw this: > > lock order reversal: > 1st 0xffffff81983bd5b8 bufwait (bufwait) @ kern/vfs_bio.c:2559 > 2nd 0xffffff000bd2ac00 dirhash (dirhash) @ ufs/ufs/ufs_dirhash.c:285 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > _witness_debugger() at _witness_debugger+0x2e > witness_checkorder() at witness_checkorder+0x81e > _sx_xlock() at _sx_xlock+0x55 > ufsdirhash_acquire() at ufsdirhash_acquire+0x44 > ufsdirhash_add() at ufsdirhash_add+0x19 > ufs_direnter() at ufs_direnter+0x88b > ufs_makeinode() at ufs_makeinode+0x2a7 > VOP_CREATE_APV() at VOP_CREATE_APV+0xb3 > vn_open_cred() at vn_open_cred+0x482 > kern_openat() at kern_openat+0x179 > syscall() at syscall+0x102 > Xfast_syscall() at Xfast_syscall+0xe1 > --- syscall (5, FreeBSD ELF64, open), rip = 0x800ce075c, rsp = > 0x7fffffffe0d8, r > bp = 0xf --- > > > But only the first time. Subsequently re-opening the same or another > few arbitrary text files with vi did not produce any repeats. And on > some occasions, nothing came up even on the first run of vi, though > usually the first vi does give a similar stack. Are you sure one of the filesystems on the disk isn't corrupt? There's been reports of this problem in the past, but AFAIR it doesn't manifest itself in this manner. Just something to consider: if you have another disk you can put in the box and install FreeBSD 8.x + upgrade to latest -STABLE on it, and it doesn't behave this way, then I'd say there's some underlying filesystem corruption of some kind. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 11:14:16 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E204C106564A for ; Thu, 25 Feb 2010 11:14:15 +0000 (UTC) (envelope-from john.marshall@riverwillow.com.au) Received: from mail1.riverwillow.net.au (mail1.riverwillow.net.au [203.58.93.36]) by mx1.freebsd.org (Postfix) with ESMTP id 657C18FC13 for ; Thu, 25 Feb 2010 11:14:14 +0000 (UTC) Received: from rwpc12.mby.riverwillow.net.au (rwpc12.mby.riverwillow.net.au [172.25.24.168]) (authenticated bits=0) by mail1.riverwillow.net.au (8.14.4/8.14.4) with ESMTP id o1PBE9WA005372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 25 Feb 2010 22:14:10 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=riverwillow.com.au; s=m1001; t=1267096451; bh=N0LylPl8xeArgruYFAYt/0oOJj2fmPIuptGHh56RA9U=; h=Date:From:To:Subject:Message-ID:References:Mime-Version: Content-Type:In-Reply-To; b=kS90JQbLm586PuldNxrcIcQ4yMW8j6q7wMq1f5fP0mOOsd5/qInq7qylkuqNPjJFY Vsql8NZMLb4IwEushBRGypHjQx1WJVwdQWykCkhE/3SVmvru1OugoQKoEYWBzqXrKN pU9EiLp4Z7UfdalXPd2i/eW8TRrvKICL2V42UaOk= Received: from rwpc12.mby.riverwillow.net.au (localhost [127.0.0.1]) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3) with ESMTP id o1PBE9F0020887 for ; Thu, 25 Feb 2010 22:14:09 +1100 (AEDT) (envelope-from john.marshall@riverwillow.com.au) Received: (from john@localhost) by rwpc12.mby.riverwillow.net.au (8.14.3/8.14.3/Submit) id o1PBE7xD020886 for freebsd-stable@freebsd.org; Thu, 25 Feb 2010 22:14:07 +1100 (AEDT) (envelope-from john) Date: Thu, 25 Feb 2010 22:14:07 +1100 From: John Marshall To: freebsd-stable@freebsd.org Message-ID: <20100225111407.GE14464@rwpc12.mby.riverwillow.net.au> Mail-Followup-To: freebsd-stable@freebsd.org References: <20100223013522.GE2303@rwpc12.mby.riverwillow.net.au> <20100224075359.GA61876@server.vk2pj.dyndns.org> <20100224112139.GT50403@deviant.kiev.zoral.com.ua> <20100224114441.GA57760@icarus.home.lan> <20100224122045.GU50403@deviant.kiev.zoral.com.ua> <20100224124101.GC14464@rwpc12.mby.riverwillow.net.au> <20100224163803.GW50403@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hQiwHBbRI9kgIhsi" Content-Disposition: inline In-Reply-To: <20100224163803.GW50403@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i OpenPGP: id=A29A84A2; url=http://pki.riverwillow.net.au/pgp/johnmarshall.asc Subject: Re: sleep(3) sometimes too sleepy on FreeBSD 8.0? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 11:14:16 -0000 --hQiwHBbRI9kgIhsi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 24 Feb 2010, 18:38 +0200, Kostik Belousov wrote: > I would be interested if you tried latest RELENG_8 kernel, in regard > the sigsuspend(2) returning with EINTR without a signal delivered. I have just finished building RELENG_8 from a fresh csup on one of the three servers: I plan to isntall it in the morning (bed time now). Another thing I did was to patch the sendmail build config on another one of the servers, and rebuild, so that sendmail's sleep() would simply call FreeBSD's nanosleep(2). I have asked on comp.mail.sendmail if anyone knows why the sendmail build only enbles use of nanosleep on Solaris. SLEEPING (HAPPY) QUEUE RUNNER - 8.14.4 Build on FreeBSD 8.0 (gdb) bt #0 0x2833f6eb in sigsuspend () from /lib/libc.so.7 #1 0x2833e050 in sigpause () from /lib/libc.so.7 #2 0x28334fae in pause () from /lib/libc.so.7 #3 0x080cc975 in sleep () #4 0x08099d96 in run_work_group () #5 0x0809a016 in runqueue () #6 0x08055379 in main () SLEEPING (HAPPY) QUEUE RUNNER - 8.14.4 Hacked Build on FreeBSD 8.0 (gdb) bt #0 0x283c43f7 in nanosleep () from /lib/libc.so.7 #1 0x080cbf7a in sleep () #2 0x08099c81 in run_work_group () #3 0x08099eef in runqueue () #4 0x080553bd in main () After the RELENG_8 upgrade in the morning I expect to have: SERVER 1 - FreeBSD 8.0-RELEASE-p2 - Sendmail 8.14.4 (modified so that sleep() uses nanosleep(2)) SERVER 2 - FreeBSD 8.0-RELEASE-p2 - Sendmail 8.14.4 SERVER 3 - FreeBSD 8-STABLE - Sendmail 8.14.4 =2E..and then watch sendmail on all three. --=20 John Marshall --hQiwHBbRI9kgIhsi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuGW38ACgkQw/tAaKKahKJy3ACePsm4NlStNnPKRndix/2QwPHI zJkAn04aPzPFqgngfb54U8ZDrurOx9fh =G1wx -----END PGP SIGNATURE----- --hQiwHBbRI9kgIhsi-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 11:41:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2077D106564A for ; Thu, 25 Feb 2010 11:41:34 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 956BD8FC0A for ; Thu, 25 Feb 2010 11:41:33 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o1PBfVGR016389 for ; Thu, 25 Feb 2010 13:41:31 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B8661E6.40502@eng.auth.gr> Date: Thu, 25 Feb 2010 13:41:26 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-stable References: <4B74502C.3080906@eng.auth.gr> In-Reply-To: <4B74502C.3080906@eng.auth.gr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 11:41:34 -0000 On 11/02/2010 20:45, George Mamalakis wrote: > 4: > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: > Miscellaneous failure (see text) (unknown mech-code 2529638919 for > mech unknown) > > which is very strange, since mech-code seems unnaturally large. This problem has been resolved. I had an issue with my /etc/hosts file, where the name of the ldap server could not be resolved correctly (via the gssapi library I assume), and openldap client gave me this reply (both ldap server and heimdal server had the same IP (two jails on the same host)). After changing the order in which the host and its IP appeared in /etc/hosts the problem stopped (which is still strange, since ldapwhoami -D 'blabla' -W worked ok, even with the old /etc/hosts). -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 12:08:02 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB704106566B for ; Thu, 25 Feb 2010 12:08:02 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 81A5D8FC12 for ; Thu, 25 Feb 2010 12:08:01 +0000 (UTC) Received: by wyb40 with SMTP id 40so2007368wyb.13 for ; Thu, 25 Feb 2010 04:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=OpOSlbGHARNBVSpKQTISFVN+FQF1C9mUF9e0PoPBddg=; b=dIvLCYa3dgyrS1nFEGFeL2E/GAzhSVYrnZVMzO9cDKXl/BruSEQ4pJdVaCmxx4lMtC ndG+Sg4OXokxu4ZadTQt7E5Z8Z2ECXHDor+w9o4aEHxqA0Di8xRaTnpJkMrr+yYOYyFV CYNH9E5LPEAQBewmVQTa+6frPWMmtBpQmFPnQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=rOnQrNDkDJwmPOmZ7yGCbXD1Nrmg8feABvEOujvVnCXbZLZh2ouR8TLvxz+m20Rwnx xK5Wnrk1Jr7OMNvJB1Kt4nKdRllDqamS/YzsjP7IixxVZEbLatGf7wGhjpJtsyXM0V8y 51Bw0YaE0paB9DOOT2KzNdSSX95CTXF7n3nIU= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.155.204 with SMTP id j54mr583569wek.104.1267099675294; Thu, 25 Feb 2010 04:07:55 -0800 (PST) In-Reply-To: <2a41acea1002241731w723406c3q7ab9aa79a2f92af5@mail.gmail.com> References: <2a41acea1002241731w723406c3q7ab9aa79a2f92af5@mail.gmail.com> From: Ivan Voras Date: Thu, 25 Feb 2010 13:07:35 +0100 X-Google-Sender-Auth: a8c1addb5bf31637 Message-ID: <9bbcef731002250407g776a4ca8xea944790a9572153@mail.gmail.com> To: Jack Vogel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8-stable crashes in vmware (possible em driver issue?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 12:08:03 -0000 On 25 February 2010 02:31, Jack Vogel wrote: > Hmmm,=C2=A0 not sure what changes are in this, what if you use the 8.0 RE= L > driver, does it still happen? Yes, this is why it is now running 8-STABLE. I have more FreeBSD guests on the same VMWare hosts which work fine, but this is the only 64-bit one. I don't know if this information helps. > > > On Wed, Feb 24, 2010 at 4:23 PM, Ivan Voras wrote: >> >> Ivan Voras wrote: >>> >>> I have a fairly recent 8-stable machine running under VMWare ESXi 3.5 >>> (amd64 guest), which apparently crashes every few days from the same ca= uses: >>> >>> em0: discard frame w/o packet header >>> em0: discard frame w/o packet header >>> em0: discard frame w/o packet header >>> Panic string: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf >>> 0xffffff00490a6400 clashing >> >> In case someone is interested or has an idea - on this machine I have >> multiple crashed cores with similarily strange problems all connected wi= th >> networking and/or the em driver: >> >> 1) >> em0: watchdog timeout -- resetting >> Fatal trap 12: page fault while in kernel mode >> current process =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0 (em0 taskq) >> >> 2) >> em0: watchdog timeout -- resetting >> Fatal trap 9: general protection fault while in kernel mode >> current process =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 1219 (slapd) >> >> 3) >> em0: discard frame w/o packet header >> panic: sbdrop >> >> I'm scratching my head about the #2 above - I don't think trap#9 is usua= l. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org= " > > From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 09:03:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BAC4106566B for ; Thu, 25 Feb 2010 09:03:11 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB2F8FC17 for ; Thu, 25 Feb 2010 09:03:10 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id o1P9321X085984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Feb 2010 10:03:02 +0100 (CET) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4B863CC5.80906@omnilan.de> Date: Thu, 25 Feb 2010 10:03:01 +0100 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.23 (X11/20090906) MIME-Version: 1.0 To: Nikos Ntarmos References: <20100218192320.B34251CC09@ptavv.es.net> <4B7DB408.9010706@omnilan.de> <20100219095539.GD14413@asgard.cs.uoi.gr> <20100224153703.GA11729@asgard.cs.uoi.gr> In-Reply-To: <20100224153703.GA11729@asgard.cs.uoi.gr> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC85738FB85F4303CBCFC03A6" X-Mailman-Approved-At: Thu, 25 Feb 2010 12:21:11 +0000 Cc: Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 09:03:11 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC85738FB85F4303CBCFC03A6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Nikos Ntarmos schrieb am 24.02.2010 16:37 (localtime): > On Fri, Feb 19, 2010 at 11:55:39AM +0200, Nikos Ntarmos wrote: >> On Thu, Feb 18, 2010 at 10:41:28PM +0100, Harald Schmalzbauer wrote: >>> Kevin Oberman schrieb am 18.02.2010 20:23 (localtime): >>> ... >>>> window allows for many packets to be in flight and with a 3 Gbps flo= w, >>>> that is a LOT of data. While an ACK is sent every two packets of >>>> received data, the transmitting side does not wait for the ACKs. It >>> ... >>>> That is a VERY simple and incomplete explanation of what is happenin= g >>>> with the window, but most of that is irrelevant in local transfers w= ith >>> Thanks a lot, then I understood it at least half correct ;) My >>> missunderstanding was that I thought the receiver would reduce >>> ACKs... Now I know more :) >>> But unfortunately that makes it more mysterious where the throughput >>> problem lies... >>> >>> Thanks to everyone so far, >> Hi there. >> >> This is a long shot but have you tried disabling checksum and >> segmentation offloading? I've found that they cause trouble with some >> NICs. FYI on FreeBSD the first is done through 'ifconfig -rxcsum' whil= e >> the latter through 'sysctl net.inet.tcp.tso=3D0'. If you try this out,= >> remember to disable these features on both communicating boxes for the= >> period of the test, just to be sure that it's not the other box causin= g >> these issues. You mentioned samba so if one of them is a win32 box, yo= u >> can access these settings through the hardware options of your NIC. >=20 > Hi again. >=20 > Just a friendly nudge. :) Did you find the root of these issues yet? I don't have solid conclusions. But I ruled out some things. First, the em driver has no problems in my setup. Neither disabling=20 rx/txcsum nor disabling TSO made any differenz in trhoughput, though no=20 direct recognizable load behaviour on my 2x3GHz machine. Mybe checsum=20 offload is beneficial on slower machines. One major problem was that one of the two FreeBSD Boxes was on a VMware=20 which slowed things down a bit, although the FreeBSD System showed=20 plenty free resources. Disabling rfc1323 defnetily increases the throughput on gigabit=20 ethernet. I can rsync between two (native) FreeBSD machines with 72-92=20 MB/s averaging at 80+MB/s. What I couldn't investigeate yet is why I always get 10% more throughput = when one side is windwos, no matter which direction, no matter what=20 application (cifs, rsync, ftp). Another big point on my todo list is to find out why tcp.inflight brakes = my webserver downloads really often to less than a quarter of the=20 available bandwith (client bw, server bw is 100mb). I saw many 10mb/s E3 = pipes with 15ms delay, but limited transfer rates to 200kb/s. Disabling=20 tcp.inflight opens that brake. Since I could only capture "bad IP length" packets with checsum=20 offloading enabled on the em, I guess it does also IP checksum=20 offloading, not only TCP. I'll have to set up a port mirroring test bed=20 to get the line packets. I hope I'll find the rfc1323 slowdown and the=20 difference between FreeBSD clients and Windows clients. But at the=20 moment I don't have spare equipment. Greets, -Harry --------------enigC85738FB85F4303CBCFC03A6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkuGPMYACgkQLDqVQ9VXb8jc1QCfbEcNCFswIXfTVrPANLYZJwaZ z+QAnieRBqX1mkNh7e1k193w0R7YMbPh =xfkZ -----END PGP SIGNATURE----- --------------enigC85738FB85F4303CBCFC03A6-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 12:57:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5524106566B for ; Thu, 25 Feb 2010 12:57:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 866218FC15 for ; Thu, 25 Feb 2010 12:57:38 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta04.emeryville.ca.mail.comcast.net with comcast id mCr31d0051Y3wxoA4Cxe2V; Thu, 25 Feb 2010 12:57:38 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id mCxe1d0043S48mS8bCxegl; Thu, 25 Feb 2010 12:57:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 30B311E301A; Thu, 25 Feb 2010 04:57:37 -0800 (PST) Resent-From: Jeremy Chadwick Resent-Date: Thu, 25 Feb 2010 04:57:37 -0800 Resent-Message-ID: <20100225125737.GA89503@icarus.home.lan> Resent-To: freebsd-stable@freebsd.org Date: Thu, 25 Feb 2010 04:57:15 -0800 From: Jeremy Chadwick To: Harald Schmalzbauer Message-ID: <20100225125715.GA89451@icarus.home.lan> References: <20100218192320.B34251CC09@ptavv.es.net> <4B7DB408.9010706@omnilan.de> <20100219095539.GD14413@asgard.cs.uoi.gr> <20100224153703.GA11729@asgard.cs.uoi.gr> <4B863CC5.80906@omnilan.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B863CC5.80906@omnilan.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: RELENG_8 ignoring TCP window size? [Was: Re: Help for TCP understanding wanted, ACK-MSS-Window [Was: Re: best practice to watch TCP parms of established sockets]] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 12:57:38 -0000 On Thu, Feb 25, 2010 at 10:03:01AM +0100, Harald Schmalzbauer wrote: > Since I could only capture "bad IP length" packets with checsum > offloading enabled on the em, I guess it does also IP checksum > offloading, not only TCP. I'll have to set up a port mirroring test > bed to get the line packets. I hope I'll find the rfc1323 slowdown > and the difference between FreeBSD clients and Windows clients. But > at the moment I don't have spare equipment. Worth pointing out: the version of Windows you're testing with matters greatly. RFC1323 isn't enabled by default in some versions of Windows, and in other versions the default/min/max window sizes on Windows are set absurdly small. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 13:28:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AF671065670 for ; Thu, 25 Feb 2010 13:28:34 +0000 (UTC) (envelope-from bsd@nezmer.info) Received: from mail.nezmer.info (nezmer.info [97.107.142.36]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2CA8FC12 for ; Thu, 25 Feb 2010 13:28:33 +0000 (UTC) Date: Thu, 25 Feb 2010 15:10:21 +0200 From: Nezmer To: freebsd-stable@freebsd.org Message-ID: <20100225131021.GA2500@mail> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Subject: stable/8: iwn5100 , unable to get scan results X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 13:28:34 -0000 Hi, I'm new to FreeBSD so don't shoot me If I'm missing something obvious. I built and installed stable/8 yesterday to try out the updated iwn driver. But every time I run: ifconfig iwn0 up scan I get: ifconfig: unable to get scan results How can I go about investigating this further? The needed module and firmware are loaded of course. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 13:42:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B16251065706 for ; Thu, 25 Feb 2010 13:42:12 +0000 (UTC) (envelope-from bschmidt@mx.techwires.net) Received: from mx.techwires.net (mx.techwires.net [IPv6:2001:4d88:100f:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF488FC1B for ; Thu, 25 Feb 2010 13:42:12 +0000 (UTC) Received: by mx.techwires.net (Postfix, from userid 1001) id 86EC81A6D5; Thu, 25 Feb 2010 14:42:11 +0100 (CET) Date: Thu, 25 Feb 2010 14:42:11 +0100 From: Bernhard Schmidt To: Nezmer Message-ID: <20100225134211.GA31135@mx.techwires.net> References: <20100225131021.GA2500@mail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100225131021.GA2500@mail> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: stable/8: iwn5100 , unable to get scan results X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 13:42:12 -0000 On Thu, Feb 25, 2010 at 03:10:21PM +0200, Nezmer wrote: > Hi, > > I'm new to FreeBSD so don't shoot me If I'm missing something obvious. > > I built and installed stable/8 yesterday to try out the updated iwn > driver. But every time I run: > ifconfig iwn0 up scan > > I get: > ifconfig: unable to get scan results > > How can I go about investigating this further? > The needed module and firmware are loaded of course. 8.0 and newer use VAPs, you have to do: # kldload if_iwn # ifconfig wlan0 create wlandev iwn0 # ifconfig wlan0 up # ifconfig wlan0 list scan From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 14:12:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36A011065676; Thu, 25 Feb 2010 14:12:55 +0000 (UTC) (envelope-from mamalos@eng.auth.gr) Received: from vergina.eng.auth.gr (vergina.eng.auth.gr [155.207.18.1]) by mx1.freebsd.org (Postfix) with ESMTP id 87DA98FC0C; Thu, 25 Feb 2010 14:12:54 +0000 (UTC) Received: from mamalacation.ee.auth.gr (mamalacation.ee.auth.gr [155.207.33.29]) by vergina.eng.auth.gr (8.14.3/8.14.1) with ESMTP id o1PECoMc030957; Thu, 25 Feb 2010 16:12:50 +0200 (EET) (envelope-from mamalos@eng.auth.gr) Message-ID: <4B86855D.7030705@eng.auth.gr> Date: Thu, 25 Feb 2010 16:12:45 +0200 From: George Mamalakis User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.5) Gecko/20100115 Thunderbird/3.0 MIME-Version: 1.0 To: Alexander Nedotsukov References: <4AB27FB6.4010806@eng.auth.gr> <20090921222241.GF1001@rwpc12.mby.riverwillow.net.au> <20091002081319.GN37304@rwpc12.mby.riverwillow.net.au> <200910020824.15488.john@baldwin.cx> <19306024-4C3D-41EC-A198-1652B047DF1A@FreeBSD.org> <20091007043806.GN1086@rwpc12.mby.riverwillow.net.au> <4B82B97C.8090808@eng.auth.gr> <5EF8A3A6-2E8B-44B5-BC1F-AF09A953F953@freebsd.org> <4B86623D.6010708@eng.auth.gr> <4B86659B.5020005@eng.auth.gr> In-Reply-To: <4B86659B.5020005@eng.auth.gr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: John Baldwin , Doug Rabson , Rick Macklem , freebsd-stable , freebsd-current@freebsd.org Subject: Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 14:12:55 -0000 To sum things up. By fixing my /etc/hosts to read as it should (this needs some work too, the behavior with the 'wrong' /etc/hosts is unexpected), ldapwhoami works fine IF (AND ONLY IF) someone kinits to a user principal; otherwise it segfaults. My default binding method is GSSAPI, hence the segfault. If I use simple bind (ldapwhoami -W -D 'blabla') it works fine. If I LD_PRELOAD the "hacked" library lala.so, which is created like this: lala.c: int gss_release_buffer(void *a, void *b) { return 0; } # gcc -c -fPIC -shared lala.c -o lala.so and if I haven't obtained any kerberos tickets, then # ldapwhoami SASL/GSSAPI authentication started Segmentation fault: 11 (core dumped) once I ldpreload the above fake-library, then: # LD_PRELOAD=./lala.so ldapwhoami SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) which is what is expected. This, maybe implies that something is freed by gss_release_buffer that normally shouldn't. amd64 won't hang in the same test (so no need to ld_preload anything), but shares the same problem with i386 when /etc/hosts is not as expected (to recreate the /etc/hosts problem, place in your /etc/hosts file two fqdns for the ldap server's IP, but write the ldap server's fqdn second in turn). Thank you all and have a nice evening. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 15:58:50 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBE00106564A; Thu, 25 Feb 2010 15:58:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BD4658FC13; Thu, 25 Feb 2010 15:58:50 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6F23946B2E; Thu, 25 Feb 2010 10:58:50 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id C32D58A021; Thu, 25 Feb 2010 10:58:49 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Thu, 25 Feb 2010 07:56:49 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201002250756.49757.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 25 Feb 2010 10:58:49 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-net@freebsd.org, Ivan Voras Subject: Re: 8-stable crashes in vmware (possible em driver issue?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 15:58:51 -0000 On Wednesday 24 February 2010 7:23:44 pm Ivan Voras wrote: > Ivan Voras wrote: > > I have a fairly recent 8-stable machine running under VMWare ESXi 3.5 > > (amd64 guest), which apparently crashes every few days from the same > > causes: > > > > em0: discard frame w/o packet header > > em0: discard frame w/o packet header > > em0: discard frame w/o packet header > > Panic string: sbsndptr: sockbuf 0xffffff007cca8c20 and mbuf > > 0xffffff00490a6400 clashing > > In case someone is interested or has an idea - on this machine I have > multiple crashed cores with similarily strange problems all connected > with networking and/or the em driver: > > 1) > em0: watchdog timeout -- resetting > Fatal trap 12: page fault while in kernel mode > current process = 0 (em0 taskq) > > 2) > em0: watchdog timeout -- resetting > Fatal trap 9: general protection fault while in kernel mode > current process = 1219 (slapd) > > 3) > em0: discard frame w/o packet header > panic: sbdrop > > I'm scratching my head about the #2 above - I don't think trap#9 is usual. Certain bad pointer values on amd64 trigger a GP# rather than a PF#, so for those you would get trap 9 instead of trap 12. Specifically, the top N bits of a pointer in amd64 have to either be all 0 or all 1. If there is a mix, then you get a GP# instead of a PF#. -- John Baldwin From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 17:29:40 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1B631065679 for ; Thu, 25 Feb 2010 17:29:40 +0000 (UTC) (envelope-from rjk@wintek.com) Received: from local.wintek.com (local.wintek.com [206.230.2.234]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC038FC1A for ; Thu, 25 Feb 2010 17:29:40 +0000 (UTC) Received: from rjk.wintek.local (172.28.1.248) by local.wintek.com (172.28.1.234) with Microsoft SMTP Server id 8.1.393.1; Thu, 25 Feb 2010 12:19:04 -0500 Message-ID: <4B86B108.8010009@wintek.com> Date: Thu, 25 Feb 2010 12:19:04 -0500 From: Richard Kuhns Organization: Wintek Corporation User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100209 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: multipart/mixed; boundary="------------040400030506020702070404" Subject: FreeBSD8.0 sound on Dell Optiplex 960 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rjk@wintek.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 17:29:40 -0000 --------------040400030506020702070404 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hello, I'm hoping someone can give me some help getting audio working on this beast. I'm by no means an audiophile; I just like to listen to the occasional CD and/or online station while I work. None of the jacks on the back of the tower seem to do anything. In addition, when starting a Virtual Machine under VirtualBox, I get a popup saying: "Some audio devices (PCM_in, PCM_mic) could not be opened". Under Details, the Error ID is HostAudioNotResponding. $ cat /dev/sndstat FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) Installed devices: pcm0: (play) default pcm1: (play/rec) pcm2: (play/rec) Per the snd_hda manpage, I'm also attaching the hda-related output from a verbose boot. Any help would be greatly appreciated! Thanks, - Richart -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 --------------040400030506020702070404 Content-Type: text/plain; name="hda-dmesg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="hda-dmesg" hdac0: Probing codec #0... hdac0: HDA Codec #0: ATI R6xx HDMI hdac0: HDA Codec ID: 0x1002aa01 hdac0: Vendor: 0x1002 hdac0: Device: 0xaa01 hdac0: Revision: 0x01 hdac0: Stepping: 0x00 hdac0: PCI Subvendor: 0xaa381028 hdac0: Found audio FG nid=1 startnode=2 endnode=4 total=2 hdac0: hdac0: Processing audio FG cad=0 nid=1... hdac0: GPIO: 0x00000000 NumGPIO=0 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=0 hdac0: nid 3 0x18560010 as 1 seq 0 Digital-out Jack jack 6 loc 24 color Unknown misc 0 hdac0: Patched pins configuration: hdac0: nid 3 0x18560010 as 1 seq 0 Digital-out Jack jack 6 loc 24 color Unknown misc 0 hdac0: 1 associations found: hdac0: Association 0 (1) out: hdac0: Pin nid=3 seq=0 hdac0: Tracing association 0 (1) hdac0: Pin 3 traced to DAC 2 hdac0: Association 0 (1) trace succeeded hdac0: Tracing input monitor hdac0: Tracing beeper hdac0: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac0: hdac0: +-------------------+ hdac0: | DUMPING HDA NODES | hdac0: +-------------------+ hdac0: hdac0: Default Parameter hdac0: ----------------- hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00020070 hdac0: 16 bits, 32 44 48 KHz hdac0: IN amp: 0x00000000 hdac0: OUT amp: 0x00000000 hdac0: hdac0: nid: 2 hdac0: Name: audio output hdac0: Widget cap: 0x00000201 hdac0: DIGITAL STEREO hdac0: Association: 0 (0x00000001) hdac0: OSS: pcm (pcm) hdac0: Stream cap: 0x00000001 hdac0: PCM hdac0: PCM cap: 0x00020070 hdac0: 16 bits, 32 44 48 KHz hdac0: hdac0: nid: 3 hdac0: Name: pin: Digital-out (Jack) hdac0: Widget cap: 0x00400381 hdac0: DIGITAL UNSOL STEREO hdac0: Association: 0 (0x00000001) hdac0: Pin cap: 0x00000094 hdac0: PDC OUT HDMI hdac0: Pin config: 0x18560010 hdac0: Pin control: 0x00000040 OUT hdac0: connections: 1 hdac0: | hdac0: + <- nid=2 [audio output] hdac0: pcm0: at cad 0 nid 1 on hdac0 pcm0: +--------------------------------------+ pcm0: | DUMPING PCM Playback/Record Channels | pcm0: +--------------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: Stream cap: 0x00000005 pcm0: AC3 PCM pcm0: PCM cap: 0x00020070 pcm0: 16 bits, 32 44 48 KHz pcm0: DAC: 2 pcm0: pcm0: +-------------------------------+ pcm0: | DUMPING Playback/Record Paths | pcm0: +-------------------------------+ pcm0: pcm0: Playback: pcm0: pcm0: nid=3 [pin: Digital-out (Jack)] pcm0: | pcm0: + <- nid=2 [audio output] [src: pcm] pcm0: pcm0: +-------------------------+ pcm0: | DUMPING Volume Controls | pcm0: +-------------------------+ pcm0: pcm0: Forcing Soft PCM volume pcm0: Forcing master volume with PCM pcm0: Mixer "vol" -> "none": child=0x00000010 pcm0: Mixer "pcm": parent="vol" pcm0: Soft PCM mixer ENABLED pcm0: clone manager: deadline=750ms flags=0x8000001e pcm0: sndbuf_setmap 1240000, 4000; 0xe7115000 -> 1240000 hdac1: Probing codec #0... hdac1: HDA Codec #0: Analog Devices AD1984A hdac1: HDA Codec ID: 0x11d4194a hdac1: Vendor: 0x11d4 hdac1: Device: 0x194a hdac1: Revision: 0x04 hdac1: Stepping: 0x00 hdac1: PCI Subvendor: 0x02761028 hdac1: Found audio FG nid=1 startnode=2 endnode=43 total=41 hdac1: hdac1: Processing audio FG cad=0 nid=1... hdac1: GPIO: 0x40000003 NumGPIO=3 NumGPO=0 NumGPI=0 GPIWake=0 GPIUnsol=1 hdac1: nid 17 0x02214040 as 4 seq 0 Headphones Jack jack 1 loc 2 color Green misc 0 hdac1: nid 18 0x01014010 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 0 hdac1: nid 19 0x991301f0 as 15 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac1: nid 20 0x02a19020 as 2 seq 0 Mic Jack jack 1 loc 2 color Pink misc 0 hdac1: nid 21 0x01813030 as 3 seq 0 Line-in Jack jack 1 loc 1 color Blue misc 0 hdac1: nid 22 0x413301f0 as 15 seq 0 CD None jack 3 loc 1 color Unknown misc 1 hdac1: nid 23 0x41a601f0 as 15 seq 0 Mic None jack 6 loc 1 color Unknown misc 1 hdac1: Patching widget caps nid=26 0x00400000 -> 0x00700000 hdac1: nid 27 0x414501f0 as 15 seq 0 SPDIF-out None jack 5 loc 1 color Unknown misc 1 hdac1: nid 28 0x413301f0 as 15 seq 0 CD None jack 3 loc 1 color Unknown misc 1 hdac1: GHOST: nid=42 j=0 entnum=4 index=0 res=0x00002701 hdac1: Patched pins configuration: hdac1: nid 17 0x02214040 as 4 seq 0 Headphones Jack jack 1 loc 2 color Green misc 0 hdac1: nid 18 0x01014010 as 1 seq 0 Line-out Jack jack 1 loc 1 color Green misc 0 hdac1: nid 19 0x991301f0 as 15 seq 0 Speaker Fixed jack 3 loc 25 color Unknown misc 1 hdac1: nid 20 0x02a19020 as 2 seq 0 Mic Jack jack 1 loc 2 color Pink misc 0 hdac1: nid 21 0x01813030 as 3 seq 0 Line-in Jack jack 1 loc 1 color Blue misc 0 hdac1: nid 22 0x413301f0 as 15 seq 0 CD None jack 3 loc 1 color Unknown misc 1 [DISABLED] hdac1: nid 23 0x41a601f0 as 15 seq 0 Mic None jack 6 loc 1 color Unknown misc 1 [DISABLED] hdac1: nid 27 0x414501f0 as 15 seq 0 SPDIF-out None jack 5 loc 1 color Unknown misc 1 [DISABLED] hdac1: nid 28 0x413301f0 as 15 seq 0 CD None jack 3 loc 1 color Unknown misc 1 [DISABLED] hdac1: 5 associations found: hdac1: Association 0 (1) out: hdac1: Pin nid=18 seq=0 hdac1: Association 1 (2) in: hdac1: Pin nid=20 seq=0 hdac1: Association 2 (3) in: hdac1: Pin nid=21 seq=0 hdac1: Association 3 (4) out: hdac1: Pin nid=17 seq=0 hdac1: Association 4 (15) out: hdac1: Pin nid=19 seq=0 hdac1: Tracing association 0 (1) hdac1: Pin 18 traced to DAC 3 hdac1: Association 0 (1) trace succeeded hdac1: Tracing association 1 (2) hdac1: Pin 20 traced to ADC 8 hdac1: Association 1 (2) trace succeeded hdac1: Tracing association 2 (3) hdac1: Pin 21 traced to ADC 9 hdac1: Association 2 (3) trace succeeded hdac1: Tracing association 3 (4) hdac1: Pin 17 traced to DAC 4 hdac1: Association 3 (4) trace succeeded hdac1: Tracing association 4 (15) hdac1: Unable to trace pin 19 seq 0 with min nid 0 hdac1: Association 4 (15) trace failed hdac1: Tracing input monitor hdac1: Tracing beeper hdac1: nid 26 traced to out hdac1: FG config/quirks: forcestereo ivref50 ivref80 ivref100 ivref hdac1: hdac1: +-------------------+ hdac1: | DUMPING HDA NODES | hdac1: +-------------------+ hdac1: hdac1: Default Parameter hdac1: ----------------- hdac1: Stream cap: 0x00000001 hdac1: PCM hdac1: PCM cap: 0x000e07ff hdac1: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 176 192 KHz hdac1: IN amp: 0x80000000 hdac1: OUT amp: 0x00052727 hdac1: hdac1: nid: 2 [DISABLED] hdac1: Name: audio output hdac1: Widget cap: 0x00030211 hdac1: DIGITAL STEREO hdac1: Stream cap: 0x00000005 hdac1: AC3 PCM hdac1: PCM cap: 0x000e07e0 hdac1: 16 20 24 bits, 44 48 88 96 176 192 KHz hdac1: hdac1: nid: 3 hdac1: Name: audio output hdac1: Widget cap: 0x00000405 hdac1: PWR STEREO hdac1: Association: 0 (0x00000001) hdac1: OSS: pcm (pcm) hdac1: Stream cap: 0x00000001 hdac1: PCM hdac1: PCM cap: 0x000e07ff hdac1: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 176 192 KHz hdac1: Output amp: 0x00052727 hdac1: mute=0 step=39 size=5 offset=39 hdac1: hdac1: nid: 4 hdac1: Name: audio output hdac1: Widget cap: 0x00000405 hdac1: PWR STEREO hdac1: Association: 3 (0x00000001) hdac1: OSS: pcm (pcm) hdac1: Stream cap: 0x00000001 hdac1: PCM hdac1: PCM cap: 0x000e07ff hdac1: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 176 192 KHz hdac1: Output amp: 0x00052727 hdac1: mute=0 step=39 size=5 offset=39 hdac1: hdac1: nid: 5 [DISABLED] hdac1: Name: vendor widget hdac1: Widget cap: 0x00f00000 hdac1: hdac1: nid: 6 [DISABLED] hdac1: Name: vendor widget hdac1: Widget cap: 0x00f00000 hdac1: hdac1: nid: 7 hdac1: Name: audio mixer hdac1: Widget cap: 0x00200103 hdac1: STEREO hdac1: Association: 3 (0x00000001) hdac1: OSS: pcm hdac1: Input amp: 0x80000000 hdac1: mute=1 step=0 size=0 offset=0 hdac1: connections: 2 hdac1: | hdac1: + <- nid=34 [audio selector] hdac1: + [DISABLED] <- nid=33 [audio selector] hdac1: hdac1: nid: 8 hdac1: Name: audio input hdac1: Widget cap: 0x00100501 hdac1: PWR STEREO hdac1: Association: 1 (0x00000001) hdac1: Stream cap: 0x00000001 hdac1: PCM hdac1: PCM cap: 0x000e07ff hdac1: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 176 192 KHz hdac1: connections: 1 hdac1: | hdac1: + <- nid=12 [audio selector] hdac1: hdac1: nid: 9 hdac1: Name: audio input hdac1: Widget cap: 0x00100501 hdac1: PWR STEREO hdac1: Association: 2 (0x00000001) hdac1: Stream cap: 0x00000001 hdac1: PCM hdac1: PCM cap: 0x000e07ff hdac1: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 176 192 KHz hdac1: connections: 1 hdac1: | hdac1: + <- nid=13 [audio selector] hdac1: hdac1: nid: 10 hdac1: Name: audio mixer hdac1: Widget cap: 0x00200103 hdac1: STEREO hdac1: Association: 0 (0x00000001) hdac1: OSS: pcm, speaker hdac1: Input amp: 0x80000000 hdac1: mute=1 step=0 size=0 offset=0 hdac1: connections: 2 hdac1: | hdac1: + [DISABLED] <- nid=4 [audio output] hdac1: + <- nid=33 [audio selector] hdac1: hdac1: nid: 11 [DISABLED] hdac1: Name: audio mixer hdac1: Widget cap: 0x00200103 hdac1: STEREO hdac1: Input amp: 0x80000000 hdac1: mute=1 step=0 size=0 offset=0 hdac1: connections: 2 hdac1: | hdac1: + [DISABLED] <- nid=15 [audio selector] [DISABLED] hdac1: + [DISABLED] <- nid=33 [audio selector] hdac1: hdac1: nid: 12 hdac1: Name: audio selector hdac1: Widget cap: 0x0030010d hdac1: STEREO hdac1: Association: 1 (0x00000001) hdac1: OSS: mic hdac1: Output amp: 0x80053627 hdac1: mute=1 step=54 size=5 offset=39 hdac1: connections: 6 hdac1: | hdac1: + <- nid=20 [pin: Mic (Pink Jack)] (selected) hdac1: + [DISABLED] <- nid=21 [pin: Line-in (Blue Jack)] hdac1: + [DISABLED] <- nid=22 [pin: CD (None)] [DISABLED] hdac1: + [DISABLED] <- nid=32 [audio mixer] hdac1: + [DISABLED] <- nid=37 [audio selector] [DISABLED] hdac1: + [DISABLED] <- nid=23 [pin: Mic (None)] [DISABLED] hdac1: hdac1: nid: 13 hdac1: Name: audio selector hdac1: Widget cap: 0x0030010d hdac1: STEREO hdac1: Association: 2 (0x00000001) hdac1: OSS: line hdac1: Output amp: 0x80053627 hdac1: mute=1 step=54 size=5 offset=39 hdac1: connections: 6 hdac1: | hdac1: + [DISABLED] <- nid=20 [pin: Mic (Pink Jack)] hdac1: + <- nid=21 [pin: Line-in (Blue Jack)] (selected) hdac1: + [DISABLED] <- nid=22 [pin: CD (None)] [DISABLED] hdac1: + [DISABLED] <- nid=32 [audio mixer] hdac1: + [DISABLED] <- nid=37 [audio selector] [DISABLED] hdac1: + [DISABLED] <- nid=23 [pin: Mic (None)] [DISABLED] hdac1: hdac1: nid: 14 [DISABLED] hdac1: Name: audio selector hdac1: Widget cap: 0x00300101 hdac1: STEREO hdac1: connections: 2 hdac1: | hdac1: + <- nid=3 [audio output] (selected) hdac1: + <- nid=4 [audio output] hdac1: hdac1: nid: 15 [DISABLED] hdac1: Name: audio selector hdac1: Widget cap: 0x00300101 hdac1: STEREO hdac1: connections: 2 hdac1: | hdac1: + <- nid=3 [audio output] (selected) hdac1: + <- nid=4 [audio output] hdac1: hdac1: nid: 16 hdac1: Name: beep widget hdac1: Widget cap: 0x0070000c hdac1: Association: -2 (0x00000000) hdac1: OSS: speaker (speaker) hdac1: Output amp: 0x800b0f0f hdac1: mute=1 step=15 size=11 offset=15 hdac1: hdac1: nid: 17 hdac1: Name: pin: Headphones (Green Jack) hdac1: Widget cap: 0x0040018d hdac1: UNSOL STEREO hdac1: Association: 3 (0x00000001) hdac1: Pin cap: 0x0000001f hdac1: ISC TRQD PDC HP OUT hdac1: Pin config: 0x02214040 hdac1: Pin control: 0x000000c0 HP OUT hdac1: Output amp: 0x80000000 hdac1: mute=1 step=0 size=0 offset=0 hdac1: connections: 1 hdac1: | hdac1: + <- nid=7 [audio mixer] hdac1: hdac1: nid: 18 hdac1: Name: pin: Line-out (Green Jack) hdac1: Widget cap: 0x0040058d hdac1: PWR UNSOL STEREO hdac1: Association: 0 (0x00000001) hdac1: Pin cap: 0x0001001f hdac1: ISC TRQD PDC HP OUT EAPD hdac1: Pin config: 0x01014010 hdac1: Pin control: 0x00000040 OUT hdac1: EAPD: 0x00000002 hdac1: Output amp: 0x80000000 hdac1: mute=1 step=0 size=0 offset=0 hdac1: connections: 1 hdac1: | hdac1: + <- nid=10 [audio mixer] hdac1: hdac1: nid: 19 [DISABLED] hdac1: Name: pin: Speaker (Fixed) hdac1: Widget cap: 0x0040050c hdac1: PWR hdac1: Pin cap: 0x00010010 hdac1: OUT EAPD hdac1: Pin config: 0x991301f0 hdac1: Pin control: 0x00000000 hdac1: EAPD: 0x00000002 hdac1: Output amp: 0x80051f1f hdac1: mute=1 step=31 size=5 offset=31 hdac1: connections: 1 hdac1: | hdac1: + [DISABLED] <- nid=31 [audio mixer] [DISABLED] hdac1: hdac1: nid: 20 hdac1: Name: pin: Mic (Pink Jack) hdac1: Widget cap: 0x0040008b hdac1: UNSOL STEREO hdac1: Association: 1 (0x00000001) hdac1: OSS: mic (mic) hdac1: Pin cap: 0x00003727 hdac1: ISC TRQD PDC IN VREF[ 50 80 100 GROUND HIZ ] hdac1: Pin config: 0x02a19020 hdac1: Pin control: 0x00000025 IN VREFs hdac1: Input amp: 0x00270300 hdac1: mute=0 step=3 size=39 offset=0 hdac1: hdac1: nid: 21 hdac1: Name: pin: Line-in (Blue Jack) hdac1: Widget cap: 0x0040008b hdac1: UNSOL STEREO hdac1: Association: 2 (0x00000001) hdac1: OSS: line (line) hdac1: Pin cap: 0x00003727 hdac1: ISC TRQD PDC IN VREF[ 50 80 100 GROUND HIZ ] hdac1: Pin config: 0x01813030 hdac1: Pin control: 0x00000025 IN VREFs hdac1: Input amp: 0x00270300 hdac1: mute=0 step=3 size=39 offset=0 hdac1: hdac1: nid: 22 [DISABLED] hdac1: Name: pin: CD (None) hdac1: Widget cap: 0x0040058d hdac1: PWR UNSOL STEREO hdac1: Pin cap: 0x00010037 hdac1: ISC TRQD PDC OUT IN EAPD hdac1: Pin config: 0x413301f0 hdac1: Pin control: 0x00000000 hdac1: EAPD: 0x00000002 hdac1: Output amp: 0x80000000 hdac1: mute=1 step=0 size=0 offset=0 hdac1: connections: 1 hdac1: | hdac1: + [DISABLED] <- nid=11 [audio mixer] [DISABLED] hdac1: hdac1: nid: 23 [DISABLED] hdac1: Name: pin: Mic (None) hdac1: Widget cap: 0x0040020b hdac1: DIGITAL STEREO hdac1: Pin cap: 0x00000020 hdac1: IN hdac1: Pin config: 0x41a601f0 hdac1: Pin control: 0x00000000 hdac1: Input amp: 0x00170300 hdac1: mute=0 step=3 size=23 offset=0 hdac1: hdac1: nid: 24 [DISABLED] hdac1: Name: vendor widget hdac1: Widget cap: 0x00f00100 hdac1: connections: 1 hdac1: | hdac1: + <- nid=6 [vendor widget] [DISABLED] hdac1: hdac1: nid: 25 [DISABLED] hdac1: Name: power widget hdac1: Widget cap: 0x00500500 hdac1: PWR hdac1: connections: 2 hdac1: | hdac1: + <- nid=32 [audio mixer] (selected) hdac1: + <- nid=33 [audio selector] hdac1: hdac1: nid: 26 hdac1: Name: beep widget hdac1: Widget cap: 0x00700000 hdac1: Association: -2 (0x00000000) hdac1: OSS: speaker (speaker) hdac1: hdac1: nid: 27 [DISABLED] hdac1: Name: pin: SPDIF-out (None) hdac1: Widget cap: 0x0040038d hdac1: DIGITAL UNSOL STEREO hdac1: Pin cap: 0x00000014 hdac1: PDC OUT hdac1: Pin config: 0x414501f0 hdac1: Pin control: 0x00000000 hdac1: Output amp: 0x80052727 hdac1: mute=1 step=39 size=5 offset=39 hdac1: connections: 1 hdac1: | hdac1: + [DISABLED] <- nid=2 [audio output] [DISABLED] hdac1: hdac1: nid: 28 [DISABLED] hdac1: Name: pin: CD (None) hdac1: Widget cap: 0x0040018d hdac1: UNSOL STEREO hdac1: Pin cap: 0x00003737 hdac1: ISC TRQD PDC OUT IN VREF[ 50 80 100 GROUND HIZ ] hdac1: Pin config: 0x413301f0 hdac1: Pin control: 0x00000000 hdac1: Output amp: 0x80000000 hdac1: mute=1 step=0 size=0 offset=0 hdac1: connections: 1 hdac1: | hdac1: + [DISABLED] <- nid=36 [audio mixer] [DISABLED] hdac1: hdac1: nid: 29 [DISABLED] hdac1: Name: vendor widget hdac1: Widget cap: 0x00f00100 hdac1: connections: 25 hdac1: | hdac1: + <- nid=7 [audio mixer] (selected) hdac1: + <- nid=10 [audio mixer] hdac1: + <- nid=11 [audio mixer] [DISABLED] hdac1: + <- nid=12 [audio selector] hdac1: + <- nid=13 [audio selector] hdac1: + <- nid=14 [audio selector] [DISABLED] hdac1: + <- nid=15 [audio selector] [DISABLED] hdac1: + <- nid=17 [pin: Headphones (Green Jack)] hdac1: + <- nid=18 [pin: Line-out (Green Jack)] hdac1: + <- nid=19 [pin: Speaker (Fixed)] [DISABLED] hdac1: + <- nid=20 [pin: Mic (Pink Jack)] hdac1: + <- nid=21 [pin: Line-in (Blue Jack)] hdac1: + [DISABLED] <- nid=22 [pin: CD (None)] [DISABLED] hdac1: + [DISABLED] <- nid=25 [power widget] [DISABLED] hdac1: + <- nid=26 [beep widget] hdac1: + [DISABLED] <- nid=28 [pin: CD (None)] [DISABLED] hdac1: + <- nid=30 [audio mixer] [DISABLED] hdac1: + <- nid=31 [audio mixer] [DISABLED] hdac1: + <- nid=32 [audio mixer] hdac1: + <- nid=33 [audio selector] hdac1: + <- nid=34 [audio selector] hdac1: + <- nid=35 [audio selector] [DISABLED] hdac1: + <- nid=36 [audio mixer] [DISABLED] hdac1: + [DISABLED] <- nid=37 [audio selector] [DISABLED] hdac1: + <- nid=38 [vendor widget] [DISABLED] hdac1: hdac1: nid: 30 [DISABLED] hdac1: Name: audio mixer hdac1: Widget cap: 0x00200103 hdac1: STEREO hdac1: Input amp: 0x80000000 hdac1: mute=1 step=0 size=0 offset=0 hdac1: connections: 2 hdac1: | hdac1: + [DISABLED] <- nid=14 [audio selector] [DISABLED] hdac1: + [DISABLED] <- nid=33 [audio selector] hdac1: hdac1: nid: 31 [DISABLED] hdac1: Name: audio mixer hdac1: Widget cap: 0x00200100 hdac1: connections: 1 hdac1: | hdac1: + <- nid=30 [audio mixer] [DISABLED] hdac1: hdac1: nid: 32 hdac1: Name: audio mixer hdac1: Widget cap: 0x0020010b hdac1: STEREO hdac1: Association: 0 (0x00000001) hdac1: OSS: pcm, speaker hdac1: Input amp: 0x80051f17 hdac1: mute=1 step=31 size=5 offset=23 hdac1: connections: 7 hdac1: | hdac1: + [DISABLED] <- nid=20 [pin: Mic (Pink Jack)] hdac1: + [DISABLED] <- nid=21 [pin: Line-in (Blue Jack)] hdac1: + [DISABLED] <- nid=22 [pin: CD (None)] [DISABLED] hdac1: + <- nid=26 [beep widget] hdac1: + [DISABLED] <- nid=37 [audio selector] [DISABLED] hdac1: + <- nid=3 [audio output] hdac1: + [DISABLED] <- nid=4 [audio output] hdac1: hdac1: nid: 33 hdac1: Name: audio selector hdac1: Widget cap: 0x0030010d hdac1: STEREO hdac1: Association: 0 (0x00000001) hdac1: OSS: pcm, speaker hdac1: Output amp: 0x80051f1f hdac1: mute=1 step=31 size=5 offset=31 hdac1: connections: 1 hdac1: | hdac1: + <- nid=32 [audio mixer] hdac1: hdac1: nid: 34 hdac1: Name: audio selector hdac1: Widget cap: 0x00300101 hdac1: STEREO hdac1: Association: 3 (0x00000001) hdac1: OSS: pcm hdac1: connections: 2 hdac1: | hdac1: + [DISABLED] <- nid=3 [audio output] hdac1: + <- nid=4 [audio output] (selected) hdac1: hdac1: nid: 35 [DISABLED] hdac1: Name: audio selector hdac1: Widget cap: 0x00300101 hdac1: STEREO hdac1: connections: 2 hdac1: | hdac1: + <- nid=3 [audio output] (selected) hdac1: + <- nid=4 [audio output] hdac1: hdac1: nid: 36 [DISABLED] hdac1: Name: audio mixer hdac1: Widget cap: 0x00200103 hdac1: STEREO hdac1: Input amp: 0x80000000 hdac1: mute=1 step=0 size=0 offset=0 hdac1: connections: 2 hdac1: | hdac1: + [DISABLED] <- nid=35 [audio selector] [DISABLED] hdac1: + [DISABLED] <- nid=33 [audio selector] hdac1: hdac1: nid: 37 [DISABLED] hdac1: Name: audio selector hdac1: Widget cap: 0x0030010d hdac1: STEREO hdac1: Output amp: 0x00270300 hdac1: mute=0 step=3 size=39 offset=0 hdac1: connections: 1 hdac1: | hdac1: + [DISABLED] <- nid=28 [pin: CD (None)] [DISABLED] hdac1: hdac1: nid: 38 [DISABLED] hdac1: Name: vendor widget hdac1: Widget cap: 0x00f00100 hdac1: connections: 3 hdac1: | hdac1: + <- nid=20 [pin: Mic (Pink Jack)] (selected) hdac1: + <- nid=21 [pin: Line-in (Blue Jack)] hdac1: + [DISABLED] <- nid=28 [pin: CD (None)] [DISABLED] hdac1: hdac1: nid: 39 [DISABLED] hdac1: Name: vendor widget hdac1: Widget cap: 0x00f00301 hdac1: DIGITAL STEREO hdac1: connections: 2 hdac1: | hdac1: + <- nid=8 [audio input] (selected) hdac1: + <- nid=9 [audio input] hdac1: hdac1: nid: 40 [DISABLED] hdac1: Name: vendor widget hdac1: Widget cap: 0x00f0030d hdac1: DIGITAL STEREO hdac1: Output amp: 0x80000000 hdac1: mute=1 step=0 size=0 offset=0 hdac1: connections: 2 hdac1: | hdac1: + <- nid=8 [audio input] (selected) hdac1: + <- nid=9 [audio input] hdac1: hdac1: nid: 41 [DISABLED] hdac1: Name: vendor widget hdac1: Widget cap: 0x00f0030d hdac1: DIGITAL STEREO hdac1: Output amp: 0x80000000 hdac1: mute=1 step=0 size=0 offset=0 hdac1: connections: 2 hdac1: | hdac1: + <- nid=8 [audio input] (selected) hdac1: + <- nid=9 [audio input] hdac1: hdac1: nid: 42 [DISABLED] hdac1: Name: vendor widget hdac1: Widget cap: 0x00f00301 hdac1: DIGITAL STEREO hdac1: connections: 2 hdac1: | hdac1: + [DISABLED] <- nid=1 [GHOST!] [UNKNOWN] (selected) hdac1: + <- nid=39 [vendor widget] [DISABLED] hdac1: pcm1: at cad 0 nid 1 on hdac1 pcm1: +--------------------------------------+ pcm1: | DUMPING PCM Playback/Record Channels | pcm1: +--------------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e07ff pcm1: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 176 192 KHz pcm1: DAC: 3 pcm1: pcm1: Record: pcm1: pcm1: Stream cap: 0x00000001 pcm1: PCM pcm1: PCM cap: 0x000e07ff pcm1: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 176 192 KHz pcm1: ADC: 8 pcm1: pcm1: +-------------------------------+ pcm1: | DUMPING Playback/Record Paths | pcm1: +-------------------------------+ pcm1: pcm1: Playback: pcm1: pcm1: nid=18 [pin: Line-out (Green Jack)] pcm1: | pcm1: + <- nid=10 [audio mixer] [src: pcm, speaker] pcm1: | pcm1: + <- nid=33 [audio selector] [src: pcm, speaker] pcm1: | pcm1: + <- nid=32 [audio mixer] [src: pcm, speaker] pcm1: | pcm1: + <- nid=26 [beep widget] [src: speaker] pcm1: + <- nid=3 [audio output] [src: pcm] pcm1: pcm1: Record: pcm1: pcm1: nid=8 [audio input] pcm1: | pcm1: + <- nid=12 [audio selector] [src: mic] pcm1: | pcm1: + <- nid=20 [pin: Mic (Pink Jack)] [src: mic] pcm1: pcm1: +-------------------------+ pcm1: | DUMPING Volume Controls | pcm1: +-------------------------+ pcm1: pcm1: Master Volume (OSS: vol) pcm1: | pcm1: +- ctl 6 (nid 10 in 1): mute pcm1: +- ctl 13 (nid 18 in ): mute pcm1: +- ctl 28 (nid 32 in 5): -34/12dB (32 steps) + mute pcm1: +- ctl 30 (nid 33 out): -46/0dB (32 steps) + mute pcm1: pcm1: PCM Volume (OSS: pcm) pcm1: | pcm1: +- ctl 1 (nid 3 out): -58/0dB (40 steps) pcm1: +- ctl 28 (nid 32 in 5): -34/12dB (32 steps) + mute pcm1: pcm1: Microphone Volume (OSS: mic) pcm1: | pcm1: +- ctl 15 (nid 20 out): 0/30dB (4 steps) pcm1: pcm1: Speaker/Beep Volume (OSS: speaker) pcm1: | pcm1: +- ctl 11 (nid 16 out): -45/0dB (16 steps) + mute pcm1: +- ctl 26 (nid 32 in 3): -34/12dB (32 steps) + mute pcm1: pcm1: Recording Level (OSS: rec) pcm1: | pcm1: +- ctl 9 (nid 12 out): -58/22dB (55 steps) + mute pcm1: pcm1: Mixer "vol": pcm1: Mixer "pcm": pcm1: Mixer "speaker": pcm1: Mixer "mic": pcm1: Mixer "rec": pcm1: Mixer "ogain": pcm1: clone manager: deadline=750ms flags=0x8000001e pcm1: sndbuf_setmap 1250000, 4000; 0xe7125000 -> 1250000 pcm1: sndbuf_setmap 1260000, 4000; 0xe7135000 -> 1260000 pcm2: at cad 0 nid 1 on hdac1 pcm2: +--------------------------------------+ pcm2: | DUMPING PCM Playback/Record Channels | pcm2: +--------------------------------------+ pcm2: pcm2: Playback: pcm2: pcm2: Stream cap: 0x00000001 pcm2: PCM pcm2: PCM cap: 0x000e07ff pcm2: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 176 192 KHz pcm2: DAC: 4 pcm2: pcm2: Record: pcm2: pcm2: Stream cap: 0x00000001 pcm2: PCM pcm2: PCM cap: 0x000e07ff pcm2: 16 20 24 bits, 8 11 16 22 32 44 48 88 96 176 192 KHz pcm2: ADC: 9 pcm2: pcm2: +-------------------------------+ pcm2: | DUMPING Playback/Record Paths | pcm2: +-------------------------------+ pcm2: pcm2: Playback: pcm2: pcm2: nid=17 [pin: Headphones (Green Jack)] pcm2: | pcm2: + <- nid=7 [audio mixer] [src: pcm] pcm2: | pcm2: + <- nid=34 [audio selector] [src: pcm] pcm2: | pcm2: + <- nid=4 [audio output] [src: pcm] pcm2: pcm2: Record: pcm2: pcm2: nid=9 [audio input] pcm2: | pcm2: + <- nid=13 [audio selector] [src: line] pcm2: | pcm2: + <- nid=21 [pin: Line-in (Blue Jack)] [src: line] pcm2: pcm2: +-------------------------+ pcm2: | DUMPING Volume Controls | pcm2: +-------------------------+ pcm2: pcm2: Master Volume (OSS: vol) pcm2: | pcm2: +- ctl 2 (nid 4 out): -58/0dB (40 steps) pcm2: +- ctl 3 (nid 7 in 0): mute pcm2: +- ctl 12 (nid 17 in ): mute pcm2: pcm2: PCM Volume (OSS: pcm) pcm2: | pcm2: +- ctl 2 (nid 4 out): -58/0dB (40 steps) pcm2: +- ctl 3 (nid 7 in 0): mute pcm2: +- ctl 12 (nid 17 in ): mute pcm2: pcm2: Line-in Volume (OSS: line) pcm2: | pcm2: +- ctl 16 (nid 21 out): 0/30dB (4 steps) pcm2: pcm2: Recording Level (OSS: rec) pcm2: | pcm2: +- ctl 10 (nid 13 out): -58/22dB (55 steps) + mute pcm2: pcm2: Mixer "vol": pcm2: Mixer "pcm": pcm2: Mixer "line": pcm2: Mixer "rec": pcm2: clone manager: deadline=750ms flags=0x8000001e pcm2: sndbuf_setmap 1270000, 4000; 0xe7145000 -> 1270000 pcm2: sndbuf_setmap 1280000, 4000; 0xe7155000 -> 1280000 --------------040400030506020702070404-- From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 17:38:29 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11FCA106564A for ; Thu, 25 Feb 2010 17:38:29 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F5618FC15 for ; Thu, 25 Feb 2010 17:38:28 +0000 (UTC) Received: by wyb40 with SMTP id 40so2188428wyb.13 for ; Thu, 25 Feb 2010 09:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=8IpXrvCN3z4ZShYHNcd7KFSvLsZUBFwAIqZPwuOEPOU=; b=LCjwGQ/6acIjkUfgZ1Sicpi5IIJATLwzemuPYOTGOdmB8DA2DBCM+xAZvyGOb+16Pk Kp8YnFrEkAzxkP+CyMDgBsWw3AEje7aM/1BEHJokI5WUj/i82eF1s651/qRLel+t+Tu4 PoBUuJKrudVjDO2IxU3py1CsDnrT//1aKLjAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=jGK53VyPycQz7TVPH+SQxYqI74R/bKWGUyqfzcA4OFQmHXjShUCwM/uR//sIvqlUWd rSxLOGBh3Byhq+iqpXIDzPjzoPWB+AcxdkMluY/a1J2ByWMhq41X27bCrC/f60b95cVS ZsPtJ74d9LPbh0tXnE1zRmgi8YOAG0W3Ho+fA= MIME-Version: 1.0 Received: by 10.216.156.203 with SMTP id m53mr28774wek.209.1267119498139; Thu, 25 Feb 2010 09:38:18 -0800 (PST) In-Reply-To: <4B86B108.8010009@wintek.com> References: <4B86B108.8010009@wintek.com> Date: Thu, 25 Feb 2010 17:38:17 +0000 Message-ID: <2e027be01002250938g2ce478a0p5ee6715c144ab0c8@mail.gmail.com> From: Tom Evans To: rjk@wintek.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD8.0 sound on Dell Optiplex 960 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 17:38:29 -0000 On Thu, Feb 25, 2010 at 5:19 PM, Richard Kuhns wrote: > Hello, > > I'm hoping someone can give me some help getting audio working on this > beast. I'm by no means an audiophile; I just like to listen to the > occasional CD and/or online station while I work. None of the jacks on th= e > back of the tower seem to do anything. > > In addition, when starting a Virtual Machine under VirtualBox, I get a po= pup > saying: > > "Some audio devices (PCM_in, PCM_mic) could not be opened". Under Details= , > the Error ID is HostAudioNotResponding. > > $ cat /dev/sndstat > FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) > Installed devices: > pcm0: (play) default > pcm1: (play/rec) > pcm2: (play/rec) > > Per the snd_hda manpage, I'm also attaching the hda-related output from a > verbose boot. > > Any help would be greatly appreciated! > > Thanks, > =C2=A0 =C2=A0 =C2=A0 =C2=A0- Richart Your default device is currently the HDMI output on your graphics card. You probably want to play with sysctl snd.default_unit=3D1 (or 2) to set it to one of the analog outputs. One should be the front audio, the other one should be the back. Once you've got it sorted out, add to /etc/sysctl.conf to persist it. Cheers Tom From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 18:42:31 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FC441065670 for ; Thu, 25 Feb 2010 18:42:31 +0000 (UTC) (envelope-from rjk@wintek.com) Received: from local.wintek.com (local.wintek.com [206.230.2.234]) by mx1.freebsd.org (Postfix) with ESMTP id CF14F8FC0C for ; Thu, 25 Feb 2010 18:42:30 +0000 (UTC) Received: from rjk.wintek.local (172.28.1.248) by local.wintek.com (172.28.1.234) with Microsoft SMTP Server id 8.1.393.1; Thu, 25 Feb 2010 13:42:29 -0500 Message-ID: <4B86C495.6030309@wintek.com> Date: Thu, 25 Feb 2010 13:42:29 -0500 From: Richard Kuhns Organization: Wintek Corporation User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100209 Thunderbird/3.0.1 MIME-Version: 1.0 To: Tom Evans References: <4B86B108.8010009@wintek.com> <2e027be01002250938g2ce478a0p5ee6715c144ab0c8@mail.gmail.com> In-Reply-To: <2e027be01002250938g2ce478a0p5ee6715c144ab0c8@mail.gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD8.0 sound on Dell Optiplex 960 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rjk@wintek.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 18:42:31 -0000 On 02/25/10 12:38, Tom Evans wrote: > On Thu, Feb 25, 2010 at 5:19 PM, Richard Kuhns wrote: >> Hello, >> >> I'm hoping someone can give me some help getting audio working on this >> beast. I'm by no means an audiophile; I just like to listen to the >> occasional CD and/or online station while I work. None of the jacks on the >> back of the tower seem to do anything. >> >> In addition, when starting a Virtual Machine under VirtualBox, I get a popup >> saying: >> >> "Some audio devices (PCM_in, PCM_mic) could not be opened". Under Details, >> the Error ID is HostAudioNotResponding. >> >> $ cat /dev/sndstat >> FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) >> Installed devices: >> pcm0: (play) default >> pcm1: (play/rec) >> pcm2: (play/rec) >> >> Per the snd_hda manpage, I'm also attaching the hda-related output from a >> verbose boot. >> >> Any help would be greatly appreciated! >> >> Thanks, >> - Richart > > Your default device is currently the HDMI output on your graphics > card. You probably want to play with sysctl snd.default_unit=1 (or 2) > to set it to one of the analog outputs. One should be the front audio, > the other one should be the back. > > Once you've got it sorted out, add to /etc/sysctl.conf to persist it. > > Cheers > > Tom OK, now I can get sound from both vlc and xmms as long as I plug the speakers into the headphone jack on the front of the tower, which is a major improvement! It doesn't make any difference which (non-zero) value I give to hw.snd.default_unit. VMs no longer complain at startup, but there's still no audio from them; there's also no sound from flash. I'm pretty sure that's what BBC Radio uses, and I've always liked to listen to Radio 4's news at 1 (which is 8 AM for me). Many thanks for your help! -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 20:11:34 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AC001065670 for ; Thu, 25 Feb 2010 20:11:34 +0000 (UTC) (envelope-from rjk@wintek.com) Received: from local.wintek.com (local.wintek.com [206.230.2.234]) by mx1.freebsd.org (Postfix) with ESMTP id 04B6F8FC08 for ; Thu, 25 Feb 2010 20:11:33 +0000 (UTC) Received: from rjk.wintek.local (172.28.1.248) by local.wintek.com (172.28.1.234) with Microsoft SMTP Server id 8.1.393.1; Thu, 25 Feb 2010 15:11:33 -0500 Message-ID: <4B86D974.2070808@wintek.com> Date: Thu, 25 Feb 2010 15:11:32 -0500 From: Richard Kuhns Organization: Wintek Corporation User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100209 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B86B108.8010009@wintek.com> <2e027be01002250938g2ce478a0p5ee6715c144ab0c8@mail.gmail.com> <4B86C495.6030309@wintek.com> In-Reply-To: <4B86C495.6030309@wintek.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD8.0 sound on Dell Optiplex 960 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rjk@wintek.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 20:11:34 -0000 On 02/25/10 13:42, Richard Kuhns wrote: > On 02/25/10 12:38, Tom Evans wrote: >> On Thu, Feb 25, 2010 at 5:19 PM, Richard Kuhns wrote: >>> Hello, >>> >>> I'm hoping someone can give me some help getting audio working on this >>> beast. I'm by no means an audiophile; I just like to listen to the >>> occasional CD and/or online station while I work. None of the jacks on the >>> back of the tower seem to do anything. >>> >>> In addition, when starting a Virtual Machine under VirtualBox, I get a popup >>> saying: >>> >>> "Some audio devices (PCM_in, PCM_mic) could not be opened". Under Details, >>> the Error ID is HostAudioNotResponding. >>> >>> $ cat /dev/sndstat >>> FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386) >>> Installed devices: >>> pcm0: (play) default >>> pcm1: (play/rec) >>> pcm2: (play/rec) >>> >>> Per the snd_hda manpage, I'm also attaching the hda-related output from a >>> verbose boot. >>> >>> Any help would be greatly appreciated! >>> >>> Thanks, >>> - Richart >> >> Your default device is currently the HDMI output on your graphics >> card. You probably want to play with sysctl snd.default_unit=1 (or 2) >> to set it to one of the analog outputs. One should be the front audio, >> the other one should be the back. >> >> Once you've got it sorted out, add to /etc/sysctl.conf to persist it. >> >> Cheers >> >> Tom > > OK, now I can get sound from both vlc and xmms as long as I plug the speakers > into the headphone jack on the front of the tower, which is a major improvement! > It doesn't make any difference which (non-zero) value I give to > hw.snd.default_unit. VMs no longer complain at startup, but there's still no > audio from them; there's also no sound from flash. I'm pretty sure that's what > BBC Radio uses, and I've always liked to listen to Radio 4's news at 1 (which is > 8 AM for me). > > Many thanks for your help! > While I know it's generally bad form to follow up to myself, I've made some more progress and it might be useful to someone else. The problem with flash was apparently that I had to symlink /usr/compat/linux/lib/libssl.so.5 to the currently installed version, libssl.so.0.9.8g. Strange but true... At any rate, I now have sound from everything I did before except for VMs under Virtual Box. Once again, thanks, Tom, for your help. -- Richard Kuhns My Desk: 765-269-8541 Wintek Corporation Internet Support: 765-269-8503 427 N 6th Street STE C Consulting: 765-269-8504 Lafayette, IN 47901-2211 Accounting: 765-269-8502 From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 21:11:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC16D1065675 for ; Thu, 25 Feb 2010 21:11:05 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8DB8FC08 for ; Thu, 25 Feb 2010 21:11:04 +0000 (UTC) Received: from furia.intranet ([93.104.121.188]) (AUTH: CRAM-MD5 lopez.on.the.lists@yellowspace.net, SSL: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by mail.yellowspace.net with esmtp; Thu, 25 Feb 2010 22:11:00 +0100 id 00341D54.000000004B86E764.0001223B Message-ID: <4B86E764.2070806@yellowspace.net> Date: Thu, 25 Feb 2010 22:11:00 +0100 From: Lorenzo Perone User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Panic on 8-STABLE in mpt(4) on a DELL PowerEdge R300 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 21:11:05 -0000 Hello, I just got a PowerEdge R300, which netbooted fine with 7.2-STABLE (FreeBSD 7.2-STABLE #6: Wed Dec 2 01:25:52 CET 2009), but is dropping me into a panic right at boot with 8.0-STABLE (just built). This is what I'm getting (please forgive the lazyness of not transcribing everything..): http://lorenzo.yellowspace.net/R300_mpt_panic.gif An excerpt: Fatal trap 12: page fault while in kernel mode current process = 8 (mpt_raid0) Stopped at xpt_rescan+0x14: movq(%rsi),%rdx After just rebuilding the kernel with debug symbols, DDB and KDB, and booting with boot -d, I'm dropped into kdb but I cannot do anything there, at least not via the vKVM of the DRAC (I would have liked to trace, but it won't work..) The controller is the SAS 6i/R. If I can provide any other details please let me know. Thanx a lot for taking your time, Regards, Lorenzo From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 21:11:12 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74E89106566C for ; Thu, 25 Feb 2010 21:11:12 +0000 (UTC) (envelope-from bsd@nezmer.info) Received: from mail.nezmer.info (nezmer.info [97.107.142.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5502B8FC19 for ; Thu, 25 Feb 2010 21:11:12 +0000 (UTC) Date: Thu, 25 Feb 2010 23:10:47 +0200 From: Nezmer To: freebsd-stable@freebsd.org Message-ID: <20100225211047.GA19493@mail> References: <20100225131021.GA2500@mail> <20100225134211.GA31135@mx.techwires.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100225134211.GA31135@mx.techwires.net> User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: stable/8: iwn5100 , unable to get scan results X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 21:11:12 -0000 On Thu, Feb 25, 2010 at 02:42:11PM +0100, Bernhard Schmidt wrote: > On Thu, Feb 25, 2010 at 03:10:21PM +0200, Nezmer wrote: > > Hi, > > > > I'm new to FreeBSD so don't shoot me If I'm missing something obvious. > > > > I built and installed stable/8 yesterday to try out the updated iwn > > driver. But every time I run: > > ifconfig iwn0 up scan > > > > I get: > > ifconfig: unable to get scan results > > > > How can I go about investigating this further? > > The needed module and firmware are loaded of course. > > 8.0 and newer use VAPs, you have to do: > # kldload if_iwn > # ifconfig wlan0 create wlandev iwn0 > # ifconfig wlan0 up > # ifconfig wlan0 list scan Forgot to say thanks. Works flawlessly. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 22:02:49 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A165106566B for ; Thu, 25 Feb 2010 22:02:49 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id EE27B8FC15 for ; Thu, 25 Feb 2010 22:02:48 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 07BBC15342F for ; Thu, 25 Feb 2010 23:02:48 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr3rzZqvlQBW; Thu, 25 Feb 2010 23:02:46 +0100 (CET) Received: from [127.0.0.1] (unknown [192.168.10.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 0A784153434 for ; Thu, 25 Feb 2010 23:02:46 +0100 (CET) Message-ID: <4B86F384.3010308@digiware.nl> Date: Thu, 25 Feb 2010 23:02:44 +0100 From: Willem Jan Withagen User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 22:02:49 -0000 Hi, I build an ZFS server based on Supermicro C2SBX with 8Gb and intel Q9550 http://www.supermicro.com/products/motherboard/Core2Duo/X38/C2SBX.cfm with an areca 1120 with 8*1,5T It has an Inter em0, as in: Feb 25 14:46:29 zfs kernel: pci0: on pcib0 Feb 25 14:46:29 zfs kernel: em0: p ort 0x1820-0x183f mem 0xdf900000-0xdf91ffff,0xdf924000-0xdf924fff irq 16 at devi ce 25.0 on pci0 Feb 25 14:46:29 zfs kernel: em0: Using MSI interrupt Feb 25 14:46:29 zfs kernel: em0: [FILTER] Feb 25 14:46:29 zfs kernel: em0: Ethernet address: 00:30:48:de:97:cd I runs 8.0-STABLE as of today, but the same problem is there on a 9 februari kernel. And just out of the blue it started today locking up the network device. Everything else seems te work, only pinging out doesn't work. And the device cannot be pinged from the outside as well. But I can log in, do work on the system but the ethernet device stays offline no matter how hard I prod it. Sometimes I get the response: Feb 25 17:41:42 zfs kernel: em0: link state changed to DOWN Feb 25 17:41:42 zfs kernel: em0: Could not setup receive structures when I want to UP the device. Rebooting is the only way out. So what is going on here???? =============================== BUT there's another snag: shutdown -r now times out on one or the other daemon. After which the system no longer tries to reboot, does not respond to the keyboard. So in the end a hard reset is the only way out. All help welcomed. --WjW From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 22:10:27 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5128106566C for ; Thu, 25 Feb 2010 22:10:27 +0000 (UTC) (envelope-from jholland@fastsoft.com) Received: from hq-es.fastsoft.com (hq-es.fastsoft.com [38.102.243.86]) by mx1.freebsd.org (Postfix) with ESMTP id CC5B78FC0A for ; Thu, 25 Feb 2010 22:10:27 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Feb 2010 14:10:27 -0800 Message-ID: In-Reply-To: <20100225090502.GA84181@icarus.home.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: vfs deadlock during panic? Thread-Index: Acq1+dtIPFYRRtrPRLCDppQp5uFQ1AASMvvg References: <20100225073317.GA82327@icarus.home.lan> <20100225090502.GA84181@icarus.home.lan> From: "Jake Holland" To: Subject: RE: vfs deadlock during panic? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 22:10:28 -0000 > Are you sure one of the filesystems on the disk isn't corrupt? =20 > There's been reports of this problem in the past, but AFAIR it=20 > doesn't manifest itself in this manner. Ah, thanks. Your comment spurred me to search for 'VOP_LOCK1_APV lock order reversal', instead of 'freebsd hang on panic', and I see now that this has been reported several times. I read a bunch of the threads, but it looks like there's no solution yet. But you're right that nobody else seems to be complaining about a rare hang-on-panic problem, either. Anyway, I didn't see any of the threads that mentioned file system corruption, with the possible exception of http://lists.freebsd.org/pipermail/freebsd-current/2010-January/014786.h tml, which said that running fsck was what triggered the LORs. So I'm assuming this was a mis-remembered detail, unless you've got a better reference, and I'll take a rain check on re-installing everything on a new disk, for now. But thanks for the comment, I do appreciate it, and it helped me realize what I should follow up on. I guess my next step is to try to fix the vfs locking. I think I'll see what happens if I use a sx_lock instead of a mtx for BO_MTX to guard the block, so it won't care so much what the underlying file system does during vnode operations, for the file access. I assume that won't work, but maybe it's a start towards understanding what I do need. The mounting one looks trickier, because the vn_lock looks rather confusing, and I'm really not sure what to do about the Giant dependencies it seems to have. But I guess maybe I'll see if there's a way to defer some of these operations to a working thread or something. Not sure if I'll actually have the time to go that deep on this issue, and I'm unfortunately not certain it'll solve the hanging panic problem. I guess I can see why nobody fixed it yet. Oh well. Thanks again for the suggestion. Maybe in light of the alternative it would be worth at least trying that separate disk idea after all. I have already seen something very similar on at least 2 different machines with different disks, but they came from the same dump/restore image, so maybe if it's because of fs corruption, there's a shared reason behind it. From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 22:16:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BD731065672 for ; Thu, 25 Feb 2010 22:16:54 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id CBDC58FC1F for ; Thu, 25 Feb 2010 22:16:53 +0000 (UTC) Received: from furia.intranet ([93.104.121.188]) (AUTH: CRAM-MD5 lopez.on.the.lists@yellowspace.net, SSL: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by mail.yellowspace.net with esmtp; Thu, 25 Feb 2010 23:16:50 +0100 id 00341D54.000000004B86F6D2.000138F3 Message-ID: <4B86F6D2.5020206@yellowspace.net> Date: Thu, 25 Feb 2010 23:16:50 +0100 From: Lorenzo Perone User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <4B86E764.2070806@yellowspace.net> In-Reply-To: <4B86E764.2070806@yellowspace.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: scottl@FreeBSD.org Subject: Re: Panic on 8-STABLE in mpt(4) on a DELL PowerEdge R300 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 22:16:54 -0000 On 25.02.10 22:11, Lorenzo Perone wrote: > I just got a PowerEdge R300, which netbooted fine with 7.2-STABLE > (FreeBSD 7.2-STABLE #6: Wed Dec 2 01:25:52 CET 2009), but is dropping me > into a panic right at boot with 8.0-STABLE (just built). > > This is what I'm getting (please forgive the lazyness of not > transcribing everything..): > > http://lorenzo.yellowspace.net/R300_mpt_panic.gif > > An excerpt: > > Fatal trap 12: page fault while in kernel mode > > current process = 8 (mpt_raid0) > Stopped at xpt_rescan+0x14: movq(%rsi),%rdx > > After just rebuilding the kernel with debug symbols, DDB and KDB, and > booting with boot -d, I'm dropped into kdb but I cannot do anything > there, at least not via the vKVM of the DRAC (I would have liked to > trace, but it won't work..) > > The controller is the SAS 6i/R. > > If I can provide any other details please let me know. > > Thanx a lot for taking your time, > A follow up - I recompiled the kernel with mpt from head (svn checkout svn://svn.freebsd.org/base/head/sys/dev/mpt) and the problem still exists. Let me know if I should post a pr. I'm also available for testing patches. Regards, Lorenzo From owner-freebsd-stable@FreeBSD.ORG Thu Feb 25 22:59:32 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56AC51065672 for ; Thu, 25 Feb 2010 22:59:32 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id DC0B88FC1B for ; Thu, 25 Feb 2010 22:59:31 +0000 (UTC) Received: by wwb22 with SMTP id 22so2487926wwb.13 for ; Thu, 25 Feb 2010 14:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zmUqAOPyN+1leZJifd1C3fLbYe3MO4Xx4XGaEpA6iqU=; b=skCHo/+t8uSyMACOCfhtdB55brlgS48s7RdFLimZnSFELoI1kGMbSN/jU/9pOzMKdR /qrw2dleXBoUH3avhEeJZWN8grhne8AuqWI596lUOBKSskrqiLx8/kEFr9p3ICvRTD1S HHbyupx5VBzCB9sxTEzUaeV473K/azN5SxmJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Kg60XYfIN59HRwQRJnqPacUiE34qHJAaH7iKRQAM7NWEOBYAfaPsSQvMiZpxh90h/q XnEG1FDyseIVfskmL/ydtc8gfTeFtn6JsHy8jU0/xEYj5keCJjZO7j6xS9hsMPYJG5nz ejHA2yp+dqrWSo2YmwizmzsBmhDXr/TjAInv0= MIME-Version: 1.0 Received: by 10.216.89.202 with SMTP id c52mr450435wef.84.1267138768513; Thu, 25 Feb 2010 14:59:28 -0800 (PST) In-Reply-To: <4B86F384.3010308@digiware.nl> References: <4B86F384.3010308@digiware.nl> Date: Thu, 25 Feb 2010 14:59:28 -0800 Message-ID: <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> From: Jack Vogel To: Willem Jan Withagen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2010 22:59:32 -0000 The failure to "setup receive structures" means it did not have sufficient mbufs to setup the RX ring and buffer structs. Not sure why this results in a lockup, but try and increase kern.ipc.nmbclusters. Let me know what happens, Jack On Thu, Feb 25, 2010 at 2:02 PM, Willem Jan Withagen wrote: > Hi, > > I build an ZFS server based on > Supermicro C2SBX with 8Gb and intel Q9550 > http://www.supermicro.com/products/motherboard/Core2Duo/X38/C2SBX.cfm > with an areca 1120 with 8*1,5T > > It has an Inter em0, as in: > Feb 25 14:46:29 zfs kernel: pci0: on pcib0 > Feb 25 14:46:29 zfs kernel: em0: 6.9.14> p > ort 0x1820-0x183f mem 0xdf900000-0xdf91ffff,0xdf924000-0xdf924fff irq 16 at > devi > ce 25.0 on pci0 > Feb 25 14:46:29 zfs kernel: em0: Using MSI interrupt > Feb 25 14:46:29 zfs kernel: em0: [FILTER] > Feb 25 14:46:29 zfs kernel: em0: Ethernet address: 00:30:48:de:97:cd > > I runs 8.0-STABLE as of today, > but the same problem is there on a 9 februari kernel. > > And just out of the blue it started today locking up the network device. > > Everything else seems te work, only pinging out doesn't work. > And the device cannot be pinged from the outside as well. > > But I can log in, do work on the system but the ethernet device stays > offline no matter how hard I prod it. > Sometimes I get the response: > Feb 25 17:41:42 zfs kernel: em0: link state changed to DOWN > Feb 25 17:41:42 zfs kernel: em0: Could not setup receive structures > when I want to UP the device. > > Rebooting is the only way out. > > So what is going on here???? > > > =============================== > BUT there's another snag: > shutdown -r now times out on one or the other daemon. > After which the system no longer tries to reboot, does not respond to the > keyboard. > So in the end a hard reset is the only way out. > > All help welcomed. > --WjW > _______________________________________________ > 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 Feb 26 01:35:53 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E26A1065676 for ; Fri, 26 Feb 2010 01:35:53 +0000 (UTC) (envelope-from faber@zod.isi.edu) Received: from zod.isi.edu (zod.isi.edu [128.9.168.221]) by mx1.freebsd.org (Postfix) with ESMTP id CB0318FC19 for ; Fri, 26 Feb 2010 01:35:52 +0000 (UTC) Received: from zod.isi.edu (localhost [127.0.0.1]) by zod.isi.edu (8.14.3/8.14.3) with ESMTP id o1Q1Zqou068348; Thu, 25 Feb 2010 17:35:52 -0800 (PST) (envelope-from faber@zod.isi.edu) Received: (from faber@localhost) by zod.isi.edu (8.14.3/8.14.3/Submit) id o1Q1ZpFt068347; Thu, 25 Feb 2010 17:35:51 -0800 (PST) (envelope-from faber) Date: Thu, 25 Feb 2010 17:35:51 -0800 From: Ted Faber To: Ian Smith Message-ID: <20100226013551.GA67689@zod.isi.edu> References: <20100224165203.GA10423@zod.isi.edu> <20100225152711.M16250@sola.nimnet.asn.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline In-Reply-To: <20100225152711.M16250@sola.nimnet.asn.au> User-Agent: Mutt/1.4.2.3i X-url: http://www.isi.edu/~faber Cc: freebsd-stable@freebsd.org Subject: Re: resume slow on Thinkpad T42 FreeBSD 8-STABLE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 01:35:53 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 25, 2010 at 05:18:22PM +1100, Ian Smith wrote: > On Wed, 24 Feb 2010, Ted Faber wrote: >=20 > > I'm running a recent (yesterday) FreeBSD 8-STABLE on my T42. When I > > resume from suspend the fan starts screen returns immediately (to text > > mode) and then the system idles for about a minute until it shakes > > itself awake. The keyboard LEDs cycle, the disk runs and X returns. >=20 > Good to hear, Ted .. I thought it was just me :) Your symptoms appear=20 > entirely identical to mine as posted on Dec 13th to mobile@ and acpi@,=20 > see thread 'Thinkpad T23 60 second stall on resuming 8.0-RELEASE/i386'=20 > http://lists.freebsd.org/pipermail/freebsd-acpi/2009-December/006192.html >=20 > Nate Lawson thought it an ATA rather than an ACPI problem and I assume=20 > he's likely right, but I've had too much $work (and too little solar=20 > power during an exceptionally wet summer) to follow it up. Yeah, that sounds like the problem. I'll poke at ata if I get the chance, but that seems unlikely for a while. > In case relevant, my ad0 is a 120GB Fujitsu MHV2120AH, but your TOSHIBA= =20 > MK4026GAX looks more likely to be the original disk? Likely, but I can't be sure. I bought it used. >=20 > I've no time to spend on hunting this now, and know nothing about ATA=20 > anyway, assuming that's where the problem lies, but I'll be quick to=20 > test any suggested solution/s! Like I say, assuming I ever get free time, I'll have a look. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuHJXcACgkQaUz3f+Zf+XsIrgCgyOXTaGP2ZQrPhG3V+FasU8l5 eOgAoOjadMWijL9E8Q0Uhs/g0NEeynfJ =kMqm -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 02:48:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B63F2106566B; Fri, 26 Feb 2010 02:48:18 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yw0-f204.google.com (mail-yw0-f204.google.com [209.85.211.204]) by mx1.freebsd.org (Postfix) with ESMTP id 165F68FC17; Fri, 26 Feb 2010 02:48:17 +0000 (UTC) Received: by ywh42 with SMTP id 42so3539013ywh.7 for ; Thu, 25 Feb 2010 18:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=LMxfO5gNvQsbzC/GH68br2vZ7Q2Xpv2l24dUyMHj+6U=; b=MnGtb/cUaheiQJziIvs0zuKleBGwoDPbv6cV1DW1MOiBfJ82DsdScl9jOkwc/zCPYN FerK5v/bo/VybPaQePeniwmQ3+vXE3knyMwbk4gwD/itkKej65JfQNJtr9AfvMbc5aUn SQGSv+ryT8NyO4nli5HqtATswIRZZxcFuKdEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=xyZ2Roc5v//nvkwDb3T0QTNu5A6EsF+B+Cti04s4rlyZZjFLP2kJPCuDSmUQFqGxWk Qocy/bI01+TFOSB6B9NbBLGVCFaGpUVNLx9IJvF9yykcCSNrA3XQU6EoYqTzy2Tc1HOQ Z1RigT7nCtokWDGMpkex0WaykCSvX5hcnDWxY= Received: by 10.101.3.3 with SMTP id f3mr476502ani.150.1267152490039; Thu, 25 Feb 2010 18:48:10 -0800 (PST) Received: from ppp-19.10.dialinfree.com (ppp-19.10.dialinfree.com [209.172.19.10]) by mx.google.com with ESMTPS id 7sm2827714ywc.49.2010.02.25.18.47.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 25 Feb 2010 18:48:07 -0800 (PST) Sender: "J. Hellenthal" Date: Thu, 25 Feb 2010 21:46:47 -0500 From: jhell To: Doug Barton In-Reply-To: <4B82122E.9050304@FreeBSD.org> Message-ID: References: <4B82122E.9050304@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current , FreeBSD Stable , freebsd-questions@freebsd.org Subject: Re: Plans for BIND and DNSSEC readiness X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 02:48:18 -0000 On Mon, 22 Feb 2010 00:12, dougb@ wrote: > ---------------------------- PGP Command Output ---------------------------- > gpg: Signature made Mon Feb 22 00:12:14 2010 EST using DSA key ID D5B2F0FB > gpg: Good signature from "Doug Barton " > gpg: aka "Doug Barton " > gpg: aka "Doug Barton " > ----------- Begin PGP Signed Message Verified 2010-02-25 21:12:11 ---------- > > I've made a post to -arch regarding my plans for BIND in the base, along > with some information about getting ready for DNSSEC, including the > upcoming signing of the root zone. You can find the message at > http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html. > > If you have any feedback regarding any of these topics, please follow up > to that thread. > > > Regards, > > Doug > > -- > > ... and that's just a little bit of history repeating. > -- Propellerheads > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > > > ------------ End PGP Signed Message Verified 2010-02-25 21:12:11 ----------- > Little late for a reply, But thanks for keeping this updated as this is obviously very important information that not everyone usually comes across. At least I didn't hear anything about it till now. Thanks Doug, -- jhell From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 05:03:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EB3A106566B for ; Fri, 26 Feb 2010 05:03:43 +0000 (UTC) (envelope-from jjrushford@gmail.com) Received: from mail-px0-f195.google.com (mail-px0-f195.google.com [209.85.216.195]) by mx1.freebsd.org (Postfix) with ESMTP id D62408FC1A for ; Fri, 26 Feb 2010 05:03:42 +0000 (UTC) Received: by pxi33 with SMTP id 33so1172124pxi.14 for ; Thu, 25 Feb 2010 21:03:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=0+/Dhvb/BvFbP6kEsZQMGl4PI3mHUQap5GVijkleLFU=; b=Cv+LczgPuw/t5yYWn6b8XBOmU9cZbR9YND2rmmaPx3goIaGfSRForKNlc4sRdqJyvl A1PvY05AB1dLfAg4DIyxsrRSPxn3lftWq8m20UqQNGE2j1KGbOShaKtHhFExOQziO+go vE10TdhZScZi4fJv7eChVDvaIkGCFnSxrcbc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=eTveIel/zCOE8mJT1dxsZvS3Duwhw7Th9DIgR1xm9Q8YEdvt/mzAzzzrmTxtonxSin CkuCJ9VUD4KalwRmXoUc/4TwwsI6HQIJiO9HAE8Ss5u8u/Sj+DdFFOMZZRaCPn4mHgiG b538j9jmvcERsr9AeW6VLgvS6mDuUf86nQ03w= Received: by 10.141.214.25 with SMTP id r25mr331028rvq.105.1267159298246; Thu, 25 Feb 2010 20:41:38 -0800 (PST) Received: from ?192.168.2.140? (h3.alisa.org [65.103.114.107]) by mx.google.com with ESMTPS id 20sm2968105pzk.3.2010.02.25.20.41.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 25 Feb 2010 20:41:36 -0800 (PST) Message-ID: <4B8750FD.3020000@gmail.com> Date: Thu, 25 Feb 2010 21:41:33 -0700 From: "John J. Rushford" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: lopez.on.the.lists@yellowspace.net, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Panic on 8-STABLE in mpt(4) on a DELL PowerEdge R300 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 05:03:43 -0000 I'm running into the same problem, mpt(4) panic on FreeBSD 8-STABLE. I'm running FreeBSD 8.0-STABLE, the current kernel was cvsup'd and built @ January 14th, 2010. I cvsup'd tonight, 2/25/2010, and built a new kernel. Attached is the panic when I tried to boot into single user mode, I was able to boot up on the old kernel built on January 14th. mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 mpt0:vol0(mpt0:0:0): 2 Members: (mpt0:1:0:0): Primary Online (mpt0:1:1:0): Secondary Online mpt0:vol0(mpt0:0:0): RAID-1 - Optimal mpt0:vol0(mpt0:0:0): Status ( Enabled ) (mpt0:vol0:0): Physical (mpt0:0:0:0), Pass-thru (mpt0:1:0:0) (mpt0:vol0:0): Online (mpt0:vol0:1): Physical (mpt0:0:1:0), Pass-thru (mpt0:1:1:0) (mpt0:vol0:1): Online Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x10 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8019c4bd stack pointer = 0x28:0xffffff80e81d5ba0 frame pointer = 0x28:0xffffff80e81d5bd0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 6 (mpt_raid0) trap number = 12 panic: page fault cpuid = 0 Uptime: 3s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 08:36:21 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D75E1065673 for ; Fri, 26 Feb 2010 08:36:21 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 458128FC1C for ; Fri, 26 Feb 2010 08:36:20 +0000 (UTC) Received: (qmail 28247 invoked by uid 0); 26 Feb 2010 08:37:53 -0000 Received: from unknown (HELO ?10.3.2.40?) (spork@bway.net@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Feb 2010 08:37:53 -0000 Date: Fri, 26 Feb 2010 03:36:19 -0500 (EST) From: Charles Sprickman X-X-Sender: spork@charles-sprickmans-imac.local To: freebsd-stable@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: 7.2-p4: panic: ufsdirhash_lookup: bad offset in hash array X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 08:36:21 -0000 I have a box that has paniced two nights in a row with this error. I have a corefile from last night, but tonight's failed: Uptime: 23h55m22s Physical memory: 6130 MB Dumping 759 MB: 744 728 712 696 680 664 648 ** DUMP FAILED (ERROR 16) ** Here's some info from the core I do have: #0 doadump () at pcpu.h:195 195 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) where #0 doadump () at pcpu.h:195 #1 0x0000000000000004 in ?? () #2 0xffffffff8034c799 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0xffffffff8034cba2 in panic (fmt=0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0xffffffff8052545f in ufsdirhash_lookup (ip=0xffffff0012530398, name=0xffffff012788b000 "1266473205.M123372P75411V0000005BI08EE5F75_0.xena.bway.net,S=43650:2,S", namelen=70, offp=0xffffffff285f474c, bpp=0xffffffff285f4738, prevoffp=0x0) at /usr/src/sys/ufs/ufs/ufs_dirhash.c:599 #5 0xffffffff805278a0 in ufs_lookup (ap=0xffffffff285f4790) at /usr/src/sys/ufs/ufs/ufs_lookup.c:224 #6 0xffffffff803be024 in vfs_cache_lookup (ap=Variable "ap" is not available.) at vnode_if.h:83 #7 0xffffffff805a08bf in VOP_LOOKUP_APV (vop=0xffffffff807945c0, a=0xffffffff285f4850) at vnode_if.c:99 #8 0xffffffff803c4a4f in lookup (ndp=0xffffffff285f4960) at vnode_if.h:57 #9 0xffffffff803c58ba in namei (ndp=0xffffffff285f4960) at /usr/src/sys/kern/vfs_lookup.c:215 #10 0xffffffff803d2c94 in kern_lstat (td=0xffffff007693aa50, path=Variable "path" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2184 #11 0xffffffff803d2f07 in lstat (td=Variable "td" is not available. ) at /usr/src/sys/kern/vfs_syscalls.c:2167 #12 0xffffffff80574e77 in syscall (frame=0xffffffff285f4c80) at /usr/src/sys/amd64/amd64/trap.c:900 #13 0xffffffff805598ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:330 #14 0x000000080071063c in ?? () Previous frame inner to this frame (corrupt stack?) Previous to this, I had one panic while this box was being stress-tested before it went into production. It's a new Dell box with a Dell/LSI RAID card (mfi driver). It's a mail server, and the ufs dirhash sysctl is pushed up to "vfs.ufs.dirhash_maxmem=33554432". Previous post on the previous panic back in November is here: http://marc.info/?l=freebsd-stable&m=125901173424554&w=2 Before last night's crash, it was up for 93 days. Nothing has changed in the past few days as far as software or overall load. The crash did happen during or shortly after the daily periodic run. Any interest in this one? Is it something to file a PR on? dmesg is below... Thanks, Charles ___ Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet - www.bway.net spork@bway.net - 212.655.9344 Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.2-RELEASE-p4 #2: Mon Nov 2 21:55:12 EST 2009 spork@bigmail.bway.net:/usr/obj/usr/src/sys/BWAY7-64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Quad-Core AMD Opteron(tm) Processor 2372 HE (2094.76-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009> AMD Features=0xee500800 AMD Features2=0x37ff,,,Prefetch,,,,> TSC: P-state invariant Cores per package: 4 usable memory = 6427951104 (6130 MB) avail memory = 6198829056 (5911 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic1: Changing APIC ID to 5 ioapic2: Changing APIC ID to 6 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-15 on motherboard ioapic1 irqs 32-47 on motherboard ioapic2 irqs 64-79 on motherboard kbd0 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) ipmi0: KCS mode found at io 0xca8 on acpi Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci8: on pcib1 pcib2: at device 13.0 on pci8 pci9: on pcib2 atapci0: port 0xdcb0-0xdcb7,0xdca0-0xdca3,0xdcb8-0xdcbf,0xdca4-0xdca7,0xdce0-0xdcef mem 0xee2fe000-0xee2fffff irq 11 at device 14.0 on pci8 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] isab0: at device 2.2 on pci0 isa0: on isab0 ohci0: port 0xc000-0xc0ff mem 0xee0ed000-0xee0edfff irq 11 at device 3.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: port 0xc400-0xc4ff mem 0xee0ee000-0xee0eefff irq 11 at device 3.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: <(0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1> on usb1 uhub1: 2 ports with 2 removable, self powered ehci0: port 0xc800-0xc8ff mem 0xee0ef000-0xee0effff irq 11 at device 3.2 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb2: EHCI version 1.0 usb2: companion controllers, 2 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: <(0x1166) EHCI root hub, class 9/0, rev 2.00/1.00, addr 1> on usb2 uhub2: 4 ports with 4 removable, self powered uhub3: on uhub2 uhub3: multiple transaction translators uhub3: 4 ports with 4 removable, self powered uhub4: on uhub3 uhub4: multiple transaction translators uhub4: 4 ports with 4 removable, self powered vgapci0: port 0xcc00-0xccff mem 0xe0000000-0xe7ffffff,0xee0f0000-0xee0fffff irq 39 at device 4.0 on pci0 pcib3: irq 32 at device 7.0 on pci0 pci10: on pcib3 pcib4: irq 33 at device 8.0 on pci0 pci11: on pcib4 pcib5: irq 37 at device 9.0 on pci0 pci1: on pcib5 pcib6: irq 37 at device 0.0 on pci1 pci2: on pcib6 pcib7: irq 37 at device 1.0 on pci2 pci3: on pcib7 pcib8: at device 0.0 on pci3 pci4: on pcib8 bce0: mem 0xec000000-0xedffffff irq 37 at device 0.0 on pci4 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce0: Ethernet address: 00:22:19:64:e4:d1 bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (0x05000405); Flags( MFW MSI ) pcib9: irq 37 at device 2.0 on pci2 pci5: on pcib9 pcib10: at device 0.0 on pci5 pci6: on pcib10 bce1: mem 0xea000000-0xebffffff irq 37 at device 0.0 on pci6 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce1: Ethernet address: 00:22:19:64:e4:d3 bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (0x05000405); Flags( MFW MSI ) pcib11: irq 37 at device 3.0 on pci2 pci7: on pcib11 mfi0: port 0xec00-0xecff mem 0xe9f80000-0xe9fbffff,0xe9fc0000-0xe9ffffff irq 37 at device 0.0 on pci7 mfi0: Megaraid SAS driver Ver 3.00 mfi0: 3047 (320486575s/0x0020/info) - Shutdown command received from host mfi0: 3048 (boot + 3s/0x0020/info) - Firmware initialization started (PCI ID 0060/1000/1f0c/1028) mfi0: 3049 (boot + 3s/0x0020/info) - Firmware version 1.22.02-0612 mfi0: 3050 (boot + 23s/0x0008/info) - Battery Present mfi0: 3051 (boot + 23s/0x0020/info) - Controller hardware revision ID (0x0) mfi0: 3052 (boot + 23s/0x0020/info) - Package version 6.2.0-0013 mfi0: 3053 (boot + 23s/0x0020/info) - Board Revision mfi0: 3054 (boot + 37s/0x0004/info) - Enclosure PD 20(c None/p0) communication restored mfi0: 3055 (boot + 38s/0x0002/info) - Inserted: Encl PD 20 mfi0: 3056 (boot + 38s/0x0002/info) - Inserted: PD 20(c None/p0) Info: enclPd=20, scsiType=d, portMap=09, sasAddr=5002408070005000,0000000000000000 mfi0: 3057 (boot + 38s/0x0002/info) - Inserted: PD 00(e0x20/s0) mfi0: 3058 (boot + 38s/0x0002/info) - Inserted: PD 00(e0x20/s0) Info: enclPd=20, scsiType=0, portMap=00, sasAddr=1221000000000000,0000000000000000 mfi0: 3059 (boot + 38s/0x0002/WARN) - PD 00(e0x20/s0) is not a certified drive mfi0: 3060 (boot + 38s/0x0002/info) - Inserted: PD 01(e0x20/s1) mfi0: 3061 (boot + 38s/0x0002/info) - Inserted: PD 01(e0x20/s1) Info: enclPd=20, scsiType=0, portMap=01, sasAddr=1221000001000000,0000000000000000 mfi0: 3062 (boot + 38s/0x0002/WARN) - PD 01(e0x20/s1) is not a certified drive mfi0: 3063 (boot + 38s/0x0002/info) - Inserted: PD 02(e0x20/s2) mfi0: 3064 (boot + 38s/0x0002/info) - Inserted: PD 02(e0x20/s2) Info: enclPd=20, scsiType=0, portMap=02, sasAddr=1221000002000000,0000000000000000 mfi0: 3065 (boot + 38s/0x0002/WARN) - PD 02(e0x20/s2) is not a certified drive mfi0: 3066 (boot + 38s/0x0002/info) - Inserted: PD 03(e0x20/s3) mfi0: 3067 (boot + 38s/0x0002/info) - Inserted: PD 03(e0x20/s3) Info: enclPd=20, scsiType=0, portMap=03, sasAddr=1221000003000000,0000000000000000 mfi0: 3068 (boot + 38s/0x0002/WARN) - PD 03(e0x20/s3) is not a certified drive mfi0: 3069 (boot + 38s/0x0002/info) - Inserted: PD 04(e0x20/s4) mfi0: 3070 (boot + 38s/0x0002/info) - Inserted: PD 04(e0x20/s4) Info: enclPd=20, scsiType=0, portMap=04, sasAddr=1221000004000000,0000000000000000 mfi0: 3071 (boot + 38s/0x0002/WARN) - PD 04(e0x20/s4) is not a certified drive mfi0: 3072 (boot + 39s/0x0042/info) - Global Hot Spare created on PD 04(e0x20/s4) (global,rev) mfi0: 3073 (boot + 39s/0x0020/info) - Cache data recovered successfully mfi0: 3074 (320486641s/0x0020/info) - Time established as 02/26/10 8:04:01; (40 seconds since power on) mfi0: 3075 (320486689s/0x0008/info) - Battery temperature is normal mfi0: [ITHREAD] pcib12: irq 35 at device 10.0 on pci0 pci12: on pcib12 pcib13: irq 36 at device 11.0 on pci0 pci13: on pcib13 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FILTER] cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 ipmi1: on isa0 device_attach: ipmi1 attach returned 16 orm0: at iomem 0xc0000-0xc8fff,0xec000-0xeffff 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 Timecounters tick every 1.000 msec acd0: DVDR at ata3-master SATA150 ipmi0: IPMI device rev. 0, firmware rev. 2.2, version 2.0 ipmi0: Number of channels 4 ipmi0: Attached watchdog mfi0: 3076 (320486689s/0x0008/info) - Current capacity of the battery is above threshold mfid0: on mfi0 mfid0: 1429760MB (2928148480 sectors) RAID volume 'Virtual Disk 0' is optimal SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #1 Launched! GEOM_LABEL: Label for provider mfid0s1a is ufsid/4aef7c53bd684719. GEOM_LABEL: Label for provider mfid0s1d is ufsid/4aef7c70156cf640. GEOM_LABEL: Label for provider mfid0s1e is ufsid/4aef7c70118f4010. GEOM_LABEL: Label for provider mfid0s1f is ufsid/4aef7c71b1b1ea99. GEOM_LABEL: Label for provider mfid0s1g is ufsid/4aef7c53dcd24191. Trying to mount root from ufs:/dev/mfid0s1a WARNING: / was not properly dismounted GEOM_LABEL: Label ufsid/4aef7c53bd684719 removed. GEOM_LABEL: Label for provider mfid0s1a is ufsid/4aef7c53bd684719. GEOM_LABEL: Label ufsid/4aef7c53dcd24191 removed. mfi0: 3077 (320486754s/0x0008/info) - Battery started charging GEOM_LABEL: Label for provider mfid0s1g is ufsid/4aef7c53dcd24191. GEOM_LABEL: Label ufsid/4aef7c70156cf640 removed. GEOM_LABEL: Label for provider mfid0s1d is ufsid/4aef7c70156cf640. GEOM_LABEL: Label ufsid/4aef7c70118f4010 removed. GEOM_LABEL: Label for provider mfid0s1e is ufsid/4aef7c70118f4010. GEOM_LABEL: Label ufsid/4aef7c71b1b1ea99 removed. GEOM_LABEL: Label for provider mfid0s1f is ufsid/4aef7c71b1b1ea99. GEOM_LABEL: Label ufsid/4aef7c53bd684719 removed. GEOM_LABEL: Label ufsid/4aef7c53dcd24191 removed. GEOM_LABEL: Label ufsid/4aef7c70156cf640 removed. GEOM_LABEL: Label ufsid/4aef7c70118f4010 removed. GEOM_LABEL: Label ufsid/4aef7c71b1b1ea99 removed. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 09:32:50 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5907B1065670 for ; Fri, 26 Feb 2010 09:32:50 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id E87708FC1D for ; Fri, 26 Feb 2010 09:32:49 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 68973153433; Fri, 26 Feb 2010 10:32:48 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zlo2BC3hqDM7; Fri, 26 Feb 2010 10:32:46 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 700CB15342F; Fri, 26 Feb 2010 10:32:46 +0100 (CET) Message-ID: <4B8795B1.4020006@digiware.nl> Date: Fri, 26 Feb 2010 10:34:41 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jack Vogel References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> In-Reply-To: <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 09:32:50 -0000 On 25-2-2010 23:59, Jack Vogel wrote: > The failure to "setup receive structures" means it did not have sufficient > mbufs > to setup the RX ring and buffer structs. Not sure why this results in a > lockup, > but try and increase kern.ipc.nmbclusters. > > Let me know what happens, I've doubled the value 25600 => 51200. This is wat netstat -m told me when it refused to revive em0: 24980/2087/27067 mbufs in use (current/cache/total) 24530/1070/25600/25600 mbuf clusters in use (current/cache/total/max) 22217/741 mbuf+clusters out of packet secondary zone in use (current/cache) 0/35/35/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 55305K/2801K/58106K bytes allocated to network (current/cache/total) 0/5970/2983 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 1011716 requests for I/O initiated by sendfile 0 calls to protocol drain routines Now I've seen some discussion on the list suggesting that full mbuf could also be because the device is down and the queue builds up rather rappidly in the mbufs. Probably the reason why this happened yesterday is that I started doing major software builds (over ZFS/NFS/TCP/v3) against data stored on this box. --WjW From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 10:06:07 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5186E106568A for ; Fri, 26 Feb 2010 10:06:07 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 107778FC1D for ; Fri, 26 Feb 2010 10:06:07 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 69F6E153433; Fri, 26 Feb 2010 11:06:06 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghFWlfyrV2pj; Fri, 26 Feb 2010 11:06:04 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 5096C15342F; Fri, 26 Feb 2010 11:06:04 +0100 (CET) Message-ID: <4B879D7E.70809@digiware.nl> Date: Fri, 26 Feb 2010 11:07:58 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gerrit_K=FChn?= References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226105829.82ba37c4.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100226105829.82ba37c4.gerrit@pmp.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org, Jack Vogel Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 10:06:07 -0000 On 26-2-2010 10:58, Gerrit Khn wrote: > On Fri, 26 Feb 2010 10:34:41 +0100 Willem Jan Withagen > wrote about Re: em0 freezes on ZFS server: > > WJW> Probably the reason why this happened yesterday is that I started > WJW> doing major software builds (over ZFS/NFS/TCP/v3) against data stored > WJW> on this box. > > I saw a similar problem this morning and suppose it started when some > automatic backup jobs started last night. A unstable em device is a rather > bad thing, I hope increasing the buffer (mine is at 64000 now) prevents > this from happening again. In my case it started indeed when I raised the volume of traffic. Probably I tripled it. Thanx for confirming like features. I have no proof that it used to work, or something like that. Since this is my first ZFS box, first Areca controller. So going back in time to see if it just regression somewhere is rather hard. And Yes, unstable em-device is a pain, since uptill now I considered the Intel chips/driver as a constant steady-state factor in my networking life. (would only buy/recommend Intel) I'm not shure it is the chipset/driver combo,could be that something in the innards of the kernel has severly changed and just starts stressing a lot more. --WjW From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 10:08:26 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72079106566B for ; Fri, 26 Feb 2010 10:08:26 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id D5ECB8FC2C for ; Fri, 26 Feb 2010 10:08:25 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1Q9wTnV032239; Fri, 26 Feb 2010 10:58:30 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 331A224; Fri, 26 Feb 2010 10:58:29 +0100 (CET) Date: Fri, 26 Feb 2010 10:58:29 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Willem Jan Withagen Message-Id: <20100226105829.82ba37c4.gerrit@pmp.uni-hannover.de> In-Reply-To: <4B8795B1.4020006@digiware.nl> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.26.94826 Cc: stable@freebsd.org, Jack Vogel Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 10:08:26 -0000 On Fri, 26 Feb 2010 10:34:41 +0100 Willem Jan Withagen wrote about Re: em0 freezes on ZFS server: WJW> Probably the reason why this happened yesterday is that I started WJW> doing major software builds (over ZFS/NFS/TCP/v3) against data stored WJW> on this box. I saw a similar problem this morning and suppose it started when some automatic backup jobs started last night. A unstable em device is a rather bad thing, I hope increasing the buffer (mine is at 64000 now) prevents this from happening again. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 10:08:57 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F4CD106568A for ; Fri, 26 Feb 2010 10:08:57 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id C512A8FC29 for ; Fri, 26 Feb 2010 10:08:56 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1Q9qZTg031831; Fri, 26 Feb 2010 10:52:36 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 8FA4524; Fri, 26 Feb 2010 10:52:35 +0100 (CET) Date: Fri, 26 Feb 2010 10:52:35 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jack Vogel Message-Id: <20100226105235.28f4e519.gerrit@pmp.uni-hannover.de> In-Reply-To: <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.26.93929 Cc: stable@freebsd.org, Willem Jan Withagen Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 10:08:57 -0000 On Thu, 25 Feb 2010 14:59:28 -0800 Jack Vogel wrote about Re: em0 freezes on ZFS server: JV> The failure to "setup receive structures" means it did not have JV> sufficient mbufs JV> to setup the RX ring and buffer structs. I don't know if this is related, but I updated an amd64 zfs machine with several em cards from 7.2 to 8-stable yesterday. First it worked fine after booting, but this morning, at least three of the five em interfaces did not do much anymore. You could revive them for some seconds with ifconfig down/up, but they always ceased functioning soon after that (within seconds). During debugging (up/down, load/unload if_em etc.) I saw the same error message as above at some point. I finally gave up and rebooted the machine. For now, everything appears to be back to normal (but for how long?). JV> Not sure why this results in a lockup, but try and increase JV> kern.ipc.nmbclusters. I just did that, just to make sure. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 10:40:44 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10CA9106564A; Fri, 26 Feb 2010 10:40:44 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id C992B8FC13; Fri, 26 Feb 2010 10:40:43 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id B98DA153433; Fri, 26 Feb 2010 11:40:42 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+v3XSc58UcQ; Fri, 26 Feb 2010 11:40:40 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 81B6815342F; Fri, 26 Feb 2010 11:40:40 +0100 (CET) Message-ID: <4B87A59B.4000605@digiware.nl> Date: Fri, 26 Feb 2010 11:42:35 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: stable@freebsd.org, current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Many many many thanks to all that develop FreeBSD. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 10:40:44 -0000 Hi, When everything is life is just smoothly flowing by, and all is hunky-dory, some things don't get the credits they deserve. So here we go.... ;) Standing at the coffee machine this morning I realized that FreeBSD has been part of my professional life for already way, way too long. Before 1993 I was tinkering with CPM, SCO, sys3/5, i386, Apollo Domain, Linux <0.98 and sorts. When friends an I decided to start an ISP, then very novel, now really part of our lives. And one of the friends suggested to use FreeBSD instead of Linux. As Linux at that time was still very much in flux and really just a flying target, we were more than up for it. Because if gave us the systems that we were all too familiar with. And it really did work richt out of the box. (well almost, needed to hack on the serial driver for the 16 port card we had) The first commercial server that we deployed was running FreeBSD 1.1. I still fondly keep that CD. One of those friends has been part of the Core team (Guido van Rooij) for a while. And I'm sure that a lot of the code he hacked up to keep the ISP going ended up somewhere in the tree. The release strategy has always been a real nice service to our business. Lots of systems where kept at major_versions, until the hardware became too old. Only then to leapfrog into the most stable version at that moment. And I don't ever recall that we were disappointed in the way FreeBSD developed itself. The ISP was sold in 2000, and I started doing other things. But in 2000 just about everything the ISP was delivering ran on FreeBSD. And I remember boxing being up for over 2 years. (especially those not exposed to the public.:)) Only reason for some windows was, because business wise you can't do without. At home FreeBSD has been my friend from that same moment forward. I trashed my Linux Toys, merged to FreeBSD and never looked back. My home is now running on 2* FreeBSD's and lots of Jave-embeded devices. Again there never disappointed in what FreeBSD delivered. Recently I started a new company again, but much to my disappointment (but understandably so) the chipset supplier (NXP/Philips) delivers only support for Linux (or WinCE) and the new shop is mainly Linux oriented. Although a some of the dev-team are still FreeBSD at hart. And parts of the system are tested against FreeBSD for avoidance of too much Linux-isms. :) So when I ran into some trouble yesterday, I realized how much FreeBSD has contributed to "painless computing"(tm). And not just only because of the quality of the software, but also because of the support that is offered. And for that I would like to thank, compliment, free-beer-license all the people that made my life trouble free Many many many thanks to all those that make FreeBSD. --WjW From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 11:04:10 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97DDA106566B for ; Fri, 26 Feb 2010 11:04:10 +0000 (UTC) (envelope-from torfing@broadpark.no) Received: from eterpe-smout.broadpark.no (eterpe-smout.broadpark.no [80.202.8.16]) by mx1.freebsd.org (Postfix) with ESMTP id 4E0388FC13 for ; Fri, 26 Feb 2010 11:04:10 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([unknown] [80.202.8.11]) by eterpe-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with ESMTP id <0KYG0039M19AR370@eterpe-smout.broadpark.no> for freebsd-stable@freebsd.org; Fri, 26 Feb 2010 11:03:10 +0100 (CET) Received: from kg-v2.kg4.no ([unknown] [80.203.92.186]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with SMTP id <0KYG003VR0ZDS910@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Fri, 26 Feb 2010 10:57:14 +0100 (CET) Date: Fri, 26 Feb 2010 11:03:37 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100226110337.70d1a758.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100220233546.GA36973@icarus.home.lan> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> <20100220202108.e1dd1b74.torfinn.ingolfsen@broadpark.no> <20100220193718.GA33214@icarus.home.lan> <20100220224959.c424dd9e.torfinn.ingolfsen@broadpark.no> <20100220233546.GA36973@icarus.home.lan> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) 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 Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 11:04:10 -0000 On Sat, 20 Feb 2010 15:35:46 -0800 Jeremy Chadwick wrote: After five days - a new crash. From /var/log/messages: Feb 26 00:57:39 kg-f2 ntpd[55453]: kernel time sync status change 6001 Feb 26 01:39:40 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 26 01:39:40 kg-f2 kernel: ata5: hardware reset timeout Feb 26 10:44:54 kg-f2 syslogd: kernel boot file is /boot/kernel/kernel > Let's backtrack a bit. I've gone back and read through all of your > previous posts on this matter, and so far all the problems are happening > on ata5 and ata6. No timeouts or anomalies have appeared on any other > ports -- just those two. It seems you are right. > The kernel error messages indicate that > commands submit to the controller took longer than 10 seconds to get a > response, so the OS does a force-reset of the ports in attempt to get > things working again. > > We can safely rule out the Silicon Image controller (otherwise "ataX" > wouldn't be involved), which leaves the AMD SB700 SATA controller and > the AMD SB700 PATA controller. And there is nothing connected to the pata controller. > What exact disks (e.g. adX) are attached to ata5 and ata6? root@kg-f2# dmesg | grep ata5 ata5: on atapci0 ata5: [ITHREAD] ad10: 953869MB at ata5-master UDMA100 SATA 3Gb/s root@kg-f2# dmesg | grep ata6 ata6: on atapci0 ata6: [ITHREAD] ad12: 953869MB at ata6-master UDMA100 SATA 3Gb/s > You haven't provided dmesg output in any of your posts, No, I didn't. I did state that full dmesg's and more info was available on the freebsd web page[1] for the machine in one of my first posts. > and atacontrol/pciconf is > not sufficient (I should really improve atacontrol by printing this > information. I'll work on that in a few minutes). Cool, I would really like that feature. > Some Linux users have reported AHCI-related issues with the SB600 > southbridge, but the core of the problem turned out to be MSI on certain > AMD northbridges (specifically RS480, RS400, and RS200). By disabling > MSI entirely they were able to achieve stability. The FreeBSD > equivalent would be to set the following in loader.conf and reboot: > > hw.pci.enable_msix="0" > hw.pci.enable_msi="0" I will try that now. It might take five days or more to get an answer. > The Linux quirk fix for this: > > http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=blob_plain;f=queue-2.6.21/pci-quirks-disable-msi-on-rs400-200-and-rs480.patch;hb=05ab505f2909acf3a614d3e6a32271c4c1f8a69d > > Your board has an AMD 740G northbridge, but it might be worth trying the > MSI disable trick anyway. If it doesn't fix the problem then definitely > re-enable MSI. Isn't hardware fun? ;-) Always. ;^) References: 1) http://sites.google.com/site/tingox/ga-ma74gm-s2h_freebsd -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 11:55:38 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1003F106564A for ; Fri, 26 Feb 2010 11:55:38 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id E439A8FC08 for ; Fri, 26 Feb 2010 11:55:37 +0000 (UTC) Received: from omta19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by qmta03.emeryville.ca.mail.comcast.net with comcast id mbuQ1d0041eYJf8A3bved8; Fri, 26 Feb 2010 11:55:38 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta19.emeryville.ca.mail.comcast.net with comcast id mbvd1d0093S48mS01bvdM7; Fri, 26 Feb 2010 11:55:38 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 262761E301A; Fri, 26 Feb 2010 03:55:36 -0800 (PST) Date: Fri, 26 Feb 2010 03:55:36 -0800 From: Jeremy Chadwick To: Torfinn Ingolfsen Message-ID: <20100226115536.GA17798@icarus.home.lan> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> <20100220202108.e1dd1b74.torfinn.ingolfsen@broadpark.no> <20100220193718.GA33214@icarus.home.lan> <20100220224959.c424dd9e.torfinn.ingolfsen@broadpark.no> <20100220233546.GA36973@icarus.home.lan> <20100226110337.70d1a758.torfinn.ingolfsen@broadpark.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100226110337.70d1a758.torfinn.ingolfsen@broadpark.no> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 11:55:38 -0000 On Fri, Feb 26, 2010 at 11:03:37AM +0100, Torfinn Ingolfsen wrote: > > What exact disks (e.g. adX) are attached to ata5 and ata6? > > root@kg-f2# dmesg | grep ata5 > ata5: on atapci0 > ata5: [ITHREAD] > ad10: 953869MB at ata5-master UDMA100 SATA 3Gb/s > root@kg-f2# dmesg | grep ata6 > ata6: on atapci0 > ata6: [ITHREAD] > ad12: 953869MB at ata6-master UDMA100 SATA 3Gb/s > ...snip... > No, I didn't. I did state that full dmesg's and more info was available on the freebsd web page[1] for the machine > in one of my first posts. Okay, so the breakdown for those following is: http://sites.google.com/site/tingox/f2-dmesg-8.0-stable-20100131.txt?attredirects=0 atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 6 3Gbps ports, PM supported ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 ata5: on atapci0 ata6: on atapci0 ata7: on atapci0 ad6: 238475MB at ata3-master UDMA100 SATA 3Gb/s ad8: 953869MB at ata4-master UDMA100 SATA 3Gb/s ad10: 953869MB at ata5-master UDMA100 SATA 3Gb/s ad12: 953869MB at ata6-master UDMA100 SATA 3Gb/s ad14: 953869MB at ata7-master UDMA100 SATA 3Gb/s But the only ports which are having issues are ata5 and ata6, which hosts disks ad10 and ad12 respectively. SMART stats for ad10 and ad12 look fantastic, aside from slightly long spin-up times (claiming over 8 seconds), but that wouldn't cause what's seen here. Both disks have used for nearly 1700 hours. No SMART error log entries exist on either disk, which means the timeouts seen when speaking to the controller are very likely when talking to the controller itself (and not when waiting for the controller to submit a request to the disk and that piece stalling). I'm out of ideas aside from the following: 1) Disabling MSI/MSIX, which at this point I'm doubting will fix anything (but you never know), since I'd expect it to affect the entire controller and not just specific ports on the controller. 2) Replacing the SATA cables used between ata5<-->ad10 and ata6<-->ad12. 3) Getting mav@ to talk to AMD to find out if there's any AHCI quirks in the IXP700 or IXP800 SATA controllers, as there could be some weird driver bug/quirk on FreeBSD which is needed. Mainly for mav@: verbose boot messages for this system are here, in case any SATA register details are of help: http://sites.google.com/site/tingox/f2-dmesg-8.0-stable-20100131_verb1.txt?attredirects=0 http://sites.google.com/site/tingox/f2-dmesg-8.0-stable-20100131_verb2.txt?attredirects=0 -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 12:10:20 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 287C51065675 for ; Fri, 26 Feb 2010 12:10:20 +0000 (UTC) (envelope-from torfing@broadpark.no) Received: from eterpe-smout.broadpark.no (eterpe-smout.broadpark.no [80.202.8.16]) by mx1.freebsd.org (Postfix) with ESMTP id CFFA98FC24 for ; Fri, 26 Feb 2010 12:10:19 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from ignis-smin.broadpark.no ([unknown] [80.202.8.11]) by eterpe-smout.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with ESMTP id <0KYG003BX73MV0B0@eterpe-smout.broadpark.no> for freebsd-stable@freebsd.org; Fri, 26 Feb 2010 13:09:22 +0100 (CET) Received: from kg-v2.kg4.no ([unknown] [80.203.92.186]) by ignis-smin.broadpark.no (Sun Java(tm) System Messaging Server 7u3-12.01 64bit (built Oct 15 2009)) with SMTP id <0KYG0051N6TPE760@ignis-smin.broadpark.no> for freebsd-stable@freebsd.org; Fri, 26 Feb 2010 13:03:26 +0100 (CET) Date: Fri, 26 Feb 2010 13:09:50 +0100 From: Torfinn Ingolfsen To: freebsd-stable@freebsd.org Message-id: <20100226130950.0c91d16b.torfinn.ingolfsen@broadpark.no> In-reply-to: <20100226110337.70d1a758.torfinn.ingolfsen@broadpark.no> References: <20100131144217.ca08e965.torfinn.ingolfsen@broadpark.no> <20100131175639.86ba9aee.torfinn.ingolfsen@broadpark.no> <20100207163631.da7205fc.torfinn.ingolfsen@broadpark.no> <20100213192404.5e15b5eb.torfinn.ingolfsen@broadpark.no> <20100217091625.d0e74570.torfinn.ingolfsen@broadpark.no> <20100220202108.e1dd1b74.torfinn.ingolfsen@broadpark.no> <20100220193718.GA33214@icarus.home.lan> <20100220224959.c424dd9e.torfinn.ingolfsen@broadpark.no> <20100220233546.GA36973@icarus.home.lan> <20100226110337.70d1a758.torfinn.ingolfsen@broadpark.no> X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.7; amd64-portbld-freebsd8.0) 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 Subject: Re: panic - sleeping thread on FreeBSD 8.0-stable / amd64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 12:10:20 -0000 On Fri, 26 Feb 2010 11:03:37 +0100 Torfinn Ingolfsen wrote: > I will try that now. It might take five days or more to get an answer. Or not. Another panic. Output from /var/log/messages: Feb 26 11:10:33 kg-f2 ntpd[942]: kernel time sync status change 2001 Feb 26 11:44:19 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 00000080 Feb 26 11:44:19 kg-f2 kernel: ata5: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 26 11:47:05 kg-f2 kernel: ata6: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 26 11:47:05 kg-f2 kernel: ata5: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 26 11:47:05 kg-f2 kernel: ata6: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 26 11:47:05 kg-f2 kernel: ata5: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 00000080 Feb 26 11:47:05 kg-f2 kernel: ata6: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 26 11:47:05 kg-f2 kernel: ata5: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 26 11:47:05 kg-f2 kernel: ata6: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 26 11:47:05 kg-f2 kernel: ata5: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 00000080 Feb 26 11:47:05 kg-f2 kernel: ata6: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ad4: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) Feb 26 11:47:05 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 0000007f Feb 26 11:47:05 kg-f2 kernel: ata5: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 26 11:47:05 kg-f2 kernel: ata6: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 00000080 Feb 26 11:47:05 kg-f2 kernel: ata5: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 00000080 Feb 26 11:47:05 kg-f2 kernel: ata6: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata5: port is not ready (timeout 10000ms) tfd = 00000080 Feb 26 11:47:05 kg-f2 kernel: ata5: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ata6: port is not ready (timeout 10000ms) tfd = 0000007f Feb 26 11:47:05 kg-f2 kernel: ata6: hardware reset timeout Feb 26 11:47:05 kg-f2 kernel: ad6: TIMEOUT - FLUSHCACHE48 retrying (1 retry left) Feb 26 11:47:05 kg-f2 kernel: ad4: TIMEOUT - WRITE_DMA retrying (1 retry left) LBA=31471070 Feb 26 12:23:38 kg-f2 syslogd: kernel boot file is /boot/kernel/kernel -- Torfinn From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 12:16:22 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D015106566C for ; Fri, 26 Feb 2010 12:16:22 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id B6FFA8FC13 for ; Fri, 26 Feb 2010 12:16:21 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1QCGICh005679; Fri, 26 Feb 2010 13:16:19 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 82B8024; Fri, 26 Feb 2010 13:16:18 +0100 (CET) Date: Fri, 26 Feb 2010 13:16:18 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jack Vogel Message-Id: <20100226131618.ae652327.gerrit@pmp.uni-hannover.de> In-Reply-To: <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.26.120633 Cc: stable@freebsd.org, Willem Jan Withagen Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 12:16:22 -0000 On Thu, 25 Feb 2010 14:59:28 -0800 Jack Vogel wrote about Re: em0 freezes on ZFS server: JV> The failure to "setup receive structures" means it did not have JV> sufficient mbufs JV> to setup the RX ring and buffer structs. I'm monitoring mbufs since I rebooted my server. Right now (after 2.5 hours or so of operation) the number of total clusters has already increased to 15k. Is this a normal behaviour for a relatively idle server or will it inevitably go through the roof in some more hours? Every 1s: netstat -m Fri Feb 26 13:14:54 2010 15001/2279/17280 mbufs in use (current/cache/total) 13970/1212/15182/64000 mbuf clusters in use (current/cache/total/max) 13970/750 mbuf+clusters out of packet secondary zone in use (current/cache) 0/119/119/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 31690K/3469K/35160K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf +clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 3 requests for I/O initiated by sendfile 0 calls to protocol drain routines cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 12:16:51 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75FCD1065675 for ; Fri, 26 Feb 2010 12:16:51 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 5D4BE8FC28 for ; Fri, 26 Feb 2010 12:16:51 +0000 (UTC) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta02.emeryville.ca.mail.comcast.net with comcast id mbuS1d0061u4NiLA2c3h8f; Fri, 26 Feb 2010 12:03:41 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta21.emeryville.ca.mail.comcast.net with comcast id mc3g1d0083S48mS8hc3g7u; Fri, 26 Feb 2010 12:03:41 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8D7EE1E301A; Fri, 26 Feb 2010 04:03:39 -0800 (PST) Date: Fri, 26 Feb 2010 04:03:39 -0800 From: Jeremy Chadwick To: Willem Jan Withagen Message-ID: <20100226120339.GB17798@icarus.home.lan> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B8795B1.4020006@digiware.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: stable@freebsd.org, Jack Vogel Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 12:16:51 -0000 On Fri, Feb 26, 2010 at 10:34:41AM +0100, Willem Jan Withagen wrote: > This is wat netstat -m told me when it refused to revive em0: Below are the netstat -m counters/lines of concern: > 24980/2087/27067 mbufs in use (current/cache/total) > 24530/1070/25600/25600 mbuf clusters in use (current/cache/total/max) > 55305K/2801K/58106K bytes allocated to network (current/cache/total) Note how close the "current" value is to that of "total". I'm not too surprised you're seeing what you are as a result of this. What on earth is this machine doing at all times? Comparatively, here's some of our servers' netstat -m stats. All these boxes do nightly backups to a centralised box on a private gigE network. All boxes use em(4). RELENG_7 amd64 2010/01/09 -- primary HTTP, pri DNS, SSH server + ZFS 514/1931/2445 mbufs in use (current/cache/total) 512/540/1052/25600 mbuf clusters in use (current/cache/total/max) 1152K/6394K/7547K bytes allocated to network (current/cache/total) RELENG_7 amd64 2010/01/11 -- secondary DNS, MySQL, dev box + ZFS 514/1151/1665 mbufs in use (current/cache/total) 512/504/1016/25600 mbuf clusters in use (current/cache/total/max) 1152K/2203K/3356K bytes allocated to network (current/cache/total) RELENG_7 i386 2008/04/19 -- secondary HTTP, SSH server, heavy memory I/O 531/624/1155 mbufs in use (current/cache/total) 512/552/1064/25600 mbuf clusters in use (current/cache/total/max) 1156K/2408K/3564K bytes allocated to network (current/cache/total) RELENG_8 amd64 2010/02/02 -- central backups + NFS+ZFS-based filer 1572/3423/4995 mbufs in use (current/cache/total) 1563/3065/4628/25600 mbuf clusters in use (current/cache/total/max) 3519K/7401K/10920K bytes allocated to network (current/cache/total) -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 12:19:10 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37B6D106566B for ; Fri, 26 Feb 2010 12:19:10 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id C5C7A8FC1C for ; Fri, 26 Feb 2010 12:19:09 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 3B954153433; Fri, 26 Feb 2010 13:19:08 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP93-lGcjAee; Fri, 26 Feb 2010 13:19:06 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 3633E15342F; Fri, 26 Feb 2010 13:19:06 +0100 (CET) Message-ID: <4B87BCAC.2050009@digiware.nl> Date: Fri, 26 Feb 2010 13:21:00 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> In-Reply-To: <20100226120339.GB17798@icarus.home.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Jack Vogel Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 12:19:10 -0000 On 26-2-2010 13:03, Jeremy Chadwick wrote: > On Fri, Feb 26, 2010 at 10:34:41AM +0100, Willem Jan Withagen wrote: >> This is wat netstat -m told me when it refused to revive em0: > > Below are the netstat -m counters/lines of concern: > >> 24980/2087/27067 mbufs in use (current/cache/total) >> 24530/1070/25600/25600 mbuf clusters in use (current/cache/total/max) >> 55305K/2801K/58106K bytes allocated to network (current/cache/total) > > Note how close the "current" value is to that of "total". I'm not too > surprised you're seeing what you are as a result of this. What on earth > is this machine doing at all times? > > Comparatively, here's some of our servers' netstat -m stats. All these > boxes do nightly backups to a centralised box on a private gigE network. > All boxes use em(4). > > RELENG_7 amd64 2010/01/09 -- primary HTTP, pri DNS, SSH server + ZFS > > 514/1931/2445 mbufs in use (current/cache/total) > 512/540/1052/25600 mbuf clusters in use (current/cache/total/max) > 1152K/6394K/7547K bytes allocated to network (current/cache/total) That's why I wrote that I assumed that the mbuf stats where a result of the pipe overflowing when the device went down. (I've seen this discussed in another thread as well) At the moment off em0-freeze, I was running 4 bitbake compile jobs of our software tree. That's a lot of small file access, but like you say nothing really major. --WjW From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 12:22:09 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D5411065755 for ; Fri, 26 Feb 2010 12:22:06 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 21D378FC1D for ; Fri, 26 Feb 2010 12:22:06 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 62460153433; Fri, 26 Feb 2010 13:22:05 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2a8JU-byEcX; Fri, 26 Feb 2010 13:22:03 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 536C015342F; Fri, 26 Feb 2010 13:22:03 +0100 (CET) Message-ID: <4B87BD5D.4040006@digiware.nl> Date: Fri, 26 Feb 2010 13:23:57 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gerrit_K=FChn?= References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <20100226131618.ae652327.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100226131618.ae652327.gerrit@pmp.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org, Jack Vogel Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 12:22:09 -0000 On 26-2-2010 13:16, Gerrit Khn wrote: > On Thu, 25 Feb 2010 14:59:28 -0800 Jack Vogel wrote > about Re: em0 freezes on ZFS server: > > JV> The failure to "setup receive structures" means it did not have > JV> sufficient mbufs > JV> to setup the RX ring and buffer structs. > > I'm monitoring mbufs since I rebooted my server. Right now (after 2.5 hours > or so of operation) the number of total clusters has already increased to > 15k. Is this a normal behaviour for a relatively idle server or will it > inevitably go through the roof in some more hours? > > > Every 1s: netstat -m Fri Feb 26 > 13:14:54 2010 > > 15001/2279/17280 mbufs in use (current/cache/total) > 13970/1212/15182/64000 mbuf clusters in use (current/cache/total/max) > 13970/750 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/119/119/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use > (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use > (current/cache/total/max) 31690K/3469K/35160K bytes allocated to network > (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf > +clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 3 requests for I/O initiated by sendfile > 0 calls to protocol drain routines Well it could be coincidence, but mine are around 15k as well: 15921/3669/19590 mbufs in use (current/cache/total) 15308/2678/17986/51200 mbuf clusters in use (current/cache/total/max) 14754/862 mbuf+clusters out of packet secondary zone in use (current/cache) System is up since last night, and has taken a few Gb in rsync-backup and several compile jobs. Hasn't given me trouble (yet). --WjW From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 12:25:37 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6BE01065674 for ; Fri, 26 Feb 2010 12:25:37 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f223.google.com (mail-fx0-f223.google.com [209.85.220.223]) by mx1.freebsd.org (Postfix) with ESMTP id 415AC8FC6D for ; Fri, 26 Feb 2010 12:25:36 +0000 (UTC) Received: by fxm23 with SMTP id 23so10603fxm.3 for ; Fri, 26 Feb 2010 04:25:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=c+sJCymD2zyFSBbaHYcP/ioiGtRedmQNZrB+FI6HgQQ=; b=q4ti0pKoduBxO8k+6CVHKq3lXl4DJFTP9XUgiuNf8o2K1H6JV/+l8BZO9dYguJ38uh cl67fh4N+31ar4ONTeoQrSAWpZF18mrEkHVFEbVByxFEUjA3bV2An5LNCq+u5V6lF2Iq 9QurNsRGEyRDVWD3icsbCAslJ5GdpvzsyoisQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=RYtXzVYjgIUxV+vaXzQ5kApN6tKb115qir4TQW5OhMmOslxDFgVKOq9DadF4MlgY2x vSmu0CFI+3MuyrBzc343cRSVsWkk33KaNnIv1dr02NaaB5PibjfvMsSa7829Mwgw77Dv T+50+tuyICSLGbsX/Zkk9aJkBSY2PlSyYA4b0= Received: by 10.223.6.68 with SMTP id 4mr353057fay.92.1267187129424; Fri, 26 Feb 2010 04:25:29 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm26334fxm.15.2010.02.26.04.25.28 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Feb 2010 04:25:29 -0800 (PST) Sender: Alexander Motin Message-ID: <4B87BDB6.7020109@FreeBSD.org> Date: Fri, 26 Feb 2010 14:25:26 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: "John J. Rushford" References: <1267172583.00223701.1267161002@10.7.7.3> In-Reply-To: <1267172583.00223701.1267161002@10.7.7.3> Content-Type: multipart/mixed; boundary="------------020205060703050103010301" Cc: lopez.on.the.lists@yellowspace.net, freebsd-stable@freebsd.org Subject: Re: Panic on 8-STABLE in mpt(4) on a DELL PowerEdge R300 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 12:25:37 -0000 This is a multi-part message in MIME format. --------------020205060703050103010301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit John J. Rushford wrote: > I'm running into the same problem, mpt(4) panic on FreeBSD 8-STABLE. > > I'm running FreeBSD 8.0-STABLE, the current kernel was cvsup'd and built > @ January 14th, 2010. I cvsup'd tonight, 2/25/2010, and built a new > kernel. Attached is the panic when I tried to boot into single user > mode, I was able to boot up on the old kernel built on January 14th. > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x10 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff8019c4bd > stack pointer = 0x28:0xffffff80e81d5ba0 > frame pointer = 0x28:0xffffff80e81d5bd0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 6 (mpt_raid0) > trap number = 12 > panic: page fault Attached patch should fix the problem. -- Alexander Motin --------------020205060703050103010301 Content-Type: text/plain; name="mpt_raid.scan.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mpt_raid.scan.patch" --- mpt_raid.c.prev 2010-02-05 21:52:04.000000000 +0200 +++ mpt_raid.c 2010-02-26 14:14:30.000000000 +0200 @@ -690,7 +690,6 @@ mpt_raid_thread(void *arg) if (mpt->raid_rescan != 0) { union ccb *ccb; - struct cam_path *path; int error; mpt->raid_rescan = 0; @@ -699,7 +698,7 @@ mpt_raid_thread(void *arg) ccb = xpt_alloc_ccb(); MPT_LOCK(mpt); - error = xpt_create_path(&path, xpt_periph, + error = xpt_create_path(&ccb->ccb_h.path, xpt_periph, cam_sim_path(mpt->phydisk_sim), CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD); if (error != CAM_REQ_CMP) { --------------020205060703050103010301-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 12:31:43 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E29A106564A for ; Fri, 26 Feb 2010 12:31:43 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id A42D48FC15 for ; Fri, 26 Feb 2010 12:31:42 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1QCVdt9006235; Fri, 26 Feb 2010 13:31:40 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 0507D24; Fri, 26 Feb 2010 13:31:39 +0100 (CET) Date: Fri, 26 Feb 2010 13:31:38 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jeremy Chadwick Message-Id: <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100226120339.GB17798@icarus.home.lan> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.26.121818 Cc: stable@freebsd.org, Willem Jan Withagen , Jack Vogel Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 12:31:43 -0000 On Fri, 26 Feb 2010 04:03:39 -0800 Jeremy Chadwick wrote about Re: em0 freezes on ZFS server: JC> Note how close the "current" value is to that of "total". I'm not too JC> surprised you're seeing what you are as a result of this. What on JC> earth is this machine doing at all times? Well, speaking for my machine: serving some nfs dirs from zfs, do some file transfers via rsync/scp, server some web pages (gitweb, redmine). Really nothing spectacular. I just updated from 7.2 to 8-stable yesterday and did not have that problem before. From my last email to now (about 15 minutes) mbuf clusters have increased from 15k to 18k. All my other machines (even another one with 8-stable, but without nfs-services and without em nics) have only a few k of buffers in use. Is there any way I could find out what is actually using these buffers? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 12:44:32 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E78F4106566C for ; Fri, 26 Feb 2010 12:44:32 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 575788FC1A for ; Fri, 26 Feb 2010 12:44:31 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1QCiT8b006740; Fri, 26 Feb 2010 13:44:30 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 3080924; Fri, 26 Feb 2010 13:44:29 +0100 (CET) Date: Fri, 26 Feb 2010 13:44:29 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Gerrit =?ISO-8859-1?Q?K=FChn?= Message-Id: <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.26.123333 Cc: stable@freebsd.org, Willem Jan Withagen , Jack Vogel , Jeremy Chadwick Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 12:44:33 -0000 On Fri, 26 Feb 2010 13:31:38 +0100 Gerrit K=FChn wrote about Re: em0 freezes on ZFS server: GK> JC> Note how close the "current" value is to that of "total". I'm not GK> JC> too surprised you're seeing what you are as a result of this. GK> JC> What on earth is this machine doing at all times? GK> Is there any way I could find out what is actually using these buffers? Sorry for replying to my own email: At least in my case I found out what is eating the buffers: nfsd does! The buffers stop increasing as soon as I stop nfsd. However, they start increasing as soon as I start nfsd again. Are there any ideas how to fix this? Downgrading back to 7-stable is not really an easy task as far as I know, and I need the server to run without having to reboot it once for twice a day... cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 12:47:46 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC9721065673 for ; Fri, 26 Feb 2010 12:47:46 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE748FC17 for ; Fri, 26 Feb 2010 12:47:46 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id DC4B9153433; Fri, 26 Feb 2010 13:47:45 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwOpq1Fg60sL; Fri, 26 Feb 2010 13:47:43 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id EAB0015342F; Fri, 26 Feb 2010 13:47:43 +0100 (CET) Message-ID: <4B87C362.3040409@digiware.nl> Date: Fri, 26 Feb 2010 13:49:38 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gerrit_K=FChn?= References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org, Jack Vogel , Jeremy Chadwick Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 12:47:46 -0000 On 26-2-2010 13:44, Gerrit Khn wrote: > On Fri, 26 Feb 2010 13:31:38 +0100 Gerrit Khn > wrote about Re: em0 freezes on ZFS server: > > GK> JC> Note how close the "current" value is to that of "total". I'm not > GK> JC> too surprised you're seeing what you are as a result of this. > GK> JC> What on earth is this machine doing at all times? > > GK> Is there any way I could find out what is actually using these buffers? > > Sorry for replying to my own email: > At least in my case I found out what is eating the buffers: nfsd does! > The buffers stop increasing as soon as I stop nfsd. However, they start > increasing as soon as I start nfsd again. > Are there any ideas how to fix this? Downgrading back to 7-stable is not > really an easy task as far as I know, and I need the server to run without > having to reboot it once for twice a day... Mine went up something like 200 mbufs, so that is not that significantly. Let alone that I prefer not to do so, since the whole box is on ZFS. --WjW From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 13:18:20 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED00D106566B for ; Fri, 26 Feb 2010 13:18:20 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 6E0858FC2A for ; Fri, 26 Feb 2010 13:18:19 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1QDHs4j008272; Fri, 26 Feb 2010 14:17:55 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 9ADD524; Fri, 26 Feb 2010 14:17:54 +0100 (CET) Date: Fri, 26 Feb 2010 14:17:54 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Daniel Braniss Message-Id: <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.26.130631 Cc: stable@freebsd.org, Willem Jan Withagen , Jack Vogel , Jeremy Chadwick Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 13:18:21 -0000 On Fri, 26 Feb 2010 15:04:37 +0200 Daniel Braniss wrote about Re: em0 freezes on ZFS server : DB> > At least in my case I found out what is eating the buffers: nfsd DB> > does! The buffers stop increasing as soon as I stop nfsd. However, DB> > they start increasing as soon as I start nfsd again. DB> > Are there any ideas how to fix this? Downgrading back to 7-stable is DB> > not really an easy task as far as I know, and I need the server to DB> > run without having to reboot it once for twice a day... DB> I want to add some spices to this stew: :-) You're welcome. :-) DB> Some few day later it hung, and it's now hanging every few days. DB> Most of the hangs are because there is no network, but the NIC is bce DB> not em! I doubled kern.ipc.nmbclusters and lets see what happens ... Do you have nfsd running and serving clients? If so, we should maybe change the topic to something like "possible nfs mbuf leakage"... DB> 23066/6634/29700 mbufs in use (current/cache/total) My server is at 22k now, and the buffer number is still increasing every few seconds... Can you monitor your mbuf usage and report if it grows? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 13:34:01 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 436BB1065670 for ; Fri, 26 Feb 2010 13:34:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id E89C48FC20 for ; Fri, 26 Feb 2010 13:34:00 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Nkzry-0000AC-0S; Fri, 26 Feb 2010 15:04:38 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Gerrit =?ISO-8859-1?Q?K=FChn?= In-reply-to: <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> Comments: In-reply-to Gerrit =?ISO-8859-1?Q?K=FChn?= message dated "Fri, 26 Feb 2010 13:44:29 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Feb 2010 15:04:37 +0200 From: Daniel Braniss Message-ID: Cc: stable@freebsd.org, Willem Jan Withagen , Jack Vogel , Jeremy Chadwick Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 13:34:01 -0000 > On Fri, 26 Feb 2010 13:31:38 +0100 Gerrit K=FChn > wrote about Re: em0 freezes on ZFS serve= r: >=20 > GK> JC> Note how close the =22current=22 value is to that of =22total= =22. I'm not > GK> JC> too surprised you're seeing what you are as a result of this. > GK> JC> What on earth is this machine doing at all times? >=20 > GK> Is there any way I could find out what is actually using these buff= ers? >=20 > Sorry for replying to my own email: > At least in my case I found out what is eating the buffers: nfsd does= =21 > The buffers stop increasing as soon as I stop nfsd. However, they start= > increasing as soon as I start nfsd again. > Are there any ideas how to fix this? Downgrading back to 7-stable is no= t > really an easy task as far as I know, and I need the server to run with= out > having to reboot it once for twice a day... I want to add some spices to this stew: :-) I have this big server (> 10 TB) which was running pretty much without ma= jor problems, till one morning it started panicking because some 'ZFS * crede= ntial *', Since this server is used by many and uptime being a priority, I upgraded it to 8-stable, the panic went away, one problem solved. Some few day later it hung, and it's now hanging every few days. Most of the hangs are because there is no network, but the NIC is bce not= em=21 I doubled kern.ipc.nmbclusters and lets see what happens ... netstat -m: 23066/6634/29700 mbufs in use (current/cache/total) 22072/5942/28014/51200 mbuf clusters in use (current/cache/total/max) 22021/2939 mbuf+clusters out of packet secondary zone in use (current/cac= he) hope this helps in finding a cure, danny From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 14:50:43 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 305341065678; Fri, 26 Feb 2010 14:50:43 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id B007C8FC26; Fri, 26 Feb 2010 14:50:42 +0000 (UTC) Received: from furia.intranet ([93.104.121.188]) (AUTH: CRAM-MD5 lopez.on.the.lists@yellowspace.net, SSL: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by mail.yellowspace.net with esmtp; Fri, 26 Feb 2010 15:50:39 +0100 id 00341D50.000000004B87DFBF.00017FF1 Message-ID: <4B87DFBE.60008@yellowspace.net> Date: Fri, 26 Feb 2010 15:50:38 +0100 From: Lorenzo Perone User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Alexander Motin References: <1267172583.00223701.1267161002@10.7.7.3> <4B87BDB6.7020109@FreeBSD.org> In-Reply-To: <4B87BDB6.7020109@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org, "John J. Rushford" Subject: Re: Panic on 8-STABLE in mpt(4) on a DELL PowerEdge R300 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 14:50:43 -0000 COOL! THANKS a LOT Alexander! Can't believe it. You post a panic at 11pm and get a patch at 1pm next day...? You must be crazy! ;) Works for me. I patched against 8/stable. I'll be testing the machine a bit more. But for now, no panics! I guess the patch should be committed soon, also because it's really happening quite at beginning, without a RAC/ILO you're locked out pretty fast, and mpt is used on many DELL/HP setups. while true ; do echo Thank You ; done Lorenzo On 26.02.10 13:25, Alexander Motin wrote: > John J. Rushford wrote: >> I'm running into the same problem, mpt(4) panic on FreeBSD 8-STABLE. >> >> I'm running FreeBSD 8.0-STABLE, the current kernel was cvsup'd and built >> @ January 14th, 2010. I cvsup'd tonight, 2/25/2010, and built a new >> kernel. Attached is the panic when I tried to boot into single user >> mode, I was able to boot up on the old kernel built on January 14th. >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x10 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff8019c4bd >> stack pointer = 0x28:0xffffff80e81d5ba0 >> frame pointer = 0x28:0xffffff80e81d5bd0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 6 (mpt_raid0) >> trap number = 12 >> panic: page fault > > Attached patch should fix the problem. > From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 14:32:01 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06FE9106566B for ; Fri, 26 Feb 2010 14:32:01 +0000 (UTC) (envelope-from skat@aport.ru) Received: from sovam.com (mail.email.ru [194.67.1.204]) by mx1.freebsd.org (Postfix) with ESMTP id 33DB18FC0C for ; Fri, 26 Feb 2010 14:31:59 +0000 (UTC) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Feb 26 17:22:57 2010 X-DSPAM-Confidence: 0.5898 X-DSPAM-Probability: 0.0000 X-AttachExt: ... X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-3.2 Received: from [109.120.34.117] (account skat@aport.ru) by mail-be04.sovam.com (CommuniGate Pro WEBUSER 5.2.16) with HTTP id 4145773 for stable@freebsd.org; Fri, 26 Feb 2010 17:21:52 +0300 From: "oleg" To: stable@freebsd.org X-Mailer: CommuniGate Pro WebUser v5.2.16 Date: Fri, 26 Feb 2010 17:21:52 +0300 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_===4145773====mail-be04.sovam.com===_" X-Mailman-Approved-At: Fri, 26 Feb 2010 15:04:09 +0000 Cc: Subject: Sysinstall does not define SATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 14:32:01 -0000 This is a multi-part MIME message --_===4145773====mail-be04.sovam.com===_ Content-Type: text/plain;charset=utf-8;format="flowed" Content-Transfer-Encoding: 8bit Have a nice time! Got some trouble. The Sysinstall program of FreeBSD 8.0 release does not define SATA hard drives. Can`t create slices. But that machine works correctly by Windows. See attached dmesg file. Please, let me know, what mast i do? Many thanks for the help. --- Ванкувер 2010. Новости Олимпиады. http://olympic.aport.ru --_===4145773====mail-be04.sovam.com===_ Content-Type: application/octet-stream Content-Disposition: attachment; filename="dmesg" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDYgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIDYuMS1TVEFCTEUgIzA6IE1vbiBKdW4g IDUgMTE6MjA6MTIgVVRDIDIwMDYKICAgIHRlY2huaXhAYW1hdGVyaWE6L3Vzci9vYmovdXNy L3NyYy9zeXMvRlJFTlpZCldBUk5JTkc6IGRlYnVnLm1wc2FmZW5ldCBmb3JjZWQgdG8gMCBh cyBpcHNlYyByZXF1aXJlcyBHaWFudApXQVJOSU5HOiBNUFNBRkUgbmV0d29yayBzdGFjayBk aXNhYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClRpbWVjb3VudGVyICJpODI1 NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNQVTogQU1EIEF0aGxvbih0bSkg SUkgWDIgMjUwIFByb2Nlc3NvciAoMzAwMC4wMi1NSHogNjg2LWNsYXNzIENQVSkKICBPcmln aW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDEwMGY2MiAgU3RlcHBpbmcgPSAyCiAgRmVh dHVyZXM9MHgxNzhiZmJmZjxGUFUsVk1FLERFLFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQ SUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0UzNixDTEZMVVNILE1NWCxGWFNSLFNT RSxTU0UyLEhUVD4KICBGZWF0dXJlczI9MHg4MDIwMDk8U1NFMyxNT04sQ1gxNiw8YjIzPj4K ICBBTUQgRmVhdHVyZXM9MHhlZTUwMDgwMDxTWVNDQUxMLE5YLE1NWCssRkZYU1IsPGIyNj4s UkRUU0NQLExNLDNETm93KywzRE5vdz4KICBBTUQgRmVhdHVyZXMyPTB4MzdmZjxMQUhGLENN UCw8YjI+LDxiMz4sQ1I4LDxiNT4sPGI2Piw8Yjc+LDxiOD4sPGI5Piw8YjEwPiw8YjEyPiw8 YjEzPj4KICBDb3JlcyBwZXIgcGFja2FnZTogMgpyZWFsIG1lbW9yeSAgPSAyMTQ3MDkwNDMy ICgyMDQ3IE1CKQphdmFpbCBtZW1vcnkgPSAyMDkyMDM2MDk2ICgxOTk1IE1CKQp3bGFuOiBt YWMgYWNsIHBvbGljeSByZWdpc3RlcmVkCm5ldHNtYl9kZXY6IGxvYWRlZAphdGhfaGFsOiAw LjkuMTYuMTYgKEFSNTIxMCwgQVI1MjExLCBBUjUyMTIsIFJGNTExMSwgUkY1MTEyLCBSRjI0 MTMsIFJGNTQxMykKY3B1MCBvbiBtb3RoZXJib2FyZApwY2liMDogPEhvc3QgdG8gUENJIGJy aWRnZT4gcGNpYnVzIDAgb24gbW90aGVyYm9hcmQKcGlyMDogPFBDSSBJbnRlcnJ1cHQgUm91 dGluZyBUYWJsZTogMTkgRW50cmllcz4gb24gbW90aGVyYm9hcmQKcGNpMDogPFBDSSBidXM+ IG9uIHBjaWIwCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAuMCAobm8gZHJpdmVy IGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBwb3J0IDB4MmYwMC0weDJmZmYg YXQgZGV2aWNlIDEuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAppY2hzbWIw OiA8U01CdXMgY29udHJvbGxlcj4gcG9ydCAweDI5MDAtMHgyOTNmLDB4MmQwMC0weDJkM2Ys MHgyZTAwLTB4MmUzZiBpcnEgNyBhdCBkZXZpY2UgMS4xIG9uIHBjaTAKaWNoc21iMDogW0dJ QU5ULUxPQ0tFRF0Kc21idXMwOiA8U3lzdGVtIE1hbmFnZW1lbnQgQnVzPiBvbiBpY2hzbWIw CnNtYjA6IDxTTUJ1cyBnZW5lcmljIEkvTz4gb24gc21idXMwCnBjaTA6IDxtZW1vcnksIFJB TT4gYXQgZGV2aWNlIDEuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8cHJvY2Vzc29y PiBhdCBkZXZpY2UgMS4zIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxtZW1vcnksIFJB TT4gYXQgZGV2aWNlIDEuNCAobm8gZHJpdmVyIGF0dGFjaGVkKQpvaGNpMDogPE9IQ0kgKGdl bmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmOWY3ZjAwMC0weGY5ZjdmZmZmIGlycSAx MSBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKb2hjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjA6IE9I Q0kgdmVyc2lvbiAxLjAsIGxlZ2FjeSBzdXBwb3J0CnVzYjA6IFNNTSBkb2VzIG5vdCByZXNw b25kLCByZXNldHRpbmcKdXNiMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBv biBvaGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVodWIwOiBuVmlkaWEgT0hDSSByb290 IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDEKdWh1YjA6IDYgcG9ydHMg d2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmVoY2kwOiA8RUhDSSAoZ2VuZXJpYykg VVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmOWY3ZWMwMC0weGY5ZjdlY2ZmIGlycSAxNSBh dCBkZXZpY2UgMi4xIG9uIHBjaTAKZWhjaTA6IFtHSUFOVC1MT0NLRURdCnVzYjE6IEVIQ0kg dmVyc2lvbiAxLjAKdXNiMTogY29tcGFuaW9uIGNvbnRyb2xsZXIsIDE1IHBvcnRzIGVhY2g6 IHVzYjAKdXNiMTogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhj aTAKdXNiMTogVVNCIHJldmlzaW9uIDIuMAp1aHViMTogblZpZGlhIEVIQ0kgcm9vdCBodWIs IGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxCnVodWIxOiA2IHBvcnRzIHdpdGgg NiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1bWFzczA6IHZlbmRvciAweDEwMDUgVVNCIEZM QVNIIERSSVZFLCByZXYgMi4wMC8xLjEwLCBhZGRyIDIKb2hjaTE6IDxPSENJIChnZW5lcmlj KSBVU0IgY29udHJvbGxlcj4gbWVtIDB4ZjlmN2QwMDAtMHhmOWY3ZGZmZiBpcnEgMTAgYXQg ZGV2aWNlIDQuMCBvbiBwY2kwCm9oY2kxOiBbR0lBTlQtTE9DS0VEXQp1c2IyOiBPSENJIHZl cnNpb24gMS4wLCBsZWdhY3kgc3VwcG9ydAp1c2IyOiBTTU0gZG9lcyBub3QgcmVzcG9uZCwg cmVzZXR0aW5nCnVzYjI6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gb2hj aTEKdXNiMjogVVNCIHJldmlzaW9uIDEuMAp1aHViMjogblZpZGlhIE9IQ0kgcm9vdCBodWIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIyOiA2IHBvcnRzIHdpdGgg NiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMTogPEVIQ0kgKGdlbmVyaWMpIFVTQiAy LjAgY29udHJvbGxlcj4gbWVtIDB4ZjlmN2U4MDAtMHhmOWY3ZThmZiBpcnEgMTAgYXQgZGV2 aWNlIDQuMSBvbiBwY2kwCmVoY2kxOiBbR0lBTlQtTE9DS0VEXQp1c2IzOiBFSENJIHZlcnNp b24gMS4wCnVzYjM6IGNvbXBhbmlvbiBjb250cm9sbGVyLCAxNSBwb3J0cyBlYWNoOiB1c2Iy CnVzYjM6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kxCnVz YjM6IFVTQiByZXZpc2lvbiAyLjAKdWh1YjM6IG5WaWRpYSBFSENJIHJvb3QgaHViLCBjbGFz cyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMQp1aHViMzogNiBwb3J0cyB3aXRoIDYgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQKdW1hc3MxOiBHZW5lcmljIE1hc3MgU3RvcmFnZSBEZXZp Y2UsIHJldiAyLjAwLzEuMDAsIGFkZHIgMgphdGFwY2kwOiA8R0VORVJJQyBBVEEgY29udHJv bGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3NiwweGZmYTAt MHhmZmFmIGF0IGRldmljZSA2LjAgb24gcGNpMAphdGEwOiA8QVRBIGNoYW5uZWwgMD4gb24g YXRhcGNpMAphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMApwY2kwOiA8bXVsdGlt ZWRpYT4gYXQgZGV2aWNlIDcuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2liMTogPFBDSUJJ T1MgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA4LjAgb24gcGNpMApwY2kxOiA8UENJIGJ1 cz4gb24gcGNpYjEKYXRhcGNpMTogPEdFTkVSSUMgQVRBIGNvbnRyb2xsZXI+IHBvcnQgMHhk NDgwLTB4ZDQ4NywweGQ0MDAtMHhkNDAzLDB4ZDA4MC0weGQwODcsMHhkMDAwLTB4ZDAwMyww eGNjMDAtMHhjYzBmIG1lbSAweGY5Zjc2MDAwLTB4ZjlmNzdmZmYgaXJxIDkgYXQgZGV2aWNl IDkuMCBvbiBwY2kwCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kxCmF0YTM6IDxB VEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kxCnBjaTA6IDxuZXR3b3JrLCBldGhlcm5ldD4gYXQg ZGV2aWNlIDEwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpYjI6IDxQQ0lCSU9TIFBDSS1Q Q0kgYnJpZGdlPiBpcnEgMTAgYXQgZGV2aWNlIDE2LjAgb24gcGNpMApwY2kyOiA8UENJIGJ1 cz4gb24gcGNpYjIKcGNpMjogPGRpc3BsYXksIFZHQT4gYXQgZGV2aWNlIDAuMCAobm8gZHJp dmVyIGF0dGFjaGVkKQpwY2liMzogPFBDSUJJT1MgUENJLVBDSSBicmlkZ2U+IGlycSAxMSBh dCBkZXZpY2UgMTguMCBvbiBwY2kwCnBjaTM6IDxQQ0kgYnVzPiBvbiBwY2liMwpwY2liNDog PFBDSUJJT1MgUENJLVBDSSBicmlkZ2U+IGlycSAxNSBhdCBkZXZpY2UgMTkuMCBvbiBwY2kw CnBjaTQ6IDxQQ0kgYnVzPiBvbiBwY2liNApwbXRpbWVyMCBvbiBpc2EwCmF0a2JkYzA6IDxL ZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MCwweDY0IG9uIGlzYTAK YXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAK YXRrYmQwOiBbR0lBTlQtTE9DS0VEXQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0 a2JkYzAKcHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogbW9kZWwgSW50ZWxsaU1vdXNlLCBk ZXZpY2UgSUQgMwpwcGMwOiBwYXJhbGxlbCBwb3J0IG5vdCBmb3VuZC4Kc2MwOiA8U3lzdGVt IGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwg Y29uc29sZXMsIGZsYWdzPTB4MzAwPgpzaW8wIGF0IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQg ZmxhZ3MgMHgxMCBvbiBpc2EwCnNpbzA6IHR5cGUgMTY1NTBBCnNpbzE6IGNvbmZpZ3VyZWQg aXJxIDMgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwCnNpbzE6IHBvcnQgbWF5IG5v dCBiZSBlbmFibGVkCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgz ZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTAKdW5rbm93bjogPFBOUDBjMDE+IGNh bid0IGFzc2lnbiByZXNvdXJjZXMgKG1lbW9yeSkKdW5rbm93bjogPFBOUDA1MDE+IGNhbid0 IGFzc2lnbiByZXNvdXJjZXMgKHBvcnQpCnVua25vd246IDxJTlQwODAwPiBjYW4ndCBhc3Np Z24gcmVzb3VyY2VzIChtZW1vcnkpCnVua25vd246IDxQTlAwYzAyPiBjYW4ndCBhc3NpZ24g cmVzb3VyY2VzIChtZW1vcnkpCnVua25vd246IDxQTlAwMzAzPiBjYW4ndCBhc3NpZ24gcmVz b3VyY2VzIChwb3J0KQp1bmtub3duOiA8UE5QMGYxMz4gY2FuJ3QgYXNzaWduIHJlc291cmNl cyAoaXJxKQpUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMzAwMDAyMjgwNiBIeiBxdWFs aXR5IDgwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCklQdjYgcGFja2V0 IGZpbHRlcmluZyBpbml0aWFsaXplZCwgZGVmYXVsdCB0byBhY2NlcHQsIGxvZ2dpbmcgbGlt aXRlZCB0byAxMDAgcGFja2V0cy9lbnRyeQpJUHNlYzogSW5pdGlhbGl6ZWQgU2VjdXJpdHkg QXNzb2NpYXRpb24gUHJvY2Vzc2luZy4KbmNwX2xvYWQ6IGxvYWRlZAppcGZ3MiAoK2lwdjYp IGluaXRpYWxpemVkLCBkaXZlcnQgbG9hZGFibGUsIHJ1bGUtYmFzZWQgZm9yd2FyZGluZyBl bmFibGVkLCBkZWZhdWx0IHRvIGFjY2VwdCwgbG9nZ2luZyBsaW1pdGVkIHRvIDEwMCBwYWNr ZXRzL2VudHJ5IGJ5IGRlZmF1bHQKbWQwOiBQcmVsb2FkZWQgaW1hZ2UgPC9ib290L2ZyZW56 eXJvb3Q+IDIwOTcxNTIgYnl0ZXMgYXQgMHhjMGQyMzBiYwphY2QwOiBEVkRSIDxBU1VTIERS Vy0xNjA4UDNTLzEuMTk+IGF0IGF0YTAtbWFzdGVyIFBJTzQKYWQ0OiAzMDUyNDVNQiA8U0FN U1VORyBIRDMyMUhKIDFBQzAxMTE4PiBhdCBhdGEyLW1hc3RlciBQSU80CmFkNjogNDc2OTQw TUIgPFNlYWdhdGUgU1QzNTAwNDE4QVMgQ0MzOD4gYXQgYXRhMy1tYXN0ZXIgUElPNApjZDAg YXQgYXRhMCBidXMgMCB0YXJnZXQgMCBsdW4gMApjZDA6IDxBU1VTIERSVy0xNjA4UDNTIDEu MTk+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0wIGRldmljZSAKY2QwOiAxNi4wMDBNQi9zIHRy YW5zZmVycwpjZDA6IGNkIHByZXNlbnQgWzk5MTQyIHggMjA0OCBieXRlIHJlY29yZHNdCmRh MCBhdCB1bWFzcy1zaW0wIGJ1cyAwIHRhcmdldCAwIGx1biAwCmRhMDogPCBVU0IgRkxBU0gg RFJJVkUgUE1BUD4gUmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0wIGRldmljZSAKZGEw OiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTA6IDc2NDBNQiAoMTU2NDY3MjAgNTEyIGJ5dGUg c2VjdG9yczogMjU1SCA2M1MvVCA5NzNDKQpkYTEgYXQgdW1hc3Mtc2ltMSBidXMgMSB0YXJn ZXQgMCBsdW4gMApkYTE6IDxHZW5lcmljIFVTQiAgQ0YgUmVhZGVyIDAuMDA+IFJlbW92YWJs ZSBEaXJlY3QgQWNjZXNzIFNDU0ktMiBkZXZpY2UgCmRhMTogNDAuMDAwTUIvcyB0cmFuc2Zl cnMKZGExOiBBdHRlbXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZ LCBNZWRpdW0gbm90IHByZXNlbnQKZGEyIGF0IHVtYXNzLXNpbTEgYnVzIDEgdGFyZ2V0IDAg bHVuIDEKZGEyOiA8R2VuZXJpYyBVU0IgIFNEIFJlYWRlciAwLjAwPiBSZW1vdmFibGUgRGly ZWN0IEFjY2VzcyBTQ1NJLTIgZGV2aWNlIApkYTI6IDQwLjAwME1CL3MgdHJhbnNmZXJzCmRh MjogQXR0ZW1wdCB0byBxdWVyeSBkZXZpY2Ugc2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVk aXVtIG5vdCBwcmVzZW50CmRhMyBhdCB1bWFzcy1zaW0xIGJ1cyAxIHRhcmdldCAwIGx1biAy CmRhMzogPEdlbmVyaWMgVVNCICBNUyBSZWFkZXIgMC4wMD4gUmVtb3ZhYmxlIERpcmVjdCBB Y2Nlc3MgU0NTSS0yIGRldmljZSAKZGEzOiA0MC4wMDBNQi9zIHRyYW5zZmVycwpkYTM6IEF0 dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBOT1QgUkVBRFksIE1lZGl1bSBu b3QgcHJlc2VudApkYTQgYXQgdW1hc3Mtc2ltMSBidXMgMSB0YXJnZXQgMCBsdW4gMwpkYTQ6 IDxHZW5lcmljIFVTQiAgU00gUmVhZGVyIDAuMDA+IFJlbW92YWJsZSBEaXJlY3QgQWNjZXNz IFNDU0ktMiBkZXZpY2UgCmRhNDogNDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGE0OiBBdHRlbXB0 IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90IHBy ZXNlbnQKKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogUkVBRCBDQVBBQ0lUWS4gQ0RCOiAyNSAw IDAgMCAwIDAgMCAwIDAgMCAKKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogQ0FNIFN0YXR1czog U0NTSSBTdGF0dXMgRXJyb3IKKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogU0NTSSBTdGF0dXM6 IENoZWNrIENvbmRpdGlvbgooZGExOnVtYXNzLXNpbTE6MTowOjApOiBOT1QgUkVBRFkgYXNj OjNhLDAKKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogTWVkaXVtIG5vdCBwcmVzZW50CihkYTE6 dW1hc3Mtc2ltMToxOjA6MCk6IFVucmV0cnlhYmxlIGVycm9yCk9wZW5lZCBkaXNrIGRhMSAt PiA2CihkYTE6dW1hc3Mtc2ltMToxOjA6MCk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgMCAw IDAgMCAwIDAgMCAwIDAgCihkYTE6dW1hc3Mtc2ltMToxOjA6MCk6IENBTSBTdGF0dXM6IFND U0kgU3RhdHVzIEVycm9yCihkYTE6dW1hc3Mtc2ltMToxOjA6MCk6IFNDU0kgU3RhdHVzOiBD aGVjayBDb25kaXRpb24KKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogTk9UIFJFQURZIGFzYzoz YSwwCihkYTE6dW1hc3Mtc2ltMToxOjA6MCk6IE1lZGl1bSBub3QgcHJlc2VudAooZGExOnVt YXNzLXNpbTE6MTowOjApOiBVbnJldHJ5YWJsZSBlcnJvcgpPcGVuZWQgZGlzayBkYTEgLT4g NgooZGExOnVtYXNzLXNpbTE6MTowOjApOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDAgMCAw IDAgMCAwIDAgMCAwIAooZGExOnVtYXNzLXNpbTE6MTowOjApOiBDQU0gU3RhdHVzOiBTQ1NJ IFN0YXR1cyBFcnJvcgooZGExOnVtYXNzLXNpbTE6MTowOjApOiBTQ1NJIFN0YXR1czogQ2hl Y2sgQ29uZGl0aW9uCihkYTE6dW1hc3Mtc2ltMToxOjA6MCk6IE5PVCBSRUFEWSBhc2M6M2Es MAooZGExOnVtYXNzLXNpbTE6MTowOjApOiBNZWRpdW0gbm90IHByZXNlbnQKKGRhMTp1bWFz cy1zaW0xOjE6MDowKTogVW5yZXRyeWFibGUgZXJyb3IKT3BlbmVkIGRpc2sgZGExIC0+IDYK KGRhMTp1bWFzcy1zaW0xOjE6MDowKTogUkVBRCBDQVBBQ0lUWS4gQ0RCOiAyNSAwIDAgMCAw IDAgMCAwIDAgMCAKKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogQ0FNIFN0YXR1czogU0NTSSBT dGF0dXMgRXJyb3IKKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogU0NTSSBTdGF0dXM6IENoZWNr IENvbmRpdGlvbgooZGExOnVtYXNzLXNpbTE6MTowOjApOiBOT1QgUkVBRFkgYXNjOjNhLDAK KGRhMTp1bWFzcy1zaW0xOjE6MDowKTogTWVkaXVtIG5vdCBwcmVzZW50CihkYTE6dW1hc3Mt c2ltMToxOjA6MCk6IFVucmV0cnlhYmxlIGVycm9yCk9wZW5lZCBkaXNrIGRhMSAtPiA2Cihk YTE6dW1hc3Mtc2ltMToxOjA6MCk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgMCAwIDAgMCAw IDAgMCAwIDAgCihkYTE6dW1hc3Mtc2ltMToxOjA6MCk6IENBTSBTdGF0dXM6IFNDU0kgU3Rh dHVzIEVycm9yCihkYTE6dW1hc3Mtc2ltMToxOjA6MCk6IFNDU0kgU3RhdHVzOiBDaGVjayBD b25kaXRpb24KKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogTk9UIFJFQURZIGFzYzozYSwwCihk YTE6dW1hc3Mtc2ltMToxOjA6MCk6IE1lZGl1bSBub3QgcHJlc2VudAooZGExOnVtYXNzLXNp bTE6MTowOjApOiBVbnJldHJ5YWJsZSBlcnJvcgpPcGVuZWQgZGlzayBkYTEgLT4gNgooZGEy OnVtYXNzLXNpbTE6MTowOjEpOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDIwIDAgMCAwIDAg MCAwIDAgMCAKKGRhMjp1bWFzcy1zaW0xOjE6MDoxKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0 dXMgRXJyb3IKKGRhMjp1bWFzcy1zaW0xOjE6MDoxKTogU0NTSSBTdGF0dXM6IENoZWNrIENv bmRpdGlvbgooZGEyOnVtYXNzLXNpbTE6MTowOjEpOiBOT1QgUkVBRFkgYXNjOjNhLDAKKGRh Mjp1bWFzcy1zaW0xOjE6MDoxKTogTWVkaXVtIG5vdCBwcmVzZW50CihkYTI6dW1hc3Mtc2lt MToxOjA6MSk6IFVucmV0cnlhYmxlIGVycm9yCk9wZW5lZCBkaXNrIGRhMiAtPiA2CihkYTI6 dW1hc3Mtc2ltMToxOjA6MSk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgMjAgMCAwIDAgMCAw IDAgMCAwIAooZGEyOnVtYXNzLXNpbTE6MTowOjEpOiBDQU0gU3RhdHVzOiBTQ1NJIFN0YXR1 cyBFcnJvcgooZGEyOnVtYXNzLXNpbTE6MTowOjEpOiBTQ1NJIFN0YXR1czogQ2hlY2sgQ29u ZGl0aW9uCihkYTI6dW1hc3Mtc2ltMToxOjA6MSk6IE5PVCBSRUFEWSBhc2M6M2EsMAooZGEy OnVtYXNzLXNpbTE6MTowOjEpOiBNZWRpdW0gbm90IHByZXNlbnQKKGRhMjp1bWFzcy1zaW0x OjE6MDoxKTogVW5yZXRyeWFibGUgZXJyb3IKT3BlbmVkIGRpc2sgZGEyIC0+IDYKKGRhMjp1 bWFzcy1zaW0xOjE6MDoxKTogUkVBRCBDQVBBQ0lUWS4gQ0RCOiAyNSAyMCAwIDAgMCAwIDAg MCAwIDAgCihkYTI6dW1hc3Mtc2ltMToxOjA6MSk6IENBTSBTdGF0dXM6IFNDU0kgU3RhdHVz IEVycm9yCihkYTI6dW1hc3Mtc2ltMToxOjA6MSk6IFNDU0kgU3RhdHVzOiBDaGVjayBDb25k aXRpb24KKGRhMjp1bWFzcy1zaW0xOjE6MDoxKTogTk9UIFJFQURZIGFzYzozYSwwCihkYTI6 dW1hc3Mtc2ltMToxOjA6MSk6IE1lZGl1bSBub3QgcHJlc2VudAooZGEyOnVtYXNzLXNpbTE6 MTowOjEpOiBVbnJldHJ5YWJsZSBlcnJvcgpPcGVuZWQgZGlzayBkYTIgLT4gNgooZGEyOnVt YXNzLXNpbTE6MTowOjEpOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDIwIDAgMCAwIDAgMCAw IDAgMCAKKGRhMjp1bWFzcy1zaW0xOjE6MDoxKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0dXMg RXJyb3IKKGRhMjp1bWFzcy1zaW0xOjE6MDoxKTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRp dGlvbgooZGEyOnVtYXNzLXNpbTE6MTowOjEpOiBOT1QgUkVBRFkgYXNjOjNhLDAKKGRhMjp1 bWFzcy1zaW0xOjE6MDoxKTogTWVkaXVtIG5vdCBwcmVzZW50CihkYTI6dW1hc3Mtc2ltMTox OjA6MSk6IFVucmV0cnlhYmxlIGVycm9yCk9wZW5lZCBkaXNrIGRhMiAtPiA2CihkYTI6dW1h c3Mtc2ltMToxOjA6MSk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgMjAgMCAwIDAgMCAwIDAg MCAwIAooZGEyOnVtYXNzLXNpbTE6MTowOjEpOiBDQU0gU3RhdHVzOiBTQ1NJIFN0YXR1cyBF cnJvcgooZGEyOnVtYXNzLXNpbTE6MTowOjEpOiBTQ1NJIFN0YXR1czogQ2hlY2sgQ29uZGl0 aW9uCihkYTI6dW1hc3Mtc2ltMToxOjA6MSk6IE5PVCBSRUFEWSBhc2M6M2EsMAooZGEyOnVt YXNzLXNpbTE6MTowOjEpOiBNZWRpdW0gbm90IHByZXNlbnQKKGRhMjp1bWFzcy1zaW0xOjE6 MDoxKTogVW5yZXRyeWFibGUgZXJyb3IKT3BlbmVkIGRpc2sgZGEyIC0+IDYKKGRhMzp1bWFz cy1zaW0xOjE6MDoyKTogUkVBRCBDQVBBQ0lUWS4gQ0RCOiAyNSA0MCAwIDAgMCAwIDAgMCAw IDAgCihkYTM6dW1hc3Mtc2ltMToxOjA6Mik6IENBTSBTdGF0dXM6IFNDU0kgU3RhdHVzIEVy cm9yCihkYTM6dW1hc3Mtc2ltMToxOjA6Mik6IFNDU0kgU3RhdHVzOiBDaGVjayBDb25kaXRp b24KKGRhMzp1bWFzcy1zaW0xOjE6MDoyKTogTk9UIFJFQURZIGFzYzozYSwwCihkYTM6dW1h c3Mtc2ltMToxOjA6Mik6IE1lZGl1bSBub3QgcHJlc2VudAooZGEzOnVtYXNzLXNpbTE6MTow OjIpOiBVbnJldHJ5YWJsZSBlcnJvcgpPcGVuZWQgZGlzayBkYTMgLT4gNgooZGEzOnVtYXNz LXNpbTE6MTowOjIpOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDQwIDAgMCAwIDAgMCAwIDAg MCAKKGRhMzp1bWFzcy1zaW0xOjE6MDoyKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0dXMgRXJy b3IKKGRhMzp1bWFzcy1zaW0xOjE6MDoyKTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRpdGlv bgooZGEzOnVtYXNzLXNpbTE6MTowOjIpOiBOT1QgUkVBRFkgYXNjOjNhLDAKKGRhMzp1bWFz cy1zaW0xOjE6MDoyKTogTWVkaXVtIG5vdCBwcmVzZW50CihkYTM6dW1hc3Mtc2ltMToxOjA6 Mik6IFVucmV0cnlhYmxlIGVycm9yCk9wZW5lZCBkaXNrIGRhMyAtPiA2CihkYTM6dW1hc3Mt c2ltMToxOjA6Mik6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgNDAgMCAwIDAgMCAwIDAgMCAw IAooZGEzOnVtYXNzLXNpbTE6MTowOjIpOiBDQU0gU3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJv cgooZGEzOnVtYXNzLXNpbTE6MTowOjIpOiBTQ1NJIFN0YXR1czogQ2hlY2sgQ29uZGl0aW9u CihkYTM6dW1hc3Mtc2ltMToxOjA6Mik6IE5PVCBSRUFEWSBhc2M6M2EsMAooZGEzOnVtYXNz LXNpbTE6MTowOjIpOiBNZWRpdW0gbm90IHByZXNlbnQKKGRhMzp1bWFzcy1zaW0xOjE6MDoy KTogVW5yZXRyeWFibGUgZXJyb3IKT3BlbmVkIGRpc2sgZGEzIC0+IDYKKGRhMzp1bWFzcy1z aW0xOjE6MDoyKTogUkVBRCBDQVBBQ0lUWS4gQ0RCOiAyNSA0MCAwIDAgMCAwIDAgMCAwIDAg CihkYTM6dW1hc3Mtc2ltMToxOjA6Mik6IENBTSBTdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9y CihkYTM6dW1hc3Mtc2ltMToxOjA6Mik6IFNDU0kgU3RhdHVzOiBDaGVjayBDb25kaXRpb24K KGRhMzp1bWFzcy1zaW0xOjE6MDoyKTogTk9UIFJFQURZIGFzYzozYSwwCihkYTM6dW1hc3Mt c2ltMToxOjA6Mik6IE1lZGl1bSBub3QgcHJlc2VudAooZGEzOnVtYXNzLXNpbTE6MTowOjIp OiBVbnJldHJ5YWJsZSBlcnJvcgpPcGVuZWQgZGlzayBkYTMgLT4gNgooZGEzOnVtYXNzLXNp bTE6MTowOjIpOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDQwIDAgMCAwIDAgMCAwIDAgMCAK KGRhMzp1bWFzcy1zaW0xOjE6MDoyKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0dXMgRXJyb3IK KGRhMzp1bWFzcy1zaW0xOjE6MDoyKTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRpdGlvbgoo ZGEzOnVtYXNzLXNpbTE6MTowOjIpOiBOT1QgUkVBRFkgYXNjOjNhLDAKKGRhMzp1bWFzcy1z aW0xOjE6MDoyKTogTWVkaXVtIG5vdCBwcmVzZW50CihkYTM6dW1hc3Mtc2ltMToxOjA6Mik6 IFVucmV0cnlhYmxlIGVycm9yCk9wZW5lZCBkaXNrIGRhMyAtPiA2CihkYTQ6dW1hc3Mtc2lt MToxOjA6Myk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgNjAgMCAwIDAgMCAwIDAgMCAwIAoo ZGE0OnVtYXNzLXNpbTE6MTowOjMpOiBDQU0gU3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJvcgoo ZGE0OnVtYXNzLXNpbTE6MTowOjMpOiBTQ1NJIFN0YXR1czogQ2hlY2sgQ29uZGl0aW9uCihk YTQ6dW1hc3Mtc2ltMToxOjA6Myk6IE5PVCBSRUFEWSBhc2M6M2EsMAooZGE0OnVtYXNzLXNp bTE6MTowOjMpOiBNZWRpdW0gbm90IHByZXNlbnQKKGRhNDp1bWFzcy1zaW0xOjE6MDozKTog VW5yZXRyeWFibGUgZXJyb3IKT3BlbmVkIGRpc2sgZGE0IC0+IDYKKGRhNDp1bWFzcy1zaW0x OjE6MDozKTogUkVBRCBDQVBBQ0lUWS4gQ0RCOiAyNSA2MCAwIDAgMCAwIDAgMCAwIDAgCihk YTQ6dW1hc3Mtc2ltMToxOjA6Myk6IENBTSBTdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihk YTQ6dW1hc3Mtc2ltMToxOjA6Myk6IFNDU0kgU3RhdHVzOiBDaGVjayBDb25kaXRpb24KKGRh NDp1bWFzcy1zaW0xOjE6MDozKTogTk9UIFJFQURZIGFzYzozYSwwCihkYTQ6dW1hc3Mtc2lt MToxOjA6Myk6IE1lZGl1bSBub3QgcHJlc2VudAooZGE0OnVtYXNzLXNpbTE6MTowOjMpOiBV bnJldHJ5YWJsZSBlcnJvcgpPcGVuZWQgZGlzayBkYTQgLT4gNgooZGE0OnVtYXNzLXNpbTE6 MTowOjMpOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDYwIDAgMCAwIDAgMCAwIDAgMCAKKGRh NDp1bWFzcy1zaW0xOjE6MDozKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0dXMgRXJyb3IKKGRh NDp1bWFzcy1zaW0xOjE6MDozKTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRpdGlvbgooZGE0 OnVtYXNzLXNpbTE6MTowOjMpOiBOT1QgUkVBRFkgYXNjOjNhLDAKKGRhNDp1bWFzcy1zaW0x OjE6MDozKTogTWVkaXVtIG5vdCBwcmVzZW50CihkYTQ6dW1hc3Mtc2ltMToxOjA6Myk6IFVu cmV0cnlhYmxlIGVycm9yCk9wZW5lZCBkaXNrIGRhNCAtPiA2CihkYTQ6dW1hc3Mtc2ltMTox OjA6Myk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgNjAgMCAwIDAgMCAwIDAgMCAwIAooZGE0 OnVtYXNzLXNpbTE6MTowOjMpOiBDQU0gU3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJvcgooZGE0 OnVtYXNzLXNpbTE6MTowOjMpOiBTQ1NJIFN0YXR1czogQ2hlY2sgQ29uZGl0aW9uCihkYTQ6 dW1hc3Mtc2ltMToxOjA6Myk6IE5PVCBSRUFEWSBhc2M6M2EsMAooZGE0OnVtYXNzLXNpbTE6 MTowOjMpOiBNZWRpdW0gbm90IHByZXNlbnQKKGRhNDp1bWFzcy1zaW0xOjE6MDozKTogVW5y ZXRyeWFibGUgZXJyb3IKT3BlbmVkIGRpc2sgZGE0IC0+IDYKKGRhNDp1bWFzcy1zaW0xOjE6 MDozKTogUkVBRCBDQVBBQ0lUWS4gQ0RCOiAyNSA2MCAwIDAgMCAwIDAgMCAwIDAgCihkYTQ6 dW1hc3Mtc2ltMToxOjA6Myk6IENBTSBTdGF0dXM6IFNDU0kgU3RhdHVzIEVycm9yCihkYTQ6 dW1hc3Mtc2ltMToxOjA6Myk6IFNDU0kgU3RhdHVzOiBDaGVjayBDb25kaXRpb24KKGRhNDp1 bWFzcy1zaW0xOjE6MDozKTogTk9UIFJFQURZIGFzYzozYSwwCihkYTQ6dW1hc3Mtc2ltMTox OjA6Myk6IE1lZGl1bSBub3QgcHJlc2VudAooZGE0OnVtYXNzLXNpbTE6MTowOjMpOiBVbnJl dHJ5YWJsZSBlcnJvcgpPcGVuZWQgZGlzayBkYTQgLT4gNgpUcnlpbmcgdG8gbW91bnQgcm9v dCBmcm9tIHVmczovZGV2L21kMAptZDEudXppcDogNDE3NiB4IDEzMDU2MCBibG9ja3MKKGRh MTp1bWFzcy1zaW0xOjE6MDowKTogUkVBRCBDQVBBQ0lUWS4gQ0RCOiAyNSAwIDAgMCAwIDAg MCAwIDAgMCAKKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0 dXMgRXJyb3IKKGRhMTp1bWFzcy1zaW0xOjE6MDowKTogU0NTSSBTdGF0dXM6IENoZWNrIENv bmRpdGlvbgooZGExOnVtYXNzLXNpbTE6MTowOjApOiBOT1QgUkVBRFkgYXNjOjNhLDAKKGRh MTp1bWFzcy1zaW0xOjE6MDowKTogTWVkaXVtIG5vdCBwcmVzZW50CihkYTE6dW1hc3Mtc2lt MToxOjA6MCk6IFVucmV0cnlhYmxlIGVycm9yCk9wZW5lZCBkaXNrIGRhMSAtPiA2CihkYTI6 dW1hc3Mtc2ltMToxOjA6MSk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgMjAgMCAwIDAgMCAw IDAgMCAwIAooZGEyOnVtYXNzLXNpbTE6MTowOjEpOiBDQU0gU3RhdHVzOiBTQ1NJIFN0YXR1 cyBFcnJvcgooZGEyOnVtYXNzLXNpbTE6MTowOjEpOiBTQ1NJIFN0YXR1czogQ2hlY2sgQ29u ZGl0aW9uCihkYTI6dW1hc3Mtc2ltMToxOjA6MSk6IE5PVCBSRUFEWSBhc2M6M2EsMAooZGEy OnVtYXNzLXNpbTE6MTowOjEpOiBNZWRpdW0gbm90IHByZXNlbnQKKGRhMjp1bWFzcy1zaW0x OjE6MDoxKTogVW5yZXRyeWFibGUgZXJyb3IKT3BlbmVkIGRpc2sgZGEyIC0+IDYKKGRhMzp1 bWFzcy1zaW0xOjE6MDoyKTogUkVBRCBDQVBBQ0lUWS4gQ0RCOiAyNSA0MCAwIDAgMCAwIDAg MCAwIDAgCihkYTM6dW1hc3Mtc2ltMToxOjA6Mik6IENBTSBTdGF0dXM6IFNDU0kgU3RhdHVz IEVycm9yCihkYTM6dW1hc3Mtc2ltMToxOjA6Mik6IFNDU0kgU3RhdHVzOiBDaGVjayBDb25k aXRpb24KKGRhMzp1bWFzcy1zaW0xOjE6MDoyKTogTk9UIFJFQURZIGFzYzozYSwwCihkYTM6 dW1hc3Mtc2ltMToxOjA6Mik6IE1lZGl1bSBub3QgcHJlc2VudAooZGEzOnVtYXNzLXNpbTE6 MTowOjIpOiBVbnJldHJ5YWJsZSBlcnJvcgpPcGVuZWQgZGlzayBkYTMgLT4gNgooZGE0OnVt YXNzLXNpbTE6MTowOjMpOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDYwIDAgMCAwIDAgMCAw IDAgMCAKKGRhNDp1bWFzcy1zaW0xOjE6MDozKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0dXMg RXJyb3IKKGRhNDp1bWFzcy1zaW0xOjE6MDozKTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRp dGlvbgooZGE0OnVtYXNzLXNpbTE6MTowOjMpOiBOT1QgUkVBRFkgYXNjOjNhLDAKKGRhNDp1 bWFzcy1zaW0xOjE6MDozKTogTWVkaXVtIG5vdCBwcmVzZW50CihkYTQ6dW1hc3Mtc2ltMTox OjA6Myk6IFVucmV0cnlhYmxlIGVycm9yCk9wZW5lZCBkaXNrIGRhNCAtPiA2CmZ1c2U0YnNk OiB2ZXJzaW9uIDAuMy4wLCBGVVNFIEFCSSA3LjUK --_===4145773====mail-be04.sovam.com===_-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 15:07:15 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 801A4106564A for ; Fri, 26 Feb 2010 15:07:15 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 3150E8FC1E for ; Fri, 26 Feb 2010 15:07:14 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Nl1mb-0002Mx-M9; Fri, 26 Feb 2010 17:07:13 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Gerrit =?ISO-8859-1?Q?K=FChn?= In-reply-to: <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> Comments: In-reply-to Gerrit =?ISO-8859-1?Q?K=FChn?= message dated "Fri, 26 Feb 2010 14:17:54 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Feb 2010 17:07:13 +0200 From: Daniel Braniss Message-ID: Cc: stable@freebsd.org, Willem Jan Withagen , Jack Vogel , Jeremy Chadwick Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 15:07:15 -0000 > On Fri, 26 Feb 2010 15:04:37 +0200 Daniel Braniss > wrote about Re: em0 freezes on ZFS server : > > DB> > At least in my case I found out what is eating the buffers: nfsd > DB> > does! The buffers stop increasing as soon as I stop nfsd. However, > DB> > they start increasing as soon as I start nfsd again. > DB> > Are there any ideas how to fix this? Downgrading back to 7-stable is > DB> > not really an easy task as far as I know, and I need the server to > DB> > run without having to reboot it once for twice a day... > > DB> I want to add some spices to this stew: :-) > > You're welcome. :-) > > DB> Some few day later it hung, and it's now hanging every few days. > DB> Most of the hangs are because there is no network, but the NIC is bce > DB> not em! I doubled kern.ipc.nmbclusters and lets see what happens ... > > Do you have nfsd running and serving clients? If so, we should maybe > change the topic to something like "possible nfs mbuf leakage"... > it's only purpose in life is a nfs server. but I wouldn't exclude zfs from the equation yet. I have othere nfs servers, not doing zfs and I don't see this. > DB> 23066/6634/29700 mbufs in use (current/cache/total) > > My server is at 22k now, and the buffer number is still increasing every > few seconds... > Can you monitor your mbuf usage and report if it grows? > I am, and in the last 2hs. it grew by about 300, it does oscilate, i.e. it grows some, then it goes down, but it seems that the low always increases. when I have enough data i'll plot it. Cheers, danny From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 15:19:28 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E29D8106566B for ; Fri, 26 Feb 2010 15:19:28 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id CBAAA8FC23 for ; Fri, 26 Feb 2010 15:19:26 +0000 (UTC) Received: from omta05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by qmta10.emeryville.ca.mail.comcast.net with comcast id me2H1d0030vp7WLAAfKTw5; Fri, 26 Feb 2010 15:19:27 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta05.emeryville.ca.mail.comcast.net with comcast id mfKS1d0073S48mS8RfKTVh; Fri, 26 Feb 2010 15:19:27 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 900241E301A; Fri, 26 Feb 2010 07:19:25 -0800 (PST) Date: Fri, 26 Feb 2010 07:19:25 -0800 From: Jeremy Chadwick To: oleg Message-ID: <20100226151925.GA23190@icarus.home.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-stable@freebsd.org Subject: Re: Sysinstall does not define SATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 15:19:29 -0000 On Fri, Feb 26, 2010 at 05:21:52PM +0300, oleg wrote: > Got some trouble. The Sysinstall program of FreeBSD 8.0 release does > not define SATA hard drives. Can`t create slices. > But that machine works correctly by Windows. > See attached dmesg file. The hard disks are seen by the system as classic PATA disks, operating in PIO4 mode, which probably indicates your BIOS is set to run the controller in "Emulation" mode. sysinstall should, I would think, see these disks since the kernel does. atapci1: port 0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f mem 0xf9f76000-0xf9f77fff irq 9 at device 9.0 on pci0 ata2: on atapci1 ata3: on atapci1 ad4: 305245MB at ata2-master PIO4 ad6: 476940MB at ata3-master PIO4 I've never seen the vendor string "GENERIC ATA controller" before. What exact motherboard or SATA controller card is this? Can you provide a link to it? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 15:27:12 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DCE41065673 for ; Fri, 26 Feb 2010 15:27:12 +0000 (UTC) (envelope-from thomas@ronner.org) Received: from mail.knopje.net (mail.knopje.net [213.214.107.232]) by mx1.freebsd.org (Postfix) with ESMTP id C65F18FC21 for ; Fri, 26 Feb 2010 15:27:11 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.knopje.net (Postfix) with ESMTP id 41DAD380BE; Fri, 26 Feb 2010 16:08:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at knopje.net Received: from mail.knopje.net ([127.0.0.1]) by localhost (hal.knopje.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BC8alFhopQ1V; Fri, 26 Feb 2010 16:08:48 +0100 (CET) Received: from [10.0.1.171] (rtutr01.ic-s.nl [213.214.96.4]) by mail.knopje.net (Postfix) with ESMTPSA id E34B4380A1; Fri, 26 Feb 2010 16:08:48 +0100 (CET) Message-Id: From: Thomas Ronner To: oleg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 26 Feb 2010 16:08:48 +0100 References: X-Mailer: Apple Mail (2.936) Cc: stable@freebsd.org Subject: Re: Sysinstall does not define SATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 15:27:12 -0000 Hello, On 26 Feb 2010, at 15:21, oleg wrote: > Got some trouble. The Sysinstall program of FreeBSD 8.0 release does > not define SATA hard drives. Can`t create slices. > But that machine works correctly by Windows. > See attached dmesg file. The dmesg you attached is from FreeBSD 6.1, not 8.0. It probably lacks the driver for your SATA chipset. Regards, Thomas From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 15:34:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38044106566C for ; Fri, 26 Feb 2010 15:34:47 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by mx1.freebsd.org (Postfix) with ESMTP id 006A78FC1D for ; Fri, 26 Feb 2010 15:34:46 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta02.emeryville.ca.mail.comcast.net with comcast id mdeZ1d00B1Y3wxoA2fanu7; Fri, 26 Feb 2010 15:34:47 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta15.emeryville.ca.mail.comcast.net with comcast id mfam1d0053S48mS8bfamct; Fri, 26 Feb 2010 15:34:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 2D9BC1E301A; Fri, 26 Feb 2010 07:34:44 -0800 (PST) Date: Fri, 26 Feb 2010 07:34:44 -0800 From: Jeremy Chadwick To: freebsd-stable@freebsd.org Message-ID: <20100226153444.GA23595@icarus.home.lan> References: <20100226151925.GA23190@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100226151925.GA23190@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Sysinstall does not define SATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 15:34:47 -0000 On Fri, Feb 26, 2010 at 07:19:25AM -0800, Jeremy Chadwick wrote: > On Fri, Feb 26, 2010 at 05:21:52PM +0300, oleg wrote: > > Got some trouble. The Sysinstall program of FreeBSD 8.0 release does > > not define SATA hard drives. Can`t create slices. > > But that machine works correctly by Windows. > > See attached dmesg file. > > The hard disks are seen by the system as classic PATA disks, operating > in PIO4 mode, which probably indicates your BIOS is set to run the > controller in "Emulation" mode. sysinstall should, I would think, see > these disks since the kernel does. > > atapci1: port 0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f mem 0xf9f76000-0xf9f77fff irq 9 at device 9.0 on pci0 > ata2: on atapci1 > ata3: on atapci1 > ad4: 305245MB at ata2-master PIO4 > ad6: 476940MB at ata3-master PIO4 > > I've never seen the vendor string "GENERIC ATA controller" before. What > exact motherboard or SATA controller card is this? Can you provide a > link to it? Note to others on the list: mail to the OP results in an autoresponder (not an SMTP-level bounce) stating the following: > From: oleg > To: Jeremy Chadwick > Date: Fri, 26 Feb 2010 18:19:29 +0300 > Subject: Re: Sysinstall does not define SATA > > This mail box closed So I'm not sure the OP is reachable or will see our responses. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 15:35:58 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B40591065672 for ; Fri, 26 Feb 2010 15:35:58 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA9E8FC28 for ; Fri, 26 Feb 2010 15:35:58 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 94C3E153433; Fri, 26 Feb 2010 16:35:56 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHFZRl4wP0mf; Fri, 26 Feb 2010 16:35:54 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 6B6E615342F; Fri, 26 Feb 2010 16:35:54 +0100 (CET) Message-ID: <4B87EACC.80105@digiware.nl> Date: Fri, 26 Feb 2010 16:37:48 +0100 From: Willem Jan Withagen Organization: Digiware User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Daniel Braniss References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, =?ISO-8859-1?Q?Gerrit_K=FChn?= , Jack Vogel , Jeremy Chadwick Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 15:35:58 -0000 On 26-2-2010 16:07, Daniel Braniss wrote: >> On Fri, 26 Feb 2010 15:04:37 +0200 Daniel Braniss >> wrote about Re: em0 freezes on ZFS server : >> >> DB> > At least in my case I found out what is eating the buffers: nfsd >> DB> > does! The buffers stop increasing as soon as I stop nfsd. However, >> DB> > they start increasing as soon as I start nfsd again. >> DB> > Are there any ideas how to fix this? Downgrading back to 7-stable is >> DB> > not really an easy task as far as I know, and I need the server to >> DB> > run without having to reboot it once for twice a day... >> >> DB> I want to add some spices to this stew: :-) >> >> You're welcome. :-) >> >> DB> Some few day later it hung, and it's now hanging every few days. >> DB> Most of the hangs are because there is no network, but the NIC is bce >> DB> not em! I doubled kern.ipc.nmbclusters and lets see what happens ... >> >> Do you have nfsd running and serving clients? If so, we should maybe >> change the topic to something like "possible nfs mbuf leakage"... >> > it's only purpose in life is a nfs server. > but I wouldn't exclude zfs from the equation yet. > I have othere nfs servers, not doing zfs and I don't see this. > >> DB> 23066/6634/29700 mbufs in use (current/cache/total) >> >> My server is at 22k now, and the buffer number is still increasing every >> few seconds... >> Can you monitor your mbuf usage and report if it grows? >> > I am, and in the last 2hs. it grew by about 300, it does oscilate, i.e. it > grows some, then > it goes down, but it seems that the low always increases. > > when I have enough data i'll plot it. Same here, from the odd samples I make. If I don't run my compiles, but just let the server sit. It just oscilates +- 500 mbufs. Once I start compiling, mbufs starts growing. I'm now at 22K Main network (NFS) traffic is than postfix writing Maildir dovecot - Maildir work Next to that it is also Samba server, but that doesn't seem to matter that much..... --WjW From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 15:41:04 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CF17106564A for ; Fri, 26 Feb 2010 15:41:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id EE1F18FC22 for ; Fri, 26 Feb 2010 15:41:03 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Nl2JK-00033U-Fw; Fri, 26 Feb 2010 17:41:02 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Gerrit =?ISO-8859-1?Q?K=FChn?= In-reply-to: References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> Comments: In-reply-to Daniel Braniss message dated "Fri, 26 Feb 2010 17:07:13 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Feb 2010 17:41:02 +0200 From: Daniel Braniss Message-ID: Cc: stable@freebsd.org, Willem Jan Withagen , Jack Vogel , Jeremy Chadwick Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 15:41:04 -0000 > when I have enough data i'll plot it. > check: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/plot.ps x is seconds, y is mbus current. > Cheers, > 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 Feb 26 16:23:45 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AEE2106566B for ; Fri, 26 Feb 2010 16:23:45 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id B6FFB8FC13 for ; Fri, 26 Feb 2010 16:23:44 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1QGNB5D018622; Fri, 26 Feb 2010 17:23:12 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 6738124; Fri, 26 Feb 2010 17:23:11 +0100 (CET) Date: Fri, 26 Feb 2010 17:23:11 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Daniel Braniss Message-Id: <20100226172311.68b72817.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.26.161519 Cc: stable@freebsd.org, Willem Jan Withagen , Jack Vogel , Jeremy Chadwick Subject: Re: em0 freezes on ZFS server X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 16:23:45 -0000 On Fri, 26 Feb 2010 17:07:13 +0200 Daniel Braniss wrote about Re: em0 freezes on ZFS server : DB> it's only purpose in life is a nfs server. I thought so, but you did not mention it explicitely. DB> but I wouldn't exclude zfs from the equation yet. DB> I have othere nfs servers, not doing zfs and I don't see this. My machine has zfs, too. I do not have 8-stable with nfs on ufs, so I cannot crosscheck that. DB> > My server is at 22k now, and the buffer number is still increasing DB> > every few seconds... DB> > Can you monitor your mbuf usage and report if it grows? DB> I am, and in the last 2hs. it grew by about 300, it does oscilate, DB> i.e. it grows some, then DB> it goes down, but it seems that the low always increases. Mine is at 36k now: 36797/3403/40200 mbufs in use (current/cache/total) 35772/1202/36974/65000 mbuf clusters in use (current/cache/total/max) 35772/836 mbuf+clusters out of packet secondary zone in use (current/cache) DB> when I have enough data i'll plot it. I think I'll reboot my machine now and hope that it lives as long as possible into the weekend. Although at the present rate it will not survive 24h. :-( cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 16:40:52 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB741106566B for ; Fri, 26 Feb 2010 16:40:52 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 621388FC0A for ; Fri, 26 Feb 2010 16:40:52 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1QGeLkT019474; Fri, 26 Feb 2010 17:40:22 +0100 Received: from pmp.uni-hannover.de (arc.pmp.uni-hannover.de [130.75.117.1]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 19E7924; Fri, 26 Feb 2010 17:40:21 +0100 (CET) Date: Fri, 26 Feb 2010 17:40:21 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Daniel Braniss Message-Id: <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.7.1 (GTK+ 2.18.4; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.26.162725 Cc: stable@freebsd.org, Willem Jan Withagen , Jack Vogel , Jeremy Chadwick Subject: mbuf leakage with nfs/zfs? (was: em0 freezes on ZFS server) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 16:40:52 -0000 On Fri, 26 Feb 2010 17:41:02 +0200 Daniel Braniss wrote about Re: em0 freezes on ZFS server : DB> check: DB> ftp://ftp.cs.huji.ac.il/users/danny/freebsd/plot.ps DB> x is seconds, y is mbus current. Looks not as bad as mine. I had 37k when I rebooted the machine some minutes ago (and it's basically idle, just serving a few nfs clients that don't do much). But from the values Jeremy has posted and from my own comparsisons here I would think that something like 5k of mbuf clusters would be normal for my machine (and probably also for yours). Some more info from my side: In the meantime I also tried a different network interface. The nfe-interface that is onboard causes the same problems, so it is probably not an em-specific issue. Furthermore I found this via Google: . I patched and recompiled my kernel with this, just to try it out. Right now I have 2264/1321/3585 mbufs in use (current/cache/total) 1239/1017/2256/65000 mbuf clusters in use (current/cache/total/max) 1239/809 mbuf+clusters out of packet secondary zone in use (current/cache) but the uptime is only 12min so far. In some hours I'll know for certain if this patch has anything to do with the problem. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 17:17:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 282F0106564A for ; Fri, 26 Feb 2010 17:17:58 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id B53DA8FC17 for ; Fri, 26 Feb 2010 17:17:57 +0000 (UTC) Received: from omta22.emeryville.ca.mail.comcast.net ([76.96.30.89]) by qmta06.emeryville.ca.mail.comcast.net with comcast id mgDD1d0041vN32cA6hHywz; Fri, 26 Feb 2010 17:17:58 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta22.emeryville.ca.mail.comcast.net with comcast id mhLS1d0063S48mS8ihLSDq; Fri, 26 Feb 2010 17:20:30 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id EBAFE1E301A; Fri, 26 Feb 2010 09:17:48 -0800 (PST) Resent-From: Jeremy Chadwick Resent-Date: Fri, 26 Feb 2010 09:17:48 -0800 Resent-Message-ID: <20100226171748.GA25865@icarus.home.lan> Resent-To: freebsd-stable@freebsd.org X-Original-To: jdc@localhost Received: from icarus.home.lan (localhost [127.0.0.1]) by icarus.home.lan (Postfix) with ESMTP id 607991E3019 for ; Fri, 26 Feb 2010 08:50:00 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on horus.parodius.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, SPF_PASS, USER_IN_BLACKLIST_TO, USER_IN_WHITELIST_TO autolearn=ham version=3.3.0 X-Original-To: freebsd@jdc.parodius.com Received: from mx01.sc1.parodius.com [72.20.98.67] by icarus.home.lan with POP3 (fetchmail-6.3.14) for (single-drop); Fri, 26 Feb 2010 08:50:00 -0800 (PST) Received: from sovam.com (mail.email.ru [194.67.1.204]) by mx01.sc1.parodius.com (Postfix) with ESMTP id 955959581D for ; Fri, 26 Feb 2010 08:49:40 -0800 (PST) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Feb 26 19:50:43 2010 X-DSPAM-Confidence: 0.8342 X-DSPAM-Probability: 0.0000 X-AttachExt: ... Received: from [94.137.5.25] (account skat@aport.ru) by mail-be01.sovam.com (CommuniGate Pro WEBUSER 5.2.16) with HTTP id 8484974 for freebsd@jdc.parodius.com; Fri, 26 Feb 2010 19:49:38 +0300 From: "oleg" To: Jeremy Chadwick X-Mailer: CommuniGate Pro WebUser v5.2.16 Date: Fri, 26 Feb 2010 19:49:38 +0300 Message-ID: In-Reply-To: <20100226151925.GA23190@icarus.home.lan> References: <20100226151925.GA23190@icarus.home.lan> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_===8484974====mail-be01.sovam.com===_" Cc: Subject: Re: Sysinstall does not define SATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 17:17:58 -0000 This is a multi-part MIME message --_===8484974====mail-be01.sovam.com===_ Content-Type: text/plain;charset=utf-8;format="flowed" Content-Transfer-Encoding: 8bit On Fri, 26 Feb 2010 07:19:25 -0800 Jeremy Chadwick wrote: > On Fri, Feb 26, 2010 at 05:21:52PM +0300, oleg wrote: >> Got some trouble. The Sysinstall program of FreeBSD 8.0 release does >> not define SATA hard drives. Can`t create slices. >> But that machine works correctly by Windows. >> See attached dmesg file. > > The hard disks are seen by the system as classic PATA disks, >operating > in PIO4 mode, which probably indicates your BIOS is set to run the > controller in "Emulation" mode. sysinstall should, I would think, >see > these disks since the kernel does. > > atapci1: port >0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f >mem 0xf9f76000-0xf9f77fff irq 9 at device 9.0 on pci0 > ata2: on atapci1 > ata3: on atapci1 > ad4: 305245MB at ata2-master PIO4 > ad6: 476940MB at ata3-master PIO4 > > I've never seen the vendor string "GENERIC ATA controller" before. > What > exact motherboard or SATA controller card is this? Can you provide >a > link to it? > > -- > | Jeremy Chadwick jdc@parodius.com >| > | Parodius Networking http://www.parodius.com/ >| > | UNIX Systems Administrator Mountain View, CA, USA >| > | Making life hard for others since 1977. PGP: 4BD6C0CB >| > ********************************************** Dear Jeremy Chadwick, many Thanks for answer. My hardware is: AM2+ Elitgroup GF8100vm-m5 - sata, II-RAID.... AMD 64 X 2 DDR2 - 2Gb 800MHz PCI Ex GeForce 9600 DDR2 SATA II 320 Samsung 321KJ 7200 16mb SATAII 500 Seagate ST3500418as Barracuda 7200 DVD-RW Sony 5240S SATA & link of the motherboad is http://www.eclipsecomputers.com/product.aspx?code=MBE-GF8100VMM5 I can offer the listing of pciconf -lv, (see attached) if you have interest to help me. But that listing received in sysadmin tools Frenzy on a base of FreeBSD-6. My gratitude for you. Yours Oleg from Russia. --- Ванкувер 2010. Новости Олимпиады. http://olympic.aport.ru --_===8484974====mail-be01.sovam.com===_ Content-Type: application/octet-stream Content-Disposition: attachment; filename="pciconf" Content-Transfer-Encoding: base64 bm9uZTBAcGNpMDowOjA6CWNsYXNzPTB4MDUwMDAwIGNhcmQ9MHgxYjY3MTAxOSBjaGlwPTB4 MDc1NDEwZGUgcmV2PTB4YTIgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ05WSURJQSBDb3Jw b3JhdGlvbicKICAgIGNsYXNzICAgID0gbWVtb3J5CiAgICBzdWJjbGFzcyA9IFJBTQppc2Fi MEBwY2kwOjE6MDoJY2xhc3M9MHgwNjAxMDAgY2FyZD0weDFiNjcxMDE5IGNoaXA9MHgwNzVj MTBkZSByZXY9MHhhMiBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0 aW9uJwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzID0gUENJLUlTQQppY2hz bWIwQHBjaTA6MToxOgljbGFzcz0weDBjMDUwMCBjYXJkPTB4MWI2NzEwMTkgY2hpcD0weDA3 NTIxMGRlIHJldj0weGExIGhkcj0weDAwCiAgICB2ZW5kb3IgICA9ICdOVklESUEgQ29ycG9y YXRpb24nCiAgICBjbGFzcyAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzID0gU01CdXMK bm9uZTFAcGNpMDoxOjI6CWNsYXNzPTB4MDUwMDAwIGNhcmQ9MHgxYjY3MTAxOSBjaGlwPTB4 MDc1MTEwZGUgcmV2PTB4YTEgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ05WSURJQSBDb3Jw b3JhdGlvbicKICAgIGNsYXNzICAgID0gbWVtb3J5CiAgICBzdWJjbGFzcyA9IFJBTQpub25l MkBwY2kwOjE6MzoJY2xhc3M9MHgwYjQwMDAgY2FyZD0weDFiNjcxMDE5IGNoaXA9MHgwNzUz MTBkZSByZXY9MHhhMiBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0 aW9uJwogICAgY2xhc3MgICAgPSBwcm9jZXNzb3IKbm9uZTNAcGNpMDoxOjQ6CWNsYXNzPTB4 MDUwMDAwIGNhcmQ9MHgxYjY3MTAxOSBjaGlwPTB4MDU2ODEwZGUgcmV2PTB4YTEgaGRyPTB4 MDAKICAgIHZlbmRvciAgID0gJ05WSURJQSBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgID0g bWVtb3J5CiAgICBzdWJjbGFzcyA9IFJBTQpvaGNpMEBwY2kwOjI6MDoJY2xhc3M9MHgwYzAz MTAgY2FyZD0weDFiNjcxMDE5IGNoaXA9MHgwNzdiMTBkZSByZXY9MHhhMSBoZHI9MHgwMAog ICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBzZXJp YWwgYnVzCiAgICBzdWJjbGFzcyA9IFVTQgplaGNpMEBwY2kwOjI6MToJY2xhc3M9MHgwYzAz MjAgY2FyZD0weDFiNjcxMDE5IGNoaXA9MHgwNzdjMTBkZSByZXY9MHhhMSBoZHI9MHgwMAog ICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBzZXJp YWwgYnVzCiAgICBzdWJjbGFzcyA9IFVTQgpvaGNpMUBwY2kwOjQ6MDoJY2xhc3M9MHgwYzAz MTAgY2FyZD0weDFiNjcxMDE5IGNoaXA9MHgwNzdkMTBkZSByZXY9MHhhMSBoZHI9MHgwMAog ICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBzZXJp YWwgYnVzCiAgICBzdWJjbGFzcyA9IFVTQgplaGNpMUBwY2kwOjQ6MToJY2xhc3M9MHgwYzAz MjAgY2FyZD0weDFiNjcxMDE5IGNoaXA9MHgwNzdlMTBkZSByZXY9MHhhMSBoZHI9MHgwMAog ICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBzZXJp YWwgYnVzCiAgICBzdWJjbGFzcyA9IFVTQgphdGFwY2kwQHBjaTA6NjowOgljbGFzcz0weDAx MDE4YSBjYXJkPTB4MWI2NzEwMTkgY2hpcD0weDA3NTkxMGRlIHJldj0weGExIGhkcj0weDAw CiAgICB2ZW5kb3IgICA9ICdOVklESUEgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICA9IG1h c3Mgc3RvcmFnZQogICAgc3ViY2xhc3MgPSBBVEEKbm9uZTRAcGNpMDo3OjA6CWNsYXNzPTB4 MDQwMzAwIGNhcmQ9MHgyOTg2MTAxOSBjaGlwPTB4MDc3NDEwZGUgcmV2PTB4YTEgaGRyPTB4 MDAKICAgIHZlbmRvciAgID0gJ05WSURJQSBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgID0g bXVsdGltZWRpYQpwY2liMUBwY2kwOjg6MDoJY2xhc3M9MHgwNjA0MDEgY2FyZD0weDAwMDAw MGI4IGNoaXA9MHgwNzVhMTBkZSByZXY9MHhhMSBoZHI9MHgwMQogICAgdmVuZG9yICAgPSAn TlZJRElBIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNz ID0gUENJLVBDSQphdGFwY2kxQHBjaTA6OTowOgljbGFzcz0weDAxMDE4NSBjYXJkPTB4MWI2 NzEwMTkgY2hpcD0weDBhZDAxMGRlIHJldj0weGEyIGhkcj0weDAwCiAgICB2ZW5kb3IgICA9 ICdOVklESUEgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICA9IG1hc3Mgc3RvcmFnZQogICAg c3ViY2xhc3MgPSBBVEEKbm9uZTVAcGNpMDoxMDowOgljbGFzcz0weDAyMDAwMCBjYXJkPTB4 MWI2NzEwMTkgY2hpcD0weDA3NjAxMGRlIHJldj0weGEyIGhkcj0weDAwCiAgICB2ZW5kb3Ig ICA9ICdOVklESUEgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICA9IG5ldHdvcmsKICAgIHN1 YmNsYXNzID0gZXRoZXJuZXQKcGNpYjJAcGNpMDoxNjowOgljbGFzcz0weDA2MDQwMCBjYXJk PTB4MDAwMDAwNDAgY2hpcD0weDA3NzgxMGRlIHJldj0weGExIGhkcj0weDAxCiAgICB2ZW5k b3IgICA9ICdOVklESUEgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICA9IGJyaWRnZQogICAg c3ViY2xhc3MgPSBQQ0ktUENJCnBjaWIzQHBjaTA6MTg6MDoJY2xhc3M9MHgwNjA0MDAgY2Fy ZD0weDAwMDAwMDQwIGNoaXA9MHgwNzViMTBkZSByZXY9MHhhMSBoZHI9MHgwMQogICAgdmVu ZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAg IHN1YmNsYXNzID0gUENJLVBDSQpwY2liNEBwY2kwOjE5OjA6CWNsYXNzPTB4MDYwNDAwIGNh cmQ9MHgwMDAwMDA0MCBjaGlwPTB4MDc3YTEwZGUgcmV2PTB4YTEgaGRyPTB4MDEKICAgIHZl bmRvciAgID0gJ05WSURJQSBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgID0gYnJpZGdlCiAg ICBzdWJjbGFzcyA9IFBDSS1QQ0kKaG9zdGIwQHBjaTA6MjQ6MDoJY2xhc3M9MHgwNjAwMDAg Y2FyZD0weDAwMDAwMDAwIGNoaXA9MHgxMjAwMTAyMiByZXY9MHgwMCBoZHI9MHgwMAogICAg dmVuZG9yICAgPSAnQWR2YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScKICAgIGNsYXNzICAg ID0gYnJpZGdlCiAgICBzdWJjbGFzcyA9IEhPU1QtUENJCmhvc3RiMUBwY2kwOjI0OjE6CWNs YXNzPTB4MDYwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTIwMTEwMjIgcmV2PTB4MDAg aGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCkn CiAgICBjbGFzcyAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgPSBIT1NULVBDSQpob3N0YjJA cGNpMDoyNDoyOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDEyMDIx MDIyIHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICA9ICdBZHZhbmNlZCBNaWNybyBE ZXZpY2VzIChBTUQpJwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzID0gSE9T VC1QQ0kKaG9zdGIzQHBjaTA6MjQ6MzoJY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwMDAwMDAw IGNoaXA9MHgxMjAzMTAyMiByZXY9MHgwMCBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnQWR2 YW5jZWQgTWljcm8gRGV2aWNlcyAoQU1EKScKICAgIGNsYXNzICAgID0gYnJpZGdlCiAgICBz dWJjbGFzcyA9IEhPU1QtUENJCmhvc3RiNEBwY2kwOjI0OjQ6CWNsYXNzPTB4MDYwMDAwIGNh cmQ9MHgwMDAwMDAwMCBjaGlwPTB4MTIwNDEwMjIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZl bmRvciAgID0gJ0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknCiAgICBjbGFzcyAgICA9 IGJyaWRnZQogICAgc3ViY2xhc3MgPSBIT1NULVBDSQpub25lNkBwY2kyOjA6MDoJY2xhc3M9 MHgwMzAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgwNjI1MTBkZSByZXY9MHhhMSBoZHI9 MHgwMAogICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAg PSBkaXNwbGF5CiAgICBzdWJjbGFzcyA9IFZHQQo= --_===8484974====mail-be01.sovam.com===_-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 18:18:54 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ED531065675 for ; Fri, 26 Feb 2010 18:18:54 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id BBA848FC18 for ; Fri, 26 Feb 2010 18:18:53 +0000 (UTC) Received: from furia.intranet ([93.104.121.188]) (AUTH: CRAM-MD5 lopez.on.the.lists@yellowspace.net, SSL: TLSv1/SSLv3, 256bits, CAMELLIA256-SHA) by mail.yellowspace.net with esmtp; Fri, 26 Feb 2010 19:18:50 +0100 id 00341CCF.000000004B88108A.00007C8B Message-ID: <4B881089.2030708@yellowspace.net> Date: Fri, 26 Feb 2010 19:18:49 +0100 From: Lorenzo Perone User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_mail.yellowspace.net-31883-1267208330-0001-2" To: freebsd-stable@freebsd.org, freebsd-jail@freebsd.org Cc: Subject: Panic on 8-STABLE in pfctl with options VIMAGE on a DELL PowerEdge R300 (bge) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 18:18:54 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_mail.yellowspace.net-31883-1267208330-0001-2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, Just encountered a panic when starting pf (/etc/rc.d/pf start) on a FreeBSD benjamin 8.0-STABLE uname -a FreeBSD 8.0-STABLE #0: Fri Feb 26 18:33:44 UTC 2010 root@benjamin:/usr/obj/usr/src/sys/BYTESATWORK_R8_INTEL_DEBUG amd64 the system is a Dell PowerEdge R300 with bge interfaces, 16 GB RAM (dmesg attached). Panic and trace remote console screenshots: http://lorenzo.yellowspace.net/R300_pfctl_panic.gif http://lorenzo.yellowspace.net/R300_pfctl_panic_trace.gif Excerpt transcript: panic: Fatal trap 12: page fault while in kernel mode current process = 1302 Stopped at pfil_head_get+0x41 movq 0x28(%rcx),%rdx trace: pfil_head_get() at pfil_head_get+0x41 pfioctl() at pfioctl+0x3351 devfs_ioctl_f() at devfs_ioctl_f+0x71 kern_ioctl() at kern_ioctl+0xe4 ioctl() at ioctl+0xed syscall() at syscall+0x1e7 Xfast_syscall() at Xfast_syscall+0xe1 While I was just planning to experiment with VIMAGE, and it is not required for production (I'm aware of the message of it being experimental...), I thought it might be useful to report it. Please send me a note if I should file a pr. The panic does not occur with the same kernel compiled without options VIMAGE. Note that the dmesg is from the system booted with the kernel without VIMAGE, that's why it doesn't contain the warning. big Regards to all the team, Lorenzo --=_mail.yellowspace.net-31883-1267208330-0001-2 Content-Type: text/plain; name="r300_dmesg.txt"; charset=iso-8859-1 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="r300_dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMTAgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtU1RBQkxFICMwOiBG cmkgRmViIDI2IDE4OjMzOjQ0IFVUQyAyMDEwCiAgICByb290QGJlbmphbWluOi91c3Ivb2Jq L3Vzci9zcmMvc3lzL0JZVEVTQVRXT1JLX1I4X0lOVEVMX05PX1ZJTUFHRV9ERUJVRyBhbWQ2 NApUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApD UFU6IEludGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICBYMzM2MyAgQCAyLjgzR0h6ICgy ODMzLjM0LU1IeiBLOC1jbGFzcyBDUFUpCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElk ID0gMHgxMDY3YSAgU3RlcHBpbmcgPSAxMAogIEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBVLFZN RSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01P VixQQVQsUFNFMzYsQ0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQs VE0sUEJFPgogIEZlYXR1cmVzMj0weDQwY2UzYmQ8U1NFMyxEVEVTNjQsTU9OLERTX0NQTCxW TVgsRVNULFRNMixTU1NFMyxDWDE2LHhUUFIsUERDTSxEQ0EsU1NFNC4xLFhTQVZFPgogIEFN RCBGZWF0dXJlcz0weDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+CiAgQU1EIEZlYXR1cmVzMj0w eDE8TEFIRj4KICBUU0M6IFAtc3RhdGUgaW52YXJpYW50CnJlYWwgbWVtb3J5ICA9IDE3MTc5 ODY5MTg0ICgxNjM4NCBNQikKYXZhaWwgbWVtb3J5ID0gMTY1NDIwNDgyNTYgKDE1Nzc1IE1C KQpBQ1BJIEFQSUMgVGFibGU6IDxERUxMICAgUEVfU0MzICA+CkZyZWVCU0QvU01QOiBNdWx0 aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcwpGcmVlQlNEL1NNUDogMSBwYWNr YWdlKHMpIHggNCBjb3JlKHMpCiBjcHUwIChCU1ApOiBBUElDIElEOiAgMAogY3B1MSAoQVAp OiBBUElDIElEOiAgMQogY3B1MiAoQVApOiBBUElDIElEOiAgMgogY3B1MyAoQVApOiBBUElD IElEOiAgMwppb2FwaWMwOiBDaGFuZ2luZyBBUElDIElEIHRvIDQKaW9hcGljMCA8VmVyc2lv biAyLjA+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAKY3J5cHRv c29mdDA6IDxzb2Z0d2FyZSBjcnlwdG8+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiA8REVMTCBQ RV9TQzM+IG9uIG1vdGhlcmJvYXJkCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2VyIEJ1 dHRvbiAoZml4ZWQpClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1 IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0 NU1Iej4gcG9ydCAweDgwOC0weDgwYiBvbiBhY3BpMAphY3BpX2hwZXQwOiA8SGlnaCBQcmVj aXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3Bp MApUaW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgOTAw CnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNw aTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpYjE6IDxQQ0ktUENJIGJyaWRn ZT4gYXQgZGV2aWNlIDIuMCBvbiBwY2kwCnBjaTM6IDxQQ0kgYnVzPiBvbiBwY2liMQpwY2li MjogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMy4wIG9uIHBjaTAKcGNpNDogPFBDSSBi dXM+IG9uIHBjaWIyCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDQu MCBvbiBwY2kwCnBjaTU6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIzCm1wdDA6IDxMU0lMb2dp YyBTQVMvU0FUQSBBZGFwdGVyPiBwb3J0IDB4ZWMwMC0weGVjZmYgbWVtIDB4ZGZjZWMwMDAt MHhkZmNlZmZmZiwweGRmY2YwMDAwLTB4ZGZjZmZmZmYgaXJxIDE2IGF0IGRldmljZSAwLjAg b24gcGNpNQptcHQwOiBbSVRIUkVBRF0KbXB0MDogTVBJIFZlcnNpb249MS41LjE4LjAKbXB0 MDogQ2FwYWJpbGl0aWVzOiAoIFJBSUQtMCBSQUlELTFFIFJBSUQtMSApCm1wdDA6IDEgQWN0 aXZlIFZvbHVtZSAoMiBNYXgpCm1wdDA6IDIgSGlkZGVuIERyaXZlIE1lbWJlcnMgKDE0IE1h eCkKcGNpYjQ6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDUuMCBvbiBwY2kwCnBjaTY6 IDxQQ0kgYnVzPiBvbiBwY2liNApwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSA2LjAgb24gcGNpMApwY2k3OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNQpwY2liNjog PEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA3LjAgb24gcGNpMApwY2k4OiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liNgpwY2liNzogPFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQg ZGV2aWNlIDI4LjAgb24gcGNpMApwY2k5OiA8UENJIGJ1cz4gb24gcGNpYjcKcGNpYjg6IDxB Q1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjQgb24gcGNpMApwY2kx OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liOApiZ2UwOiA8QnJvYWRjb20gTmV0WHRyZW1lIEdp Z2FiaXQgRXRoZXJuZXQgQ29udHJvbGxlciwgQVNJQyByZXYuIDB4MDBhMjAwPiBtZW0gMHhk ZmRmMDAwMC0weGRmZGZmZmZmIGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTEKbWlpYnVz MDogPE1JSSBidXM+IG9uIGJnZTAKYnJncGh5MDogPEJDTTU3MjIgMTAvMTAwLzEwMDBiYXNl VFggUEhZPiBQSFkgMSBvbiBtaWlidXMwCmJyZ3BoeTA6ICAxMGJhc2VULCAxMGJhc2VULUZE WCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIDEwMDBiYXNlVC1GRFgs IGF1dG8KYmdlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjY6Yjk6NTA6MDM6M2UKYmdlMDog W0ZJTFRFUl0KcGNpYjk6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNl IDI4LjUgb24gcGNpMApwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liOQpiZ2UxOiA8QnJv YWRjb20gTmV0WHRyZW1lIEdpZ2FiaXQgRXRoZXJuZXQgQ29udHJvbGxlciwgQVNJQyByZXYu IDB4MDBhMjAwPiBtZW0gMHhkZmVmMDAwMC0weGRmZWZmZmZmIGlycSAxNyBhdCBkZXZpY2Ug MC4wIG9uIHBjaTIKbWlpYnVzMTogPE1JSSBidXM+IG9uIGJnZTEKYnJncGh5MTogPEJDTTU3 MjIgMTAvMTAwLzEwMDBiYXNlVFggUEhZPiBQSFkgMSBvbiBtaWlidXMxCmJyZ3BoeTE6ICAx MGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFz ZVQsIDEwMDBiYXNlVC1GRFgsIGF1dG8KYmdlMTogRXRoZXJuZXQgYWRkcmVzczogMDA6MjY6 Yjk6NTA6MDM6M2YKYmdlMTogW0ZJTFRFUl0KdWhjaTA6IDxJbnRlbCA4MjgwMUkgKElDSDkp IFVTQiBjb250cm9sbGVyPiBwb3J0IDB4Y2M4MC0weGNjOWYgaXJxIDIxIGF0IGRldmljZSAy OS4wIG9uIHBjaTAKdWhjaTA6IFtJVEhSRUFEXQp1c2J1czA6IDxJbnRlbCA4MjgwMUkgKElD SDkpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMAp1aGNpMTogPEludGVsIDgyODAxSSAoSUNI OSkgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhjY2EwLTB4Y2NiZiBpcnEgMjAgYXQgZGV2aWNl IDI5LjEgb24gcGNpMAp1aGNpMTogW0lUSFJFQURdCnVzYnVzMTogPEludGVsIDgyODAxSSAo SUNIOSkgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kxCnVoY2kyOiA8SW50ZWwgODI4MDFJIChJ Q0g5KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGNjYzAtMHhjY2RmIGlycSAyMSBhdCBkZXZp Y2UgMjkuMiBvbiBwY2kwCnVoY2kyOiBbSVRIUkVBRF0KdXNidXMyOiA8SW50ZWwgODI4MDFJ IChJQ0g5KSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTIKZWhjaTA6IDxJbnRlbCA4MjgwMUkg KElDSDkpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZGZhZmZjMDAtMHhkZmFmZmZmZiBp cnEgMjEgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAplaGNpMDogW0lUSFJFQURdCnVzYnVzMzog RUhDSSB2ZXJzaW9uIDEuMAp1c2J1czM6IDxJbnRlbCA4MjgwMUkgKElDSDkpIFVTQiAyLjAg Y29udHJvbGxlcj4gb24gZWhjaTAKcGNpYjEwOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDMwLjAgb24gcGNpMApwY2kxMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjEwCnZn YXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4ZGMwMC0weGRjZmYgbWVt IDB4ZDAwMDAwMDAtMHhkN2ZmZmZmZiwweGRmZmYwMDAwLTB4ZGZmZmZmZmYgaXJxIDE5IGF0 IGRldmljZSA3LjAgb24gcGNpMTAKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNl IDMxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPEludGVs IElDSDkgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4Y2MyMC0weGNjMjcsMHhjYzEwLTB4 Y2MxMywweGNjMjgtMHhjYzJmLDB4Y2MxNC0weGNjMTcsMHhjYzQwLTB4Y2M0ZiwweGNjNTAt MHhjYzVmIGlycSAyMyBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwCmF0YXBjaTA6IFtJVEhSRUFE XQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGEyOiBbSVRIUkVBRF0KYXRh MzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKYXRhMzogW0lUSFJFQURdCmF0YXBjaTE6 IDxJbnRlbCBJQ0g5IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweGNjMzAtMHhjYzM3LDB4 Y2MxOC0weGNjMWIsMHhjYzM4LTB4Y2MzZiwweGNjMWMtMHhjYzFmLDB4Y2M2MC0weGNjNmYs MHhjYzcwLTB4Y2M3ZiBpcnEgMjIgYXQgZGV2aWNlIDMxLjUgb24gcGNpMAphdGFwY2kxOiBb SVRIUkVBRF0KYXRhNDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTEKYXRhNDogW0lUSFJF QURdCmF0YTU6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kxCmF0YTU6IFtJVEhSRUFEXQph dHJ0YzA6IDxBVCByZWFsdGltZSBjbG9jaz4gcG9ydCAweDcwLTB4N2YgaXJxIDggb24gYWNw aTAKZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyPiBwb3J0IDB4M2YwLTB4M2Y1LDB4 M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwCmZkYzA6IGRvZXMgbm90IHJlc3BvbmQKZGV2aWNl X2F0dGFjaDogZmRjMCBhdHRhY2ggcmV0dXJuZWQgNgp1YXJ0MDogPDE2NTUwIG9yIGNvbXBh dGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMAp1YXJ0 MDogW0ZJTFRFUl0KdWFydDE6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4MmY4LTB4 MmZmIGlycSAzIG9uIGFjcGkwCnVhcnQxOiBbRklMVEVSXQpjcHUwOiA8QUNQSSBDUFU+IG9u IGFjcGkwCmVzdDA6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9u IGNwdTAKZXN0OiBDUFUgc3VwcG9ydHMgRW5oYW5jZWQgU3BlZWRzdGVwLCBidXQgaXMgbm90 IHJlY29nbml6ZWQuCmVzdDogY3B1X3ZlbmRvciBHZW51aW5lSW50ZWwsIG1zciA0ODFmNDgx ZjA2MDA0ODFmCmRldmljZV9hdHRhY2g6IGVzdDAgYXR0YWNoIHJldHVybmVkIDYKcDR0Y2Mw OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTAKY3B1MTogPEFDUEkg Q1BVPiBvbiBhY3BpMAplc3QxOiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250 cm9sPiBvbiBjcHUxCmVzdDogQ1BVIHN1cHBvcnRzIEVuaGFuY2VkIFNwZWVkc3RlcCwgYnV0 IGlzIG5vdCByZWNvZ25pemVkLgplc3Q6IGNwdV92ZW5kb3IgR2VudWluZUludGVsLCBtc3Ig NDgxZjQ4MWYwNjAwNDgxZgpkZXZpY2VfYXR0YWNoOiBlc3QxIGF0dGFjaCByZXR1cm5lZCA2 CnA0dGNjMTogPENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUxCmNwdTI6 IDxBQ1BJIENQVT4gb24gYWNwaTAKZXN0MjogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVu Y3kgQ29udHJvbD4gb24gY3B1Mgplc3Q6IENQVSBzdXBwb3J0cyBFbmhhbmNlZCBTcGVlZHN0 ZXAsIGJ1dCBpcyBub3QgcmVjb2duaXplZC4KZXN0OiBjcHVfdmVuZG9yIEdlbnVpbmVJbnRl bCwgbXNyIDQ4MWY0ODFmMDYwMDQ4MWYKZGV2aWNlX2F0dGFjaDogZXN0MiBhdHRhY2ggcmV0 dXJuZWQgNgpwNHRjYzI6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1 MgpjcHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmVzdDM6IDxFbmhhbmNlZCBTcGVlZFN0ZXAg RnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTMKZXN0OiBDUFUgc3VwcG9ydHMgRW5oYW5jZWQg U3BlZWRzdGVwLCBidXQgaXMgbm90IHJlY29nbml6ZWQuCmVzdDogY3B1X3ZlbmRvciBHZW51 aW5lSW50ZWwsIG1zciA0ODFmNDgxZjA2MDA0ODFmCmRldmljZV9hdHRhY2g6IGVzdDMgYXR0 YWNoIHJldHVybmVkIDYKcDR0Y2MzOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+ IG9uIGNwdTMKZmRjMDogPGZsb3BweSBkcml2ZSBjb250cm9sbGVyPiBwb3J0IDB4M2YwLTB4 M2Y1LDB4M2Y3IGlycSA2IGRycSAyIG9uIGFjcGkwCmZkYzA6IGRvZXMgbm90IHJlc3BvbmQK ZGV2aWNlX2F0dGFjaDogZmRjMCBhdHRhY2ggcmV0dXJuZWQgNgpvcm0wOiA8SVNBIE9wdGlv biBST01zPiBhdCBpb21lbSAweGMwMDAwLTB4YzhmZmYsMHhjOTAwMC0weGM5ZmZmLDB4ZWMw MDAtMHhlZmZmZiBvbiBpc2EwCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEw MCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4K dmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21lbSAweGEw MDAwLTB4YmZmZmYgb24gaXNhMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgw NDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBvbiBpc2EwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBp cnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0K YXRrYmQwOiBbSVRIUkVBRF0KcHBjMDogY2Fubm90IHJlc2VydmUgSS9PIHBvcnQgcmFuZ2UK VGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwp1c2J1czA6IDEyTWJwcyBGdWxs IFNwZWVkIFVTQiB2MS4wCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjAKdXNi dXMyOiAxMk1icHMgRnVsbCBTcGVlZCBVU0IgdjEuMAp1c2J1czM6IDQ4ME1icHMgSGlnaCBT cGVlZCBVU0IgdjIuMAptcHQwOnZvbDAobXB0MDowOjApOiBTZXR0aW5ncyAoIE1lbWJlci1X Q0UgSG90LVBsdWctU3BhcmVzIEhpZ2gtUHJpb3JpdHktUmVTeW5jICkKbXB0MDp2b2wwKG1w dDA6MDowKTogVXNpbmcgU3BhcmUgUG9vbDogMAptcHQwOnZvbDAobXB0MDowOjApOiAyIE1l bWJlcnM6CiAgICAgIChtcHQwOjE6OTowKTogUHJpbWFyeSBPbmxpbmUKICAgICAgKG1wdDA6 MToxOjApOiBTZWNvbmRhcnkgT25saW5lCm1wdDA6dm9sMChtcHQwOjA6MCk6IFJBSUQtMSAt IE9wdGltYWwKbXB0MDp2b2wwKG1wdDA6MDowKTogU3RhdHVzICggRW5hYmxlZCApCihtcHQw OnZvbDA6MSk6IFBoeXNpY2FsIChtcHQwOjA6MTowKSwgUGFzcy10aHJ1IChtcHQwOjE6MDow KQoobXB0MDp2b2wwOjEpOiBPbmxpbmUKKG1wdDA6dm9sMDowKTogUGh5c2ljYWwgKG1wdDA6 MDo5OjApLCBQYXNzLXRocnUgKG1wdDA6MToxOjApCihtcHQwOnZvbDA6MCk6IE9ubGluZQoo eHB0MDptcHQwOjE6LTE6LTEpOiByZXNjYW4gYWxyZWFkeSBxdWV1ZWQKdWdlbjAuMTogPElu dGVsPiBhdCB1c2J1czAKdWh1YjA6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAs IHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMwCnVnZW4xLjE6IDxJbnRlbD4gYXQg dXNidXMxCnVodWIxOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMQp1Z2VuMi4xOiA8SW50ZWw+IGF0IHVzYnVzMgp1 aHViMjogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwg YWRkciAxPiBvbiB1c2J1czIKdWdlbjMuMTogPEludGVsPiBhdCB1c2J1czMKdWh1YjM6IDxJ bnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMT4g b24gdXNidXMzCmFjZDA6IERWRFIgPFBMRFMgRFZEKy8tUlcgRFMtOEEzUy9IRDUyPiBhdCBh dGEyLXNsYXZlIFVETUExMDAgU0FUQSAxLjVHYi9zCnVodWIwOiAyIHBvcnRzIHdpdGggMiBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkCnVodWIzOiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1 Z2VuMy4yOiA8dmVuZG9yIDB4NDEzYz4gYXQgdXNidXMzCnVodWI0OiA8dmVuZG9yIDB4NDEz YyBwcm9kdWN0IDB4YTAwMSwgY2xhc3MgOS8wLCByZXYgMi4wMC8wLjAwLCBhZGRyIDI+IG9u IHVzYnVzMwp1aHViNDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK c2VzMCBhdCBtcHQwIGJ1cyAwIHNjYnVzMCB0YXJnZXQgOCBsdW4gMApzZXMwOiA8RFAgQkFD S1BMQU5FIDEuMDU+IEZpeGVkIEVuY2xvc3VyZSBTZXJ2aWNlcyBTQ1NJLTUgZGV2aWNlIApz ZXMwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKc2VzMDogU0NTSS0zIFNFUyBEZXZpY2UKcGFz czIgYXQgbXB0MCBidXMgMSBzY2J1czEgdGFyZ2V0IDAgbHVuIDAKcGFzczI6IDxBVEEgSGl0 YWNoaSBIVUE3MjEwMSBBSjBBPiBGaXhlZCBVbmluc3RhbGxlZCBTQ1NJLTUgZGV2aWNlIApw YXNzMjogMzAwLjAwME1CL3MgdHJhbnNmZXJzCnBhc3MyOiBDb21tYW5kIFF1ZXVlaW5nIGVu YWJsZWQKZGEwIGF0IG1wdDAgYnVzIDAgc2NidXMwIHRhcmdldCAwIGx1biAwCmRhMDogPERl bGwgVklSVFVBTCBESVNLIDEwMjg+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS01IGRldmlj ZSAKZGEwOiAzMDAuMDAwTUIvcyB0cmFuc2ZlcnMKZGEwOiBDb21tYW5kIFF1ZXVlaW5nIGVu YWJsZWQKZGEwOiA5NTMzNDRNQiAoMTk1MjQ0ODUxMiA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVI IDYzUy9UIDEyMTUzNEMpClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpTTVA6IEFQIENQVSAj MiBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhClJvb3QgbW91bnQgd2FpdGlu ZyBmb3I6IHVzYnVzMwp1Z2VuMy4zOiA8RGVsbD4gYXQgdXNidXMzCnVrYmQwOiA8S2V5Ym9h cmQ+IG9uIHVzYnVzMwprYmQyIGF0IHVrYmQwCnVtczA6IDxNb3VzZT4gb24gdXNidXMzCnVt czA6IDMgYnV0dG9ucyBhbmQgW1pdIGNvb3JkaW5hdGVzIElEPTAKUm9vdCBtb3VudCB3YWl0 aW5nIGZvcjogdXNidXMzCnVnZW4zLjQ6IDx2ZW5kb3IgMHgwNGI0PiBhdCB1c2J1czMKdWh1 YjU6IDx2ZW5kb3IgMHgwNGI0IHByb2R1Y3QgMHg2NTYwLCBjbGFzcyA5LzAsIHJldiAyLjAw LzkwLjE1LCBhZGRyIDQ+IG9uIHVzYnVzMwp1aHViNTogMiBwb3J0cyB3aXRoIDIgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9s YWJlbC9yb290ZnMKWkZTIGZpbGVzeXN0ZW0gdmVyc2lvbiAzClpGUyBzdG9yYWdlIHBvb2wg dmVyc2lvbiAxNApiZ2UwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKYmdlMTogbGluayBz dGF0ZSBjaGFuZ2VkIHRvIFVQCgo= --=_mail.yellowspace.net-31883-1267208330-0001-2-- From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 19:15:11 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25001106564A; Fri, 26 Feb 2010 19:15:11 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id AEF0B8FC0A; Fri, 26 Feb 2010 19:15:10 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id B45C341C7AC; Fri, 26 Feb 2010 20:15:09 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id AVJ-XXX5CYxj; Fri, 26 Feb 2010 20:15:09 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 0F2FD41C7A8; Fri, 26 Feb 2010 20:15:09 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 867824448EC; Fri, 26 Feb 2010 19:15:05 +0000 (UTC) Date: Fri, 26 Feb 2010 19:15:05 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Lorenzo Perone In-Reply-To: <4B881089.2030708@yellowspace.net> Message-ID: <20100226191339.O27327@maildrop.int.zabbadoz.net> References: <4B881089.2030708@yellowspace.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Panic on 8-STABLE in pfctl with options VIMAGE on a DELL PowerEdge R300 (bge) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 19:15:11 -0000 On Fri, 26 Feb 2010, Lorenzo Perone wrote: Hi, > While I was just planning to experiment with VIMAGE, and it is not required > for production (I'm aware of the message of it being experimental...), I > thought it might be useful to report it. Please send me a note if I should > file a pr. > > The panic does not occur with the same kernel compiled without options > VIMAGE. FAQ from virtualization@ ; pf support for VIMAGE only basically exists here: http://svn.freebsd.org/base/user/eri/pf45/head/ but is not fully ready either. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 19:31:05 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80111106566C for ; Fri, 26 Feb 2010 19:31:05 +0000 (UTC) (envelope-from bob@immure.com) Received: from maul.immure.com (adsl-66-136-206-1.dsl.austtx.swbell.net [66.136.206.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3E2F08FC15 for ; Fri, 26 Feb 2010 19:31:04 +0000 (UTC) Received: from rancor.immure.com (rancor.immure.com [10.1.132.9]) by maul.immure.com (8.14.4/8.14.4) with ESMTP id o1QJHu8M002743 for ; Fri, 26 Feb 2010 13:17:56 -0600 (CST) (envelope-from bob@immure.com) Received: from rancor.immure.com (localhost [127.0.0.1]) by rancor.immure.com (8.14.3/8.14.3) with ESMTP id o1QJHtUT042813 for ; Fri, 26 Feb 2010 13:17:55 -0600 (CST) (envelope-from bob@rancor.immure.com) Received: (from bob@localhost) by rancor.immure.com (8.14.3/8.14.3/Submit) id o1QJHtpC042812 for freebsd-stable@freebsd.org; Fri, 26 Feb 2010 13:17:55 -0600 (CST) (envelope-from bob) Date: Fri, 26 Feb 2010 13:17:55 -0600 From: Bob Willcox To: stable list Message-ID: <20100226191755.GA42384@rancor.immure.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-immure-MailScanner-Information: Please contact the ISP for more information X-immure-MailScanner-ID: o1QJHu8M002743 X-immure-MailScanner: Found to be clean X-immure-MailScanner-From: bob@immure.com X-Spam-Status: No Subject: ipfw & natd with recent MFC of firewall_coscripts functionality X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bob Willcox List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 19:31:05 -0000 I just updated my gateway machine to 7.3-PRERELEASE and immediately noticed that natd no longer started (hard to miss, no outside network access). It looks like the MFC of the firewall_coscripts function may be the cause (cvs rev 1.15.2.3 to /usr/src/etc/rc.d/ipfw). These changes add the two lines (along with other stuff): ... ${_coscript} quietstart ... ${_coscript} quietstop ... I believe the problem is that neither "quietstart" or "quietstop" are recognized as valid arguments in by /etc/rc.d/natd so natd isn't started. Further, my hunch is that by removing the "quiet" prefix it will work (I'm reluctant to try this at the moment as I am remote). Bob -- Bob Willcox The shifts of Fortune test the reliability of friends. bob@immure.com -- Marcus Tullius Cicero Austin, TX From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 20:09:35 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02B6A106566B for ; Fri, 26 Feb 2010 20:09:35 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 9EFE68FC12 for ; Fri, 26 Feb 2010 20:09:34 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1Nl6VA-000557-D9; Fri, 26 Feb 2010 22:09:32 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Gerrit =?ISO-8859-1?Q?K=FChn?= In-reply-to: <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> Comments: In-reply-to Gerrit =?ISO-8859-1?Q?K=FChn?= message dated "Fri, 26 Feb 2010 17:40:21 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Feb 2010 22:09:32 +0200 From: Daniel Braniss Message-ID: Cc: stable@freebsd.org, Willem Jan Withagen , Jack Vogel , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? (was: em0 freezes on ZFS server) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 20:09:35 -0000 > On Fri, 26 Feb 2010 17:41:02 +0200 Daniel Braniss > wrote about Re: em0 freezes on ZFS server : > > DB> check: > DB> ftp://ftp.cs.huji.ac.il/users/danny/freebsd/plot.ps > DB> x is seconds, y is mbus current. > > Looks not as bad as mine. I had 37k when I rebooted the machine some > minutes ago (and it's basically idle, just serving a few nfs clients that > don't do much). > But from the values Jeremy has posted and from my own comparsisons here I > would think that something like 5k of mbuf clusters would be normal for my > machine (and probably also for yours). > > Some more info from my side: > In the meantime I also tried a different network interface. The > nfe-interface that is onboard causes the same problems, so it is probably > not an em-specific issue. > Furthermore I found this via Google: > . I'll have to do some packet snooping to check if it's TCP or UDP nfs traffic, since some of the clients are Linux ... > I patched and recompiled my kernel with this, just to try it out. Right > now I have > > 2264/1321/3585 mbufs in use (current/cache/total) > 1239/1017/2256/65000 mbuf clusters in use (current/cache/total/max) > 1239/809 mbuf+clusters out of packet secondary zone in use (current/cache) > > but the uptime is only 12min so far. In some hours I'll know for certain > if this patch has anything to do with the problem. at the moment there is not much activity, but if you check the latest plot.ps you will see that the bottom is slowly increasing, so my bet is that there must be some leakage! cheers danny From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 21:30:36 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7F8B3106566B; Fri, 26 Feb 2010 21:30:36 +0000 (UTC) (envelope-from onur@ulakbim.gov.tr) Received: from mail.ulakbim.gov.tr (mail.ulakbim.gov.tr [193.140.83.6]) by mx1.freebsd.org (Postfix) with ESMTP id 2D2948FC15; Fri, 26 Feb 2010 21:30:35 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by mail.ulakbim.gov.tr (Postfix) with ESMTP id 4FA45124523; Fri, 26 Feb 2010 23:14:28 +0200 (EET) X-Virus-Scanned: amavisd-new at ulakbim.gov.tr Received: from mail.ulakbim.gov.tr ([127.0.0.1]) by localhost (mail.ulakbim.gov.tr [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Bx4oyPF91pC9; Fri, 26 Feb 2010 23:14:28 +0200 (EET) Received: from [192.168.1.3] (unknown [88.254.84.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ulakbim.gov.tr (Postfix) with ESMTP id 92E7612443B; Fri, 26 Feb 2010 23:14:27 +0200 (EET) Message-ID: <4B8839AD.3090208@ulakbim.gov.tr> Date: Fri, 26 Feb 2010 23:14:21 +0200 From: Onur Bektas User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Lorenzo Perone References: <4B881089.2030708@yellowspace.net> In-Reply-To: <4B881089.2030708@yellowspace.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Panic on 8-STABLE in pfctl with options VIMAGE on a DELL PowerEdge R300 (bge) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 21:30:36 -0000 Hi, I had the same problem, I have updated the source tree and recompile the kernel but the problem is still unresolved.. pf + vimage = "kernel crash" problem was also reported as a bug.. http://www.freebsd.org/cgi/query-pr.cgi?pr=143808&cat= Regards, Onur. On 2/26/2010 8:18 PM, Lorenzo Perone wrote: > > Hello, > > Just encountered a panic when starting pf (/etc/rc.d/pf start) on a > FreeBSD benjamin 8.0-STABLE > > uname -a > > FreeBSD 8.0-STABLE #0: Fri Feb 26 18:33:44 UTC 2010 > root@benjamin:/usr/obj/usr/src/sys/BYTESATWORK_R8_INTEL_DEBUG amd64 > > the system is a Dell PowerEdge R300 with bge interfaces, 16 GB RAM > (dmesg attached). > > Panic and trace remote console screenshots: > > http://lorenzo.yellowspace.net/R300_pfctl_panic.gif > http://lorenzo.yellowspace.net/R300_pfctl_panic_trace.gif > > Excerpt transcript: > > panic: > > Fatal trap 12: page fault while in kernel mode > current process = 1302 > Stopped at pfil_head_get+0x41 movq 0x28(%rcx),%rdx > > trace: > > pfil_head_get() at pfil_head_get+0x41 > pfioctl() at pfioctl+0x3351 > devfs_ioctl_f() at devfs_ioctl_f+0x71 > kern_ioctl() at kern_ioctl+0xe4 > ioctl() at ioctl+0xed > syscall() at syscall+0x1e7 > Xfast_syscall() at Xfast_syscall+0xe1 > > While I was just planning to experiment with VIMAGE, and it is not > required for production (I'm aware of the message of it being > experimental...), I thought it might be useful to report it. Please > send me a note if I should file a pr. > > The panic does not occur with the same kernel compiled without options > VIMAGE. > > Note that the dmesg is from the system booted with the kernel without > VIMAGE, that's why it doesn't contain the warning. > > big Regards to all the team, > > Lorenzo > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-jail@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-jail > To unsubscribe, send any mail to "freebsd-jail-unsubscribe@freebsd.org" Onur BEKTAS Sistem Yöneticisi / System Administrator TÜBITAK ULAKBIM From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 21:43:55 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89A35106566C for ; Fri, 26 Feb 2010 21:43:55 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 0E1F88FC0C for ; Fri, 26 Feb 2010 21:43:54 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1QLhL6o027385; Fri, 26 Feb 2010 22:43:22 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 3DA8024; Fri, 26 Feb 2010 22:43:21 +0100 (CET) Date: Fri, 26 Feb 2010 22:43:20 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Daniel Braniss Message-Id: <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.26.213629 Cc: stable@freebsd.org, Willem Jan Withagen , Jack Vogel , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? (was: em0 freezes on ZFS server) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 21:43:55 -0000 On Fri, 26 Feb 2010 22:09:32 +0200 Daniel Braniss wrote about Re: mbuf leakage with nfs/zfs? (was: em0 freezes on ZFS server) : DB> > Furthermore I found this via Google: DB> > . This did not help, I still see the same problem. DB> I'll have to do some packet snooping to check if it's TCP or UDP nfs DB> traffic, since some of the clients are Linux ... I have Linux clients, too. Some use tcp, some udp. DB> > 2264/1321/3585 mbufs in use (current/cache/total) DB> > 1239/1017/2256/65000 mbuf clusters in use (current/cache/total/max) DB> > 1239/809 mbuf+clusters out of packet secondary zone in use DB> > (current/cache) DB> > but the uptime is only 12min so far. In some hours I'll know for DB> > certain if this patch has anything to do with the problem. It did not help. In the meantime the values read 20555/1465/22020 mbufs in use (current/cache/total) 19529/1029/20558/65000 mbuf clusters in use (current/cache/total/max) 19529/823 mbuf+clusters out of packet secondary zone in use (current/cache) I created a little graph here: . y-axis are the total mbuf clusters, x-axis in minutes. The flat part in the upper right corner is a 10min-interval when I had stopped nfsd. DB> at the moment there is not much activity, but if you check the latest DB> plot.ps you will see that the bottom is slowly increasing, so my bet DB> is that there must be some leakage! There certainly is. I wonder when this came in and why it has gone unnoticed so far. Probably not all people serving nfs from zfs see this, or this would have popped up earlier. Maybe the Linux clients are somehow triggering the issue? Or did it start with the import of zvol version 14? Unfortunately I have upgraded my pool, so I cannot easily go back to 8-REL to test this (otoh, I need a stable server quite urgently). cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 21:47:01 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC4C1106567C for ; Fri, 26 Feb 2010 21:47:01 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 1787B8FC2B for ; Fri, 26 Feb 2010 21:47:00 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1QLkSWk027444; Fri, 26 Feb 2010 22:46:30 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id E5F0F24; Fri, 26 Feb 2010 22:46:28 +0100 (CET) Date: Fri, 26 Feb 2010 22:46:28 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Daniel Braniss Message-Id: <20100226224628.c7d9e356.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.26.213629 Cc: stable@freebsd.org, Willem Jan Withagen , Jack Vogel , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? (was: em0 freezes on ZFS server) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 21:47:01 -0000 On Fri, 26 Feb 2010 22:09:32 +0200 Daniel Braniss wrote about Re: mbuf leakage with nfs/zfs? (was: em0 freezes on ZFS server) : DB> at the moment there is not much activity, but if you check the latest DB> plot.ps you will see that the bottom is slowly increasing, so my bet DB> is that there must be some leakage! BTW: I filed a PR for this: cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 22:12:44 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2EBF1106564A for ; Fri, 26 Feb 2010 22:12:44 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id B30228FC24 for ; Fri, 26 Feb 2010 22:12:43 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 459AE153433; Fri, 26 Feb 2010 23:12:41 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1pTvGWI-Dpg; Fri, 26 Feb 2010 23:12:39 +0100 (CET) Received: from [127.0.0.1] (unknown [192.168.10.212]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id F02FA15342F; Fri, 26 Feb 2010 23:12:38 +0100 (CET) Message-ID: <4B884757.9040001@digiware.nl> Date: Fri, 26 Feb 2010 23:12:39 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gerrit_K=FChn?= References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org, Jack Vogel , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 22:12:44 -0000 On 26-2-2010 22:43, Gerrit Khn wrote: > DB> I'll have to do some packet snooping to check if it's TCP or UDP nfs > DB> traffic, since some of the clients are Linux ... > > I have Linux clients, too. Some use tcp, some udp. I have Linux and FreeBSD clients running. The build system runs on Linux. All Linux's are UDP.... Also connect the build machine to the old 7.2/amd64/bge0/ufs machine, but there the count doesn't go over a few 1000 mbufs. > It did not help. In the meantime the values read > > 20555/1465/22020 mbufs in use (current/cache/total) > 19529/1029/20558/65000 mbuf clusters in use (current/cache/total/max) > 19529/823 mbuf+clusters out of packet secondary zone in use (current/cache) Mine are now: 41533/2402/43935 mbufs in use (current/cache/total) 41454/1572/43026/262144 mbuf clusters in use (current/cache/total/max) 39241/823 mbuf+clusters out of packet secondary zone in use (current/cache) > There certainly is. I wonder when this came in and why it has gone > unnoticed so far. Probably not all people serving nfs from zfs see this, > or this would have popped up earlier. Maybe the Linux clients are somehow > triggering the issue? Or did it start with the import of zvol version 14? > Unfortunately I have upgraded my pool, so I cannot easily go back to 8-REL > to test this (otoh, I need a stable server quite urgently). 'mmmm, I did set the zvol version this morning also to 14 but I think that I ran into trouble already when still running version 13. And the server was used as storage for the build system since the last 2 weeks. Uptil yesterday without much trouble. --WjW From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 22:31:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A9681065670 for ; Fri, 26 Feb 2010 22:31:47 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5638FC12 for ; Fri, 26 Feb 2010 22:31:46 +0000 (UTC) Received: by gya1 with SMTP id 1so335645gya.13 for ; Fri, 26 Feb 2010 14:31:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=LQ0o/DsCYFUtvW6f+VrDYZeCagKgf/VMd6FvtsQcU9U=; b=HumD9LhrYz65Ndh9R68hm3vOWb9leZwG4eL3RJaqCF1/xPpxvLabo4ivTKktGd85Xj SUduYp0ZKlfmmiwr1pP7ssFvcM73+575ms/3RUnjkfPYaAjdqG+W45e6QG1fUC/FszMS uGqIeMT4rYwX4nEHm3PvYs+eW9PJRMc9jxx/M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=T7lvdTbMRQnPWGjiQwM7bRmbjkCGR6Jw0VOdsetgXKxHA24Dry1kmiS6zB3HDxyUYj pt1NiCVQZ6me9PvVUfSMWbq5n9DfOhl/St6gJzzzMWsG1U0Zte98AXCzdnud672WuXET tbM9rZknJ6If5ghcGC//cni/JdKdlhfufp9qk= Received: by 10.101.206.22 with SMTP id i22mr1775002anq.36.1267223503770; Fri, 26 Feb 2010 14:31:43 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 14sm409781gxk.3.2010.02.26.14.31.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Feb 2010 14:31:41 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 26 Feb 2010 14:31:06 -0800 From: Pyun YongHyeon Date: Fri, 26 Feb 2010 14:31:06 -0800 To: Jonathan Chen Message-ID: <20100226223106.GN13807@michelle.cdnetworks.com> References: <20100202193616.GA16953@osiris.chen.org.nz> <20100202212029.GA5295@asgard.cs.uoi.gr> <20100203225255.GB14315@osiris.chen.org.nz> <20100204012503.GK5901@michelle.cdnetworks.com> <20100204020015.GA17301@osiris.chen.org.nz> <20100204192315.GN5901@michelle.cdnetworks.com> <20100204213137.GA9431@osiris.chen.org.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100204213137.GA9431@osiris.chen.org.nz> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: if_bge upload stalls repeatedly (Was: 8-STABLE outgoing scp stalling frequently) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 22:31:47 -0000 On Fri, Feb 05, 2010 at 10:31:37AM +1300, Jonathan Chen wrote: > On Thu, Feb 04, 2010 at 11:23:15AM -0800, Pyun YongHyeon wrote: > > On Thu, Feb 04, 2010 at 03:00:15PM +1300, Jonathan Chen wrote: > > > On Wed, Feb 03, 2010 at 05:25:03PM -0800, Pyun YongHyeon wrote: > [...] > > > > I'm not sure but recently added code to support TSO may cause the > > > > issue. Would you show me verbose boot output(only bge(4) related > > > > one)? > > > > > > bge0: mem 0xf1bf0000-0xf1bfffff irq 17 at device 0.0 on pci9 > > > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf1bf0000 > > > bge0: adjust device control 0x2000 -> 0x5000 > > > bge0: attempting to allocate 1 MSI vectors (1 supported) > > > bge0: using IRQ 258 for MSI > > > bge0: CHIP ID 0x0000a002; ASIC REV 0x0a; CHIP REV 0xa0; PCI-E > > > bge0: Disabling fastboot > > > bge0: Disabling fastboot > > > miibus0: on bge0 > > > bge0: bpf attached > > > bge0: Ethernet address: 00:1d:09:d2:d1:9e > > > bge0: [MPSAFE] > > > bge0: [FILTER] > > > bge0: Disabling fastboot > > > bge0: Disabling fastboot > > > bge0: link UP > > > > > > >To rule out possible TSO issue, disable TSO and try it > > > > again(#ifconfig bge0 -tso). Does it make any difference? > > > > > > Yup, it sure does! With a TSO disabled, my upload and download speeds > > > are pretty much symmetrical at a decent 10MB/s. > > > > > > > Hmm, that means TSO was broken on your controller. Because BCM5755 > > or newer controllers have no known TSO issues I don't know why the > > controller fails on TSO. Very recent controllers use new TSO format > > but I don't think your controller is one of them and FreeBSD has no > > support for these controllers anyway. > > Would you show me the output of "pciconf -lcv" of your bge(4) > > controller? > > bge0@pci0:9:0:0: class=0x020000 card=0x01fe1028 chip=0x167314e4 rev=0x02 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'NetXtreme BCM5755M Gigabit Ethernet PCIe' > class = network > subclass = ethernet > cap 01[48] = powerspec 3 supports D0 D3 current D0 > cap 03[50] = VPD > cap 09[58] = vendor (length 120) > cap 05[e8] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[d0] = PCI-Express 1 endpoint max data 128(128) link x1(x1) > > This is on a Dell Latitude D830 Laptop. > I committed a fix which disables TSO on BCM5755M. Still have no idea why it fails though. Thanks for reporting! From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 22:32:53 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B54201065670; Fri, 26 Feb 2010 22:32:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8E7478FC12; Fri, 26 Feb 2010 22:32:53 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o1QMWqRU012390; Fri, 26 Feb 2010 17:32:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o1QMWqWS012389; Fri, 26 Feb 2010 22:32:52 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 26 Feb 2010 22:32:52 GMT Message-Id: <201002262232.o1QMWqWS012389@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 22:32:53 -0000 TB --- 2010-02-26 21:24:43 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-02-26 21:24:43 - starting RELENG_8 tinderbox run for powerpc/powerpc TB --- 2010-02-26 21:24:43 - cleaning the object tree TB --- 2010-02-26 21:25:00 - cvsupping the source tree TB --- 2010-02-26 21:25:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/powerpc/powerpc/supfile TB --- 2010-02-26 21:25:29 - building world TB --- 2010-02-26 21:25:29 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-26 21:25:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-26 21:25:29 - TARGET=powerpc TB --- 2010-02-26 21:25:29 - TARGET_ARCH=powerpc TB --- 2010-02-26 21:25:29 - TZ=UTC TB --- 2010-02-26 21:25:29 - __MAKE_CONF=/dev/null TB --- 2010-02-26 21:25:29 - cd /src TB --- 2010-02-26 21:25:29 - /usr/bin/make -B buildworld >>> World build started on Fri Feb 26 21:25:29 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Feb 26 22:21:53 UTC 2010 TB --- 2010-02-26 22:21:53 - generating LINT kernel config TB --- 2010-02-26 22:21:53 - cd /src/sys/powerpc/conf TB --- 2010-02-26 22:21:53 - /usr/bin/make -B LINT TB --- 2010-02-26 22:21:53 - building LINT kernel TB --- 2010-02-26 22:21:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-26 22:21:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-26 22:21:53 - TARGET=powerpc TB --- 2010-02-26 22:21:53 - TARGET_ARCH=powerpc TB --- 2010-02-26 22:21:53 - TZ=UTC TB --- 2010-02-26 22:21:53 - __MAKE_CONF=/dev/null TB --- 2010-02-26 22:21:53 - cd /src TB --- 2010-02-26 22:21:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 26 22:21:53 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> export_syms awk -f /src/sys/conf/kmod_syms.awk atapicam.kld export_syms | xargs -J% objcopy % atapicam.kld ld -Bshareable -d -warn-common -o atapicam.ko atapicam.kld objcopy --strip-debug atapicam.ko ===> ath (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/powerpc/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mlongcall -fno-omit-frame-pointer -I/obj/powerpc/src/sys/LINT -msoft-float -mno-altivec -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/ath/../../dev/ath/if_ath.c /src/sys/modules/ath/../../dev/ath/if_ath.c: In function 'ath_key_alloc': /src/sys/modules/ath/../../dev/ath/if_ath.c:2240: error: expected expression before '/' token *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-02-26 22:32:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-02-26 22:32:52 - ERROR: failed to build lint kernel TB --- 2010-02-26 22:32:52 - 3311.13 user 560.65 system 4088.76 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-powerpc-powerpc.full From owner-freebsd-stable@FreeBSD.ORG Fri Feb 26 22:45:45 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 981AB106564A; Fri, 26 Feb 2010 22:45:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 71C288FC15; Fri, 26 Feb 2010 22:45:45 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o1QMjiWJ034003; Fri, 26 Feb 2010 17:45:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o1QMjinN034002; Fri, 26 Feb 2010 22:45:44 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 26 Feb 2010 22:45:44 GMT Message-Id: <201002262245.o1QMjinN034002@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [releng_8 tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2010 22:45:45 -0000 TB --- 2010-02-26 21:41:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-02-26 21:41:33 - starting RELENG_8 tinderbox run for sparc64/sparc64 TB --- 2010-02-26 21:41:33 - cleaning the object tree TB --- 2010-02-26 21:41:48 - cvsupping the source tree TB --- 2010-02-26 21:41:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/RELENG_8/sparc64/sparc64/supfile TB --- 2010-02-26 21:42:27 - building world TB --- 2010-02-26 21:42:27 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-26 21:42:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-26 21:42:27 - TARGET=sparc64 TB --- 2010-02-26 21:42:27 - TARGET_ARCH=sparc64 TB --- 2010-02-26 21:42:27 - TZ=UTC TB --- 2010-02-26 21:42:27 - __MAKE_CONF=/dev/null TB --- 2010-02-26 21:42:27 - cd /src TB --- 2010-02-26 21:42:27 - /usr/bin/make -B buildworld >>> World build started on Fri Feb 26 21:42:28 UTC 2010 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Feb 26 22:33:52 UTC 2010 TB --- 2010-02-26 22:33:52 - generating LINT kernel config TB --- 2010-02-26 22:33:52 - cd /src/sys/sparc64/conf TB --- 2010-02-26 22:33:52 - /usr/bin/make -B LINT TB --- 2010-02-26 22:33:52 - building LINT kernel TB --- 2010-02-26 22:33:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-02-26 22:33:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-02-26 22:33:52 - TARGET=sparc64 TB --- 2010-02-26 22:33:52 - TARGET_ARCH=sparc64 TB --- 2010-02-26 22:33:52 - TZ=UTC TB --- 2010-02-26 22:33:52 - __MAKE_CONF=/dev/null TB --- 2010-02-26 22:33:52 - cd /src TB --- 2010-02-26 22:33:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 26 22:33:52 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> export_syms awk -f /src/sys/conf/kmod_syms.awk atapicam.kld export_syms | xargs -J% objcopy % atapicam.kld ld -Bshareable -d -warn-common -o atapicam.ko atapicam.kld objcopy --strip-debug atapicam.ko ===> ath (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I/src/sys/modules/ath/../../dev/ath -I/src/sys/modules/ath/../../dev/ath/ath_hal -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/sparc64/src/sys/LINT -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/ath/../../dev/ath/if_ath.c /src/sys/modules/ath/../../dev/ath/if_ath.c: In function 'ath_key_alloc': /src/sys/modules/ath/../../dev/ath/if_ath.c:2240: error: expected expression before '/' token *** Error code 1 Stop in /src/sys/modules/ath. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-02-26 22:45:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-02-26 22:45:44 - ERROR: failed to build lint kernel TB --- 2010-02-26 22:45:44 - 3187.37 user 550.32 system 3851.27 real http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8-sparc64-sparc64.full From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 01:06:55 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C7E7106566B; Sat, 27 Feb 2010 01:06:55 +0000 (UTC) (envelope-from jjrushford@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id DEE198FC0C; Sat, 27 Feb 2010 01:06:54 +0000 (UTC) Received: by pvg3 with SMTP id 3so237673pvg.13 for ; Fri, 26 Feb 2010 17:06:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=wlIxg9XgP1lRv1mGJeNGrtiqo+2kPgePdqiR63kd8TE=; b=iwnSLTfBySj6He9rp4/PKJW2cgLXxQOeUc1bmA/a+tcxxIOTOw7zYW1G4xaDwGQ+AL M16T7Sz/DgQ9Pi/StheuJw7tgOmVX8Nm2ydrtWYdToGO/4D1rzPMigGcFnjlTA+jRvyN TkkyJq4mKKHYmw2yqGM7k/qFKs1MkFPiZAmm8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=MnEJqeWyfdG2F4Dg9tgT3HPdIaAvCHNpH6E8DqhAtGU+/5tQIRYjq6truW0k/x6/2Q EmvJRpTtOUdIaYHq8c+Z8Pv2nU+XwMHbmjAdOMnIDma8NgeHTxVl/dE3BKUw98A5R6vs BFBxBFdLIjn8LvTqgFnkotAJ/E8Y5gcNm+KA8= Received: by 10.115.101.13 with SMTP id d13mr694095wam.2.1267232809652; Fri, 26 Feb 2010 17:06:49 -0800 (PST) Received: from ?192.168.1.72? (c-98-245-3-221.hsd1.co.comcast.net [98.245.3.221]) by mx.google.com with ESMTPS id 20sm556152pzk.11.2010.02.26.17.06.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Feb 2010 17:06:48 -0800 (PST) Message-ID: <4B887025.1040301@gmail.com> Date: Fri, 26 Feb 2010 18:06:45 -0700 From: "John J. Rushford" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Lorenzo Perone References: <1267172583.00223701.1267161002@10.7.7.3> <4B87BDB6.7020109@FreeBSD.org> <4B87DFBE.60008@yellowspace.net> In-Reply-To: <4B87DFBE.60008@yellowspace.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-stable@freebsd.org Subject: Re: Panic on 8-STABLE in mpt(4) on a DELL PowerEdge R300 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 01:06:55 -0000 Thanks very much Alexander, I'll test t the patch this weekend. John Lorenzo Perone wrote: > COOL! THANKS a LOT Alexander! > > Can't believe it. You post a panic at 11pm and get a patch at 1pm next > day...? You must be crazy! ;) > > Works for me. I patched against 8/stable. I'll be testing the machine > a bit more. But for now, no panics! > > I guess the patch should be committed soon, also because it's really > happening quite at beginning, without a RAC/ILO you're locked out > pretty fast, and mpt is used on many DELL/HP setups. > > while true ; do echo Thank You ; done > > Lorenzo > > On 26.02.10 13:25, Alexander Motin wrote: >> John J. Rushford wrote: >>> I'm running into the same problem, mpt(4) panic on FreeBSD 8-STABLE. >>> >>> I'm running FreeBSD 8.0-STABLE, the current kernel was cvsup'd and >>> built >>> @ January 14th, 2010. I cvsup'd tonight, 2/25/2010, and built a new >>> kernel. Attached is the panic when I tried to boot into single user >>> mode, I was able to boot up on the old kernel built on January 14th. >>> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 0; apic id = 00 >>> fault virtual address = 0x10 >>> fault code = supervisor read data, page not present >>> instruction pointer = 0x20:0xffffffff8019c4bd >>> stack pointer = 0x28:0xffffff80e81d5ba0 >>> frame pointer = 0x28:0xffffff80e81d5bd0 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 6 (mpt_raid0) >>> trap number = 12 >>> panic: page fault >> >> Attached patch should fix the problem. >> > > > From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 07:02:24 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EFFE2106564A for ; Sat, 27 Feb 2010 07:02:24 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 747338FC18 for ; Sat, 27 Feb 2010 07:02:24 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1R72KkD007668; Sat, 27 Feb 2010 08:02:22 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id B230D24; Sat, 27 Feb 2010 08:02:20 +0100 (CET) Date: Sat, 27 Feb 2010 08:02:20 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Willem Jan Withagen Message-Id: <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> In-Reply-To: <4B884757.9040001@digiware.nl> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.27.65126 Cc: stable@freebsd.org, Jack Vogel , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 07:02:25 -0000 On Fri, 26 Feb 2010 23:12:39 +0100 Willem Jan Withagen wrote about Re: mbuf leakage with nfs/zfs?: WJW> Mine are now: WJW> 41533/2402/43935 mbufs in use (current/cache/total) WJW> 41454/1572/43026/262144 mbuf clusters in use (current/cache/total/max) WJW> 39241/823 mbuf+clusters out of packet secondary zone in use WJW> (current/cache) 81492/2613/84105 mbufs in use (current/cache/total) 80467/2235/82702/128000 mbuf clusters in use (current/cache/total/max) 80458/822 mbuf+clusters out of packet secondary zone in use (current/cache) If I keep increasing the clusters, maybe I can make it over the weekend. :-) WJW> 'mmmm, I did set the zvol version this morning also to 14 but I think WJW> that I ran into trouble already when still running version 13. Ok, so this is possibly ruled out, too. Maybe the Linux clients do something weird? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 07:10:02 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB686106566B for ; Sat, 27 Feb 2010 07:10:02 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 6EA468FC16 for ; Sat, 27 Feb 2010 07:10:01 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1R79Tfd007797; Sat, 27 Feb 2010 08:09:30 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id E6F1D24; Sat, 27 Feb 2010 08:09:28 +0100 (CET) Date: Sat, 27 Feb 2010 08:09:28 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Willem Jan Withagen Message-Id: <20100227080928.e49cb82c.gerrit@pmp.uni-hannover.de> In-Reply-To: <4B884757.9040001@digiware.nl> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.27.70052 Cc: stable@freebsd.org, Jack Vogel , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 07:10:03 -0000 On Fri, 26 Feb 2010 23:12:39 +0100 Willem Jan Withagen wrote about Re: mbuf leakage with nfs/zfs?: WJW> > DB> I'll have to do some packet snooping to check if it's TCP or WJW> > DB> UDP nfs traffic, since some of the clients are Linux ... WJW> > I have Linux clients, too. Some use tcp, some udp. WJW> I have Linux and FreeBSD clients running. The build system runs on WJW> Linux. All Linux's are UDP.... Another shot in the dark: After upgrading the server, all my Linux clients hang with "stale nfs dir/file handle/whatever". I was not able to umount them (not even forcefully). I had to use either lazy forceful umount (-fl) or reboot. Some of these clients are still hanging around, because they are physically hard to access (clean room installs etc.). Maybe these clients still try to establish connections that eat up the buffers and never come back? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 07:24:12 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC956106564A for ; Sat, 27 Feb 2010 07:24:12 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4208FC0C for ; Sat, 27 Feb 2010 07:24:12 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NlH22-000AIE-Lx; Sat, 27 Feb 2010 09:24:10 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Gerrit =?ISO-8859-1?Q?K=FChn?= In-reply-to: <20100227080928.e49cb82c.gerrit@pmp.uni-hannover.de> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080928.e49cb82c.gerrit@pmp.uni-hannover.de> Comments: In-reply-to Gerrit =?ISO-8859-1?Q?K=FChn?= message dated "Sat, 27 Feb 2010 08:09:28 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Feb 2010 09:24:10 +0200 From: Daniel Braniss Message-ID: Cc: stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 07:24:13 -0000 > On Fri, 26 Feb 2010 23:12:39 +0100 Willem Jan Withagen > wrote about Re: mbuf leakage with nfs/zfs?: > > WJW> > DB> I'll have to do some packet snooping to check if it's TCP or > WJW> > DB> UDP nfs traffic, since some of the clients are Linux ... > > WJW> > I have Linux clients, too. Some use tcp, some udp. > > WJW> I have Linux and FreeBSD clients running. The build system runs on > WJW> Linux. All Linux's are UDP.... > > Another shot in the dark: > After upgrading the server, all my Linux clients hang with "stale nfs > dir/file handle/whatever". I was not able to umount them (not even > forcefully). I had to use either lazy forceful umount (-fl) or reboot. Some > of these clients are still hanging around, because they are physically > hard to access (clean room installs etc.). Maybe these clients still try to > establish connections that eat up the buffers and never come back? I doubt it, but here is another shot: are we all running samba? I'm asking because the lock manager keeps dying and ... cheers, danny PS: I dropped Jack from the CC, I think em is innocent :-) From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 08:24:06 2010 Return-Path: Delivered-To: FreeBSD-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D70671065672 for ; Sat, 27 Feb 2010 08:24:06 +0000 (UTC) (envelope-from alexs@ulgsm.ru) Received: from mail.ulgsm.ru (skuns.ulgsm.ru [93.93.136.26]) by mx1.freebsd.org (Postfix) with ESMTP id 812408FC08 for ; Sat, 27 Feb 2010 08:24:05 +0000 (UTC) Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id 39D0D398A6 for ; Sat, 27 Feb 2010 11:24:00 +0300 (MSK) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.gsm900.net X-Spam-Level: X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from mail.ulgsm.ru (localhost [127.0.0.1]) by mail.ulgsm.ru (Postfix) with ESMTP id 1D935398A5 for ; Sat, 27 Feb 2010 11:24:00 +0300 (MSK) Received: from mail.ulgsm.ru (bazar.gsm900.net [192.168.0.160]) by mail.ulgsm.ru (Postfix) with ESMTP id DF01A398A4 for ; Sat, 27 Feb 2010 11:23:59 +0300 (MSK) Date: Sat, 27 Feb 2010 11:23:59 +0300 From: alexs@ulgsm.ru To: FreeBSD-stable@freebsd.org Message-ID: <20100227082359.GA11868@mail.ulgsm.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Virus-Scanned: ClamAV using ClamSMTP Cc: Subject: Cannot write to nfsv4 share X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 08:24:06 -0000 I have the same trable as Richard Mace http://lists.freebsd.org/pipermail/freebsd-questions/2009-December/209334.html nfs server ]>uname -a FreeBSD bazar 8.0-STABLE FreeBSD 8.0-STABLE #0: Thu Feb 25 14:42:08 MSK 2010 In rc.conf: nfs_server_enable="YES" #nfs_server_flags="-u -t -n 16" nfsv4_server_enable="YES" nfsuserd_enable="YES" mountd_flags="-r" rpcbind_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" nfs_client_enable="YES" in exports: /exp/home -maproot=0:0 192.168.3.195 10.144.142.57 V4: /exp /exp/fbsd71 /exp/ports /exp/distfiles /exp/fbsd_src/7.2/src /exp/fbsd_src/8.0/src /exp/fbsd_src/stable/src ]>showmount -e Exports list on localhost: /exp/ports Everyone /exp/home 192.168.3.195 10.144.142.57 10.144.142.54 /exp/fbsd_src/stable/src Everyone /exp/fbsd_src/8.0/src Everyone /exp/fbsd_src/7.2/src Everyone /exp/fbsd71 Everyone /exp/distfiles Everyone On client ]>uname -a FreeBSD skuns.gsm900.net 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #2: Wed Jan 20 10:55:34 MSK 2010 in rc.conf: nfsuserd_enable="YES" nfscbd_enable="YES" nfs_client_enable="YES" rpc_lockd_enable="YES" rpc_statd_enable="YES" rpcbind_enable="YES" in fstab 10.144.140.160:/distfiles /exp/distfiles nfs rw,nfsv4,noauto 0 0 try to mount /exp/distfiles ]>mount /exp/distfiles ]> try to write ]>touch /exp/distfiles/t touch: /exp/distfiles/t: Permission denied ls and read files ok. p.s. showmount on server dosnt show clients when client has mounted share. -- alexs From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 08:57:35 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B7CA6106566B for ; Sat, 27 Feb 2010 08:57:35 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 035F68FC16 for ; Sat, 27 Feb 2010 08:57:34 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1R8v2lG010146; Sat, 27 Feb 2010 09:57:03 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id CA8E54F; Sat, 27 Feb 2010 09:57:02 +0100 (CET) Date: Sat, 27 Feb 2010 09:57:02 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Daniel Braniss Message-Id: <20100227095702.ffa01da8.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080928.e49cb82c.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.27.83923 Cc: stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 08:57:35 -0000 On Sat, 27 Feb 2010 09:24:10 +0200 Daniel Braniss wrote about Re: mbuf leakage with nfs/zfs? : DB> I doubt it, but here is another shot: DB> are we all running samba? I'm asking because the lock manager keeps DB> dying and ... Nope, no samba on my side. I am running lockd and statd on the server, but stoppeing them does not change anything. All clients are using option nolock anyway. DB> PS: I dropped Jack from the CC, I think em is innocent :-) Yes, good idea. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 09:14:58 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A76BD106566C for ; Sat, 27 Feb 2010 09:14:58 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 52C418FC15 for ; Sat, 27 Feb 2010 09:14:58 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NlIlE-000B4U-Fz; Sat, 27 Feb 2010 11:14:56 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Gerrit =?ISO-8859-1?Q?K=FChn?= In-reply-to: <20100227095702.ffa01da8.gerrit@pmp.uni-hannover.de> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080928.e49cb82c.gerrit@pmp.uni-hannover.de> <20100227095702.ffa01da8.gerrit@pmp.uni-hannover.de> Comments: In-reply-to Gerrit =?ISO-8859-1?Q?K=FChn?= message dated "Sat, 27 Feb 2010 09:57:02 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Feb 2010 11:14:56 +0200 From: Daniel Braniss Message-ID: Cc: stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 09:14:58 -0000 > On Sat, 27 Feb 2010 09:24:10 +0200 Daniel Braniss > wrote about Re: mbuf leakage with nfs/zfs? : > > DB> I doubt it, but here is another shot: > DB> are we all running samba? I'm asking because the lock manager keeps > DB> dying and ... > > Nope, no samba on my side. I am running lockd and statd on the server, but > stoppeing them does not change anything. All clients are using option > nolock anyway. > it was a shot in the dark. anyways, I am running tests on an 'unused' server, only me using it to 'make world' and it's leaking. cheers, danny From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 10:16:53 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE6811065672 for ; Sat, 27 Feb 2010 10:16:53 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 367468FC16 for ; Sat, 27 Feb 2010 10:16:52 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1RAGJJb012178; Sat, 27 Feb 2010 11:16:20 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 8984524; Sat, 27 Feb 2010 11:16:19 +0100 (CET) Date: Sat, 27 Feb 2010 11:16:18 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Daniel Braniss Message-Id: <20100227111618.df9d29fb.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080928.e49cb82c.gerrit@pmp.uni-hannover.de> <20100227095702.ffa01da8.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.27.100328 Cc: stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 10:16:53 -0000 On Sat, 27 Feb 2010 11:14:56 +0200 Daniel Braniss wrote about Re: mbuf leakage with nfs/zfs? : DB> anyways, I am running tests on an 'unused' server, only me using it to DB> 'make world' DB> and it's leaking. Hm, I've got a server with 8-PRE from somewhen in Nov09 that is serving nfs from zfs fine and shows no leakage... cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 10:26:04 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB3D01065674 for ; Sat, 27 Feb 2010 10:26:04 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 850878FC18 for ; Sat, 27 Feb 2010 10:26:04 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NlJs2-000BZi-5A; Sat, 27 Feb 2010 12:26:02 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Gerrit =?ISO-8859-1?Q?K=FChn?= In-reply-to: <20100227111618.df9d29fb.gerrit@pmp.uni-hannover.de> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080928.e49cb82c.gerrit@pmp.uni-hannover.de> <20100227095702.ffa01da8.gerrit@pmp.uni-hannover.de> <20100227111618.df9d29fb.gerrit@pmp.uni-hannover.de> Comments: In-reply-to Gerrit =?ISO-8859-1?Q?K=FChn?= message dated "Sat, 27 Feb 2010 11:16:18 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Feb 2010 12:26:02 +0200 From: Daniel Braniss Message-ID: Cc: stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 10:26:04 -0000 > On Sat, 27 Feb 2010 11:14:56 +0200 Daniel Braniss > wrote about Re: mbuf leakage with nfs/zfs? : > > DB> anyways, I am running tests on an 'unused' server, only me using it to > DB> 'make world' > DB> and it's leaking. > > Hm, I've got a server with 8-PRE from somewhen in Nov09 that is serving > nfs from zfs fine and shows no leakage... > > > cu > Gerrit the binary search has started! sorry, have to go know :-) [realy], but should be back in a couple of hours, let me know if you managed to pin it down, else I can continue. danny From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 10:38:15 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6FC6106566C for ; Sat, 27 Feb 2010 10:38:15 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 242788FC19 for ; Sat, 27 Feb 2010 10:38:14 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1RAbhh4012688; Sat, 27 Feb 2010 11:37:44 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 36C3A24; Sat, 27 Feb 2010 11:37:43 +0100 (CET) Date: Sat, 27 Feb 2010 11:37:42 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Daniel Braniss Message-Id: <20100227113742.9fdecd42.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080928.e49cb82c.gerrit@pmp.uni-hannover.de> <20100227095702.ffa01da8.gerrit@pmp.uni-hannover.de> <20100227111618.df9d29fb.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.27.102419 Cc: stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 10:38:15 -0000 On Sat, 27 Feb 2010 12:26:02 +0200 Daniel Braniss wrote about Re: mbuf leakage with nfs/zfs? : DB> > Hm, I've got a server with 8-PRE from somewhen in Nov09 that is DB> > serving nfs from zfs fine and shows no leakage... DB> the binary search has started! DB> sorry, have to go know :-) [realy], but should be back in a couple of DB> hours, let me know if you managed to pin it down, else I can continue. Sorry, but I cannot do much over the weekend. Both the machine with leakage and the one without are in production (and about 40km apart from each other and away from my home :-). I still wonder if there are more circumstances needed to provoke this problem. I really doubt that this would have gone unnoticed for weeks or even months if it only takes some nfs-server serving from zfs storage and some client to see it. What does the client in your test setup look like? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 12:27:18 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0ECF106564A for ; Sat, 27 Feb 2010 12:27:18 +0000 (UTC) (envelope-from spil.oss@googlemail.com) Received: from mail-pz0-f182.google.com (mail-pz0-f182.google.com [209.85.222.182]) by mx1.freebsd.org (Postfix) with ESMTP id AB06E8FC0C for ; Sat, 27 Feb 2010 12:27:18 +0000 (UTC) Received: by pzk12 with SMTP id 12so1650709pzk.14 for ; Sat, 27 Feb 2010 04:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=bme73TlU5FmwgKJTy9/Cy7xOoz5wtxSEicddHDlxpAo=; b=APzNwWchHmimCMtp0VMXy+hJB/me3ODhppi/xJEn9NeH4UEXYGabhCxdukfmMojkSN dBL3sr7uTUGktWnQIlw61kb/hmdAerpVWSwIQtQ4aFbif/O850EpELGAbogjBGmwou18 ++KIxfJLt7Qw+4GcKiVBOaxsromIZs1HY/ehQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=PcPbgzIEFLyYdt3mtuWhg+yydoAGs2Wi2aQMqzpLsfKuZVEYTfac/1DCvNVbmUgXJD Dw5U1rldqem47dfEBOKTGmbrItyptCQbvr8QJJb1mMDW9LEa5MCvsCb5qshr3Ifb2q9k mRCxKyaztGvGVoU0CE6R184wesTi+xAczLAgw= MIME-Version: 1.0 Received: by 10.141.100.20 with SMTP id c20mr992749rvm.143.1267273629266; Sat, 27 Feb 2010 04:27:09 -0800 (PST) Date: Sat, 27 Feb 2010 13:27:09 +0100 Message-ID: <5fbf03c21002270427s74d0f067gb76cfe10c2794121@mail.gmail.com> From: Spil Oss To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: FreeBSD-8.0 802.11n support with ath X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 12:27:18 -0000 Hi All, Got myself an Atheros AR5416 card to upgrade my HostAP to Wireless-N speed. Somehow I can't find a way to convince the driver to go into 11n mode # ifconfig wlan0 mode 11b # ifconfig wlan0 mode 11g # ifconfig wlan0 mode 11n ifconfig: SIOCSIFMEDIA (media): Device not configured # uname -a FreeBSD server.example.org 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #1: Thu Jan 14 16:35:41 UTC 2010 root@:/usr/obj/usr/src/sys/SERVER80 i386 # dmesg | grep ath ath0: mem 0xfcfd0000-0xfcfdffff irq 9 at device 3.0 on pci1 ath0: [ITHREAD] ath0: AR5416 mac 13.10 RF2133 phy 8.1 kernel was compiled with options AH_SUPPORT_AR5416 The man-page for ifconfig specifies only 11a, 11b and 11g as modes. The part is functioning fine in 11g mode. Am I missing something obvious or is Wireless-N support not fully implemented yet? Kind regards, Spil. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 12:43:09 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F18971065670 for ; Sat, 27 Feb 2010 12:43:09 +0000 (UTC) (envelope-from bschmidt@mx.techwires.net) Received: from mx.techwires.net (mx.techwires.net [IPv6:2001:4d88:100f:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 94B2A8FC0C for ; Sat, 27 Feb 2010 12:43:09 +0000 (UTC) Received: by mx.techwires.net (Postfix, from userid 1001) id 435E11AA43; Sat, 27 Feb 2010 13:43:08 +0100 (CET) Date: Sat, 27 Feb 2010 13:43:08 +0100 From: Bernhard Schmidt To: spil.oss@gmail.com Message-ID: <20100227124308.GA28213@mx.techwires.net> References: <5fbf03c21002270427s74d0f067gb76cfe10c2794121@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5fbf03c21002270427s74d0f067gb76cfe10c2794121@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD-8.0 802.11n support with ath X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 12:43:10 -0000 On Sat, Feb 27, 2010 at 01:27:09PM +0100, Spil Oss wrote: > Hi All, > > Got myself an Atheros AR5416 card to upgrade my HostAP to Wireless-N speed. > > Somehow I can't find a way to convince the driver to go into 11n mode > > # ifconfig wlan0 mode 11b > # ifconfig wlan0 mode 11g > # ifconfig wlan0 mode 11n > ifconfig: SIOCSIFMEDIA (media): Device not configured It's either mode 11na or mode 11ng. > The man-page for ifconfig specifies only 11a, 11b and 11g as modes. > The part is functioning fine in 11g mode. > > Am I missing something obvious or is Wireless-N support not fully > implemented yet? There is no rate control algo fuer 11n, afaik, you will only be able to use legacy rates. -- Bernhard From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 13:01:47 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 189461065676 for ; Sat, 27 Feb 2010 13:01:47 +0000 (UTC) (envelope-from spil.oss@googlemail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id E369C8FC17 for ; Sat, 27 Feb 2010 13:01:46 +0000 (UTC) Received: by pvg3 with SMTP id 3so372527pvg.13 for ; Sat, 27 Feb 2010 05:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=MtWwTFudtVDCSnFnr1vAvW53fFPfdbYiZKgKkWYvR8A=; b=s6Ugzww/lS+s4gC/DLKQPIH//NPFCFHeUwg8GXyxSixcphnYLFdA3VIp9O8vmIbx24 NJrLkZoFITt5eGHctJuHVcrCE2M8bejJl7rBLihJlHrIF0lBN+7t9a86mWkR750foJYP Y4GLbibbSf+Ckb95ujZo0mDdQgd268ew3VGPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=mlFhTks9JxRcmn7ttMgd+aYsTKkyMRerrWaiGK4K21vtltuH2+7zCApGgATSaPnbqw 4bsY6vme4l8oHSVvPmYbIJy4WvOBl9lFtvPneq8aORo3pabruDEmq2ouxc3oYU73D/Fe AVBEcRajHJX2kHh3xuSgjiBbijutYK/TIBWMc= MIME-Version: 1.0 Received: by 10.141.107.10 with SMTP id j10mr995053rvm.282.1267275701404; Sat, 27 Feb 2010 05:01:41 -0800 (PST) In-Reply-To: <20100227124308.GA28213@mx.techwires.net> References: <5fbf03c21002270427s74d0f067gb76cfe10c2794121@mail.gmail.com> <20100227124308.GA28213@mx.techwires.net> Date: Sat, 27 Feb 2010 14:01:41 +0100 Message-ID: <5fbf03c21002270501l2e388ec9tbdad684d38609861@mail.gmail.com> From: Spil Oss To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: FreeBSD-8.0 802.11n support with ath X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: spil.oss@gmail.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 13:01:47 -0000 Thanks for the confirmation! Is anything known re. a timeline for implementation of wireless-N? (8.1? 9.0?) Kind regards, Spil On Sat, Feb 27, 2010 at 1:43 PM, Bernhard Schmidt wrote: > On Sat, Feb 27, 2010 at 01:27:09PM +0100, Spil Oss wrote: >> Hi All, >> >> Got myself an Atheros AR5416 card to upgrade my HostAP to Wireless-N speed. >> >> Somehow I can't find a way to convince the driver to go into 11n mode >> >> # ifconfig wlan0 mode 11b >> # ifconfig wlan0 mode 11g >> # ifconfig wlan0 mode 11n >> ifconfig: SIOCSIFMEDIA (media): Device not configured > > It's either mode 11na or mode 11ng. > >> The man-page for ifconfig specifies only 11a, 11b and 11g as modes. >> The part is functioning fine in 11g mode. >> >> Am I missing something obvious or is Wireless-N support not fully >> implemented yet? > > There is no rate control algo fuer 11n, afaik, you will only be able to > use legacy rates. > > -- > Bernhard > From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 14:15:57 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 307C3106566B for ; Sat, 27 Feb 2010 14:15:57 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id B1D098FC08 for ; Sat, 27 Feb 2010 14:15:56 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 0734315342F; Sat, 27 Feb 2010 15:15:54 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpnaPXPtUUPU; Sat, 27 Feb 2010 15:15:51 +0100 (CET) Received: from [127.0.0.1] (unknown [192.168.10.212]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id BDE46153434; Sat, 27 Feb 2010 15:15:51 +0100 (CET) Message-ID: <4B892918.4080701@digiware.nl> Date: Sat, 27 Feb 2010 15:15:52 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gerrit_K=FChn?= References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org, Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 14:15:57 -0000 On 27-2-2010 8:02, Gerrit Khn wrote: > On Fri, 26 Feb 2010 23:12:39 +0100 Willem Jan Withagen > wrote about Re: mbuf leakage with nfs/zfs?: > > WJW> Mine are now: > WJW> 41533/2402/43935 mbufs in use (current/cache/total) > WJW> 41454/1572/43026/262144 mbuf clusters in use (current/cache/total/max) > WJW> 39241/823 mbuf+clusters out of packet secondary zone in use > WJW> (current/cache) > > 81492/2613/84105 mbufs in use (current/cache/total) > 80467/2235/82702/128000 mbuf clusters in use (current/cache/total/max) > 80458/822 mbuf+clusters out of packet secondary zone in use (current/cache) Over the night I only had rsync and FreeBSD nfs traffic. 45337/2828/48165 mbufs in use (current/cache/total) 44708/1902/46610/262144 mbuf clusters in use (current/cache/total/max) 44040/888 mbuf+clusters out of packet secondary zone in use (current/cache) I only have one Linux box runing Kubuntu 8.10, mounted UDP: (rw,udp,nolock,rsize=32768,wsize=32768,intr) Now runing ls -R on the remote file system only lets the mbufs slightly decrease.... But running something like 'find openembedded | xarg cat > /dev/null' Shows a steadily growing number of mbufs, and letting the system sit for 5 min. doesn't decrease the used mbufs 48438/3672/52110 mbufs in use (current/cache/total) 47757/3461/51218/262144 mbuf clusters in use (current/cache/total/max) 47406/850 mbuf+clusters out of packet secondary zone in use (current/cache) Doing this on another FreeBSD 7.2 client runs the mbufs up(max inc about 2000 mbuf), but within a few secs after the last file was fetched, the mbuf tab runs down to around to what is was before the command. Not shure where to go from here? I'm certainly not fluent enough in NFS to start interpreting a wireshark trace. --WjW From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 19:21:16 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 066461065670; Sat, 27 Feb 2010 19:21:16 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 7A01E8FC1B; Sat, 27 Feb 2010 19:21:09 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1RJL5oM028046; Sat, 27 Feb 2010 20:21:07 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id DF62624; Sat, 27 Feb 2010 20:21:05 +0100 (CET) Date: Sat, 27 Feb 2010 20:21:05 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Willem Jan Withagen Message-Id: <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> In-Reply-To: <4B892918.4080701@digiware.nl> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.27.190629 Cc: freebsd-fs@freebsd.org, stable@freebsd.org, Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 19:21:16 -0000 On Sat, 27 Feb 2010 15:15:52 +0100 Willem Jan Withagen wrote about Re: mbuf leakage with nfs/zfs?: WJW> > 81492/2613/84105 mbufs in use (current/cache/total) WJW> > 80467/2235/82702/128000 mbuf clusters in use WJW> > (current/cache/total/max) 80458/822 mbuf+clusters out of packet WJW> > secondary zone in use (current/cache) WJW> Over the night I only had rsync and FreeBSD nfs traffic. WJW> WJW> 45337/2828/48165 mbufs in use (current/cache/total) WJW> 44708/1902/46610/262144 mbuf clusters in use (current/cache/total/max) WJW> 44040/888 mbuf+clusters out of packet secondary zone in use WJW> (current/cache) After about 24h I now have 128320/2630/130950 mbufs in use (current/cache/total) 127294/1200/128494/512000 mbuf clusters in use (current/cache/total/max) 127294/834 mbuf+clusters out of packet secondary zone in use (current/cache) WJW> I only have one Linux box runing Kubuntu 8.10, mounted UDP: WJW> (rw,udp,nolock,rsize=32768,wsize=32768,intr) Hm, are you able to narrow this down? Does a single Linux client with tcp mount cause the same trouble? Or a FreeBSD client with udp? If it was only Linux clients with udp mounts or something like this, I could understand why it took some time to pop up. WJW> But running something like 'find openembedded | xarg cat > /dev/null' WJW> Shows a steadily growing number of mbufs, and letting the system sit WJW> for 5 min. doesn't decrease the used mbufs I still have several udp and tcp mounts by Linux clients on my Server, though most of them are probably stale now after the upgrade; and my buffers keep draining... WJW> Doing this on another FreeBSD 7.2 client runs the mbufs up(max inc WJW> about 2000 mbuf), but within a few secs after the last file was WJW> fetched, the mbuf tab runs down to around to what is was before the WJW> command. FreeBSD client with udp mount? Then it is either Linux client with udp or all Linux clients triggering this leakage. I doubt that this is the case with all Linux clients, this would have caused more trouble earlier. WJW> Not shure where to go from here? I'm certainly not fluent enough in WJW> NFS to start interpreting a wireshark trace. Nor do I. I already wrote Rick Macklem an Email on Friday, but so far only got back an automated reply stating he is on "permanent vacation". I guess we need him or one of the other nfs guys to get this fixed. Could you try a single Linux client with tcp mount in the meantime? This would tell us if Linux clients as such are causing the issue, or if it is only Linux with udp mount. cu Gerrit P.S.: I cc'ed freebsd-fs because my PR went there. From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 19:27:19 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 724A81065676; Sat, 27 Feb 2010 19:27:19 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id E22548FC18; Sat, 27 Feb 2010 19:27:18 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1RJQ7iS028144; Sat, 27 Feb 2010 20:26:08 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 6C06E24; Sat, 27 Feb 2010 20:26:07 +0100 (CET) Date: Sat, 27 Feb 2010 20:26:06 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Daniel Braniss Message-Id: <20100227202606.67df5a59.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080928.e49cb82c.gerrit@pmp.uni-hannover.de> <20100227095702.ffa01da8.gerrit@pmp.uni-hannover.de> <20100227111618.df9d29fb.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.27.190629 Cc: freebsd-fs@freebsd.org, stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 19:27:19 -0000 On Sat, 27 Feb 2010 12:26:02 +0200 Daniel Braniss wrote about Re: mbuf leakage with nfs/zfs? : DB> > Hm, I've got a server with 8-PRE from somewhen in Nov09 that is DB> > serving nfs from zfs fine and shows no leakage... DB> the binary search has started! After considering the last email from Willem: My 8-PRE server does not have udp Linux clients, only Linux with tcp. If indeed Linux with udp is causing the problem, it may very well even be in 8-PRE, and I just did not see it so far. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 19:36:50 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 973F51065675 for ; Sat, 27 Feb 2010 19:36:50 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id 34D658FC08 for ; Sat, 27 Feb 2010 19:36:49 +0000 (UTC) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1NlST1-000Jhg-KZ; Sat, 27 Feb 2010 21:36:47 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Gerrit =?ISO-8859-1?Q?K=FChn?= In-reply-to: <20100227202606.67df5a59.gerrit@pmp.uni-hannover.de> References: <4B86F384.3010308@digiware.nl> <2a41acea1002251459v40e8c6ddxd0437decbada4594@mail.gmail.com> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080928.e49cb82c.gerrit@pmp.uni-hannover.de> <20100227095702.ffa01da8.gerrit@pmp.uni-hannover.de> <20100227111618.df9d29fb.gerrit@pmp.uni-hannover.de> <20100227202606.67df5a59.gerrit@pmp.uni-hannover.de> Comments: In-reply-to Gerrit =?ISO-8859-1?Q?K=FChn?= message dated "Sat, 27 Feb 2010 20:26:06 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 27 Feb 2010 21:36:47 +0200 From: Daniel Braniss Message-ID: Cc: freebsd-fs@freebsd.org, stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 19:36:50 -0000 > On Sat, 27 Feb 2010 12:26:02 +0200 Daniel Braniss > wrote about Re: mbuf leakage with nfs/zfs? : > > > DB> > Hm, I've got a server with 8-PRE from somewhen in Nov09 that is > DB> > serving nfs from zfs fine and shows no leakage... > > DB> the binary search has started! > > After considering the last email from Willem: My 8-PRE server does not > have udp Linux clients, only Linux with tcp. If indeed Linux with udp is > causing the problem, it may very well even be in 8-PRE, and I just did not > see it so far. I have been running for the last few hours, 8-rel, and the only client is another 8-stable, furthermore, no ZFS, just plain UFS, and the leak is there! I am now trying 8-rc2 but will check in the morning, it is after all saturday night :-) danny From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 19:38:23 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DFF3E106566C for ; Sat, 27 Feb 2010 19:38:22 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by mx1.freebsd.org (Postfix) with ESMTP id 8683D8FC18 for ; Sat, 27 Feb 2010 19:38:22 +0000 (UTC) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta02.westchester.pa.mail.comcast.net with comcast id n5rf1d00117dt5G527eNTw; Sat, 27 Feb 2010 19:38:22 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta13.westchester.pa.mail.comcast.net with comcast id n7eM1d0073S48mS3Z7eMNP; Sat, 27 Feb 2010 19:38:22 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id BB85B1E301A; Sat, 27 Feb 2010 11:38:19 -0800 (PST) Date: Sat, 27 Feb 2010 11:38:19 -0800 From: Jeremy Chadwick To: Gerrit =?iso-8859-1?Q?K=FChn?= Message-ID: <20100227193819.GA60576@icarus.home.lan> References: <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, stable@freebsd.org, Willem Jan Withagen Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 19:38:23 -0000 On Sat, Feb 27, 2010 at 08:21:05PM +0100, Gerrit Khn wrote: > On Sat, 27 Feb 2010 15:15:52 +0100 Willem Jan Withagen > wrote about Re: mbuf leakage with nfs/zfs?: > > WJW> > 81492/2613/84105 mbufs in use (current/cache/total) > WJW> > 80467/2235/82702/128000 mbuf clusters in use > WJW> > (current/cache/total/max) 80458/822 mbuf+clusters out of packet > WJW> > secondary zone in use (current/cache) > > WJW> Over the night I only had rsync and FreeBSD nfs traffic. > WJW> > WJW> 45337/2828/48165 mbufs in use (current/cache/total) > WJW> 44708/1902/46610/262144 mbuf clusters in use (current/cache/total/max) > WJW> 44040/888 mbuf+clusters out of packet secondary zone in use > WJW> (current/cache) > > After about 24h I now have > > 128320/2630/130950 mbufs in use (current/cache/total) > 127294/1200/128494/512000 mbuf clusters in use (current/cache/total/max) > 127294/834 mbuf+clusters out of packet secondary zone in use (current/cache) Follow-up regarding my server statistics shown here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055458.html I just pulled the statistics on the same servers for comparison (then vs. now). RELENG_7 amd64 2010/01/09 -- primary HTTP, pri DNS, SSH server + ZFS 515/1930/2445 mbufs in use (current/cache/total) 512/540/1052/25600 mbuf clusters in use (current/cache/total/max) 1152K/6394K/7547K bytes allocated to network (current/cache/total) RELENG_7 amd64 2010/01/11 -- secondary DNS, MySQL, dev box + ZFS 514/1151/1665 mbufs in use (current/cache/total) 512/504/1016/25600 mbuf clusters in use (current/cache/total/max) 1152K/2203K/3356K bytes allocated to network (current/cache/total) RELENG_7 i386 2008/04/19 -- secondary HTTP, SSH server, heavy memory I/O 515/820/1335 mbufs in use (current/cache/total) 513/631/1144/25600 mbuf clusters in use (current/cache/total/max) 1154K/2615K/3769K bytes allocated to network (current/cache/total) RELENG_8 amd64 2010/02/02 -- central backups + NFS+ZFS-based filer 1572/3423/4995 mbufs in use (current/cache/total) 1539/3089/4628/25600 mbuf clusters in use (current/cache/total/max) 3471K/7449K/10920K bytes allocated to network (current/cache/total) So, not much difference. I should point out that the NFS+ZFS-based filer doesn't actually do its backups using NFS; it uses rsnapshot (rsync) over SSH. There is intense network I/O during backup time though, depending on how much data there is to back up. The NFS mounts (on the clients) are only used to provide a way for people to get access to their nightly backups in a convenient way; it isn't used very heavily. I can do something NFS-intensive on any of the above clients if people want me to kind of testing. Possibly an rsync with a source of the NFS mount and a destination of the local disk would be a good test? Let me know if anyone's interested in me testing that. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 20:29:42 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AF9C106566B for ; Sat, 27 Feb 2010 20:29:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 250F78FC17 for ; Sat, 27 Feb 2010 20:29:42 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B9B0D46B09; Sat, 27 Feb 2010 15:29:41 -0500 (EST) Date: Sat, 27 Feb 2010 20:29:41 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: spil.oss@gmail.com In-Reply-To: <5fbf03c21002270501l2e388ec9tbdad684d38609861@mail.gmail.com> Message-ID: References: <5fbf03c21002270427s74d0f067gb76cfe10c2794121@mail.gmail.com> <20100227124308.GA28213@mx.techwires.net> <5fbf03c21002270501l2e388ec9tbdad684d38609861@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD-8.0 802.11n support with ath X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 20:29:42 -0000 On Sat, 27 Feb 2010, Spil Oss wrote: > Thanks for the confirmation! > > Is anything known re. a timeline for implementation of wireless-N? (8.1? > 9.0?) I know that Rui Paulo is working on this actively; I've added him to the CC line as I'm not sure if he follows freebsd-stable. Robert N M Watson Computer Laboratory University of Cambridge > > Kind regards, > > Spil > > On Sat, Feb 27, 2010 at 1:43 PM, Bernhard Schmidt > wrote: >> On Sat, Feb 27, 2010 at 01:27:09PM +0100, Spil Oss wrote: >>> Hi All, >>> >>> Got myself an Atheros AR5416 card to upgrade my HostAP to Wireless-N speed. >>> >>> Somehow I can't find a way to convince the driver to go into 11n mode >>> >>> # ifconfig wlan0 mode 11b >>> # ifconfig wlan0 mode 11g >>> # ifconfig wlan0 mode 11n >>> ifconfig: SIOCSIFMEDIA (media): Device not configured >> >> It's either mode 11na or mode 11ng. >> >>> The man-page for ifconfig specifies only 11a, 11b and 11g as modes. >>> The part is functioning fine in 11g mode. >>> >>> Am I missing something obvious or is Wireless-N support not fully >>> implemented yet? >> >> There is no rate control algo fuer 11n, afaik, you will only be able to >> use legacy rates. >> >> -- >> Bernhard >> > _______________________________________________ > 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 Feb 27 21:00:11 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ACE6106564A; Sat, 27 Feb 2010 21:00:11 +0000 (UTC) (envelope-from ltning@anduin.net) Received: from mail.anduin.net (mail.anduin.net [213.225.74.249]) by mx1.freebsd.org (Postfix) with ESMTP id 715578FC17; Sat, 27 Feb 2010 21:00:10 +0000 (UTC) Received: from [212.62.248.146] (helo=[192.168.2.198]) by mail.anduin.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NlTL6-000FX0-Mg; Sat, 27 Feb 2010 21:32:40 +0100 Mime-Version: 1.0 (Apple Message framework v1077) From: =?iso-8859-1?Q?Eirik_=D8verby?= In-Reply-To: <20100227193819.GA60576@icarus.home.lan> Date: Sat, 27 Feb 2010 21:32:39 +0100 Message-Id: References: <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> <20100227193819.GA60576@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1077) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, stable@freebsd.org, =?iso-8859-1?Q?Gerrit_K=FChn?= , Willem Jan Withagen Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 21:00:11 -0000 On 27. feb. 2010, at 20.38, Jeremy Chadwick wrote: > On Sat, Feb 27, 2010 at 08:21:05PM +0100, Gerrit K=FChn wrote: >> On Sat, 27 Feb 2010 15:15:52 +0100 Willem Jan Withagen = >> wrote about Re: mbuf leakage with nfs/zfs?: >>=20 >> WJW> > 81492/2613/84105 mbufs in use (current/cache/total) >> WJW> > 80467/2235/82702/128000 mbuf clusters in use >> WJW> > (current/cache/total/max) 80458/822 mbuf+clusters out of = packet >> WJW> > secondary zone in use (current/cache) >>=20 >> WJW> Over the night I only had rsync and FreeBSD nfs traffic. >> WJW>=20 >> WJW> 45337/2828/48165 mbufs in use (current/cache/total) >> WJW> 44708/1902/46610/262144 mbuf clusters in use = (current/cache/total/max) >> WJW> 44040/888 mbuf+clusters out of packet secondary zone in use >> WJW> (current/cache) >>=20 >> After about 24h I now have >>=20 >> 128320/2630/130950 mbufs in use (current/cache/total) >> 127294/1200/128494/512000 mbuf clusters in use = (current/cache/total/max) >> 127294/834 mbuf+clusters out of packet secondary zone in use = (current/cache) >=20 > Follow-up regarding my server statistics shown here: >=20 > = http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055458.htm= l >=20 > I just pulled the statistics on the same servers for comparison (then > vs. now). >=20 > RELENG_7 amd64 2010/01/09 -- primary HTTP, pri DNS, SSH server + ZFS >=20 > 515/1930/2445 mbufs in use (current/cache/total) > 512/540/1052/25600 mbuf clusters in use = (current/cache/total/max) > 1152K/6394K/7547K bytes allocated to network = (current/cache/total) >=20 > RELENG_7 amd64 2010/01/11 -- secondary DNS, MySQL, dev box + ZFS >=20 > 514/1151/1665 mbufs in use (current/cache/total) > 512/504/1016/25600 mbuf clusters in use = (current/cache/total/max) > 1152K/2203K/3356K bytes allocated to network = (current/cache/total) >=20 > RELENG_7 i386 2008/04/19 -- secondary HTTP, SSH server, heavy memory = I/O >=20 > 515/820/1335 mbufs in use (current/cache/total) > 513/631/1144/25600 mbuf clusters in use = (current/cache/total/max) > 1154K/2615K/3769K bytes allocated to network = (current/cache/total) >=20 > RELENG_8 amd64 2010/02/02 -- central backups + NFS+ZFS-based filer >=20 > 1572/3423/4995 mbufs in use (current/cache/total) > 1539/3089/4628/25600 mbuf clusters in use = (current/cache/total/max) > 3471K/7449K/10920K bytes allocated to network = (current/cache/total) >=20 > So, not much difference. >=20 > I should point out that the NFS+ZFS-based filer doesn't actually do = its > backups using NFS; it uses rsnapshot (rsync) over SSH. There is = intense > network I/O during backup time though, depending on how much data = there > is to back up. The NFS mounts (on the clients) are only used to = provide > a way for people to get access to their nightly backups in a = convenient > way; it isn't used very heavily. >=20 > I can do something NFS-intensive on any of the above clients if people > want me to kind of testing. Possibly an rsync with a source of the = NFS > mount and a destination of the local disk would be a good test? Let = me > know if anyone's interested in me testing that. I've had a discussion with some folks on this for a while. I can easily = reproduce this situation by mounting a FreeBSD ZFS filesystem via = NFS-UDP from an OpenBSD machine. Telling the OpenBSD machine to use TCP = instead of UDP makes the problem go away. Other FreeBSD systems mounting the same share, either using UDP or TCP, = does not cause the problem to show up. A patch was suggested by Rick Macklem, but that did not solve the issue: = http://lists.freebsd.org/pipermail/freebsd-current/2009-December/014181.ht= ml /Eirik > --=20 > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | >=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 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 21:31:58 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97062106566B; Sat, 27 Feb 2010 21:31:58 +0000 (UTC) (envelope-from dan.naumov@gmail.com) Received: from mail-yx0-f177.google.com (mail-yx0-f177.google.com [209.85.210.177]) by mx1.freebsd.org (Postfix) with ESMTP id ECB328FC1A; Sat, 27 Feb 2010 21:31:57 +0000 (UTC) Received: by yxe7 with SMTP id 7so367088yxe.3 for ; Sat, 27 Feb 2010 13:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=b2Yuaigc6fz2bdvIRNBqRLf4M3zNhVSQFqEnYz3ewro=; b=MjD+u3zw2bHtBQmOb05uopYs1bqXAvwpDUUX+hmS15kh32wZCnDkpz8CVMBVueejGI pSJgqxkdSbjNftUqVc4VQLsYc179Nf7owIiNJGj1IgCuPy8Vqjd+6XhST+YuWbyHSXeH C5CytuJ2OnsgamR3sJTgY7q3+bNIv2NCiJ4PE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rM+tivnS1NZ26nptw0sUBEV6QopdkDMKzl9UPcj3fg4NyHxs1IT7NsRT9yPs1TAVyx mwcdcT+7l8c+bkEcxDwZuSIdgjTqWw4U+JdGCoVIY0Sw57FAlrVGOps0xdhW+hOe2IZv oh9qcC26iaQMGbJYR2YQQx8su9frZLg8n2gYY= MIME-Version: 1.0 Received: by 10.101.172.3 with SMTP id z3mr3225792ano.192.1267306310832; Sat, 27 Feb 2010 13:31:50 -0800 (PST) Date: Sat, 27 Feb 2010 23:31:50 +0200 Message-ID: From: Dan Naumov To: FreeBSD-STABLE Mailing List , freebsd-questions@freebsd.org, freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Subject: Re: 8.0-RELEASE/amd64 - full ZFS install - low read and write disk performance (fixed) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 21:31:58 -0000 Hello folks A few weeks ago, there was a discussion started by me regarding abysmal read/write performance using ZFS mirror on 8.0-RELEASE. I was using an Atom 330 system with 2GB ram and it was pointed out to me that my problem was most likely having both disks attached to a PCI SIL3124 controller, switching to the new AHCI drivers didn't help one bit. To reitirate, here are the Bonnie and DD numbers I got on that system: =================================================== Atom 330 / 2gb ram / Intel board + PCI SIL3124 -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 8192 21041 53.5 22644 19.4 13724 12.8 25321 48.5 43110 14.0 143.2 3.3 dd if=/dev/zero of=/root/test1 bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 143.878615 secs (29851325 bytes/sec) (28,4 mb/s) =================================================== Since then, I switched the exact same disks to a different system: Atom D510 / 4gb ram / Supermicro X7SPA-H / ICH9R controller (native). Here are the updated results: -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 8192 30057 68.7 50965 36.4 27236 21.3 33317 58.0 53051 14.3 172.4 3.2 dd if=/dev/zero of=/root/test1 bs=1M count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 54.977978 secs (78121594 bytes/sec) (74,5 mb/s) =================================================== Write performance now seems to have increased by a factor of 2 to 3 and is now definately in line with the expected performance of the disks in question (cheap 2TB WD20EADS with 32mb cache). Thanks to everyone who has offered help and tips! - Sincerely, Dan Naumov From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 21:38:11 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42598106566C; Sat, 27 Feb 2010 21:38:11 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id B96028FC12; Sat, 27 Feb 2010 21:38:10 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1RLc2nV031058; Sat, 27 Feb 2010 22:38:03 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 5E92924; Sat, 27 Feb 2010 22:38:02 +0100 (CET) Date: Sat, 27 Feb 2010 22:38:01 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Eirik =?ISO-8859-1?Q?=D8verby?= Message-Id: <20100227223801.15aa657b.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> <20100227193819.GA60576@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.27.212132 Cc: freebsd-fs@freebsd.org, stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 21:38:11 -0000 On Sat, 27 Feb 2010 21:32:39 +0100 Eirik =D8verby wrote about Re: mbuf leakage with nfs/zfs?: E> I've had a discussion with some folks on this for a while. I can easily E> reproduce this situation by mounting a FreeBSD ZFS filesystem via E> NFS-UDP from an OpenBSD machine. Telling the OpenBSD machine to use TCP E> instead of UDP makes the problem go away. So we see this problem with udp clients from OpenBSD and Linux. E> Other FreeBSD systems mounting the same share, either using UDP or TCP, E> does not cause the problem to show up. As Daniel reported he saw the problem with FBSD 8-stable: Which version was the FBSD-client that worked for you with udp? E> A patch was suggested by Rick Macklem, but that did not solve the issue: E> http://lists.freebsd.org/pipermail/freebsd-current/2009-December/014181.= html Yeah, I also found and tried this on Friday - unfortunately without any success, the leakage is still there. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 21:39:50 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84E111065670; Sat, 27 Feb 2010 21:39:50 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id F2AF28FC12; Sat, 27 Feb 2010 21:39:49 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1RLdItd031072; Sat, 27 Feb 2010 22:39:19 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 4307F24; Sat, 27 Feb 2010 22:39:18 +0100 (CET) Date: Sat, 27 Feb 2010 22:39:17 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Daniel Braniss Message-Id: <20100227223917.6d5d0238.gerrit@pmp.uni-hannover.de> In-Reply-To: References: <4B86F384.3010308@digiware.nl> <4B8795B1.4020006@digiware.nl> <20100226120339.GB17798@icarus.home.lan> <20100226133138.d47dd080.gerrit@pmp.uni-hannover.de> <20100226134429.041ea6f2.gerrit@pmp.uni-hannover.de> <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080928.e49cb82c.gerrit@pmp.uni-hannover.de> <20100227095702.ffa01da8.gerrit@pmp.uni-hannover.de> <20100227111618.df9d29fb.gerrit@pmp.uni-hannover.de> <20100227202606.67df5a59.gerrit@pmp.uni-hannover.de> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.27.213052 Cc: freebsd-fs@freebsd.org, stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 21:39:50 -0000 On Sat, 27 Feb 2010 21:36:47 +0200 Daniel Braniss wrote about Re: mbuf leakage with nfs/zfs? : DB> I have been running for the last few hours, 8-rel, and the only client DB> is another DB> 8-stable, furthermore, no ZFS, just plain UFS, and the leak is there! Mounted via udp, not tcp, I guess...?! DB> I am now trying 8-rc2 but will check in the morning, it is after all DB> saturday night :-) Same here. :-) cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 21:40:47 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D2EB1065679; Sat, 27 Feb 2010 21:40:47 +0000 (UTC) (envelope-from ltning@anduin.net) Received: from mail.anduin.net (mail.anduin.net [213.225.74.249]) by mx1.freebsd.org (Postfix) with ESMTP id E8C688FC25; Sat, 27 Feb 2010 21:40:46 +0000 (UTC) Received: from [212.62.248.146] (helo=[192.168.2.198]) by mail.anduin.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1NlUOy-000L0L-9Q; Sat, 27 Feb 2010 22:40:44 +0100 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Eirik_=D8verby?= In-Reply-To: <20100227223801.15aa657b.gerrit@pmp.uni-hannover.de> Date: Sat, 27 Feb 2010 22:40:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0C3ADBC6-66EA-4316-9366-1814D27B3A87@anduin.net> References: <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> <20100227193819.GA60576@icarus.home.lan> <20100227223801.15aa657b.gerrit@pmp.uni-hannover.de> To: =?iso-8859-1?Q?Gerrit_K=FChn?= X-Mailer: Apple Mail (2.1077) Cc: freebsd-fs@freebsd.org, stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 21:40:47 -0000 On 27. feb. 2010, at 22.38, Gerrit K=FChn wrote: > On Sat, 27 Feb 2010 21:32:39 +0100 Eirik =D8verby = wrote > about Re: mbuf leakage with nfs/zfs?: >=20 > E> I've had a discussion with some folks on this for a while. I can = easily > E> reproduce this situation by mounting a FreeBSD ZFS filesystem via > E> NFS-UDP from an OpenBSD machine. Telling the OpenBSD machine to use = TCP > E> instead of UDP makes the problem go away. >=20 > So we see this problem with udp clients from OpenBSD and Linux. I have not had the opportunity to test with Linux or anything else. = Could try from Windows, but not sure I want to get my hands THAT dirty. > E> Other FreeBSD systems mounting the same share, either using UDP or = TCP, > E> does not cause the problem to show up. >=20 > As Daniel reported he saw the problem with FBSD 8-stable: Which = version > was the FBSD-client that worked for you with udp? 7.1, 7.2, 8.0-RCsomething and 8.0-RELEASE - no problems with either. > E> A patch was suggested by Rick Macklem, but that did not solve the = issue: > E> = http://lists.freebsd.org/pipermail/freebsd-current/2009-December/014181.ht= ml >=20 > Yeah, I also found and tried this on Friday - unfortunately without = any > success, the leakage is still there. >=20 >=20 > cu > Gerrit >=20 From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 21:43:37 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A47A0106566C; Sat, 27 Feb 2010 21:43:37 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id 29BD48FC12; Sat, 27 Feb 2010 21:43:36 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1RLhXwC031167; Sat, 27 Feb 2010 22:43:34 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 9F56324; Sat, 27 Feb 2010 22:43:33 +0100 (CET) Date: Sat, 27 Feb 2010 22:43:33 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Jeremy Chadwick Message-Id: <20100227224333.5bee38ac.gerrit@pmp.uni-hannover.de> In-Reply-To: <20100227193819.GA60576@icarus.home.lan> References: <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> <20100227193819.GA60576@icarus.home.lan> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.27.213052 Cc: freebsd-fs@freebsd.org, stable@freebsd.org, Willem Jan Withagen Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 21:43:37 -0000 On Sat, 27 Feb 2010 11:38:19 -0800 Jeremy Chadwick wrote about Re: mbuf leakage with nfs/zfs?: JC> I should point out that the NFS+ZFS-based filer doesn't actually do its JC> backups using NFS; it uses rsnapshot (rsync) over SSH. There is JC> intense network I/O during backup time though, depending on how much JC> data there is to back up. The NFS mounts (on the clients) are only JC> used to provide a way for people to get access to their nightly JC> backups in a convenient way; it isn't used very heavily. That's rather similar to my situation, I would say. Most traffic goes via rsync, nfs only gives access to home dirs, which are not intensively used. JC> I can do something NFS-intensive on any of the above clients if people JC> want me to kind of testing. Possibly an rsync with a source of the NFS JC> mount and a destination of the local disk would be a good test? Let me JC> know if anyone's interested in me testing that. >From the last emails I would say we get most out of it by comparing tcp and udp clients to make sure this happens only with udp (and it is still not quite clear to me if it also happens with a FBSD client using udp). OTOH it would be great if someone with the ability to actually fix something in the nfs code could get in this discussion to guide us to do the debugging needed to do so. cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 21:47:00 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62C18106566C; Sat, 27 Feb 2010 21:47:00 +0000 (UTC) (envelope-from gerrit@pmp.uni-hannover.de) Received: from mrelay1.uni-hannover.de (mrelay1.uni-hannover.de [130.75.2.106]) by mx1.freebsd.org (Postfix) with ESMTP id D997D8FC22; Sat, 27 Feb 2010 21:46:59 +0000 (UTC) Received: from www.pmp.uni-hannover.de (www.pmp.uni-hannover.de [130.75.117.2]) by mrelay1.uni-hannover.de (8.14.2/8.14.2) with ESMTP id o1RLkqai031235; Sat, 27 Feb 2010 22:46:53 +0100 Received: from pmp.uni-hannover.de (theq.pmp.uni-hannover.de [130.75.117.4]) by www.pmp.uni-hannover.de (Postfix) with SMTP id 6185524; Sat, 27 Feb 2010 22:46:52 +0100 (CET) Date: Sat, 27 Feb 2010 22:46:51 +0100 From: Gerrit =?ISO-8859-1?Q?K=FChn?= To: Eirik =?ISO-8859-1?Q?=D8verby?= Message-Id: <20100227224651.d2102fca.gerrit@pmp.uni-hannover.de> In-Reply-To: <0C3ADBC6-66EA-4316-9366-1814D27B3A87@anduin.net> References: <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> <20100227193819.GA60576@icarus.home.lan> <20100227223801.15aa657b.gerrit@pmp.uni-hannover.de> <0C3ADBC6-66EA-4316-9366-1814D27B3A87@anduin.net> Organization: Albert-Einstein-Institut (MPI =?ISO-8859-1?Q?f=FCr?= Gravitationsphysik & IGP =?ISO-8859-1?Q?Universit=E4t?= Hannover) X-Mailer: Sylpheed 2.4.2 (GTK+ 2.10.12; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.27.213325 Cc: freebsd-fs@freebsd.org, stable@freebsd.org, Willem Jan Withagen , Jeremy Chadwick Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 21:47:00 -0000 On Sat, 27 Feb 2010 22:40:43 +0100 Eirik =D8verby wrote about Re: mbuf leakage with nfs/zfs?: E> > So we see this problem with udp clients from OpenBSD and Linux. E> I have not had the opportunity to test with Linux or anything else. I guess all others who reported so far (including me) had Linux on the client side. E> Could try from Windows, but not sure I want to get my hands THAT dirty. :-))) E> > As Daniel reported he saw the problem with FBSD 8-stable: Which E> > version was the FBSD-client that worked for you with udp? E> 7.1, 7.2, 8.0-RCsomething and 8.0-RELEASE - no problems with either. Daniel, are you sure you had the leakage with 8-stable? Eirik, do you have the opportunity to try 8-stable with udp? cu Gerrit From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 21:53:03 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 327D81065670; Sat, 27 Feb 2010 21:53:03 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id B68EB8FC1A; Sat, 27 Feb 2010 21:53:02 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id E7817153433; Sat, 27 Feb 2010 22:53:00 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m54sQjbHQmCK; Sat, 27 Feb 2010 22:52:59 +0100 (CET) Received: from [127.0.0.1] (unknown [192.168.10.212]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPSA id 024BF15342F; Sat, 27 Feb 2010 22:52:59 +0100 (CET) Message-ID: <4B89943C.70704@digiware.nl> Date: Sat, 27 Feb 2010 22:53:00 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Eirik_=D8verby?= References: <20100226141754.86ae5a3f.gerrit@pmp.uni-hannover.de> <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> <20100227193819.GA60576@icarus.home.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org, stable@freebsd.org, =?ISO-8859-1?Q?=FChn?= , Jeremy Chadwick , =?ISO-8859-1?Q?Gerrit_K?= Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 21:53:03 -0000 On 27-2-2010 21:32, Eirik verby wrote: > I've had a discussion with some folks on this for a while. I can easily > reproduce this situation by mounting a FreeBSD ZFS filesystem via > NFS-UDP from an OpenBSD machine. Telling the OpenBSD machine to use TCP > instead of UDP makes the problem go away. > > Other FreeBSD systems mounting the same share, either using UDP or TCP, > does not cause the problem to show up. > > A patch was suggested by Rick Macklem, but that did not solve the issue: > http://lists.freebsd.org/pipermail/freebsd-current/2009-December/014181.html I concur. Everything in my network is now on TCP, and there is no mbuf leakage. I just don't get over the 5500 mark, no matter what I throw at it. I do feel that TCP is not as well performing on a local net with Linux, hence the choice for UDP. But TCP is workable as next best. --WjW From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 22:03:12 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD53D106566B for ; Sat, 27 Feb 2010 22:03:12 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id BBF2B8FC1D for ; Sat, 27 Feb 2010 22:03:12 +0000 (UTC) Received: from omta08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by qmta11.emeryville.ca.mail.comcast.net with comcast id n9Uc1d0010FhH24AB9zix5; Sat, 27 Feb 2010 21:59:42 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta08.emeryville.ca.mail.comcast.net with comcast id nA3B1d00H3S48mS8UA3CbN; Sat, 27 Feb 2010 22:03:12 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 992AE1E301A; Sat, 27 Feb 2010 14:03:10 -0800 (PST) Date: Sat, 27 Feb 2010 14:03:10 -0800 From: Jeremy Chadwick To: rwatson@freebsd.org Message-ID: <20100227220310.GA65110@icarus.home.lan> References: <20100226174021.8feadad9.gerrit@pmp.uni-hannover.de> <20100226224320.8c4259bf.gerrit@pmp.uni-hannover.de> <4B884757.9040001@digiware.nl> <20100227080220.ac6a2e4d.gerrit@pmp.uni-hannover.de> <4B892918.4080701@digiware.nl> <20100227202105.f31cbef7.gerrit@pmp.uni-hannover.de> <20100227193819.GA60576@icarus.home.lan> <4B89943C.70704@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B89943C.70704@digiware.nl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-fs@freebsd.org, stable@freebsd.org, Gerrit =?iso-8859-1?Q?K=FChn?= , Willem Jan Withagen , Eirik =?iso-8859-1?Q?=D8verby?= Subject: Re: mbuf leakage with nfs/zfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 22:03:12 -0000 On Sat, Feb 27, 2010 at 10:53:00PM +0100, Willem Jan Withagen wrote: > On 27-2-2010 21:32, Eirik verby wrote: > >I've had a discussion with some folks on this for a while. I can easily > >reproduce this situation by mounting a FreeBSD ZFS filesystem via > >NFS-UDP from an OpenBSD machine. Telling the OpenBSD machine to use TCP > >instead of UDP makes the problem go away. > > > >Other FreeBSD systems mounting the same share, either using UDP or TCP, > >does not cause the problem to show up. > > > >A patch was suggested by Rick Macklem, but that did not solve the issue: > >http://lists.freebsd.org/pipermail/freebsd-current/2009-December/014181.html > > I concur. > Everything in my network is now on TCP, and there is no mbuf leakage. > I just don't get over the 5500 mark, no matter what I throw at it. > > I do feel that TCP is not as well performing on a local net with Linux, > hence the choice for UDP. But TCP is workable as next best. I'm pulling in Robert Watson, who has some familiarity with the UDP stack/code in FreeBSD. I'm not sure he'll be a sufficient source of knowledge for this specific issue since it appears (?) to be specific to NFS; Rick Macklem would be a better choice, but as reported, he's MIA. Robert, are you aware of any changes or implementation issues which might cause excessive (read: leaking) mbuf use under UDP-based NFS? Do you know of a way folks could determine the source of the leak, either via DDB or while the system is live? -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-stable@FreeBSD.ORG Sat Feb 27 22:50:56 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26C93106564A for ; Sat, 27 Feb 2010 22:50:56 +0000 (UTC) (envelope-from erik@malcolm.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id 0424E8FC13 for ; Sat, 27 Feb 2010 22:50:55 +0000 (UTC) Received: from malcolm.berkeley.edu (localhost [127.0.0.1]) by malcolm.berkeley.edu (8.14.3/8.13.8m1) with ESMTP id o1RMotse075040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Feb 2010 14:50:55 -0800 (PST) (envelope-from erik@malcolm.berkeley.edu) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.95.3 at malcolm.berkeley.edu Received: (from erik@localhost) by malcolm.berkeley.edu (8.14.3/8.13.3/Submit) id o1RMosPF075039; Sat, 27 Feb 2010 14:50:54 -0800 (PST) (envelope-from erik) Date: Sat, 27 Feb 2010 14:50:54 -0800 From: Erik Klavon To: Pyun YongHyeon Message-ID: <20100227225054.GA74976@malcolm.berkeley.edu> References: <20100218213213.GD11675@michelle.cdnetworks.com> <20100218215039.GK55307@zxy.spb.ru> <20100219001913.GE11675@michelle.cdnetworks.com> <20100219055129.GL55307@zxy.spb.ru> <20100219122415.GR55307@zxy.spb.ru> <20100219190359.GJ11675@michelle.cdnetworks.com> <20100219191103.GT55307@zxy.spb.ru> <20100219200647.GK11675@michelle.cdnetworks.com> <20100219201359.GU55307@zxy.spb.ru> <20100219211201.GL11675@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100219211201.GL11675@michelle.cdnetworks.com> User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (malcolm.berkeley.edu [127.0.0.1]); Sat, 27 Feb 2010 14:50:55 -0800 (PST) Cc: Nick Rogers , stable@freebsd.org, Slawa Olhovchenkov Subject: Re: trap 12: page fault while in kernel mode on 8.0-RELEASE (possibly bge(4) related) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2010 22:50:56 -0000 Hi Pyun, On Fri, Feb 19, 2010 at 01:12:01PM -0800, Pyun YongHyeon wrote: > Since I don't have BCM5704 hardware it's hard to find which > revision may affect to this issue. Could you narrow down which > revision number started showing the issue? I have BCM5704 hardware (Tyan S2882 system board). I am seeing kernel panics very similar to those described in this thread on this hardware. pciconf -lcv output below. If you'd like access to this hardware I can arrange it; please contact me off list. Erik bge0@pci0:2:9:0: class=0x020000 card=0x164414e4 chip=0x164814e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' class = network subclass = ethernet cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit bge1@pci0:2:9:1: class=0x020000 card=0x164414e4 chip=0x164814e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' class = network subclass = ethernet cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction cap 01[48] = powerspec 2 supports D0 D3 current D0 cap 03[50] = VPD cap 05[58] = MSI supports 8 messages, 64 bit