From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 02:09:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61649106564A for ; Sun, 19 Jul 2009 02:09:32 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 377378FC08 for ; Sun, 19 Jul 2009 02:09:32 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 9AB323B93C1; Sat, 18 Jul 2009 22:09:31 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sat, 18 Jul 2009 22:09:31 -0400 X-Sasl-enc: Qybq6gWiiCzGKGoKWCgXQNoTWPZww82Y+Vlt8Ml+LmON 1247969371 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 2FE8BA089; Sat, 18 Jul 2009 22:09:31 -0400 (EDT) Message-ID: <4A628056.60009@incunabulum.net> Date: Sun, 19 Jul 2009 03:09:26 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Pieter de Goeje References: <200907182056.47383.pieter@degoeje.nl> In-Reply-To: <200907182056.47383.pieter@degoeje.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Sending multicast datagrams broken (regression) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 02:09:32 -0000 Pieter de Goeje wrote: > I'm observing that multicast IPv4 UDP datagrams sent from the latest 8.0-BETA2 > are being discarded. The code below used to work with 7.2. > Can you tcpdump this? This may be related to an llentry related regression which Xin Li recently posted a patch for, it appears that layer 2 addresses for multicast/broadcast datagrams may be broken in 8.0-BETA2. Although I haven't tested this myself since committing the SSM code around April, where I observed such traffic was correct. thanks BMS From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 07:24:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9554F106566B for ; Sun, 19 Jul 2009 07:24:28 +0000 (UTC) (envelope-from sweetnavelorange@gmail.com) Received: from mail-px0-f200.google.com (mail-px0-f200.google.com [209.85.216.200]) by mx1.freebsd.org (Postfix) with ESMTP id 6B39A8FC14 for ; Sun, 19 Jul 2009 07:24:28 +0000 (UTC) (envelope-from sweetnavelorange@gmail.com) Received: by pxi38 with SMTP id 38so1240275pxi.3 for ; Sun, 19 Jul 2009 00:24:28 -0700 (PDT) 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 :content-transfer-encoding; bh=F/eX0rUmLMMWOI+NIKOsZ7fX0dg5oN7GETrH3v9u4VI=; b=JGOq5LhyzlxhisILDipMHV2h/iWaY+QOB6wiAU3SGZtEQpdLKs1jN5WIOByFWlT6t9 TQAzsUJTjLRM8Vt7Xxyg1beMV8crY2vjZjX62WTWO6Jp6fO5si9c3mfBSPttO0Vfmwe5 +HkWnHbqDGBnVPwxeHZcePPLHHxMTHKq84+M4= 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:content-transfer-encoding; b=bNkdPB4cSqFb/XIlHqEBEfsPG7ocTpDAeRUpxdpHQlbxGofT1bIifqOTtfqwOCK1IR Q2qaFt85KfLqeMTxSJ6RVrPxnrMqyWc1+tp6covc/AIR1YC8tQdtEip/i4i46BYVhbDq +UcUJkqF++xd4sCQfwha1r7Ona6QW6fr1fVYA= MIME-Version: 1.0 Received: by 10.114.182.9 with SMTP id e9mr3758905waf.22.1247988268140; Sun, 19 Jul 2009 00:24:28 -0700 (PDT) In-Reply-To: <4A608F26.8050904@errno.com> References: <4A608F26.8050904@errno.com> Date: Sun, 19 Jul 2009 19:24:28 +1200 Message-ID: From: James Butler To: Sam Leffler , current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: ipw in 8.0-BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 07:24:28 -0000 2009/7/18 Sam Leffler : > James Butler wrote: >> >> Greetings >> >> Are ipw devices expected to work in 8.0-BETA1? Mine apparently >> doesn't. I have updated my rc.conf according to the instructions in >> UPDATING relating to wlans; the wlan0 interface is created, but >> wpa_supplicant doesn't associate. >> >> I ask after seeing this snippet from the list back in March: >> >>> Unfortunately the vap conversion of the ipw driver never was completed >>> (it's the only driver in the tree that is known to be totally broken). >>> =C2=A0It's on >>> my todo list for 8.0 but would happily defer to someone else :). >> >> If the answer is yes, then I'll try a little harder. > > Sorry the driver never got fixed after conversion to vaps; it's on the 8.= 0 > TODO list. =C2=A0I'm not sure it's going to be fixed before 8.0. OK thanks for the reply, and TIA for whenever you're able to fix it. -James From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 07:55:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CFDB106564A; Sun, 19 Jul 2009 07:55:03 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id E26418FC0C; Sun, 19 Jul 2009 07:55:02 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id E6C6E33CB8; Sun, 19 Jul 2009 09:54:59 +0200 (SAST) Date: Sun, 19 Jul 2009 09:54:59 +0200 From: John Hay To: Tim Kientzle Message-ID: <20090719075459.GA31256@zibbi.meraka.csir.co.za> References: <4A615602.4090000@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A615602.4090000@freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: "'freebsd-current@freebsd.org'" Subject: Re: Joliet and release ISOs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 07:55:04 -0000 On Fri, Jul 17, 2009 at 09:56:34PM -0700, Tim Kientzle wrote: > Do we need Joliet extensions on the release ISOs? > > The reason I ask is a little involved: jkim@ recently > pointed out to me that tar in -CURRENT can no longer > extract symlinks from the release ISOs. > > I tracked this down to the fact that the release ISOs > have both Joliet and RockRidge extensions and tar now > supports (and actually prefers) Joliet extensions when > it sees them. Joliet doesn't support symlinks, so tar > doesn't see symlinks on disks with both kinds of extensions. > > There's a workaround that people can use for now: > tar xf image.iso --options=!joliet > disables the Joliet support. > > I'm curious whether removing the -J option from > /usr/src/release/*/mkisoimages.sh is an option. What is the reason for prefering Juliet in tar? Can't we just swap the preference? John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 08:17:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDADF106566C for ; Sun, 19 Jul 2009 08:17:14 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id A04888FC17 for ; Sun, 19 Jul 2009 08:17:14 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n6J8HE2D061335; Sun, 19 Jul 2009 01:17:14 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 4b8ditzrwtf8nazu6p8xd6y7aa; Sun, 19 Jul 2009 01:17:14 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A62D689.1050906@freebsd.org> Date: Sun, 19 Jul 2009 01:17:13 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090601 SeaMonkey/1.1.16 MIME-Version: 1.0 To: John Hay References: <4A615602.4090000@freebsd.org> <20090719075459.GA31256@zibbi.meraka.csir.co.za> In-Reply-To: <20090719075459.GA31256@zibbi.meraka.csir.co.za> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'freebsd-current@freebsd.org'" Subject: Re: Joliet and release ISOs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 08:17:15 -0000 John Hay wrote: > On Fri, Jul 17, 2009 at 09:56:34PM -0700, Tim Kientzle wrote: >> Do we need Joliet extensions on the release ISOs? >> >> The reason I ask is a little involved: jkim@ recently >> pointed out to me that tar in -CURRENT can no longer >> extract symlinks from the release ISOs. >> >> I tracked this down to the fact that the release ISOs >> have both Joliet and RockRidge extensions and tar now >> supports (and actually prefers) Joliet extensions when >> it sees them. Joliet doesn't support symlinks, so tar >> doesn't see symlinks on disks with both kinds of extensions. > > What is the reason for prefering Juliet in tar? Can't we > just swap the preference? Because of the way libarchive works internally coupled with basic differences in how Joliet and RockRidge information is stored, it turns out that libarchive has to decide whether or not to use the Joliet information before it can tell whether RockRidge information is available. So preferring RockRidge is actually quite difficult. I would like to change this, but it's going to be quite a while before I have enough time to work on it. Tim From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 11:05:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 410FC106566C for ; Sun, 19 Jul 2009 11:05:48 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id C61BE8FC16 for ; Sun, 19 Jul 2009 11:05:47 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:35503 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MSUCw-00028c-4F; Sun, 19 Jul 2009 13:05:32 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 7F096163D47; Sun, 19 Jul 2009 13:05:27 +0200 (CEST) Message-Id: <9472A71F-085D-4547-90FA-3FC56BAFE845@exscape.org> From: Thomas Backman To: McLone In-Reply-To: <451cb3010907181027q13d5c345w8962a648c7682ed8@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 19 Jul 2009 13:05:25 +0200 References: <451cb3010907181027q13d5c345w8962a648c7682ed8@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MSUCw-00028c-4F. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MSUCw-00028c-4F 3b815335621c374dfee2f9b879d5d99e Cc: freebsd-current@freebsd.org Subject: Re: [bug] ZFS zvol dev entry disappearing upon reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 11:05:48 -0000 On Jul 18, 2009, at 19:27, McLone wrote: > Hell Low. > > As downloading torrent files from many peers to ZFS > imposes fragmentation (and there's no way to defragment > ZFS volume - what a pity! How come now-a-days FS can > go like this?), i created zvol with UFS2 on it last time > i wanted to watch some old sci-fi. I had plans to > move sci-fi from UFS2/zvol to ZFS when it'll be complete, > but forgot it, and rebooted machine. After reboot > rtorrent said sci-fi is marked as complete, but it > can not find files. I wasn't surprised, as i haven't modified > my /etc/fstab, so i entered "mount /dev/zvol" and pressed > Tab in hope of tcsh (eek) autocomplete. > It just beeped on me. > I've done "ls /dev" and there was no directory there named zvol. > Then i've done "zfs list" and my zvol was there. > Puzzled, i've done "zfs snapshot" and then a little dance of > "zfs send | zfs recv" to a new volume. Now dev entries appeared > (both for newly created snapshot of an old zvol and for new zvol). > I rebooted, and there was no /dev/zvol again. > > I looked at my uname -v output (it was HEAD/amd64 from Jul 1) > and decided to update. Updating didn't solved this problem. > > Strangely, simple "zfs rename zpool/zvol zpool/newzvol" > cures this woe, but i think this is a bug. > > Steps to reproduce: > zfs create -V 1g zpool/zvol > [newfs /dev/zvol/zpool/zvol] > reboot > ls /dev > > Workaround: > zfs rename zpool/zvol zpool/newzvol > mount /dev/zvol/zpool/zvol /mnt Hmm, I did a quick test and was unable to reproduce. There are ALL the steps I took, i.e. I never mounted the fs's or anything. [root@chaos ~]# zfs create -V 1g tank/zvol [root@chaos ~]# zfs create -V 1g tank/zvol2 ## to test if the name "zvol" causes problems [root@chaos ~]# newfs /dev/zvol/tank/zvol /dev/zvol/tank/zvol: 1024.0MB (2097152 sectors) block size 16384, fragment size 2048 using 6 cylinder groups of 183.72MB, 11758 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376416, 752672, 1128928, 1505184, 1881440 [root@chaos ~]# newfs /dev/zvol/tank/zvol2 /dev/zvol/tank/zvol2: 1024.0MB (2097152 sectors) block size 16384, fragment size 2048 using 6 cylinder groups of 183.72MB, 11758 blks, 23552 inodes. super-block backups (for fsck -b #) at: 160, 376416, 752672, 1128928, 1505184, 1881440 [root@chaos ~]# ls -R /dev/z* /dev/zero /dev/zfs /dev/zvol: tank /dev/zvol/tank: zvol zvol2 [root@chaos ~]# reboot Connection to 192.168.1.10 closed by remote host. ---------------- [root@chaos ~]# uptime 1:04PM up 29 secs, 2 users, load averages: 0.87, 0.27, 0.10 [root@chaos ~]# ls -R /dev/z* /dev/zero /dev/zfs /dev/zvol: tank /dev/zvol/tank: zvol zvol2 Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 13:02:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E95E106566B; Sun, 19 Jul 2009 13:02:04 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id 89FC38FC16; Sun, 19 Jul 2009 13:02:03 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.43,229,1246831200"; d="scan'208";a="219092181" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 19 Jul 2009 15:02:01 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id B0AEF1B07E1; Sun, 19 Jul 2009 15:02:01 +0200 (CEST) Date: Sun, 19 Jul 2009 15:02:01 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: John Baldwin , Message-ID: In-Reply-To: <200907170901.31617.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Thomas Backman Subject: Re: core dumps being overwritten X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 13:02:04 -0000 you're right. i found this in one of my logs: savecore: unable to read from bounds, using 0 Expensive timeout(9) function: 0xc051b930(0xc0a22340) 0.013787226 s savecore: unable to read from bounds, using 0 savecore: reboot after panic: mutex ACPI global lock owned at /usr/src/sys/kern/kern_event.c:1758 Jul 16 00:22:20 otaku savecore: reboot after panic: mutex ACPI global lock owned at /usr/src/sys/kern/kern_event.c:1758 savecore: writing core to vmcore.0 Writing crash summary to /var/crash/core.txt.0. alex John Baldwin schrieb am 2009-07-17: > On Thursday 16 July 2009 4:04:17 am Alexander Best wrote: > > exactly. `cat /var/crash/bounds` => 2. > This can happen if you lose the 'bounds' file during a crash or if > that file > is corrupted in some other fashion. From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 13:19:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61DAD1065673 for ; Sun, 19 Jul 2009 13:19:36 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 162458FC1D for ; Sun, 19 Jul 2009 13:19:35 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MSWIf-0005y7-Ds for freebsd-current@freebsd.org; Sun, 19 Jul 2009 13:19:33 +0000 Received: from 93-138-105-230.adsl.net.t-com.hr ([93.138.105.230]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Jul 2009 13:19:33 +0000 Received: from ivoras by 93-138-105-230.adsl.net.t-com.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 19 Jul 2009 13:19:33 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Sun, 19 Jul 2009 15:19:14 +0200 Lines: 34 Message-ID: References: <20090717010813.03477b27.matheus@eternamente.info> <0a394f735684111014877d2b39783693.squirrel@cygnus.homeunix.com> <2fd30e75fbd3e231117ab9f2459f896b.squirrel@10.1.1.10> <066c4b53956bc62c3d6e089861ebddf7.squirrel@10.1.1.10> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3FE804198B540D5518295663" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 93-138-105-230.adsl.net.t-com.hr User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) In-Reply-To: <066c4b53956bc62c3d6e089861ebddf7.squirrel@10.1.1.10> X-Enigmail-Version: 0.96.0 Sender: news Subject: Re: gstripe problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 13:19:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3FE804198B540D5518295663 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Nenhum_de_Nos wrote: > I'd really like to hear on this: I just wiped out all disks data, delet= ed > all two partitions and recreated them. created another stripe using the= > same arguments as the other times but it keeps vanishing when I reboot.= > fresh 8-BETA2 and old pc in i386. what to do now ? give up ? Did you load geom_stripe.ko? --------------enig3FE804198B540D5518295663 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkpjHVIACgkQldnAQVacBcggmwCgyMSv1aUJFKE6BCf6U1Hz1N8A MbYAnRX384Ww1naOWBULR1pMZAIU07on =tJFR -----END PGP SIGNATURE----- --------------enig3FE804198B540D5518295663-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 14:10:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BDE11065672 for ; Sun, 19 Jul 2009 14:10:39 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id C4A498FC18 for ; Sun, 19 Jul 2009 14:10:38 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 84498 invoked from network); 19 Jul 2009 13:43:55 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 19 Jul 2009 13:43:55 -0000 Message-ID: <4A632310.60606@acm.poly.edu> Date: Sun, 19 Jul 2009 09:43:44 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.19 (X11/20090108) MIME-Version: 1.0 To: Patrick Lamaiziere References: <18510.213.150.228.38.1246864978.squirrel@mail.magicbooks.org> <20090706103602.394c463a@baby-jane.lamaiziere.net> In-Reply-To: <20090706103602.394c463a@baby-jane.lamaiziere.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Rene Schickbauer , freebsd-current@freebsd.org Subject: Re: RFC: powerd Patch & proposed future changes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 14:10:39 -0000 Patrick Lamaiziere wrote: > Le Mon, 6 Jul 2009 09:22:58 +0200 (CEST), > "Rene Schickbauer" a écrit : > > >> Hi! >> > > Hello, > > >> Yesterday i submitted a patch for powerd to set maximum allowed CPU >> speed for adaptive modes (to keep the system cool and using less >> power). >> >> PR: 136354 >> > > I would like an option to set the minimum allowed CPU speed, instead > the use of the sysctl debug.cpufreq.lowest. > A while ago, I wrote a patch that adds minimum and maximum frequencies to powerd (http://acm.poly.edu/~spawk/powerd/). It was written for and tested on 7.0, but I can update it for newer versions if there is any interest. >> Would it also make sense to have powerd run an (optional) user >> configureable script on ac state change? I'm thinking about things >> like dimming TFT backlight, on EEE PC turning of the webcam and so on. >> > > We can do this with devd. > > (my 0.42 euro) > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 14:19:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 241CA1065672 for ; Sun, 19 Jul 2009 14:19:41 +0000 (UTC) (envelope-from freebsd-current-local@be-well.ilk.org) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.5]) by mx1.freebsd.org (Postfix) with ESMTP id ED7E68FC27 for ; Sun, 19 Jul 2009 14:19:40 +0000 (UTC) (envelope-from freebsd-current-local@be-well.ilk.org) Received: (qmail 29157 invoked from network); 19 Jul 2009 13:52:58 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 19 Jul 2009 13:52:58 -0000 Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.6]) by be-well.ilk.org (Postfix) with ESMTP id 313E650822; Sun, 19 Jul 2009 09:52:51 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id DABC71CC53; Sun, 19 Jul 2009 09:52:49 -0400 (EDT) To: Tim Kientzle References: <4A615602.4090000@freebsd.org> <20090719075459.GA31256@zibbi.meraka.csir.co.za> <4A62D689.1050906@freebsd.org> From: Lowell Gilbert Date: Sun, 19 Jul 2009 09:52:49 -0400 In-Reply-To: <4A62D689.1050906@freebsd.org> (Tim Kientzle's message of "Sun\, 19 Jul 2009 01\:17\:13 -0700") Message-ID: <4463doaifi.fsf@lowell-desk.lan> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: John Hay , "'freebsd-current@freebsd.org'" Subject: Re: Joliet and release ISOs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 14:19:41 -0000 Tim Kientzle writes: > John Hay wrote: >> On Fri, Jul 17, 2009 at 09:56:34PM -0700, Tim Kientzle wrote: >>> Do we need Joliet extensions on the release ISOs? >>> >>> The reason I ask is a little involved: jkim@ recently >>> pointed out to me that tar in -CURRENT can no longer >>> extract symlinks from the release ISOs. >>> >>> I tracked this down to the fact that the release ISOs >>> have both Joliet and RockRidge extensions and tar now >>> supports (and actually prefers) Joliet extensions when >>> it sees them. Joliet doesn't support symlinks, so tar >>> doesn't see symlinks on disks with both kinds of extensions. >> >> What is the reason for prefering Juliet in tar? Can't we >> just swap the preference? > > Because of the way libarchive works internally coupled with > basic differences in how Joliet and RockRidge information > is stored, it turns out that libarchive has to decide > whether or not to use the Joliet information before it > can tell whether RockRidge information is available. > So preferring RockRidge is actually quite difficult. > > I would like to change this, but it's going to be > quite a while before I have enough time to work on it. Sounds like you're out of good options then. Maybe a good temporary workaround would be a switch to disable Joliet support? From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 17:28:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00BFE106564A; Sun, 19 Jul 2009 17:28:13 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f208.google.com (mail-bw0-f208.google.com [209.85.218.208]) by mx1.freebsd.org (Postfix) with ESMTP id 49C608FC1A; Sun, 19 Jul 2009 17:28:11 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz4 with SMTP id 4so1410924bwz.43 for ; Sun, 19 Jul 2009 10:28:11 -0700 (PDT) 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 :content-transfer-encoding; bh=6P1ZVyNcBSMX8Dmh/2Uc5NQQd6rJYwD53Knh5n7ktG0=; b=ryv1P71/2cghmlNIjXvb4K0vb8+8gkEHurV7wAOnDXU+B2nGU1WcoXClcFfJ/qX+Qk vwbUkdMPt/6wegWZWCetGVT1BDHwliTVq3gdKs084OeIp9wGXnLXWglaU0VrEH2bYn86 QxVMQ/gdL/W8sxfLru9WC1CLJA+F1NJpUV0BA= 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:content-transfer-encoding; b=vaYxCW0kWdj3IdtT15KFzTv7namzJDKzUpoD9lTzg9nHZ3RaTh7rpfokqGaUdNexe9 79m3o+Hn5e3NRwAbQhgU9ITFKcIQoBTYf4AwGrSwCYuUpjDF6eKtsA7Nlon7lQ6YKVnd PnrgTzrcfqBdlJ7U55ume9fUGgmIH5wlcJmug= MIME-Version: 1.0 Received: by 10.204.51.210 with SMTP id e18mr3407490bkg.69.1248024491072; Sun, 19 Jul 2009 10:28:11 -0700 (PDT) In-Reply-To: <3a142e750907150027t106edef5m767dd0319f83bd63@mail.gmail.com> References: <3a142e750906080809i381c4e6amd93da8a135ab9bd3@mail.gmail.com> <1244477453.7794.2.camel@localhost> <3a142e750906081006v6369051dw75c5077e6032101f@mail.gmail.com> <1244656248.1701.53.camel@localhost> <3a142e750906101108v588e33dfsb0cb81f024c65cfb@mail.gmail.com> <1244658479.1701.56.camel@localhost> <3a142e750906101805re85136cif71eeeda2c641451@mail.gmail.com> <1245323702.1754.0.camel@localhost> <3a142e750907040333o3938c06y6369af6fa6976812@mail.gmail.com> <3a142e750907150027t106edef5m767dd0319f83bd63@mail.gmail.com> Date: Sun, 19 Jul 2009 19:28:10 +0200 Message-ID: <3a142e750907191028u15dfd769o26270d48d15ae664@mail.gmail.com> From: "Paul B. Mahol" To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: ndis lor: hal preemption lock X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 17:28:13 -0000 On 7/15/09, Paul B. Mahol wrote: > On 7/4/09, Paul B. Mahol wrote: >> On 6/18/09, Coleman Kane wrote: >>> I've committed this one as r194432. >> >> Ah, that one introduced regression. >> Switching ndisX up before creating vap will cause panic. >> Here is fix: >> >> --- /sys/dev/if_ndis/if_ndis.c 2009-06-28 09:15:54.000000000 +0000 >> +++ if_ndis.c 2009-07-04 10:23:41.000000000 +0000 >> @@ -2292,6 +2292,8 @@ >> ifp = sc->ifp; >> ic = ifp->if_l2com; >> vap = TAILQ_FIRST(&ic->ic_vaps); >> + if (vap == NULL) >> + return; >> >> if (!NDIS_INITIALIZED(sc)) { >> DPRINTF(("%s: NDIS not initialized\n", __func__)); > > Bump! > > Please commit. Beep! kern/136895 -- Paul From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 18:17:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 540AC1065670; Sun, 19 Jul 2009 18:17:10 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id F3AAC8FC18; Sun, 19 Jul 2009 18:17:09 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [192.168.1.101] (cpe-74-77-179-53.buffalo.res.rr.com [74.77.179.53]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n6JIH5mX048027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 14:17:09 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: freebsd-current@freebsd.org, freebsd-stable Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-cbD+tMhyqRzyu/TEjcov" Date: Sun, 19 Jul 2009 14:16:57 -0400 Message-Id: <1248027417.14210.110.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 Cc: Subject: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 18:17:10 -0000 --=-cbD+tMhyqRzyu/TEjcov Content-Type: text/plain Content-Transfer-Encoding: quoted-printable First I want to apologize. This should have happened a bit sooner in our release cycle than now. To be honest I had slipped into "We have symbol versioning for our libraries now" mode. But only a few of the libraries currently have that turned on and I sorta forgot we still need to deal with all the shared libraries that do not have symbol versioning enabled yet. Sorry for the hassle this will cause. Today with svn commit 195767 I bumped the version number of all non-symbol-version-ed shared libraries in preparation for 8.0-REL. We do this just in case API/ABI changes occured in head between 7.0 and now, it lets us provide the older library versions as "compatibility library ports" in the ports tree. The problem is that as of the next time you update a machine that had been running -current you are best off reinstalling all ports or other applications you have on the machine. When you reboot after doing the update to the base system everything you have installed will still work because the old shared library versions will still be there. However anything you build on the machine after its base system gets updated would be linked against the newer base system shared libraries but any libraries that are part of ports or other applications (e.g. the Xorg libraries) would have been linked against the older library versions. You really don't want to leave things that way. The ports folks will be starting up a fresh package build now but it takes some time for full package runs like this to complete, get uploaded, and then propagate out to the mirrors. If you tend to use pre-built packages instead of building them as ports yourself you might want to just hold off on updating anything until they let us know a fresh set of packages is available. And BETA3 will definitely be scheduled for after the fresh set of packages becomes available. And again - sorry for the hassle. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-cbD+tMhyqRzyu/TEjcov Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpjYxkACgkQ/G14VSmup/b7aACgi5vkEuoGif2atxgOz9dCMCMb 7mwAmwbFxSXhAmfyM8nbA4FEKzn5nPXY =BshS -----END PGP SIGNATURE----- --=-cbD+tMhyqRzyu/TEjcov-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 18:26:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E1C2E106564A for ; Sun, 19 Jul 2009 18:26:39 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4148FC1D for ; Sun, 19 Jul 2009 18:26:39 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:58155 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MSb5e-0001gZ-3v; Sun, 19 Jul 2009 20:26:28 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 63D971386C7; Sun, 19 Jul 2009 20:26:24 +0200 (CEST) Message-Id: <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> From: Thomas Backman To: Ken Smith In-Reply-To: <1248027417.14210.110.camel@neo.cse.buffalo.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 19 Jul 2009 20:26:21 +0200 References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MSb5e-0001gZ-3v. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MSb5e-0001gZ-3v b201278915acd34693d46894c0c0555c Cc: FreeBSD current , freebsd-stable Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 18:26:40 -0000 On Jul 19, 2009, at 20:16, Ken Smith wrote: > The problem is that as of the next time you update a machine that had > been running -current you are best off reinstalling all ports or other > applications you have on the machine. When you reboot after doing the > update to the base system everything you have installed will still > work > because the old shared library versions will still be there. However > anything you build on the machine after its base system gets updated > would be linked against the newer base system shared libraries but any > libraries that are part of ports or other applications (e.g. the Xorg > libraries) would have been linked against the older library versions. > You really don't want to leave things that way. So, to be clear: a fresh ports tree and "portupgrade -af" after building and installing r195767+ should be enough to solve any problems? (installkernel, installworld, reboot, portupgrade -af) Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 18:33:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 752CA106564A; Sun, 19 Jul 2009 18:33:58 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from phoebe.cse.buffalo.edu (phoebe.cse.buffalo.edu [128.205.32.89]) by mx1.freebsd.org (Postfix) with ESMTP id 37B428FC24; Sun, 19 Jul 2009 18:33:58 +0000 (UTC) (envelope-from kensmith@cse.Buffalo.EDU) Received: from [192.168.1.101] (cpe-74-77-179-53.buffalo.res.rr.com [74.77.179.53]) (authenticated bits=0) by phoebe.cse.buffalo.edu (8.14.1/8.13.7) with ESMTP id n6JIXp5V048068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 19 Jul 2009 14:33:55 -0400 (EDT) (envelope-from kensmith@cse.buffalo.edu) From: Ken Smith To: Thomas Backman In-Reply-To: <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ZDoqDuif4Ydxt75AAoqh" Date: Sun, 19 Jul 2009 14:33:46 -0400 Message-Id: <1248028426.14210.114.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port X-DCC-Buffalo.EDU-Metrics: phoebe.cse.buffalo.edu 1336; Body=0 Fuz1=0 Fuz2=0 Cc: FreeBSD current , freebsd-stable Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 18:33:58 -0000 --=-ZDoqDuif4Ydxt75AAoqh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2009-07-19 at 20:26 +0200, Thomas Backman wrote: > On Jul 19, 2009, at 20:16, Ken Smith wrote: > > The problem is that as of the next time you update a machine that had > > been running -current you are best off reinstalling all ports or other > > applications you have on the machine. When you reboot after doing the > > update to the base system everything you have installed will still =20 > > work > > because the old shared library versions will still be there. However > > anything you build on the machine after its base system gets updated > > would be linked against the newer base system shared libraries but any > > libraries that are part of ports or other applications (e.g. the Xorg > > libraries) would have been linked against the older library versions. > > You really don't want to leave things that way. > So, to be clear: a fresh ports tree and "portupgrade -af" after =20 > building and installing r195767+ should be enough to solve any =20 > problems? (installkernel, installworld, reboot, portupgrade -af) >=20 Correct for those of you who let portupgrade do all the building for you (which the example command you give does). The reason I'm being careful is portupgrade can also be told to fetch pre-built packages. At the moment that will not work, if you use that approach please hold off until the ports folks let us know the packages have been rebuilt. --=20 Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | --=-ZDoqDuif4Ydxt75AAoqh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkpjZwoACgkQ/G14VSmup/afbgCfTGrvBGVQKHRlXf3FwbpE7wCK yTcAn3z4wTx0qFrpltDHMzPHxNbhXGTC =Cuim -----END PGP SIGNATURE----- --=-ZDoqDuif4Ydxt75AAoqh-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 18:40:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 842DB106566B for ; Sun, 19 Jul 2009 18:40:17 +0000 (UTC) (envelope-from kaduk@MIT.EDU) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by mx1.freebsd.org (Postfix) with ESMTP id 36B3C8FC16 for ; Sun, 19 Jul 2009 18:40:16 +0000 (UTC) (envelope-from kaduk@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n6JISACc003632 for ; Sun, 19 Jul 2009 14:28:11 -0400 (EDT) Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n6JIS9GN002265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 19 Jul 2009 14:28:10 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id n6JIS9UU017226; Sun, 19 Jul 2009 14:28:09 -0400 (EDT) Date: Sun, 19 Jul 2009 14:28:08 -0400 (EDT) From: Benjamin Kaduk To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Subject: nondeterministic device probing (mouse, laptop) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 18:40:17 -0000 Hi all, My laptop (ThinkPad T400) is running 8-current from May 24 or so. Sometimes, it fails to probe /dev/psm on boot; if I turn it off and turn it on again, it usually does find the mouse the second time. Any thoughts for how to start debugging this? I don't even know whether to suspect hardware or software more, at this point. Thanks, Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 18:45:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DB1C106566C for ; Sun, 19 Jul 2009 18:45:24 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 520F98FC1E for ; Sun, 19 Jul 2009 18:45:24 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id n6JIjNCa072677 for ; Sun, 19 Jul 2009 11:45:23 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id n6JIjNdb072676 for current@freebsd.org; Sun, 19 Jul 2009 11:45:23 -0700 (PDT) (envelope-from david) Date: Sun, 19 Jul 2009 11:45:23 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20090719184523.GU61607@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20090717161046.GH61607@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yRXsXhSYq7voLSEz" Content-Disposition: inline In-Reply-To: <20090717161046.GH61607@bunrab.catwhisker.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Trouble building world from r195708 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 18:45:24 -0000 --yRXsXhSYq7voLSEz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 17, 2009 at 09:10:46AM -0700, David Wolfskill wrote: > ... > /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0x1e0d): In function `_Unwind_Ra= iseException': > : undefined reference to `__stack_chk_fail_local' > /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0x1fe1): more undefined referenc= es to `__stack_chk_fail_local' follow > *** Error code 1 > ... pushd gnu/lib/libgcc && make && make install; popd appears to have resolved that issue. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --yRXsXhSYq7voLSEz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkpjacIACgkQmprOCmdXAD0hWwCfflO33gK5PuRLUwzulB4Wja1G qeYAnAuf4v7o9JND/B+BvdfYu6R9qJR3 =z9gH -----END PGP SIGNATURE----- --yRXsXhSYq7voLSEz-- From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 17:24:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 937DC106566C for ; Sun, 19 Jul 2009 17:24:09 +0000 (UTC) (envelope-from hank@millerfarm.com) Received: from millerfarm.com (mail.millerfarm.com [72.21.237.200]) by mx1.freebsd.org (Postfix) with SMTP id D06908FC19 for ; Sun, 19 Jul 2009 17:24:08 +0000 (UTC) (envelope-from hank@millerfarm.com) Received: (qmail 32538 invoked by uid 453); 19 Jul 2009 16:57:17 -0000 X-Virus-Checked: Checked by ClamAV on millerfarm.com Received: from pc-00001.millerfarm.com (HELO shiara.millerfarm.com) (192.168.1.1) (smtp-auth username hank, mechanism plain) by millerfarm.com (qpsmtpd/0.40) with ESMTPA; Sun, 19 Jul 2009 11:57:17 -0500 From: Henry Miller To: freebsd-current@freebsd.org Date: Sun, 19 Jul 2009 11:56:13 -0500 User-Agent: KMail/1.11.4 (FreeBSD/7.2-RELEASE; KDE/4.2.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907191156.13273.hank@millerfarm.com> X-Mailman-Approved-At: Sun, 19 Jul 2009 18:46:06 +0000 Subject: intel 5100 wifi - not detected in Beta 2, can I get it working? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 17:24:09 -0000 I have a laptop with an Intel 5100 wifi adapter in my laptop. (I think it is 5100, might be a 5300 if I ordered the other option, but either way the same driver should work?) I loaded the Beta-2 live CD, but was unable to get this to function. Nothing in dmesg even indicated that the adapter is detected. Is there something I can do to the live CD to make this work? Do I need to do a full install and enable something? I have been unable to find much about this by searching, apparently Daniel is working on support. It seems that the iwn driver could work, but I can't find any status. I'd offer to help write the support if I could find enough documentation on how this card works (I haven't done much driver work, but I think I could), so pointers in that direction would be welcome too. I'm not subscribed (yet) so please CC me on all replies. From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 19:04:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C8AE106564A; Sun, 19 Jul 2009 19:04:07 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9388FC0A; Sun, 19 Jul 2009 19:03:34 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090719190333.DERV6742.mtaout01-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>; Sun, 19 Jul 2009 20:03:33 +0100 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout04-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090719190333.OUTN22934.aamtaout04-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com>; Sun, 19 Jul 2009 20:03:33 +0100 X-Virus-Scanned: amavisd-new at omega.private.lan Received: from localhost (localhost [127.0.0.1]) by cpc1-cove3-0-0-cust909.sol2.cable.ntl.com (8.14.3/8.14.3) with ESMTP id n6JJ3RRr017922; Sun, 19 Jul 2009 20:03:27 +0100 (BST) (envelope-from ianjhart@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com) Received: from gamma.private.lan (gamma.private.lan [192.168.0.12]) by webmail.private.lan (Horde Framework) with HTTP; Sun, 19 Jul 2009 20:03:27 +0100 Message-ID: <20090719200327.848399266qvz2jgg@webmail.private.lan> Date: Sun, 19 Jul 2009 20:03:27 +0100 From: Ian J Hart To: Kip Macy References: <20090624153442.137934uzyotkb5og@10.248.192.16> <20090707210345.13681mi2dwvan78k@webmail.private.lan> <3c1674c90907071412t346b1591rfecfae22bb60a8f5@mail.gmail.com> <20090708122417.14619w86w7wfu4ms@10.248.192.16> <3c1674c90907081313q31c48953u8c4bde5d0e156acf@mail.gmail.com> In-Reply-To: <3c1674c90907081313q31c48953u8c4bde5d0e156acf@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-7.2 X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc1-cove3-0-0-cust909.sol2.cable.ntl.com X-Cloudmark-Analysis: v=1.0 c=1 a=ERehf_AEJYYA:10 a=6I5d2MoRAAAA:8 a=szcsTo1WmaNtUgNiKykA:9 a=gND7lsdQPnmvpj85HeoA:7 a=qQD79z1B9CsrlDau0RXBtGhtLS0A:4 a=SV7veod9ZcQA:10 Cc: freebsd-current@freebsd.org, Ian J Hart Subject: Re: zpool scrub errors on 3ware 9550SXU X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 19:04:07 -0000 Quoting Kip Macy : > The reason why the results on 7-STABLE are so important is that it is > now running the exact same version of ZFS as HEAD. So if you aren't > seeing checksum errors on 7-STABLE then the problem lies elsewhere in > the storage stack. There are so many things that could cause this that > I won't even speculate. > > Thanks for the information. I'll try to figure out how to narrow it down. > > -Kip > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > I realise this is not going anywhere unless someone else gets the same error (preferably on different hardware) but FWIW I still get the same error on 8.0-BETA2. I only did one run so far but it took 3 hours rather than 40 minutes. Offset is roughly twice the typical value, although again, this may not be significant. Any commits in the storage stack? I have a new mobo/cpu/ram/raid card on order which I'll be able to test the week after next. The old board etc will go into a system with a set of 500GB disks, so I'll get two sets of tests for the price of one. Very soon after that I have to put both boxes into production. Jul 19 19:12:54 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da14 offset=624129919488 size=22016 Jul 19 19:12:54 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da11 offset=624129591808 size=21504 Jul 19 19:12:54 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da9 offset=624130029568 size=22016 Jul 19 19:13:06 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da4 offset=624318266368 size=21504 Jul 19 19:13:06 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da15 offset=624317789696 size=22016 Jul 19 19:13:08 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da14 offset=624339560448 size=22016 Jul 19 19:13:10 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da10 offset=624369130496 size=22016 Jul 19 19:13:10 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da11 offset=624369171456 size=22016 Jul 19 19:13:14 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da0 offset=624426701824 size=22016 Jul 19 19:13:14 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da1 offset=624426701824 size=22016 Jul 19 19:13:14 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da2 offset=624426701824 size=22016 Jul 19 19:13:14 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da3 offset=624426701824 size=22016 Jul 19 19:13:14 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da4 offset=624426701824 size=22016 Jul 19 19:13:14 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da5 offset=624426701824 size=22016 Jul 19 19:13:14 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da6 offset=624426701824 size=21504 Jul 19 19:13:14 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da7 offset=624426701824 size=21504 Jul 19 19:13:16 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da10 offset=624469054464 size=21504 Jul 19 19:13:16 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da2 offset=624469552640 size=21504 Jul 19 19:13:16 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da3 offset=624469552640 size=21504 Jul 19 19:13:37 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da5 offset=626105954816 size=22016 Jul 19 19:13:53 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da2 offset=626296076800 size=22016 Jul 19 19:13:55 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da3 offset=626306811904 size=22016 Jul 19 19:13:55 data kernel: twa0: ERROR: (0x16: 0x1302): Unexpected status bit(s): status reg = 0xd00000 Unexpected bits: [PCI_ABRT,Q_ERR,PCI_PERR] Jul 19 19:13:55 data kernel: twa0: parity error: clearing... Re-seat/move/replace card: (0x49435000: 0x1303): PCI parity error: clearing... Re-seat/move/replace card: status reg = 0x30db64a7 [MC_RDY,RESP_Q_EMPTY,RESP_INTR,CMD_INTR,HOS T_INTR,PCI_ABRT,Q_ERR,PCI_PERR] Jul 19 19:13:55 data kernel: twa0: abort: clearing... : (0x49435000: 0x1304): PCI abort: clearing... : status reg = 0x30db64a7 [MC_RDY,RESP_Q_EMPTY,RESP_INTR,CMD_INTR,HOST_INTR,PCI_ABRT,Q_ERR,PCI_PERR] Jul 19 19:13:55 data kernel: twa0: troller queue error: clearing... : (0x6E6F4300: 0x1305): Controller queue error: clearing... : status reg = 0x30db64a7 [MC_RDY,RESP_Q_EMPTY,RESP_INTR,CMD_INTR,HOST_INTR,PCI_ABRT,Q_ERR,PCI_PERR] Jul 19 19:13:55 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da6 offset=626306920960 size=22016 Jul 19 19:13:55 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da7 offset=626306920960 size=22016 Jul 19 19:13:56 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da7 offset=626316084224 size=16384 Jul 19 19:13:56 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da6 offset=626317622784 size=22016 Jul 19 19:13:56 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da13 offset=626316797440 size=22016 Jul 19 19:14:12 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da15 offset=626486498304 size=21504 Jul 19 19:14:12 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da2 offset=626486997504 size=21504 Jul 19 19:14:12 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da3 offset=626486756352 size=22016 Jul 19 19:14:43 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da2 offset=626830958592 size=21504 Jul 19 19:14:43 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da3 offset=626830980096 size=17920 Jul 19 19:14:43 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da12 offset=626830480384 size=22016 Jul 19 19:14:43 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da13 offset=626830480384 size=22016 Jul 19 19:14:43 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da14 offset=626830480384 size=22016 Jul 19 19:14:43 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da15 offset=626830480384 size=22016 Jul 19 19:14:43 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da8 offset=626830480896 size=22016 Jul 19 19:14:43 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da9 offset=626830480896 size=22016 Jul 19 19:14:43 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da10 offset=626830480896 size=21504 Jul 19 19:14:43 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da11 offset=626830480896 size=21504 Jul 19 19:14:44 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da7 offset=626839974400 size=17920 Jul 19 19:14:44 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da9 offset=626839497216 size=17920 Jul 19 19:14:44 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da8 offset=626839429120 size=18944 Jul 19 19:14:47 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da12 offset=626870235648 size=21504 Jul 19 19:14:47 data kernel: twa0: ERROR: (0x16: 0x1302): Unexpected status bit(s): status reg = 0x200000 Unexpected bits: [MC_ERR,] Jul 19 19:14:47 data kernel: twa0: or! : (0x72726520: 0x1307): Micro-controller error! : status reg = 0x97273372 [CMD_Q_EMPTY,MC_RDY,RESP_INTR,CMD_INTR,ATTN_INTR,MC_ERR,] Jul 19 19:14:56 data root: ZFS: checksum mismatch, zpool=tank path=/dev/da4 offset=626964436992 size=21504 Cheers -- ian j hart ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 19:09:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D150F106564A for ; Sun, 19 Jul 2009 19:09:28 +0000 (UTC) (envelope-from krad@snaffler.net) Received: from mk-filter-2-a-1.mail.uk.tiscali.com (mk-filter-2-a-1.mail.uk.tiscali.com [212.74.100.53]) by mx1.freebsd.org (Postfix) with ESMTP id 6C7978FC1D for ; Sun, 19 Jul 2009 19:09:28 +0000 (UTC) (envelope-from krad@snaffler.net) X-Trace: 232188378/mk-filter-2.mail.uk.tiscali.com/B2C/$b2c-THROTTLED/b2c-CUSTOMER-STATIC-IP/80.45.84.89/None/krad@snaffler.net X-SBRS: None X-RemoteIP: 80.45.84.89 X-IP-MAIL-FROM: krad@snaffler.net X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2900.5512Produced By Microsoft MimeOLE V6.00.2900.5579 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEMAOcEY0pQLVRZ/2dsb2JhbACBSlKIa8AchAwFgT8 X-IronPort-AV: E=Sophos;i="4.43,230,1246834800"; d="scan'208";a="232188378" Received: from lambo.snaffler.net (HELO LTPCSCOTT) ([80.45.84.89]) by smtp.tiscali.co.uk with SMTP; 19 Jul 2009 19:40:27 +0100 Message-ID: From: "krad" To: Date: Sun, 19 Jul 2009 19:37:33 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: usb pen drive not detecting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 19:09:29 -0000 hi I cant get bsd to detect any usb pen drives on my system. I have a generic kernel with a few extra options that i cant see causing any issues. I do get a few kernel messages when I plug the drive in (see below). The pen drives are plugged directly into the usb headers on the back of the motherboard ie not the kvm (which works) I'm happy to supply any extra debug information usbd_req_re_enumerate:1539: addr=4, set address failed! (USB_ERR_TIMEOUT, ignored) Root mount waiting for: usbus4 usbd_req_re_enumerate:1553: getting device descriptor at addr 4 failed, USB_ERR_TIMEOUT! ugen4.4: <(null)> at usbus4 (disconnected) uhub_reattach_port:435: could not allocate new device! $ usbconfig ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.2: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.3: at usbus4, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON $ uname -a FreeBSD X 8.0-BETA2 FreeBSD 8.0-BETA2 #2: Sat Jul 18 23:29:28 BST 2009 root@x:/usr/obj/usr/src/sys/me amd64 $ cat /sys/amd64/conf/me include GENERIC options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ALTQ_NOPCC device carp options COM_MULTIPORT device puc From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 18:31:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C7501065670 for ; Sun, 19 Jul 2009 18:31:11 +0000 (UTC) (envelope-from krad@snaffler.net) Received: from mk-filter-1-a-1.mail.uk.tiscali.com (mk-filter-1-a-1.mail.uk.tiscali.com [212.74.100.52]) by mx1.freebsd.org (Postfix) with ESMTP id EBDF68FC25 for ; Sun, 19 Jul 2009 18:31:10 +0000 (UTC) (envelope-from krad@snaffler.net) X-Trace: 232600736/mk-filter-1.mail.uk.tiscali.com/B2C/$b2c-THROTTLED/b2c-CUSTOMER-STATIC-IP/80.45.84.89/None/krad@snaffler.net X-SBRS: None X-RemoteIP: 80.45.84.89 X-IP-MAIL-FROM: krad@snaffler.net X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2900.5512Produced By Microsoft MimeOLE V6.00.2900.5579 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEMADv8YkpQLVRZ/2dsb2JhbACBSlKIa8APhAwFgT8 X-IronPort-AV: E=Sophos;i="4.43,230,1246834800"; d="scan'208";a="232600736" Received: from lambo.snaffler.net (HELO LTPCSCOTT) ([80.45.84.89]) by smtp.tiscali.co.uk with SMTP; 19 Jul 2009 19:01:56 +0100 Message-ID: <7142D2AC7FF846A297A54BE55D821CF0@uk.tiscali.intl> From: "krad" To: Date: Sun, 19 Jul 2009 19:01:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailman-Approved-At: Sun, 19 Jul 2009 19:26:50 +0000 Cc: Subject: usb pen drive not detecting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 18:31:11 -0000 hi I cant get bsd to detect any usb pen drives on my system. I have a generic kernel with a few extra options that i cant see causing any issues. I do get a few kernel messages when I plug the drive in (see below). The pen drives are plugged directly into the usb headers on the back of the motherboard ie not the kvm (which works) I'm happy to supply any extra debug information usbd_req_re_enumerate:1539: addr=4, set address failed! (USB_ERR_TIMEOUT, ignored) Root mount waiting for: usbus4 usbd_req_re_enumerate:1553: getting device descriptor at addr 4 failed, USB_ERR_TIMEOUT! ugen4.4: <(null)> at usbus4 (disconnected) uhub_reattach_port:435: could not allocate new device! $ usbconfig ugen2.1: at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.2: at usbus4, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE ugen4.3: at usbus4, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON $ uname -a FreeBSD X 8.0-BETA2 FreeBSD 8.0-BETA2 #2: Sat Jul 18 23:29:28 BST 2009 root@x:/usr/obj/usr/src/sys/me amd64 $ cat /sys/amd64/conf/me include GENERIC options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options ALTQ options ALTQ_CBQ options ALTQ_RED options ALTQ_RIO options ALTQ_HFSC options ALTQ_CDNR options ALTQ_PRIQ options ALTQ_NOPCC device carp options COM_MULTIPORT device puc From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 19:28:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFD59106566B; Sun, 19 Jul 2009 19:28:50 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: from mail-bw0-f208.google.com (mail-bw0-f208.google.com [209.85.218.208]) by mx1.freebsd.org (Postfix) with ESMTP id 1ADAC8FC21; Sun, 19 Jul 2009 19:28:49 +0000 (UTC) (envelope-from f0andrey@gmail.com) Received: by bwz4 with SMTP id 4so1442467bwz.43 for ; Sun, 19 Jul 2009 12:28:49 -0700 (PDT) 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=0UbK9MNlOa6lc+L9qBGpf6LVJQGzgERNDqdBsaUf9Z8=; b=IK1gWQIZsRZHYiB3VApRGY/7sIIGWXQNW2Z2DW5GrAy0O39m9kru2+sw8m6hNTUaOh lKYVewDch+f7jNIlj2/zRpbpM6SstQlNE8s9ixfOY4oKrRuROtTAKV1pc72OHcx9bAvC kf28P8DLppegWf8sXs4Ulj57INdfTDAxaT1wE= 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=b+AY9x1LoBYMzFpIWbG/3fB12fNGAqUa+Okk4njT6v4aRSv44r+Ygxtd2fyQ6FerNp moYKiFPHfIW+vC+hoAOwRrBgwF37wpy1WM75fvmLKGSUtpYJRkoLbjdOJ2CrINja4oXD xH+fqXzjr4PUANMMOXz5fpbsWzpXToRQhZWU4= MIME-Version: 1.0 Received: by 10.223.108.15 with SMTP id d15mr972104fap.62.1248029792996; Sun, 19 Jul 2009 11:56:32 -0700 (PDT) In-Reply-To: <200907191156.13273.hank@millerfarm.com> References: <200907191156.13273.hank@millerfarm.com> Date: Sun, 19 Jul 2009 22:56:32 +0400 Message-ID: <19e7832a0907191156m76f87283qb67208bc8f686890@mail.gmail.com> From: Andrey Fesenko To: Henry Miller , freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: intel 5100 wifi - not detected in Beta 2, can I get it working? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 19:28:51 -0000 On Sun, Jul 19, 2009 at 8:56 PM, Henry Miller wrote: > > I have a laptop with an Intel 5100 wifi adapter in my laptop. (I think it > is > 5100, might be a 5300 if I ordered the other option, but either way the > same > driver should work?) I loaded the Beta-2 live CD, but was unable to get > this > to function. > This last message http://lists.freebsd.org/pipermail/freebsd-current/2009-April/006274.htmlabout this wifi card intel 5100 agn :( This card intel 5100 agn worked on OpenBSD, and OpenSolaris. From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 19:52:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 633CE106564A for ; Sun, 19 Jul 2009 19:52:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id C33978FC1C for ; Sun, 19 Jul 2009 19:52:16 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=PiioE0IkECKPiCO94QMA:9 a=RkhHhzEW_q1FjES_q0dL3rM6D7IA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 226695088; Sun, 19 Jul 2009 21:52:15 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 19 Jul 2009 21:51:59 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA1; KDE/4.2.4; i386; ; ) References: <7142D2AC7FF846A297A54BE55D821CF0@uk.tiscali.intl> In-Reply-To: <7142D2AC7FF846A297A54BE55D821CF0@uk.tiscali.intl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907192152.01076.hselasky@c2i.net> Cc: krad , current@freebsd.org Subject: Re: usb pen drive not detecting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 19:52:18 -0000 On Sunday 19 July 2009 20:01:48 krad wrote: > I cant get bsd to detect any usb pen drives on my system. I have a generic > kernel with a few extra options that i cant see Are your pen-drives detected if you set: sysctl hw.usb.ehci.no_hs=1 Before plugging the device? --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 21:01:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A89721065670 for ; Sun, 19 Jul 2009 21:01:02 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2DA2B8FC0C for ; Sun, 19 Jul 2009 21:01:01 +0000 (UTC) (envelope-from michiel@boland.org) Received: from aja.boland.org (91-43-215.ftth.xms.internl.net [82.215.43.91]) (authenticated bits=0) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id n6JKmuKA087502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 19 Jul 2009 22:48:56 +0200 (CEST) (envelope-from michiel@boland.org) Message-ID: <4A6386B8.9050606@boland.org> Date: Sun, 19 Jul 2009 22:48:56 +0200 From: Michiel Boland User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: mklocale broken -> buildworld broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 21:01:02 -0000 Hi. Buildworld stops in ===> share/mklocale (all) mklocale -o am_ET.UTF-8.out /usr/src/share/mklocale/am_ET.UTF-8.src am_ET.UTF-8.out: Inappropriate ioctl for device I believe I solved this by doing a make and make install in usr.bin/mklocale, but surely the buildworld would want to build mklocale first, and then use that in share/mklocale Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 20:52:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56C29106566C for ; Sun, 19 Jul 2009 20:52:30 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id CBC648FC08 for ; Sun, 19 Jul 2009 20:52:29 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (mail.upper.net [62.75.224.33]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id n6JKqLaJ020297 for ; Sun, 19 Jul 2009 22:52:25 +0200 Received: from ubm.mine.nu ([85.181.21.137] helo=ubm.mine.nu) by ASSP.nospam.UpPeRnEt; 19 Jul 2009 22:52:21 +0200 Date: Sun, 19 Jul 2009 22:52:21 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20090719225221.cf9d8417.ubm@u-boot-man.de> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.10; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 19 Jul 2009 21:28:03 +0000 Subject: Really slow gigabit link in one direction (em -> sk) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 20:52:30 -0000 Hiho! :-) Transfer speed from the em adapter in our fileserver to another machine (sk adapter) is really slow (measurements taken with iperf without options): ------------------------------------------------------------ Client connecting to 192.168.0.23, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.0.222 port 52856 connected with 192.168.0.23 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.2 sec 181 MBytes 149 Mbits/sec On the other hand, speed from the sk adapter to em is acceptable (for an untuned connection and a possibly crappy cable, imho): ------------------------------------------------------------ Client connecting to 192.168.0.222, TCP port 5001 TCP window size: 32.5 KByte (default) ------------------------------------------------------------ [ 3] local 192.168.0.23 port 32579 connected with 192.168.0.222 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 505 MBytes 423 Mbits/sec Cable is about 15m long, cat-5. On the receiving end sits a Marvell sk gigabit card. I've tried setting the mtu on both sides to 9000 and to other values as well, but it makes no difference. Neither does increasing net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 to 8MB, as some sources suggested (actually, it does make a difference, it nets ca. 100Mbit more in the sk->em direction, but does nothing for the em->sk direction). Am I doing something wrong? Should I burn my cable? :-) Additional info for the machine containing the sk card: skc0@pci0:2:8:0: class=0x020000 card=0xc2311297 chip=0x432011ab rev=0x13 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'Yukon 88E8001/8003/8010 PCI Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet sk0: flags=8843 metric 0 mtu 1500 options=b ether 00:30:1b:b5:fb:d9 inet 192.168.0.23 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseT ) status: active net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 310 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.wlock_looped: 0 net.inet.tcp.wlock_relocked: 0 net.inet.tcp.wlock_upgraded: 11246 net.inet.tcp.tcp_wlock_atfirst: 19669 net.inet.tcp.rlock_atfirst: 4875339 net.inet.tcp.read_locking: 1 net.inet.tcp.recvbuf_max: 16777216 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.ecn.enable: 0 net.inet.tcp.abc_l_var: 2 net.inet.tcp.rfc3465: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 16777216 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 2610 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 2 net.inet.tcp.reass.maxsegments: 1600 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 96 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 30000 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 5120 Additional info for the computer with the em card: em0@pci0:1:7:0: class=0x020000 card=0x13768086 chip=0x107c8086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (Copper) rev 5 (82541PI)' class = network subclass = ethernet em0: flags=8843 metric 0 mtu 9000 options=9b ether 00:1b:21:17:2e:5d inet 192.168.0.222 netmask 0xffffff00 broadcast 192.168.0.255 media: Ethernet autoselect (1000baseT ) status: active net.inet.tcp.rfc1323: 1 net.inet.tcp.mssdflt: 512 net.inet.tcp.keepidle: 7200000 net.inet.tcp.keepintvl: 75000 net.inet.tcp.sendspace: 32768 net.inet.tcp.recvspace: 65536 net.inet.tcp.keepinit: 75000 net.inet.tcp.delacktime: 100 net.inet.tcp.v6mssdflt: 1024 net.inet.tcp.hostcache.purge: 0 net.inet.tcp.hostcache.prune: 300 net.inet.tcp.hostcache.expire: 3600 net.inet.tcp.hostcache.count: 1 net.inet.tcp.hostcache.bucketlimit: 30 net.inet.tcp.hostcache.hashsize: 512 net.inet.tcp.hostcache.cachelimit: 15360 net.inet.tcp.wlock_looped: 0 net.inet.tcp.wlock_relocked: 0 net.inet.tcp.wlock_upgraded: 281 net.inet.tcp.tcp_wlock_atfirst: 296 net.inet.tcp.rlock_atfirst: 1608326 net.inet.tcp.read_locking: 1 net.inet.tcp.recvbuf_max: 16777216 net.inet.tcp.recvbuf_inc: 16384 net.inet.tcp.recvbuf_auto: 1 net.inet.tcp.insecure_rst: 0 net.inet.tcp.ecn.maxretries: 1 net.inet.tcp.ecn.enable: 0 net.inet.tcp.abc_l_var: 2 net.inet.tcp.rfc3465: 1 net.inet.tcp.rfc3390: 1 net.inet.tcp.rfc3042: 1 net.inet.tcp.drop_synfin: 0 net.inet.tcp.delayed_ack: 1 net.inet.tcp.blackhole: 0 net.inet.tcp.log_in_vain: 0 net.inet.tcp.sendbuf_max: 16777216 net.inet.tcp.sendbuf_inc: 8192 net.inet.tcp.sendbuf_auto: 1 net.inet.tcp.tso: 1 net.inet.tcp.newreno: 1 net.inet.tcp.local_slowstart_flightsize: 4 net.inet.tcp.slowstart_flightsize: 1 net.inet.tcp.path_mtu_discovery: 1 net.inet.tcp.reass.overflows: 0 net.inet.tcp.reass.maxqlen: 48 net.inet.tcp.reass.cursegments: 0 net.inet.tcp.reass.maxsegments: 1600 net.inet.tcp.sack.globalholes: 0 net.inet.tcp.sack.globalmaxholes: 65536 net.inet.tcp.sack.maxholes: 128 net.inet.tcp.sack.enable: 1 net.inet.tcp.inflight.stab: 20 net.inet.tcp.inflight.max: 1073725440 net.inet.tcp.inflight.min: 6144 net.inet.tcp.inflight.rttthresh: 10 net.inet.tcp.inflight.debug: 0 net.inet.tcp.inflight.enable: 1 net.inet.tcp.isn_reseed_interval: 0 net.inet.tcp.icmp_may_rst: 1 net.inet.tcp.pcbcount: 11 net.inet.tcp.do_tcpdrain: 1 net.inet.tcp.tcbhashsize: 512 net.inet.tcp.log_debug: 0 net.inet.tcp.minmss: 216 net.inet.tcp.syncache.rst_on_sock_fail: 1 net.inet.tcp.syncache.rexmtlimit: 3 net.inet.tcp.syncache.hashsize: 512 net.inet.tcp.syncache.count: 0 net.inet.tcp.syncache.cachelimit: 15360 net.inet.tcp.syncache.bucketlimit: 30 net.inet.tcp.syncookies_only: 0 net.inet.tcp.syncookies: 1 net.inet.tcp.timer_race: 0 net.inet.tcp.finwait2_timeout: 60000 net.inet.tcp.fast_finwait2_recycle: 0 net.inet.tcp.always_keepalive: 1 net.inet.tcp.rexmit_slop: 200 net.inet.tcp.rexmit_min: 30 net.inet.tcp.msl: 30000 net.inet.tcp.nolocaltimewait: 0 net.inet.tcp.maxtcptw: 5120 Bye Marc -- "And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born?" W.B. Yeats, The Second Coming From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 22:18:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B67D01065678 for ; Sun, 19 Jul 2009 22:18:12 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from mail-bw0-f208.google.com (mail-bw0-f208.google.com [209.85.218.208]) by mx1.freebsd.org (Postfix) with ESMTP id 1B8E68FC19 for ; Sun, 19 Jul 2009 22:18:11 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: by bwz4 with SMTP id 4so1484454bwz.43 for ; Sun, 19 Jul 2009 15:18:10 -0700 (PDT) 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:content-type; bh=J0ndQFSG35TkxCU8UJsEcqx0A4wZXg97cXOQE6I/mJM=; b=QdXtcPzF+uvdf4t+Zv212WrPP5aGGNE+3bGNVZoo4kdkS37TMFvfN7Tkv0DyJOFHB6 8atolm8uwEedxsHP3LFCfJF/AEigrsi8yT5fAsnGOgq2wATF6JyFrwd5wSeTtlZ1QpLD 2HBU3aCbLWOtJFJVb0AMGuYnKE+SOHxvosuFk= 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 :content-type; b=W6a73ov7La51YoFqMgxauxq/Ca0fJECcUlCnQdmL7pz3Mwm6VJRNb2V2WkPxAv+hdr OiDTuzaY1CwrEB6DiVmDX/ArrA/+AdUyfCGSNB+WJx5lBg3IBKGlm/7AOO4T3LEgNEhK 5TzZ+B+1/lJg6hrb3RVbhfM9H+iL2kxo67qDs= MIME-Version: 1.0 Received: by 10.103.225.11 with SMTP id c11mr932198mur.57.1248040306774; Sun, 19 Jul 2009 14:51:46 -0700 (PDT) In-Reply-To: References: <7142D2AC7FF846A297A54BE55D821CF0@uk.tiscali.intl> <200907192152.01076.hselasky@c2i.net> Date: Sun, 19 Jul 2009 22:51:46 +0100 Message-ID: From: chris scott To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Fwd: usb pen drive not detecting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 22:18:13 -0000 not visible after boot either even though i have poked it in loader.conf 2009/7/19 chris scott > hmm, i notice it nobbles the port to 12 Meg, not ideal is this a know > issue? > > > 2009/7/19 chris scott > > >> >> 2009/7/19 Hans Petter Selasky >> >> On Sunday 19 July 2009 20:01:48 krad wrote: >>> > I cant get bsd to detect any usb pen drives on my system. I have a >>> generic >>> > kernel with a few extra options that i cant see >>> >>> Are your pen-drives detected if you set: >>> >>> sysctl hw.usb.ehci.no_hs=1 >>> >>> Before plugging the device? >>> >>> --HPS >>> >>> hmm this did indeed work thanks. Is this setting going to be in the >> default sysctl.conf as if it isn't I can see it causing a lot of fault >> reports when current becomes stable? >> > > From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 22:30:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C3EE1065673 for ; Sun, 19 Jul 2009 22:30:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4813F8FC15 for ; Sun, 19 Jul 2009 22:30:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id CA7B341C7AA for ; Mon, 20 Jul 2009 00:30:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id ooOuV-FDY4+1 for ; Mon, 20 Jul 2009 00:30:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 1576A41C750; Mon, 20 Jul 2009 00:30:06 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1B5D74448E6 for ; Sun, 19 Jul 2009 22:28:08 +0000 (UTC) Date: Sun, 19 Jul 2009 22:28:08 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20090719221755.W245@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: minidump size X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 22:30:08 -0000 Hi, I am booting an amd64 machine with 8GB RAM from NFS (NFS Root). If I enter the debugger by the time I get to the login prompt or shortly afterwards and run call doadump the dump size is between 1.2 and 1.9GB (sometimes I logged in ran netstat, ps and the like, rebuilt a library). For a freshly booted system this sounds huge; no I am not using any disk and the swap space only for the dumps (and thus no ZFS either just to answer that question upfront). Has anyone an idea why the minidumps are so huge at this stage of uptime? Is it because of the NFS root? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 22:30:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14AC2106566B for ; Sun, 19 Jul 2009 22:30:49 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-qy0-f204.google.com (mail-qy0-f204.google.com [209.85.221.204]) by mx1.freebsd.org (Postfix) with ESMTP id 69CF08FC19 for ; Sun, 19 Jul 2009 22:30:48 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by qyk42 with SMTP id 42so1509779qyk.3 for ; Sun, 19 Jul 2009 15:30:47 -0700 (PDT) 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=jPcwXwoL2eMTaxa8rwvcrCG0fexw2FJFltxQ2+9NHZ8=; b=qThQ3Nx5NYcKCNmSLxG5gBxB2NcFLCxKuAMHa0l060NUjdo6BhQnOZti4FiDUHWw0Z MbHoDSlb5Sdll5x7+K2KGtzPz0Ps8AqPDvDiCz9gpjCW5Hz2lLjyQGZpqWeJRXcqjDIl CCbebShVluI0xOHOjcFz8a1vSqX2PBr2X0/2A= 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=R/SCAuc5e0qxjSi5K/tEKpNudBvcF3XMw26k/AYihhif5edUFUNiSNxWAa+FmoTayY 6SGU9yi4b1DpAKI733/L2gcFtOjIhG0/cPmyvchgL36Exk8uKxLP0+5duSkghTdoWOPY vnB2tla9HqvU3qoEZpptx4fy4EuiPRnzrZw6c= MIME-Version: 1.0 Received: by 10.224.45.72 with SMTP id d8mr2260552qaf.205.1248042647266; Sun, 19 Jul 2009 15:30:47 -0700 (PDT) In-Reply-To: <3a142e750907171509o62c999c5o446bcd7cd576b9a5@mail.gmail.com> References: <4A5D27F2.50208@voicenet.com> <3a142e750907150020h712bfcecq89d5ccf3e00e302c@mail.gmail.com> <200907150713.47807.adamk@voicenet.com> <200907171743.11143.gnemmi@gmail.com> <3a142e750907171509o62c999c5o446bcd7cd576b9a5@mail.gmail.com> Date: Mon, 20 Jul 2009 00:30:47 +0200 Message-ID: <19e9a5dc0907191530s679c0b37v49a836cc00bbf58a@mail.gmail.com> From: Gonzalo Nemmi To: "Paul B. Mahol" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Adam K Kirchhoff Subject: Re: bge problems when resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 22:30:51 -0000 On Sat, Jul 18, 2009 at 12:09 AM, Paul B. Mahol wrote: > On 7/17/09, Gonzalo Nemmi wrote: > > On Wednesday 15 July 2009 8:13:47 am Adam K Kirchhoff wrote: > >> On Wednesday 15 July 2009 03:20:45 Paul B. Mahol wrote: > >> > On 7/15/09, Adam K Kirchhoff wrote: > >> > > Hello all, > >> > > > >> > > I have a Dell Latitude D610 laptop with 8.0-BETA1 installed. I > >> > > hadn't tried suspend/resume for a while and decided to give it a > >> > > shot. I was pleasantly surprised to see that I could suspend to > >> > > ram, resume, and have a (relatively) working system (previously > >> > > the display would never come back up and the serial console I had > >> > > hooked up remained dead). Great job to everyone who helped make > >> > > that possible. > >> > > > >> > > The only real issue that I seem to have now is that bge is > >> > > completely unusable after resume. Another individual seems to > >> > > have reported similar problems with bge and resume, but he also > >> > > had other issues that apparently trumped his networking issues: > >> > > > >> > > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/0090 > >> > >23.html > >> > > > >> > > Like him, resuming from suspend gives me: > >> > > > >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > >> > > reg 0, val 32768) > >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY read timed out (phy 1, > >> > > reg 0, val 0xffffffff) > >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > >> > > reg 24, val 3072) > >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > >> > > reg 23, val 10) > >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > >> > > reg 21, val 12555) > >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > >> > > reg 23, val 8223) > >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > >> > > reg 21, val 38150) > >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > >> > > reg 23, val 16415) > >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > >> > > reg 21, val 5346) > >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > >> > > reg 24, val 1024) > >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, > >> > > reg 24, val 7) > >> > > > >> > > And so on and so forth. > >> > > > >> > > I thought that compiling if_bge as a module, unloading it before > >> > > suspend, and reloading it after resume, might get this working. > >> > > However, doing a "kldload if_bge" after the resume does nothing. > >> > > Well, the module gets loaded, but the device doesn't show up. No > >> > > errors from kldload, and there is nothing new in dmesg. > >> > > > >> > > Before the suspend, the device shows up as: > >> > > > >> > > bge0@pci0:2:0:0: class=0x020000 card=0x01821028 > >> > > chip=0x167714e4 rev=0x01 hdr=0x00 > >> > > vendor = 'Broadcom Corporation' > >> > > device = 'NetXtreme Gigabit Ethernet PCI Express > >> > > (BCM5750A1)' class = network > >> > > subclass = ethernet > >> > > > >> > > After resuming, and reloading the module, it's: > >> > > > >> > > none1@pci0:2:0:0: class=0x020000 card=0x01821028 > >> > > chip=0x167714e4 rev=0x01 hdr=0x00 > >> > > vendor = 'Broadcom Corporation' > >> > > device = 'NetXtreme Gigabit Ethernet PCI Express > >> > > (BCM5750A1)' class = network > >> > > subclass = ethernet > >> > > > >> > > If there are no ideas, I'll go ahead and open up a pr. I assume > >> > > this is just one bug, since both problems (the PHY issues and the > >> > > inability to reload the driver) are both related to the network > >> > > device. > >> > > >> > Put this lines into loader.conf and reboot. > >> > > >> > hw.pci.do_power_nodriver="3" > >> > hw.pci.do_power_resume="1" > >> > > >> > Now, before suspend, unload if_bge and some another driver (sound > >> > drivers are best candidate) and load sound driver again, suspend > >> > and resume. > >> > Now loading if_bge should make it succesfully attach. > >> > >> Unfortunately, after doing this, reloading the if_bge driver causes > >> the laptop to completely lock up... It gets as far as: > >> > >> bge0: >> rev. 0xffff> > >> mem 0xdfdf0000-0xdfdfffff irq 16 at device 0.0 on pci2 > >> > >> And then the entire machine hangs. I'm on ttyv0, so I'd see any > >> kernel panic, but nothing like that happens. The screen stays on, > >> but nothing else happens till I force a reboot. > >> > >> Adam > > > > Hi Adam, Paul ... > > I'm the "another individual" from you OP. > > I have the same problems you have regarding bge, but they weren't > > trumped .. I just had an order of priorities ;) > > > > Anyways, I tried the solution Paul posted and, just as in your case, I > > got a hard lock too ... > > > > I tried loading if_bge through /boot/loader.conf > > Then issued a: > > > > kldunload if_bge coretemp > > coretemp is wrong module, it must be one of modules that attach to pci. > Sorry Paul! I gave it a go with snd_hda and I got the same result except that this time I also got the following message: fwohci0: ... firewire0: ... fwohci0: ... pci0: < multimedia HDA > at device 27.0 ( no driver attached ) bge0 ... Then, the same hard lock :( Will install BETA2 today ! Best Regards Gonzalo > > acpiconf -s 3 > > > > machine suspended > > > > As soon as I woke it up I got the following message followed by a hard > > lock: > > > > fwohci0: Phy 1394a available S400, 1 ports. > > fwohci0: Link S400, max_rec 2048 bytes. > > fwohci0: Initiate bus reset > > fwohci0: fwohci_intr_core: BUS reset > > fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, > > CYCLEMASTER mode > > firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) > > firewire0: bus manager 0 > > fwohci0: unrecoverable error > > bge0: > 0xffff> mem 0xf69f0000-0xf69fffff irq 17 at device 0.0 on pci9 > > > > All this happens on a Dell 1318, FreeBSD 8.0-BETA1, i386, Intel(R) > > Celeron(R) CPU 560@2.13GHz. > > > > bge0@pci0:9:0:0: class=0x020000 card=0x02861028 chip=0x171314e4 > rev=0x02 > > hdr=0x00 > > vendor = 'Broadcom Corporation' > > device = 'Broadcom NetLink (TM) Fast Ethernet (BCM5906m)' > > class = network > > subclass = ethernet > > bar [10] = type Memory, range 64, base 0xf69f0000, size 65536, > > enabled > > 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) > > > > If somebody needs more info, just ask me for it and I'll try to answer > > as soon as I can. > > > > Adam, if you do file a PR, please let me know so I can follow it. > > > > Best Regards > > -- > > Blessings > > Gonzalo Nemmi > > > > > -- > Paul > From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 22:52:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A7EE106564A for ; Sun, 19 Jul 2009 22:52:18 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 32C2D8FC15 for ; Sun, 19 Jul 2009 22:52:18 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=PiioE0IkECKPiCO94QMA:9 a=RkhHhzEW_q1FjES_q0dL3rM6D7IA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 226695088; Sun, 19 Jul 2009 21:52:15 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 19 Jul 2009 21:51:59 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA1; KDE/4.2.4; i386; ; ) References: <7142D2AC7FF846A297A54BE55D821CF0@uk.tiscali.intl> In-Reply-To: <7142D2AC7FF846A297A54BE55D821CF0@uk.tiscali.intl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907192152.01076.hselasky@c2i.net> Cc: krad , current@freebsd.org Subject: Re: usb pen drive not detecting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 22:52:18 -0000 On Sunday 19 July 2009 20:01:48 krad wrote: > I cant get bsd to detect any usb pen drives on my system. I have a generic > kernel with a few extra options that i cant see Are your pen-drives detected if you set: sysctl hw.usb.ehci.no_hs=1 Before plugging the device? --HPS From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 22:53:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D225106566B for ; Sun, 19 Jul 2009 22:53:54 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f208.google.com (mail-bw0-f208.google.com [209.85.218.208]) by mx1.freebsd.org (Postfix) with ESMTP id DF8EC8FC15 for ; Sun, 19 Jul 2009 22:53:53 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz4 with SMTP id 4so1491903bwz.43 for ; Sun, 19 Jul 2009 15:53:52 -0700 (PDT) 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 :content-transfer-encoding; bh=vuqmBjIiaDMeUlMa/09avHlf4s87H8AxliBorCYUUYc=; b=OjmB2a12pJ+YQKtZVurc6stEL26FHTBbIQgxzmW/wJnd0Nkvn/3O0BUKRjDo/ehG0W KSHYCIVmkluEEWdd3fYtCQWASlIZfGWLdnh7W/9zcrb3wZWUSfJrbnMg9H8G0p7EU8fv HFTV5zthLPkt1LEXylnshfFOqxkgzLfDw63tU= 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:content-transfer-encoding; b=FQP3uwzrn8WgmvI87USGz1I2RJbrb2/+hjeJtk2Id9Yu3+W1lVgCreetMiF/hbEeK+ Hhr813G8gHO+iS6ecKH7am8/HZ30y84niNxpN95Ymn2Y98qJW5OtEWgg+SGDMe1lup7O t7YTVnr6MBHvyNZdMnNXGWEpUTq+xtZkB16/k= MIME-Version: 1.0 Received: by 10.204.101.2 with SMTP id a2mr3665529bko.104.1248044032722; Sun, 19 Jul 2009 15:53:52 -0700 (PDT) In-Reply-To: <19e9a5dc0907191530s679c0b37v49a836cc00bbf58a@mail.gmail.com> References: <4A5D27F2.50208@voicenet.com> <3a142e750907150020h712bfcecq89d5ccf3e00e302c@mail.gmail.com> <200907150713.47807.adamk@voicenet.com> <200907171743.11143.gnemmi@gmail.com> <3a142e750907171509o62c999c5o446bcd7cd576b9a5@mail.gmail.com> <19e9a5dc0907191530s679c0b37v49a836cc00bbf58a@mail.gmail.com> Date: Mon, 20 Jul 2009 00:53:52 +0200 Message-ID: <3a142e750907191553u1fd266a4q286e7168b74ee889@mail.gmail.com> From: "Paul B. Mahol" To: Gonzalo Nemmi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Adam K Kirchhoff Subject: Re: bge problems when resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 22:53:54 -0000 On 7/20/09, Gonzalo Nemmi wrote: > On Sat, Jul 18, 2009 at 12:09 AM, Paul B. Mahol wrote: > >> On 7/17/09, Gonzalo Nemmi wrote: >> > On Wednesday 15 July 2009 8:13:47 am Adam K Kirchhoff wrote: >> >> On Wednesday 15 July 2009 03:20:45 Paul B. Mahol wrote: >> >> > On 7/15/09, Adam K Kirchhoff wrote: >> >> > > Hello all, >> >> > > >> >> > > I have a Dell Latitude D610 laptop with 8.0-BETA1 installed. I >> >> > > hadn't tried suspend/resume for a while and decided to give it a >> >> > > shot. I was pleasantly surprised to see that I could suspend to >> >> > > ram, resume, and have a (relatively) working system (previously >> >> > > the display would never come back up and the serial console I had >> >> > > hooked up remained dead). Great job to everyone who helped make >> >> > > that possible. >> >> > > >> >> > > The only real issue that I seem to have now is that bge is >> >> > > completely unusable after resume. Another individual seems to >> >> > > have reported similar problems with bge and resume, but he also >> >> > > had other issues that apparently trumped his networking issues: >> >> > > >> >> > > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/0090 >> >> > >23.html >> >> > > >> >> > > Like him, resuming from suspend gives me: >> >> > > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, >> >> > > reg 0, val 32768) >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY read timed out (phy 1, >> >> > > reg 0, val 0xffffffff) >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, >> >> > > reg 24, val 3072) >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, >> >> > > reg 23, val 10) >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, >> >> > > reg 21, val 12555) >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, >> >> > > reg 23, val 8223) >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, >> >> > > reg 21, val 38150) >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, >> >> > > reg 23, val 16415) >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, >> >> > > reg 21, val 5346) >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, >> >> > > reg 24, val 1024) >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out (phy 1, >> >> > > reg 24, val 7) >> >> > > >> >> > > And so on and so forth. >> >> > > >> >> > > I thought that compiling if_bge as a module, unloading it before >> >> > > suspend, and reloading it after resume, might get this working. >> >> > > However, doing a "kldload if_bge" after the resume does nothing. >> >> > > Well, the module gets loaded, but the device doesn't show up. No >> >> > > errors from kldload, and there is nothing new in dmesg. >> >> > > >> >> > > Before the suspend, the device shows up as: >> >> > > >> >> > > bge0@pci0:2:0:0: class=0x020000 card=0x01821028 >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 >> >> > > vendor = 'Broadcom Corporation' >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express >> >> > > (BCM5750A1)' class = network >> >> > > subclass = ethernet >> >> > > >> >> > > After resuming, and reloading the module, it's: >> >> > > >> >> > > none1@pci0:2:0:0: class=0x020000 card=0x01821028 >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 >> >> > > vendor = 'Broadcom Corporation' >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express >> >> > > (BCM5750A1)' class = network >> >> > > subclass = ethernet >> >> > > >> >> > > If there are no ideas, I'll go ahead and open up a pr. I assume >> >> > > this is just one bug, since both problems (the PHY issues and the >> >> > > inability to reload the driver) are both related to the network >> >> > > device. >> >> > >> >> > Put this lines into loader.conf and reboot. >> >> > >> >> > hw.pci.do_power_nodriver="3" >> >> > hw.pci.do_power_resume="1" >> >> > >> >> > Now, before suspend, unload if_bge and some another driver (sound >> >> > drivers are best candidate) and load sound driver again, suspend >> >> > and resume. >> >> > Now loading if_bge should make it succesfully attach. >> >> >> >> Unfortunately, after doing this, reloading the if_bge driver causes >> >> the laptop to completely lock up... It gets as far as: >> >> >> >> bge0: > >> rev. 0xffff> >> >> mem 0xdfdf0000-0xdfdfffff irq 16 at device 0.0 on pci2 >> >> >> >> And then the entire machine hangs. I'm on ttyv0, so I'd see any >> >> kernel panic, but nothing like that happens. The screen stays on, >> >> but nothing else happens till I force a reboot. >> >> >> >> Adam >> > >> > Hi Adam, Paul ... >> > I'm the "another individual" from you OP. >> > I have the same problems you have regarding bge, but they weren't >> > trumped .. I just had an order of priorities ;) >> > >> > Anyways, I tried the solution Paul posted and, just as in your case, I >> > got a hard lock too ... >> > >> > I tried loading if_bge through /boot/loader.conf >> > Then issued a: >> > >> > kldunload if_bge coretemp >> >> coretemp is wrong module, it must be one of modules that attach to pci. >> > > Sorry Paul! > I gave it a go with snd_hda and I got the same result except that this time > I also got the following message: After unloading snd_hda you loaded it again before suspending? > > fwohci0: ... > firewire0: ... > fwohci0: ... > pci0: < multimedia HDA > at device 27.0 ( no driver attached ) > bge0 ... > > Then, the same hard lock :( > > Will install BETA2 today ! > > Best Regards > Gonzalo > > >> > acpiconf -s 3 >> > >> > machine suspended >> > >> > As soon as I woke it up I got the following message followed by a hard >> > lock: >> > >> > fwohci0: Phy 1394a available S400, 1 ports. >> > fwohci0: Link S400, max_rec 2048 bytes. >> > fwohci0: Initiate bus reset >> > fwohci0: fwohci_intr_core: BUS reset >> > fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, >> > CYCLEMASTER mode >> > firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) >> > firewire0: bus manager 0 >> > fwohci0: unrecoverable error >> > bge0: > > 0xffff> mem 0xf69f0000-0xf69fffff irq 17 at device 0.0 on pci9 >> > >> > All this happens on a Dell 1318, FreeBSD 8.0-BETA1, i386, Intel(R) >> > Celeron(R) CPU 560@2.13GHz. >> > >> > bge0@pci0:9:0:0: class=0x020000 card=0x02861028 chip=0x171314e4 >> rev=0x02 >> > hdr=0x00 >> > vendor = 'Broadcom Corporation' >> > device = 'Broadcom NetLink (TM) Fast Ethernet (BCM5906m)' >> > class = network >> > subclass = ethernet >> > bar [10] = type Memory, range 64, base 0xf69f0000, size 65536, >> > enabled >> > 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) >> > >> > If somebody needs more info, just ask me for it and I'll try to answer >> > as soon as I can. >> > >> > Adam, if you do file a PR, please let me know so I can follow it. >> > >> > Best Regards >> > -- >> > Blessings >> > Gonzalo Nemmi >> > >> >> >> -- >> Paul >> > -- Paul From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 23:07:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84A96106564A for ; Sun, 19 Jul 2009 23:07:34 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.freebsd.org (Postfix) with ESMTP id 083428FC23 for ; Sun, 19 Jul 2009 23:07:33 +0000 (UTC) (envelope-from michiel@boland.org) Received: from aja.boland.org (91-43-215.ftth.xms.internl.net [82.215.43.91]) (authenticated bits=0) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id n6JN7RCK086994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Jul 2009 01:07:32 +0200 (CEST) (envelope-from michiel@boland.org) Message-ID: <4A63A72F.9020809@boland.org> Date: Mon, 20 Jul 2009 01:07:27 +0200 From: Michiel Boland User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Subject: problems with make delete-old(-libs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 23:07:34 -0000 Hi. On recent -CURRENT make delete-old wants to delete the following files /usr/include/dev/usb/usbdi.h /usr/include/dev/usb/usbdi_util.h /usr/include/libusb.h As far as I can see these files are still built/installed Also, it looks like /usr/lib/libvgl.so.5 is missing from the OLD_LIBS Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Sun Jul 19 23:47:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3431F106566C; Sun, 19 Jul 2009 23:47:01 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: from pinus.izb.knu.ac.kr (pinus.izb.knu.ac.kr [IPv6:2001:470:1f05:5f6:3::1]) by mx1.freebsd.org (Postfix) with ESMTP id 940748FC1B; Sun, 19 Jul 2009 23:47:00 +0000 (UTC) (envelope-from bh@izb.knu.ac.kr) Received: from pinus.izb.knu.ac.kr (localhost.izb.knu.ac.kr [IPv6:::1]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id BFD9757359; Mon, 20 Jul 2009 08:46:58 +0900 (KST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=izb.knu.ac.kr; h=from:to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type:content-transfer-encoding; s= soyeomul; bh=8s0PlcHEdEHCMa+6bhilqoF38+WQjSlqyo1oH80nlmM=; b=En5 +7pV/j67unriucuqHmUyUwUmiqGbLBySywDPS6qo26CVBmjwYK1JMKEOY4Wz2PGh isdqM1Hy07IriW8q9X+rAsb3QEMF/vSK7PN2I3fSjJAh+0pMqfhndccg00zG0s+t +WPQQlKf2H2+qo6YOYfYTvII9uKOXW5NUpngPnBU= DomainKey-Signature: a=rsa-sha1; c=simple; d=izb.knu.ac.kr; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=soyeomul; b=RW IagcC0aeGC1uUsDOJ22f4XlJemx+exs43z3aQxI4OwAfw/iTLrxGHoX+46O2nwX7 2PNw/RRXAJpDyJ3/FbMWv1QD9lg7N1VK2EsQ0uYHbABXTAuHE30CBYWWdBjFhiRD sJHQ4loYkgnMg+gGR6mXc1GSb+WnPC1ZTSWdEwhkc= Received: from rhodo.izb.knu.ac.kr (rhodo.izb.knu.ac.kr [IPv6:2001:470:1f05:5f8:3::2]) by pinus.izb.knu.ac.kr (Postfix) with ESMTP id 539AB57355; Mon, 20 Jul 2009 08:46:58 +0900 (KST) Received: from betla.izb.knu.ac.kr (betla.izb.knu.ac.kr [IPv6:2001:470:1f05:5f6:3::a1]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: bh@izb.knu.ac.kr) by rhodo.izb.knu.ac.kr (Postfix) with ESMTP id A4F6D1CD6F; Mon, 20 Jul 2009 08:46:54 +0900 (KST) From: Byung-Hee HWANG To: Ken Smith References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> Date: Mon, 20 Jul 2009 08:46:44 +0900 In-Reply-To: <1248027417.14210.110.camel@neo.cse.buffalo.edu> (Ken Smith's message of "Sun, 19 Jul 2009 14:16:57 -0400") Message-ID: <864ot8s0bf.fsf@betla.izb.knu.ac.kr> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2009 23:47:01 -0000 Ken Smith writes: > First I want to apologize. This should have happened a bit sooner in > our release cycle than now. To be honest I had slipped into "We have > symbol versioning for our libraries now" mode. But only a few of the > libraries currently have that turned on and I sorta forgot we still need > to deal with all the shared libraries that do not have symbol versioning > enabled yet. Sorry for the hassle this will cause. > > Today with svn commit 195767 I bumped the version number of all > non-symbol-version-ed shared libraries in preparation for 8.0-REL. We > do this just in case API/ABI changes occured in head between 7.0 and > now, it lets us provide the older library versions as "compatibility > library ports" in the ports tree. > > The problem is that as of the next time you update a machine that had > been running -current you are best off reinstalling all ports or other > applications you have on the machine. When you reboot after doing the > update to the base system everything you have installed will still work > because the old shared library versions will still be there. However > anything you build on the machine after its base system gets updated > would be linked against the newer base system shared libraries but any > libraries that are part of ports or other applications (e.g. the Xorg > libraries) would have been linked against the older library versions. > You really don't want to leave things that way. > > The ports folks will be starting up a fresh package build now but it > takes some time for full package runs like this to complete, get > uploaded, and then propagate out to the mirrors. If you tend to use > pre-built packages instead of building them as ports yourself you might > want to just hold off on updating anything until they let us know a > fresh set of packages is available. And BETA3 will definitely be > scheduled for after the fresh set of packages becomes available. > > And again - sorry for the hassle. In my case, there is no upgrade with servers -- i have two servers (4.11-STABLE, 6.3-RELEASE). So plz don't worry. Only what i do upgrade is client which is my main desktop -- currently it runs as 7.2-RELEASE. Though! Don't worry because always i do upgrade as follow:=20 =3D> csup =3D> make world =3D> reboot =3D> (after coffee time)=20=20 =3D> pkg_delete -af =3D> pkg_add -r -v gnome (with several package) That's very fine and fast for me, anyway... --=20 Byung-Hee HWANG, KNU =E2=88=91 WWW: http://izb.knu.ac.kr/~bh/ "Come on, stick it in. Stick it in, Johnny, that's what you really want." -- Margot Ashton, "Chapter 1", page 12 From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 07:35:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A629C106566C for ; Mon, 20 Jul 2009 07:35:53 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 409118FC08 for ; Mon, 20 Jul 2009 07:35:52 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=gg2W7PyvkLb8p4ie143lBA==:17 a=zSSrKSnfKr09rhKs7nQA:9 a=dskoNndWul-nevr6UkFI5rgi1xYA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1280369423 for current@freebsd.org; Mon, 20 Jul 2009 09:35:50 +0200 To: current@freebsd.org Content-Disposition: inline From: Hans Petter Selasky Date: Mon, 20 Jul 2009 09:35:38 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200907200935.38910.hselasky@c2i.net> Cc: Subject: Re: usb pen drive not detecting X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 07:35:53 -0000 On Sunday 19 July 2009 23:16:03 chris scott wrote: > hmm, i notice it nobbles the port to 12 Meg, not ideal is this a know > issue? > It sounds like no IRQ's are generated on your EHCI controller, which is not directly an USB problem. You can try tuning: ACPI support on/off BIOS USB support on/off --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 09:14:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05CE1106566B for ; Mon, 20 Jul 2009 09:14:22 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id 8E49D8FC13 for ; Mon, 20 Jul 2009 09:14:21 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: by fxm1 with SMTP id 1so273398fxm.43 for ; Mon, 20 Jul 2009 02:14:20 -0700 (PDT) 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:content-transfer-encoding; bh=YK6hju7HhTGEx8PqxUx9ZL1hnGmVU7+Q6SkYm7jMdXw=; b=Vr1bqEhyptGPp4hcPBWRi0ZKTuO2QSTy4N2tHZd5WQEAzV00DJn8StzhWUCxEUwM/x GGS0HiTTEn5XoO3MSW9tEArg1NsVdIMQaKfEhMB1+9kIK0sOlJsWH1KM5Q3gSJTMSmvm E6lz88tkVr64V7Zy5m51ksYuxJBfQMwYqsYo8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=XFGWBYZc7W6NEUiGEV0bJ42MjSNYqJCoOUYMOVEGeXwlUxJBLl2v1e0U08g3VelV78 M6HEXXL0DZw8amcb6lXuveaGVqhNI+YILM+uiEtCzITi9w2kFKi1P+OnrueDXWwv8X3k Nfug+i3d/7fzMooZvxFo8jXoeThU9xDYWyWVs= MIME-Version: 1.0 Received: by 10.103.178.14 with SMTP id f14mr2121771mup.21.1248081260447; Mon, 20 Jul 2009 02:14:20 -0700 (PDT) Date: Mon, 20 Jul 2009 12:14:20 +0300 Message-ID: <9e20d71e0907200214s42fd7fa3k43f60ce2fd12f51d@mail.gmail.com> From: Artis Caune To: FreeBSD Current Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: unmount ZFS on shutdown, # KEYWORD: shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 09:14:22 -0000 Hi, When using ZFS as root file system, on shutdown it's reporting: Force unmount is experimental - report any problems. Force unmount was disabled, but then re-enabled. I also found this thread: http://www.freebsd.org/cgi/getmsg.cgi?fetch=863639+0+/usr/local/www/db/text/2007/cvs-src/20070415.cvs-src If I have 25+ ZFS file systems, console screen is full with those warnings, but anyway why just not to unmount unused file systems on shutdown and if there are any kind of problems with forced unmounts, then they will hurt only /, /var, /var/log, ... -- Artis Caune Everything should be made as simple as possible, but not simpler. From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 09:18:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09278106564A for ; Mon, 20 Jul 2009 09:18:24 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1118FC20 for ; Mon, 20 Jul 2009 09:18:23 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MSp0n-0008PK-KM for freebsd-current@freebsd.org; Mon, 20 Jul 2009 09:18:21 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Jul 2009 09:18:21 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 20 Jul 2009 09:18:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Ivan Voras Date: Mon, 20 Jul 2009 11:18:07 +0200 Lines: 28 Message-ID: References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> <1248028426.14210.114.camel@neo.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.21 (X11/20090615) In-Reply-To: <1248028426.14210.114.camel@neo.cse.buffalo.edu> Sender: news Cc: freebsd-stable@freebsd.org Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 09:18:24 -0000 Ken Smith wrote: > On Sun, 2009-07-19 at 20:26 +0200, Thomas Backman wrote: >> On Jul 19, 2009, at 20:16, Ken Smith wrote: >>> The problem is that as of the next time you update a machine that had >>> been running -current you are best off reinstalling all ports or other >>> applications you have on the machine. When you reboot after doing the >>> update to the base system everything you have installed will still >>> work >>> because the old shared library versions will still be there. However >>> anything you build on the machine after its base system gets updated >>> would be linked against the newer base system shared libraries but any >>> libraries that are part of ports or other applications (e.g. the Xorg >>> libraries) would have been linked against the older library versions. >>> You really don't want to leave things that way. >> So, to be clear: a fresh ports tree and "portupgrade -af" after >> building and installing r195767+ should be enough to solve any >> problems? (installkernel, installworld, reboot, portupgrade -af) >> > > Correct for those of you who let portupgrade do all the building for you > (which the example command you give does). The reason I'm being careful > is portupgrade can also be told to fetch pre-built packages. At the > moment that will not work, if you use that approach please hold off > until the ports folks let us know the packages have been rebuilt. Could we perhaps get a auto-generated libmap.conf to map either the new libraries to the old ones or (more useful) the old libraries to the new ones? From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 09:55:56 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49220106564A for ; Mon, 20 Jul 2009 09:55:56 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 034478FC18 for ; Mon, 20 Jul 2009 09:55:55 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by qw-out-2122.google.com with SMTP id 3so670201qwe.7 for ; Mon, 20 Jul 2009 02:55:55 -0700 (PDT) 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:content-type :content-transfer-encoding; bh=isEPSDtwxlIvcISHdboSfOAsXw8BJLv3QeTEj98FOI8=; b=NeJtK0qSQiy1occaX+ww3RnKRnEiNs0lRzSaLiibEB0S90zWVZ2jVr+yw8yxzs3Wph YiZ3IaolWk2xdBgxk75CUkiUdxMr0eS8Cg1tYCxWI5JorZEkZ5ag12G64UXI/tjEbAEe onhj7l4AKBR3i91/FkhqowT6IhNcpeK2oLh+A= 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 :content-type:content-transfer-encoding; b=f1v8PgR6VrvuOymQb0E1leOqFj7T2f8uf3YHA0IupWSF88bxC0xD9dZ3c35AJEHg9q tRoR/QiHtwbawUuIjPOlRsZcXFeNZ9P9+j6DdTOTOKw1fNlH7CmzFYGW1maL7owem4bm El/xRGhm+63t2Z957s7PX6SAcEK1c42RzuWoc= MIME-Version: 1.0 Received: by 10.229.100.13 with SMTP id w13mr793085qcn.62.1248083755351; Mon, 20 Jul 2009 02:55:55 -0700 (PDT) In-Reply-To: <200907191156.13273.hank@millerfarm.com> References: <200907191156.13273.hank@millerfarm.com> Date: Mon, 20 Jul 2009 11:55:55 +0200 Message-ID: <90a5caac0907200255v547bbbe7x7ef8bf0216ae525a@mail.gmail.com> From: Lucius Windschuh To: Henry Miller , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: intel 5100 wifi - not detected in Beta 2, can I get it working? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 09:55:56 -0000 Hi Henry. Before you try it: ndiswrapper doesn't work, either. I don't have the error messages at hand, sorry. Lucius From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 11:27:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79FC31065670 for ; Mon, 20 Jul 2009 11:27:12 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 41B618FC14 for ; Mon, 20 Jul 2009 11:27:12 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:281f:c799:4227:58d4] (unknown [IPv6:2001:7b8:3a7:0:281f:c799:4227:58d4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C0D355C59; Mon, 20 Jul 2009 13:27:10 +0200 (CEST) Message-ID: <4A645489.8050804@andric.com> Date: Mon, 20 Jul 2009 13:27:05 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.1pre) Gecko/20090716 Shredder/3.0b4pre MIME-Version: 1.0 To: Michiel Boland References: <4A63A72F.9020809@boland.org> In-Reply-To: <4A63A72F.9020809@boland.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: problems with make delete-old(-libs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 11:27:13 -0000 On 2009-07-20 01:07, Michiel Boland wrote: > Hi. On recent -CURRENT make delete-old wants to delete the following files > > /usr/include/dev/usb/usbdi.h > /usr/include/dev/usb/usbdi_util.h > /usr/include/libusb.h > > As far as I can see these files are still built/installed Yes indeed, they are installed during every installworld, but are still in ObsoleteFiles.inc; this looks like an oversight during the USB stack switch. From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 11:32:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0F06106566C for ; Mon, 20 Jul 2009 11:32:30 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swip.net [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 395FD8FC14 for ; Mon, 20 Jul 2009 11:32:29 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=gHsyN9T6crAA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=jc6aPawPoy8-AFLwiIwA:9 a=rh34sUkam1yeHqZ9jsysiFDzPEQA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1111565039; Mon, 20 Jul 2009 13:32:28 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 20 Jul 2009 13:32:14 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <4A63A72F.9020809@boland.org> <4A645489.8050804@andric.com> In-Reply-To: <4A645489.8050804@andric.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907201332.15530.hselasky@c2i.net> Cc: Michiel Boland , Dimitry Andric Subject: Re: problems with make delete-old(-libs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 11:32:30 -0000 On Monday 20 July 2009 13:27:05 Dimitry Andric wrote: > On 2009-07-20 01:07, Michiel Boland wrote: > > Hi. On recent -CURRENT make delete-old wants to delete the following > > files > > > > /usr/include/dev/usb/usbdi.h > > /usr/include/dev/usb/usbdi_util.h > > /usr/include/libusb.h > > > > As far as I can see these files are still built/installed > > Yes indeed, they are installed during every installworld, but are still > in ObsoleteFiles.inc; this looks like an oversight during the USB stack > switch. This is a known issue. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 05:09:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35477106566C for ; Mon, 20 Jul 2009 05:09:28 +0000 (UTC) (envelope-from guhi.zhang@gmail.com) Received: from mail-px0-f200.google.com (mail-px0-f200.google.com [209.85.216.200]) by mx1.freebsd.org (Postfix) with ESMTP id E46098FC13 for ; Mon, 20 Jul 2009 05:09:27 +0000 (UTC) (envelope-from guhi.zhang@gmail.com) Received: by pxi38 with SMTP id 38so1557877pxi.3 for ; Sun, 19 Jul 2009 22:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:references :subject:message-id:x-mailer:mime-version:content-type; bh=GqlVKEZUG39QDYCHwkj3FEIvfFrsl+PWTKsyCX+cYw4=; b=h3AWN+BEsF/tnBvylL8WXXN/SK482wKIaXc33+dCxsz+EWfECfMiWwy8HCg8HQjgxi 2m36Z0E2fdlbQM3uyge6qw0E4OWGd4E89kz/HEgYjpy6cPm38Koi0H0SZNB2gErXW8Dv AiIoMjePO+rhzYdPHs0asJAtlWaeX6Sdqa56c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:references:subject:message-id:x-mailer:mime-version :content-type; b=r9uzQrqSjgsxIuD6mXYQkgKeIdv4dTtYy8f1g018Hz2BODbujw/WWpWCOn5prMEfek gFEYsgfVmRh/yzT4g3HLzniYezSLzqzv8+DPY0GXShg+CyyeJzJxVkMd6sAZfOWucm1X P8KX4zmY2SZ96rVD+wr6O0jbge+lpAAiIxMEA= Received: by 10.114.234.13 with SMTP id g13mr6680339wah.52.1248065360981; Sun, 19 Jul 2009 21:49:20 -0700 (PDT) Received: from zhanghui-127 ([122.224.205.158]) by mx.google.com with ESMTPS id f20sm8280826waf.52.2009.07.19.21.49.13 (version=SSLv3 cipher=RC4-MD5); Sun, 19 Jul 2009 21:49:18 -0700 (PDT) Date: Mon, 20 Jul 2009 12:50:01 +0800 From: "guhi.zhang" To: "freebsd-current" References: <20090719120022.B265C1065678@hub.freebsd.org> Message-ID: <200907201249585313862@gmail.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 X-Mailman-Approved-At: Mon, 20 Jul 2009 12:04:38 +0000 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: freebsd-current Digest, Vol 300, Issue 16 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 05:09:28 -0000 SSBoYXZlIGRvd25sb2FkZWQgdGhlIEZyZWVCU0QgOC4wIGJldGEyIEFNRDY0IHZlcnNpb24sIGJ1 dCBpbiBteSBtYWluYm9hcmQgb2YgQU1EIDc5MEdYIGNoaXBzZXQoU291dGhCcmlkZ2UgU0I3NTAp LCBpdCBzdGlsbCBjYW4ndCBzdXBwb3J0IHRoZSBSQUlEIG1vZGUuIFdoZW4gSSBjaG9zZW4gdGhl IFJBSUQgbW9kZSBpbiBCSU9TLCBhbmQgSSBib290IGZyb20gdGhlIGNkcm9tLCBteSBjb21wdXRl ciByZXN0YXJ0ZWQgcmlnaHQgbm93Lg0KDQpXaGVuIGNhbiBGcmVlQlNEIHN1cHBvcnQgU0I3NTAn cyBSQUlEIG1vZGU/DQoNCg0KDQpndWhpLnpoYW5nIA0KMjAwOS0wNy0yMA0KDQoNCg0Kt6K8/sjL o7ogZnJlZWJzZC1jdXJyZW50LXJlcXVlc3QgDQq3osvNyrG85KO6IDIwMDktMDctMTkgIDIwOjAx OjAzIA0KytW8/sjLo7ogZnJlZWJzZC1jdXJyZW50IA0Ks63LzaO6IA0K1vfM4qO6IGZyZWVic2Qt Y3VycmVudCBEaWdlc3QsIFZvbCAzMDAsIElzc3VlIDE2IA0KIA0KU2VuZCBmcmVlYnNkLWN1cnJl bnQgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQpmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5v cmcNClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxkIFdpZGUgV2ViLCB2 aXNpdA0KaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1j dXJyZW50DQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9k eSAnaGVscCcgdG8NCmZyZWVic2QtY3VycmVudC1yZXF1ZXN0QGZyZWVic2Qub3JnDQpZb3UgY2Fu IHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCmZyZWVic2QtY3VycmVudC1v d25lckBmcmVlYnNkLm9yZw0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0 IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZpYw0KdGhhbiAiUmU6IENvbnRlbnRzIG9mIGZyZWVi c2QtY3VycmVudCBkaWdlc3QuLi4iDQpUb2RheSdzIFRvcGljczoNCiAgIDEuIFJlOiBDQVJQIGJy b2tlbiBvbiAtQ1VSUkVOVD8gKEJydWNlIFNpbXBzb24pDQogICAyLiBSZTogW25ld25mcy9jbGll bnRdIFNJR0lORk8gYWJvcnRzIHRyYW5zZmVyIGFuZCBwcm9kdWNlcw0KICAgICAgYHBlcm1pc3Np b24gZGVuaWVkJyAoUmljayBNYWNrbGVtKQ0KICAgMy4gTG90cyBvZiAiYXRoMDogYmFkIHNlcmll czAgaHdyYXRlIDB4MWIiIGluIDguMC1CRVRBMg0KICAgICAgKEFydGVtIE5hbHV6aG55eSkNCiAg IDQuIFJlOiBnc3RyaXBlIHByb2JsZW0gKE5lbmh1bV9kZV9Ob3MpDQogICA1LiBMb3RzIG9mICJh dGgwOiBiYWQgc2VyaWVzMCBod3JhdGUgMHgxYiIgaW4gOC4wLUJFVEEyDQogICAgICAoQXJ0ZW0g TmFsdXpobnl5KQ0KICAgNi4gbWFrZSBkaXN0cmlidXRpb24gUmU6IDguMC1CRVRBMiBBdmFpbGFi bGUgKE1hcnRlbiBWaWpuKQ0KICAgNy4gW1BBVENIXSBGaXggaW42cF9sZWF2ZV9ncm91cCgpIHBh bmljIGJ5IG1pc2JlaGF2aW5nIGFwcHMNCiAgICAgIChCcnVjZSBTaW1wc29uKQ0KICAgOC4gUmU6 IG1ha2UgZGlzdHJpYnV0aW9uIFJlOiA4LjAtQkVUQTIgQXZhaWxhYmxlIChEYW5pZWwgR2Vyem8p DQogICA5LiBSZTogbWFrZSBkaXN0cmlidXRpb24gUmU6IDguMC1CRVRBMiBBdmFpbGFibGUgKE1h cnRlbiBWaWpuKQ0KICAxMC4gW2J1Z10gWkZTIHp2b2wgZGV2IGVudHJ5IGRpc2FwcGVhcmluZyB1 cG9uIHJlYm9vdCAoTWNMb25lKQ0KICAxMS4gUmU6IExvdHMgb2YgImF0aDA6IGJhZCBzZXJpZXMw IGh3cmF0ZSAweDFiIiBpbiA4LjAtQkVUQTINCiAgICAgIChTYW0gTGVmZmxlcikNCiAgMTIuIFJl OiBbbmV3bmZzL2NsaWVudF0gU0lHSU5GTyBhYm9ydHMgdHJhbnNmZXIgYW5kIHByb2R1Y2VzDQog ICAgICBgcGVybWlzc2lvbiBkZW5pZWQnIChBbm9ueW1vdXMpDQogIDEzLiBTZW5kaW5nIG11bHRp Y2FzdCBkYXRhZ3JhbXMgYnJva2VuIChyZWdyZXNzaW9uKSAoUGlldGVyIGRlIEdvZWplKQ0KICAx NC4gU2lJMzEyNC8zMTMyLzM1MzEgQ0FNIGRyaXZlciAoQWxleGFuZGVyIE1vdGluKQ0KICAxNS4g OC4wLUJFVEEyIHN5c2luc3RhbGwgc3BlbGxpbmcgZXJyb3IgKERhdmlkIEJveWQpDQogIDE2LiBS ZTogTG90cyBvZiAiYXRoMDogYmFkIHNlcmllczAgaHdyYXRlIDB4MWIiIGluIDguMC1CRVRBMg0K ICAgICAgKEFydGVtIE5hbHV6aG55eSkNCiAgMTcuIFJlOiBTZW5kaW5nIG11bHRpY2FzdCBkYXRh Z3JhbXMgYnJva2VuIChyZWdyZXNzaW9uKQ0KICAgICAgKEJydWNlIFNpbXBzb24pDQogIDE4LiBS ZTogaXB3IGluIDguMC1CRVRBMSAoSmFtZXMgQnV0bGVyKQ0KICAxOS4gUmU6IEpvbGlldCBhbmQg cmVsZWFzZSBJU09zPyAoSm9obiBIYXkpDQogIDIwLiBSZTogSm9saWV0IGFuZCByZWxlYXNlIElT T3M/IChUaW0gS2llbnR6bGUpDQogIDIxLiBSZTogW2J1Z10gWkZTIHp2b2wgZGV2IGVudHJ5IGRp c2FwcGVhcmluZyB1cG9uIHJlYm9vdA0KICAgICAgKFRob21hcyBCYWNrbWFuKQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9t OiAgQnJ1Y2UgU2ltcHNvbiA8Ym1zQGluY3VuYWJ1bHVtLm5ldD4NClRvOiAgZEBkZWxwaGlqLm5l dA0KU3ViamVjdDogIFJlOiBDQVJQIGJyb2tlbiBvbiAtQ1VSUkVOVD8NCkRhdGU6ICBTYXQxOCBK dWwgMjAwOSAxNDoyOTozNSArMDEwMA0KWGluIExJIHdyb3RlOg0KPiAtLS0tLUJFR0lOIFBHUCBT SUdORUQgTUVTU0FHRS0tLS0tDQo+IEhhc2g6IFNIQTENCj4NCj4gSSBnb3QgaXQuICBJdCB3YXMg dGhlIGNhY2hlZCBsbGVudHJ5IHRoYXQgcHJldmVudGluZyBldGhlcl9vdXRwdXQoKSB0bw0KPiBj aG9vc2UgdGhlIHJpZ2h0IGJyb2FkY2FzdC9tdWx0aWNhc3QgYWRkcmVzcyBhbmQgdXNlIHRoZSBk ZWZhdWx0DQo+IGdhdGV3YXkncyBMMiBhZGRyZXNzLiAgSGVyZSBpcyBhIHByb3Bvc2VkIHBhdGNo Lg0KPiAgIA0KVGhpcyBtaWdodCBmaXggdGhlIGxheWVyIDIgYWRkcmVzcyBicmVha2FnZSBzZWVu IGluIElHTVB2MyB0cmFmZmljIGJ5IA0KaXByZWJlZ0AgaW4gVk13YXJlLCB3aGljaCBkaWRuJ3Qg c2VlbSB0byBjb21lIGZyb20gdGhlIG11bHRpY2FzdCBjb2RlIA0KZnVydGhlciB1cCBpbiB0aGUg c3RhY2ssIGFzIGl0IGhhZG4ndCBjaGFuZ2VkIHNpbmNlIHRlc3RpbmcuDQp0aGFua3MsDQpCTVMN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpGcm9tOiAgUmljayBNYWNrbGVtIDxybWFja2xlbUB1b2d1ZWxwaC5jYT4NClRv OiAgQW5vbnltb3VzIDxzd2VsbC5rQGdtYWlsLmNvbT4NClN1YmplY3Q6ICBSZTogW25ld25mcy9j bGllbnRdIFNJR0lORk8gYWJvcnRzIHRyYW5zZmVyIGFuZCBwcm9kdWNlcyBgcGVybWlzc2lvbmRl bmllZCcNCkRhdGU6ICBTYXQxOCBKdWwgMjAwOSAwOTozNTozMyAtMDQwMCAoRURUKQ0KT24gU2F0 LCAxOCBKdWwgMjAwOSwgQW5vbnltb3VzIHdyb3RlOg0KPg0KPiBZZXAsIEkgY2FuIHJlcHJvZHVj ZSBpdCBhcyBlYXNpbHkgb24gOC4wLUJFVEEyIHNuYXBzaG90IHVuZGVyIHFlbXUNCj4NCj4gIyB1 bmFtZSAtdm0NCj4gRnJlZUJTRCA4LjAtQkVUQTIgIzA6IFdlZCBKdWwgMTUgMjM6MjU6MzAgVVRD IDIwMDkNCj4gcm9vdEBhbG1laWRhLmNzZS5idWZmYWxvLmVkdTovdXNyL29iai91c3Ivc3JjL3N5 cy9HRU5FUklDICBpMzg2DQo+DQpJJ2xsIHRyeSB0byBnZXQgYXJvdW5kIHRvIHRlc3RpbmcgaXQg dGhpcyB3ZWVrZW5kLCBidXQgaWYgeW91J2QNCmxpa2UgdG8gdGVzdCB0aGUgZm9sbG93aW5nIHBh dGNoLCBJIHRoaW5rIGl0IG1pZ2h0IGZpeCB0aGUgcHJvYmxlbS4NClRoZSBuZXcga3JwYyBvbmx5 IGNoZWNrcyBORlNNTlRfSU5UIGF0IGNvbm5lY3QgYW5kIG5vdCBldmVyeSBycGMuDQpyaWNrDQpw czogVGhlIGxpbmUgI3MgYXNzdW1lIHRoZSBvdGhlciBwYXRjaCB5b3UgdGVzdGVkIGlzIGFscmVh ZHkgYXBwbGllZC4NCi0tLSB1bnRlc3RlZCBleHAuIG5mcyBjbGllbnQgcGF0Y2ggLS0tDQotLS0g ZnMvbmZzY2xpZW50L25mc19jbHZmc29wcy5jLnNhdjIgMjAwOS0wNy0xOCAwOToxOTowNy4wMDAw MDAwMDAgLTA0MDANCisrKyBmcy9uZnNjbGllbnQvbmZzX2NsdmZzb3BzLmMgMjAwOS0wNy0xOCAw OToyOToxNC4wMDAwMDAwMDAgLTA0MDANCkBAIC0xMDM3LDcgKzEwMzcsNyBAQA0KICB7DQogICBz dHJ1Y3QgbmZzbW91bnQgKm5tcDsNCiAgIHN0cnVjdCBuZnNub2RlICpucDsNCi0gaW50IGVycm9y LCB0cnljbnQsIHJldCwgY2xlYXJpbnRyOw0KKyBpbnQgZXJyb3IsIHRyeWNudCwgcmV0Ow0KICAg c3RydWN0IG5mc3ZhdHRyIG5mc3ZhOw0KICAgc3RhdGljIHVfaW50NjRfdCBjbHZhbCA9IDA7DQpA QCAtMTE1MiwyMCArMTE1Miw4IEBADQogICBubXAtPm5tX3NvY2tyZXEubnJfdmVycyA9IE5GU19W RVIyOw0KLSAvKg0KLSAgKiBGb3IgQ29ubmVjdGlvbiBiYXNlZCBzb2NrZXRzIChUQ1AsLi4uKSBk byB0aGUgY29ubmVjdCBoZXJlLA0KLSAgKiBidXQgbWFrZSBpdCBpbnRlcnJ1cHRpYmxlLCBldmVu IGZvciBub24taW50ZXJ1cHRpYmxlIG1vdW50cy4NCi0gICovDQotIGlmICgobm1wLT5ubV9mbGFn ICYgTkZTTU5UX0lOVCkgPT0gMCkgew0KLSBubXAtPm5tX2ZsYWcgfD0gTkZTTU5UX0lOVDsNCi0g Y2xlYXJpbnRyID0gMTsNCi0gfSBlbHNlIHsNCi0gY2xlYXJpbnRyID0gMDsNCi0gfQ0KICAgaWYg KChlcnJvciA9IG5ld25mc19jb25uZWN0KG5tcCwgJm5tcC0+bm1fc29ja3JlcSwgY3JlZCwgdGQs IDApKSkNCiAgIGdvdG8gYmFkOw0KLSBpZiAoY2xlYXJpbnRyKQ0KLSBubXAtPm5tX2ZsYWcgJj0g fk5GU01OVF9JTlQ7DQogICAvKg0KICAgICogQSByZWZlcmVuY2UgY291bnQgaXMgbmVlZGVkIG9u IHRoZSBuZnNub2RlIHJlcHJlc2VudGluZyB0aGUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiAgQXJ0ZW0gTmFs dXpobnl5IDx0dXRAbmhhbW9uLmNvbS51YT4NClRvOiAgY3VycmVudCA8Y3VycmVudEBmcmVlYnNk Lm9yZz4NClN1YmplY3Q6ICBMb3RzIG9mICJhdGgwOiBiYWQgc2VyaWVzMCBod3JhdGUgMHgxYiIg aW4gOC4wLUJFVEEyDQpEYXRlOiAgU2F0MTggSnVsIDIwMDkgMTY6NDg6MjggKzAzMDANCkhpLA0K QWZ0ZXIgNy4yLVJMRUFTRSAtPiA4LjAtQkVUQTIgdXBkYXRlIG15IG5vdGVib29rIHdpcmVsZXNz IHdvcmtzDQp3aXRob3V0IHByb2JsZW1zIGJ1dCB0aGVyZSBhcmUgbG90cyBvZiBhbm5veWluZyAi YXRoMDogYmFkIHNlcmllczANCmh3cmF0ZSAweDFiIi1saWtlIG1lc3NhZ2VzIG9uIGNvbnNvbGUg bm93Lg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KcGNpY29uZjoNCmF0aDBAcGNpMDoxOjA6MDogICAgICAgIGNsYXNzPTB4MDIwMDAwIGNhcmQ9 MHgzMDY1MTY4YyBjaGlwPTB4MDAxYzE2OGMNCnJldj0weDAxIGhkcj0weDAwDQogICB2ZW5kb3Ig ICAgID0gJ0F0aGVyb3MgQ29tbXVuaWNhdGlvbnMgSW5jLicNCiAgIGRldmljZSAgICAgPQ0KJ0hE QVVESU9GVU5DXzAxJlZFTl8xMDk1JkRFVl8xMzkyJlNVQlNZU18xMDI4MDI0MiZSRVZfMTAwMA0K KFVTQlZJRF8xNDdFJlBJRF8yMDE2NSZCNzFBNDQ2JjAmMSknDQogICBjbGFzcyAgICAgID0gbmV0 d29yaw0KICAgc3ViY2xhc3MgICA9IGV0aGVybmV0DQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpzeXNjdGxzOg0KaHcuYXRoLmJzdHVjazogNA0K aHcuYXRoLnR4YnVmOiAyMDANCmh3LmF0aC5yeGJ1ZjogNDANCmh3LmF0aC5yZXNldGNhbDogMTIw MA0KaHcuYXRoLnNob3J0Y2FsOiAxMDANCmh3LmF0aC5sb25nY2FsOiAzMA0KaHcuYXRoLmhhbC5z d2JhX2JhY2tvZmY6IDANCmh3LmF0aC5oYWwuc3dfYnJ0OiAxMA0KaHcuYXRoLmhhbC5kbWFfYnJ0 OiAyDQpkZXYuYXRoLjAuJWRlc2M6IEF0aGVyb3MgNTQyNC8yNDI0DQpkZXYuYXRoLjAuJWRyaXZl cjogYXRoDQpkZXYuYXRoLjAuJWxvY2F0aW9uOiBzbG90PTAgZnVuY3Rpb249MA0KZGV2LmF0aC4w LiVwbnBpbmZvOiB2ZW5kb3I9MHgxNjhjIGRldmljZT0weDAwMWMgc3VidmVuZG9yPTB4MTY4Yw0K c3ViZGV2aWNlPTB4MzA2NSBjbGFzcz0weDAyMDAwMA0KZGV2LmF0aC4wLiVwYXJlbnQ6IHBjaTEN CmRldi5hdGguMC5zbW9vdGhpbmdfcmF0ZTogOTUNCmRldi5hdGguMC5zYW1wbGVfcmF0ZTogMTAN CmRldi5hdGguMC5zYW1wbGVfc3RhdHM6IDANCmRldi5hdGguMC5jb3VudHJ5Y29kZTogMA0KZGV2 LmF0aC4wLnJlZ2RvbWFpbjogOTYNCmRldi5hdGguMC5zbG90dGltZTogOQ0KZGV2LmF0aC4wLmFj a3RpbWVvdXQ6IDQ4DQpkZXYuYXRoLjAuY3RzdGltZW91dDogNDgNCmRldi5hdGguMC5zb2Z0bGVk OiAwDQpkZXYuYXRoLjAubGVkcGluOiAwDQpkZXYuYXRoLjAubGVkb246IDANCmRldi5hdGguMC5s ZWRpZGxlOiAyNzAwDQpkZXYuYXRoLjAudHhhbnRlbm5hOiAwDQpkZXYuYXRoLjAucnhhbnRlbm5h OiAxDQpkZXYuYXRoLjAuZGl2ZXJzaXR5OiAxDQpkZXYuYXRoLjAudHhpbnRycGVyaW9kOiA1DQpk ZXYuYXRoLjAuZGlhZzogMA0KZGV2LmF0aC4wLnRwc2NhbGU6IDANCmRldi5hdGguMC50cGM6IDAN CmRldi5hdGguMC50cGFjazogNjMNCmRldi5hdGguMC50cGN0czogNjMNCmRldi5hdGguMC5yZnNp bGVudDogMQ0KZGV2LmF0aC4wLnJma2lsbDogMQ0KZGV2LmF0aC4wLmludG1pdDogMQ0KZGV2LmF0 aC4wLm1vbnBhc3M6IDI0DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpkbWVzZzoNCmF0aDA6IDxBdGhlcm9zIDU0MjQvMjQyND4gbWVtIDB4YmY3 ZjAwMDAtMHhiZjdmZmZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBvbiBwY2kxDQphdGgwOiBbSVRI UkVBRF0NCmF0aDA6IEFSNTQxMyBtYWMgMTAuMCBSRjU0MjQgcGh5IDYuMQ0KYXRoMDogYmFkIHNl cmllczAgaHdyYXRlIDB4MWIsIHRyaWVzIDEgdHNfc3RhdHVzIDB4MA0KYXRoMDogYmFkIHNlcmll czAgaHdyYXRlIDB4MWIsIHRyaWVzIDEgdHNfc3RhdHVzIDB4MA0KYXRoMDogYmFkIHNlcmllczMg aHdyYXRlIDB4MWIsIHRyaWVzIDIgdHNfc3RhdHVzIDB4MA0KYXRoMDogYmFkIHNlcmllczAgaHdy YXRlIDB4MWIsIHRyaWVzIDEgdHNfc3RhdHVzIDB4MA0KYXRoMDogYmFkIHNlcmllczIgaHdyYXRl IDB4MWMsIHRyaWVzIDQgdHNfc3RhdHVzIDB4MA0KYXRoMDogYmFkIHNlcmllczMgaHdyYXRlIDB4 MWIsIHRyaWVzIDIgdHNfc3RhdHVzIDB4MA0KYXRoMDogYmFkIHNlcmllczMgaHdyYXRlIDB4MWIs IHRyaWVzIDIgdHNfc3RhdHVzIDB4MA0KYXRoMDogYmFkIHNlcmllczMgaHdyYXRlIDB4MWIsIHRy aWVzIDIgdHNfc3RhdHVzIDB4MA0KYXRoMDogYmFkIHNlcmllczMgaHdyYXRlIDB4MWIsIHRyaWVz IDIgdHNfc3RhdHVzIDB4MA0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQ0KaWZjb25maWc6DQphdGgwOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxS VU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBtZXRyaWMgMCBtdHUgMjI5MA0KICAgICAgIGV0aGVy IDAwOjE1OmFmOnh4Onh4Onh4DQogICAgICAgbWVkaWE6IElFRUUgODAyLjExIFdpcmVsZXNzIEV0 aGVybmV0IGF1dG9zZWxlY3QgbW9kZSAxMWcNCiAgICAgICBzdGF0dXM6IGFzc29jaWF0ZWQNCnds YW4wOiBmbGFncz04ODQzPFVQLEJST0FEQ0FTVCxSVU5OSU5HLFNJTVBMRVgsTVVMVElDQVNUPiBt ZXRyaWMgMCBtdHUgMTUwMA0KICAgICAgIGV0aGVyIDAwOjE1OmFmOnh4Onh4Onh4DQogICAgICAg aW5ldCB4eC54eC54eC54eCBuZXRtYXNrIDB4ZmZmZmZmZjggYnJvYWRjYXN0IHh4Lnh4Lnh4Lnh4 DQogICAgICAgbWVkaWE6IElFRUUgODAyLjExIFdpcmVsZXNzIEV0aGVybmV0IE9GRE0vNTRNYnBz IG1vZGUgMTFnDQogICAgICAgc3RhdHVzOiBhc3NvY2lhdGVkDQogICAgICAgc3NpZCB4eCBjaGFu bmVsIDMgKDI0MjIgTWh6IDExZykgYnNzaWQgMDA6MWY6MWY6eHg6eHg6eHgNCiAgICAgICByZWdk b21haW4gOTYgaW5kb29yIGVjbSBhdXRobW9kZSBXUEEyLzgwMi4xMWkgcHJpdmFjeSBPTg0KICAg ICAgIGRlZnR4a2V5IFVOREVGIFRLSVAgMjoxMjgtYml0IHR4cG93ZXIgMjAgYm1pc3MgNyBzY2Fu dmFsaWQgNDUwIGJnc2Nhbg0KICAgICAgIGJnc2NhbmludHZsIDMwMCBiZ3NjYW5pZGxlIDI1MCBy b2FtOnJzc2kgNyByb2FtOnJhdGUgNSBwcm90bW9kZSBDVFMNCiAgICAgICB3bWUgcm9hbWluZyBN QU5VQUwNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0NCi0tDQpBcnRlbSBOYWx1emhueXkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiAgIk5lbmh1bV9kZV9Ob3Mi IDxtYXRoZXVzQGV0ZXJuYW1lbnRlLmluZm8+DQpUbzogIGZyZWVic2QtY3VycmVudEBmcmVlYnNk Lm9yZw0KU3ViamVjdDogIFJlOiBnc3RyaXBlIHByb2JsZW0NCkRhdGU6ICBTYXQxOCBKdWwgMjAw OSAxMTowNjozMyAtMDMwMCAoQlJUKQ0KT24gRnJpLCBKdWx5IDE3LCAyMDA5IDIxOjAxLCBOZW5o dW1fZGVfTm9zIHdyb3RlOg0KPg0KPiBPbiBGcmksIEp1bHkgMTcsIDIwMDkgMDk6MDcsIE5lbmh1 bV9kZV9Ob3Mgd3JvdGU6DQo+Pg0KPj4gT24gRnJpLCBKdWx5IDE3LCAyMDA5IDA3OjIwLCBJdmFu IFZvcmFzIHdyb3RlOg0KPj4+IE5lbmh1bV9kZV9Ob3Mgd3JvdGU6DQo+Pj4+IGhhaWwsDQo+Pj4+ DQo+Pj4+IEkgaGF2ZSBhIHByb2JsZW0gd2l0aCBnc3RyaXBlIG9uIHRvZGF5IHN0YWJsZS4gSSBj cmVhdGVkIHRoaXMgc3RyaXBlDQo+Pj4+IHVzaW5nIGEgYml0IG1vcmUgb2xkIHN0YWJsZSAodHdv IHdlZWtzIHRvcHMpIGFuZCBpdCBjYW4ndCBiZSByZWFkIG9uDQo+Pj4+IG9sZA0KPj4+PiBzdGFi bGUgKGZyb20gMzAvMTIvMjAwOCkuIFNvIEkgcmVjcmVhdGVkIGluIDgtQkVUQTEgYW5kIEkgY291 bGQgbW91bnQNCj4+Pj4gYW5kIHNlZSBmaWxlcy4gV2hlbiBJIHRyaWVkIGFnYWluIG9uIDMwLzEy LzIwMDggc3RhYmxlIGFuZCB0b2RheXMsIG9uDQo+Pj4+IFBJSSBtYWNoaW5lIChpMzg2KToNCj4+ Pg0KPj4+IFNvIHlvdXIgcHJvYmxlbSBpcyB0aGF0Og0KPj4+DQo+Pj4gYSkgeW91IGNyZWF0ZWQg YSBnc3RyaXBlIGFycmF5IG9uIGEgcmVjZW50IFNUQUJMRSAodHdvIHdlZWtzIGFnbykgYW5kDQo+ Pj4gaXQNCj4+PiB3YXMgZmluZQ0KPj4+IGIpIHlvdSB0cmllZCB0byB1c2UgaXQgd2l0aCBhbiBv bGQgU1RBQkxFICgzMC4xMi4yMDA4LikgYW5kIGl0IGRpZG4ndA0KPj4+IHdvcmsNCj4+PiBjKSB5 b3UgdHJpZWQgdG8gdXNlIGl0IHdpdGggdG9kYXkncyBTVEFCTEUgYW5kIGl0IGRpZG4ndCB3b3Jr DQo+Pj4gZCkgaXQgd29ya3Mgd2l0aCA4LUJFVEExDQo+Pj4gPw0KPj4NCj4+IGl0cyBxdWl0ZSB0 aGlzLiB0aGUgc3RyaXBlIGp1c3QgdmFuaXNoZXMgd2hlbiBJIHRyeSB0byBzZWUgaXQgaW4gYW55 DQo+PiBzdGFibGUuIGFuZCBpZiBJIGNyZWF0ZSBpbiBzdGFibGUsIGEgcmVib290IG1ha2VzIGl0 IGdvIHdheSA6KA0KPj4NCj4+PiBUaGUgb25seSB0aGluZyB0aGF0IGNvbWVzIHRvIG15IG1pbmQg aXMgdGhhdCBkdXJpbmcgeW91ciB0ZXN0cyB5b3UgaGF2ZQ0KPj4+IGNoYW5nZWQgdGhlIHN0cmlw ZSBzaXplLCBtYWtpbmcgdGhlIGZpbGUgc3lzdGVtIGRhdGEgdW51c2FibGUgKGFuZA0KPj4+IHVu bW91bnRhYmxlKS4NCj4+Pg0KPj4+PiBbcm9vdEB4eHggfl0jIGdzdHJpcGUgc3RhdHVzDQo+Pj4+ ICAgICAgICAgICBOYW1lICBTdGF0dXMgIENvbXBvbmVudHMNCj4+Pj4gc3RyaXBlL3N0cmlwZTAg ICAgICBVUCAgYWQ0czINCj4+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgYWQ2czINCj4+Pg0K Pj4+PiBtb3VudDogL2Rldi9zdHJpcGUvc3RyaXBlMCA6IEludmFsaWQgYXJndW1lbnQNCj4+Pj4N Cj4+Pj4gb24gOC1CRVRBMSBpdCB3b3JrcywgYnV0IGNhbid0IGNyZWF0ZSBzdHJpcGUgb24gaXQg YW5kIHVzZSBvbiB0aGlzDQo+Pj4+IHN0YWJsZSBib3ggdGhvdWdoLiB0aGUgc3RyaXBlIGFscmVh ZHkgaGFzIGZpbGVzICEgc28gYW55dGhpbmcgd2VpcmQNCj4+Pj4gY291bGQgbWFrZSBtZSBsb29z ZSBteSBkYXRhIC4uLg0KPj4+DQo+Pj4gQXJlIHlvdSBzYXlpbmcgeW91IHdvbid0IHVzZSA4LUJF VEExIGJlY2F1c2UgeW91IGZlYXIgdGhlcmUgbWF5IGJlDQo+Pj4gcHJvYmxlbXMgd2l0aCBpdD8g SWYgc28sIHlvdSBzaG91bGRuJ3Qgd29ycnkgc28gbXVjaCAtIDgtQ1VSUkVOVCBpcw0KPj4+IHZl cnkNCj4+PiBzdGFibGUuDQo+Pg0KPj4gSSBrbm93IGl0IGlzLiA4LUNVUlJFTlQgaXMgZ3JlYXQg cmVhbGx5IChJIHVzZSBpdCBpbiBvdGhlciBwbGFjZXMpLiBteQ0KPj4gbWFpbiBjb25jZXJuIGlz IHRoYXQgdGhpcyBpcyBhIHNlcnZlciB3aXRoIG1haWwvZG5zL2RoY3AvYXBhY2hlL3NvbWUNCj4+ IG90aGVyDQo+PiBzZXJ2aWNlcyBJIGZvcmdvdCBhbmQgY2hhbmdpbmcgdG8gOC1CRVRBIG1heSBu ZWVkIHRvIHJlY29tcGlsZSBhbGwNCj4+IHRoaW5ncywNCj4+IGFuZCBuZWVkIHRpbWUgSSBkb24n dCBoYXZlIHJpZ2h0IG5vdyAuLi4NCj4+DQo+PiBjYW4gSSBqdXN0IHVwZGF0ZSBhbmQgdXNlIGFs bCBzb2Z0d2FyZSBjb21waWxlZCBmb3IgNy4xLVBSRVJFTEVBU0UgPw0KPj4NCj4+IHRoYW5rcywN Cj4+DQo+PiBtYXRoZXVzDQo+DQo+IHRoaW5zIGhlcmUganVzdCBnb3Qgd2VpcmQuIEkgZGlkIHVw ZGF0ZWQgdG8gOC1CRVRBMi4gc2FtZSBwcm9ibGVtIHRob3VnaC4NCj4gc28gSSBqdXN0IHRob3Vn aHQgaXQgd2FzIHByb2JsZW0gd2hlbiBJIGNyZWF0ZSBhIHN0cmlwZSBpbiBhbWQ2NCBtYWNoaW5l DQo+IGFuZCB0cnkgdG8gdXNlIGl0IG9uIGkzODYuDQo+DQo+IEkgdGhlbiBwdXQgdGhlIGRyaXZl cyBpbiB0aGUgYW1kNjQgbWFjaGluZSwgYW5kIGl0IGRpZCB3b3JrZWQgZmluZSwgYWZ0ZXINCj4g YW5vdGhlciBnc3RyaXBlIGNyZWF0ZSBjb21tYW5kLiBzbyBJIHJlYm9vdGVkIHRoZSBhbWQ2NCBt YWNoaW5lIHRvIHNlZSBpZg0KPiBhZnRlciByZWJvb3QgdGhlIHN0cmlwZSB3b3VsZCBiZSB0aGVy ZS4gZ3Vlc3Mgd2hhdCAuLi4gbm90aGluZyB0aGVyZSAuLi4NCj4NCj4gSSB1c2VkIGdtaXJyb3Ig YW5kIGdzdHJpcGUgZm9yIGFib3V0IGFuIHllYXIsIG5vIHByb2JsZW0uIGNvdXBsZSBvZiBtb250 aHMNCj4gYWdvIEkgaGFkIGEgcHJvYmxlbSBhbmQgaGFkIHRvIGNoYW5nZSB0aGUgcGMgKGRlYWQg b25lKS4gc28gYWxsIGNoYW5nZWQsDQo+IHVzaW5nIHNpbDMxMTQgc2F0YSBwY2kgY2FyZCBub3cg YW5kIFBJSSAzMDAgTUh6LiBub3cgdGhlIGRpc2tzIGJlaGF2ZSBsaWtlDQo+IHRoaXMuDQo+DQo+ IGlmIGFueW9uZSBoYXMgYW55IGxlYWRzLCBJJ20gbW92aW5nIGRhdGEgZnJvbSB0aGUgZGlza3Mg bm93IC4uLiBjYW4gdGVzdA0KPiB0aG91Z2guDQo+DQo+IHRoYW5rcywNCj4NCj4gbWF0aGV1cw0K bW92aW5nIHRvIGN1cnJlbnRAIGFzIGl0IGlzIHJ1bm5pbmcgbm93IDgtQkVUQTIuDQpJJ2QgcmVh bGx5IGxpa2UgdG8gaGVhciBvbiB0aGlzOiBJIGp1c3Qgd2lwZWQgb3V0IGFsbCBkaXNrcyBkYXRh LCBkZWxldGVkDQphbGwgdHdvIHBhcnRpdGlvbnMgYW5kIHJlY3JlYXRlZCB0aGVtLiBjcmVhdGVk IGFub3RoZXIgc3RyaXBlIHVzaW5nIHRoZQ0Kc2FtZSBhcmd1bWVudHMgYXMgdGhlIG90aGVyIHRp bWVzIGJ1dCBpdCBrZWVwcyB2YW5pc2hpbmcgd2hlbiBJIHJlYm9vdC4NCmZyZXNoIDgtQkVUQTIg YW5kIG9sZCBwYyBpbiBpMzg2LiB3aGF0IHRvIGRvIG5vdyA/IGdpdmUgdXAgPw0KSSBjaGFuZ2Vk IHRoZSBwYXJ0aXRpb25zIHNpemUsIHRvIG5vdCBtYXRjaCB0aGUgc2FtZSBoZCBzZWN0b3JzIGFu ZA0Kbm90aGluZy4gYW5kIG5vdyBJIGRpZG4ndCB1c2UgdGhlIGFkMTZzMiwgYnV0IGFkMTZzMmQg KEkgY3JlYXRlZCBzb21lDQpsYWJlbHMpIGFuZCBub3RoaW5nIGFnYWluIC4uLg0KaXMgdGhlcmUg YSBsaW1pdCBvZiB1c2luZyBnc3RyaXBlID8gaGFyZHdhcmUgZm9yIHRoYXQgbWF0dGVyID8NCmF0 YXBjaTFAcGNpMDowOjEzOjA6IGNsYXNzPTB4MDEwNDAwIGNhcmQ9MHg2MTE0MTA5NSBjaGlwPTB4 MzExNDEwOTUNCnJldj0weDAyIGhkcj0weDAwDQogICAgdmVuZG9yICAgICA9ICdTaWxpY29uIElt YWdlIEluYyAoV2FzOiBDTUQgVGVjaG5vbG9neSBJbmMpJw0KICAgIGRldmljZSAgICAgPSAnU0FU QUxpbmsvU0FUQVJhaWQgQ29udHJvbGxlciAoU2lsIDMxMTQpJw0KICAgIGNsYXNzICAgICAgPSBt YXNzIHN0b3JhZ2UNCiAgICBzdWJjbGFzcyAgID0gUkFJRA0KYW55IGluZm8gbmVlZGVkIHBsZWFz ZSBhc2suDQp0d28gc2VhZ2F0ZSA3NTBHQiBzYXRhIGRpc2tzIDEyMEdCIGZyb20gYm90aCBvbiBn bWlycm9yIGFuZCB3aGF0IGxlZnRzIG9uDQpnc3RyaXBlLg0KdGhhbmtzLA0KbWF0aGV1cw0KLS0g DQpXZSB3aWxsIGNhbGwgeW91IGN5Z251cywNClRoZSBHb2Qgb2YgYmFsYW5jZSB5b3Ugc2hhbGwg YmUNCkE6IEJlY2F1c2UgaXQgbWVzc2VzIHVwIHRoZSBvcmRlciBpbiB3aGljaCBwZW9wbGUgbm9y bWFsbHkgcmVhZCB0ZXh0Lg0KUTogV2h5IGlzIHRvcC1wb3N0aW5nIHN1Y2ggYSBiYWQgdGhpbmc/ DQpodHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1Bvc3Rpbmdfc3R5bGUNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpG cm9tOiAgQXJ0ZW0gTmFsdXpobnl5IDxhcnRlbUBhbHRlcmF0ZWxlY29tLmNvbT4NClRvOiAgY3Vy cmVudEBmcmVlYnNkLm9yZw0KU3ViamVjdDogIExvdHMgb2YgImF0aDA6IGJhZCBzZXJpZXMwIGh3 cmF0ZSAweDFiIiBpbiA4LjAtQkVUQTINCkRhdGU6ICBTYXQxOCBKdWwgMjAwOSAxNjo0NDo1NiAr MDMwMA0KSGksDQpBZnRlciA3LjItUkxFQVNFIC0+IDguMC1CRVRBMiB1cGRhdGUgbXkgbm90ZWJv b2sgd2lyZWxlc3Mgd29ya3MNCndpdGhvdXQgcHJvYmxlbXMgYnV0IHRoZXJlIGFyZSBsb3RzIG9m IGFubm95aW5nICJhdGgwOiBiYWQgc2VyaWVzMA0KaHdyYXRlIDB4MWIiLWxpa2UgbWVzc2FnZXMg b24gY29uc29sZSBub3cuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQpwY2ljb25mOg0KYXRoMEBwY2kwOjE6MDowOiBjbGFzcz0weDAyMDAwMCBj YXJkPTB4MzA2NTE2OGMgY2hpcD0weDAwMWMxNjhjDQpyZXY9MHgwMSBoZHI9MHgwMA0KICAgIHZl bmRvciAgICAgPSAnQXRoZXJvcyBDb21tdW5pY2F0aW9ucyBJbmMuJw0KICAgIGRldmljZSAgICAg PQ0KJ0hEQVVESU9GVU5DXzAxJlZFTl8xMDk1JkRFVl8xMzkyJlNVQlNZU18xMDI4MDI0MiZSRVZf MTAwMA0KKFVTQlZJRF8xNDdFJlBJRF8yMDE2NSZCNzFBNDQ2JjAmMSknDQogICAgY2xhc3MgICAg ICA9IG5ldHdvcmsNCiAgICBzdWJjbGFzcyAgID0gZXRoZXJuZXQNCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCnN5c2N0bHM6DQpody5hdGguYnN0 dWNrOiA0DQpody5hdGgudHhidWY6IDIwMA0KaHcuYXRoLnJ4YnVmOiA0MA0KaHcuYXRoLnJlc2V0 Y2FsOiAxMjAwDQpody5hdGguc2hvcnRjYWw6IDEwMA0KaHcuYXRoLmxvbmdjYWw6IDMwDQpody5h dGguaGFsLnN3YmFfYmFja29mZjogMA0KaHcuYXRoLmhhbC5zd19icnQ6IDEwDQpody5hdGguaGFs LmRtYV9icnQ6IDINCmRldi5hdGguMC4lZGVzYzogQXRoZXJvcyA1NDI0LzI0MjQNCmRldi5hdGgu MC4lZHJpdmVyOiBhdGgNCmRldi5hdGguMC4lbG9jYXRpb246IHNsb3Q9MCBmdW5jdGlvbj0wDQpk ZXYuYXRoLjAuJXBucGluZm86IHZlbmRvcj0weDE2OGMgZGV2aWNlPTB4MDAxYyBzdWJ2ZW5kb3I9 MHgxNjhjDQpzdWJkZXZpY2U9MHgzMDY1IGNsYXNzPTB4MDIwMDAwDQpkZXYuYXRoLjAuJXBhcmVu dDogcGNpMQ0KZGV2LmF0aC4wLnNtb290aGluZ19yYXRlOiA5NQ0KZGV2LmF0aC4wLnNhbXBsZV9y YXRlOiAxMA0KZGV2LmF0aC4wLnNhbXBsZV9zdGF0czogMA0KZGV2LmF0aC4wLmNvdW50cnljb2Rl OiAwDQpkZXYuYXRoLjAucmVnZG9tYWluOiA5Ng0KZGV2LmF0aC4wLnNsb3R0aW1lOiA5DQpkZXYu YXRoLjAuYWNrdGltZW91dDogNDgNCmRldi5hdGguMC5jdHN0aW1lb3V0OiA0OA0KZGV2LmF0aC4w LnNvZnRsZWQ6IDANCmRldi5hdGguMC5sZWRwaW46IDANCmRldi5hdGguMC5sZWRvbjogMA0KZGV2 LmF0aC4wLmxlZGlkbGU6IDI3MDANCmRldi5hdGguMC50eGFudGVubmE6IDANCmRldi5hdGguMC5y eGFudGVubmE6IDENCmRldi5hdGguMC5kaXZlcnNpdHk6IDENCmRldi5hdGguMC50eGludHJwZXJp b2Q6IDUNCmRldi5hdGguMC5kaWFnOiAwDQpkZXYuYXRoLjAudHBzY2FsZTogMA0KZGV2LmF0aC4w LnRwYzogMA0KZGV2LmF0aC4wLnRwYWNrOiA2Mw0KZGV2LmF0aC4wLnRwY3RzOiA2Mw0KZGV2LmF0 aC4wLnJmc2lsZW50OiAxDQpkZXYuYXRoLjAucmZraWxsOiAxDQpkZXYuYXRoLjAuaW50bWl0OiAx DQpkZXYuYXRoLjAubW9ucGFzczogMjQNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0NCmRtZXNnOg0KYXRoMDogPEF0aGVyb3MgNTQyNC8yNDI0PiBt ZW0gMHhiZjdmMDAwMC0weGJmN2ZmZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTENCmF0 aDA6IFtJVEhSRUFEXQ0KYXRoMDogQVI1NDEzIG1hYyAxMC4wIFJGNTQyNCBwaHkgNi4xDQphdGgw OiBiYWQgc2VyaWVzMCBod3JhdGUgMHgxYiwgdHJpZXMgMSB0c19zdGF0dXMgMHgwDQphdGgwOiBi YWQgc2VyaWVzMCBod3JhdGUgMHgxYiwgdHJpZXMgMSB0c19zdGF0dXMgMHgwDQphdGgwOiBiYWQg c2VyaWVzMyBod3JhdGUgMHgxYiwgdHJpZXMgMiB0c19zdGF0dXMgMHgwDQphdGgwOiBiYWQgc2Vy aWVzMCBod3JhdGUgMHgxYiwgdHJpZXMgMSB0c19zdGF0dXMgMHgwDQphdGgwOiBiYWQgc2VyaWVz MiBod3JhdGUgMHgxYywgdHJpZXMgNCB0c19zdGF0dXMgMHgwDQphdGgwOiBiYWQgc2VyaWVzMyBo d3JhdGUgMHgxYiwgdHJpZXMgMiB0c19zdGF0dXMgMHgwDQphdGgwOiBiYWQgc2VyaWVzMyBod3Jh dGUgMHgxYiwgdHJpZXMgMiB0c19zdGF0dXMgMHgwDQphdGgwOiBiYWQgc2VyaWVzMyBod3JhdGUg MHgxYiwgdHJpZXMgMiB0c19zdGF0dXMgMHgwDQphdGgwOiBiYWQgc2VyaWVzMyBod3JhdGUgMHgx YiwgdHJpZXMgMiB0c19zdGF0dXMgMHgwDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQppZmNvbmZpZzoNCmF0aDA6IGZsYWdzPTg4NDM8VVAsQlJP QURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAyMjkwDQpldGhl ciAwMDoxNTphZjp4eDp4eDp4eA0KbWVkaWE6IElFRUUgODAyLjExIFdpcmVsZXNzIEV0aGVybmV0 IGF1dG9zZWxlY3QgbW9kZSAxMWcNCnN0YXR1czogYXNzb2NpYXRlZA0Kd2xhbjA6IGZsYWdzPTg4 NDM8VVAsQlJPQURDQVNULFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAx NTAwDQpldGhlciAwMDoxNTphZjp4eDp4eDp4eA0KaW5ldCB4eC54eC54eC54eCBuZXRtYXNrIDB4 ZmZmZmZmZjggYnJvYWRjYXN0IHh4Lnh4Lnh4Lnh4DQptZWRpYTogSUVFRSA4MDIuMTEgV2lyZWxl c3MgRXRoZXJuZXQgT0ZETS81NE1icHMgbW9kZSAxMWcNCnN0YXR1czogYXNzb2NpYXRlZA0Kc3Np ZCB4eCBjaGFubmVsIDMgKDI0MjIgTWh6IDExZykgYnNzaWQgMDA6MWY6MWY6eHg6eHg6eHgNCnJl Z2RvbWFpbiA5NiBpbmRvb3IgZWNtIGF1dGhtb2RlIFdQQTIvODAyLjExaSBwcml2YWN5IE9ODQpk ZWZ0eGtleSBVTkRFRiBUS0lQIDI6MTI4LWJpdCB0eHBvd2VyIDIwIGJtaXNzIDcgc2NhbnZhbGlk IDQ1MCBiZ3NjYW4NCmJnc2NhbmludHZsIDMwMCBiZ3NjYW5pZGxlIDI1MCByb2FtOnJzc2kgNyBy b2FtOnJhdGUgNSBwcm90bW9kZSBDVFMNCndtZSByb2FtaW5nIE1BTlVBTA0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KLS0gDQpBcnRlbSBOYWx1 emhueXkNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpGcm9tOiAgTWFydGVuIFZpam4gPGluZm9AbWFydGVudmlqbi5ubD4N ClRvOiAgS2VuIFNtaXRoIDxrZW5zbWl0aEBjc2UuQnVmZmFsby5FRFU+DQpTdWJqZWN0OiAgbWFr ZSBkaXN0cmlidXRpb24gUmU6IDguMC1CRVRBMiBBdmFpbGFibGUNCkRhdGU6ICBTYXQxOCBKdWwg MjAwOSAxODowNTowMCArMDIwMA0KY2QgL3Vzci9zcmMNCm1ha2UgZGlzdHJpYnV0aW9uIGdpdmVz IGFuIGVycm9yDQpkYXRhIGJlbG93LA0Ka2lkbiByZWdhcmRzLA0KTWFydGVuDQptYWtlIGluc3Rh bGx3b3JsZCBERVNURElSPS91c3IvdGZ0cGJvb3QxLw0KPHNuaXA+PG9rPg0KbWFrZSBpbnN0YWxs a2VybmVsIERFU1RESVI9L3Vzci90ZnRwYm9vdDEvDQo8c25pcD5vaz4NCiMgbWFrZSBkaXN0cmli dXRpb24gREVTVERJUj0vdXNyL3RmdHBib290MS8NCmNkIC91c3Ivc3JjL2V0YzsgTUFLRU9CSkRJ UlBSRUZJWD0vdXNyL29iaiAgTUFDSElORV9BUkNIPWkzODYNCk1BQ0hJTkU9aTM4NiAgQ1BVVFlQ RT0NCkdST0ZGX0JJTl9QQVRIPS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvYmluDQpH Uk9GRl9GT05UX1BBVEg9L3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zaGFyZS9ncm9m Zl9mb250DQpHUk9GRl9UTUFDX1BBVEg9L3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9z aGFyZS90bWFjDQpQQVRIPS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2JpbjovdXNy L29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2JpbjovdXNyL29iai91c3Ivc3JjL3RtcC9sZWdh Y3kvdXNyL2dhbWVzOi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9zYmluOi91c3Ivb2JqL3Vzci9z cmMvdG1wL3Vzci9iaW46L3Vzci9vYmovdXNyL3NyYy90bXAvdXNyL2dhbWVzOi9zYmluOi9iaW46 L3Vzci9zYmluOi91c3IvYmluIG1ha2UgZGlzdHJpYnV0aW9uDQpjZCAvdXNyL3NyYy9ldGM7ICBp bnN0YWxsIC1vIHJvb3QgLWcgd2hlZWwgLW0gNjQ0ICBhdXRoLmNvbmYgIGNyb250YWINCmRldmQu Y29uZiBkZXZmcy5jb25mICBkZGIuY29uZiBkaGNsaWVudC5jb25mIGRpc2t0YWIgZmJ0YWIgIGZ0 cHVzZXJzDQpnZXR0eXRhYiBncm91cCAgaG9zdHMgaG9zdHMuYWxsb3cgaG9zdHMuZXF1aXYgIGlu ZXRkLmNvbmYgbGliYWxpYXMuY29uZg0KbG9naW4uYWNjZXNzIGxvZ2luLmNvbmYgbWFjLmNvbmYg bW90ZCAgbmV0Y29uZmlnIG5ldHdvcmsuc3ViciBuZXR3b3Jrcw0KbmV3c3lzbG9nLmNvbmYgbnNz d2l0Y2guY29uZiAgcGhvbmVzIHByb2ZpbGUgcHJvdG9jb2xzICByYw0KcmMuYnNkZXh0ZW5kZWQg cmMuZmlyZXdhbGwgcmMuZmlyZXdhbGw2IHJjLmluaXRkaXNrbGVzcyAgcmMuc2VuZG1haWwNCnJj LnNodXRkb3duICByYy5zdWJyIHJlbW90ZSBycGMgc2VydmljZXMgc2hlbGxzICBzeXNjdGwuY29u ZiBzeXNsb2cuY29uZg0KZXRjLmkzODYvdHR5cyBhbWQubWFwIGFwbWQuY29uZiBzbm1wZC5jb25m aWcNCmZyZWVic2QtdXBkYXRlLmNvbmYgL3Vzci9zcmMvZXRjLy4uL3Vzci5iaW4vbG9jYXRlL2xv Y2F0ZS9sb2NhdGUucmMNCmhvc3RzLmxwZA0KcHJpbnRjYXAgL3Vzci9zcmMvZXRjLy4uL3Vzci5i aW4vbWFpbC9taXNjL21haWwucmMgL3Vzci9zcmMvZXRjLy4uL2dudS91c3IuYmluL21hbi9tYW5w YXRoL21hbnBhdGguY29uZmlnIG50cC5jb25mIG5zY2QuY29uZiBwb3J0c25hcC5jb25mIHBmLm9z IGNzaC5jc2hyYyBjc2gubG9naW4gY3NoLmxvZ291dCByZWdkb21haW4ueG1sIC91c3IvdGZ0cGJv b3QxLy9ldGM7ICBjYXBfbWtkYiAtbCAvdXNyL3RmdHBib290MS8vZXRjL2xvZ2luLmNvbmY7ICBp bnN0YWxsIC1vIHJvb3QgLWcgd2hlZWwgLW0gNzU1ICBuZXRzdGFydCBwY2NhcmRfZXRoZXIgcmMu c3VzcGVuZCByYy5yZXN1bWUgL3Vzci90ZnRwYm9vdDEvL2V0YzsgIGluc3RhbGwgLW8gcm9vdCAt ZyB3aGVlbCAtbSA2MDAgIG1hc3Rlci5wYXNzd2QgbnNtYi5jb25mIG9waWVhY2Nlc3MgL3Vzci90 ZnRwYm9vdDEvL2V0YzsNCnB3ZF9ta2RiIC1MIC1pIC1wDQotZCAvdXNyL3RmdHBib290MS8vZXRj ICAvdXNyL3RmdHBib290MS8vZXRjL21hc3Rlci5wYXNzd2QNCmNkIC91c3Ivc3JjL2V0Yy9ibHVl dG9vdGg7IG1ha2UgaW5zdGFsbA0KaW5zdGFsbCAtbyByb290ICAtZyB3aGVlbCAtbSA2MDANCmhj c2VjZC5jb25mICAvdXNyL3RmdHBib290MS8vZXRjL2JsdWV0b290aC9oY3NlY2QuY29uZg0KaW5z dGFsbCAtbyByb290ICAtZyB3aGVlbCAtbSA2NDQNCmhvc3RzICAvdXNyL3RmdHBib290MS8vZXRj L2JsdWV0b290aC9ob3N0cw0KaW5zdGFsbCAtbyByb290IC1nIHdoZWVsICAtbSA0NDQgcHJvdG9j b2xzIC91c3IvdGZ0cGJvb3QxLy9ldGMvYmx1ZXRvb3RoDQpjZCAvdXNyL3NyYy9ldGMvZGVmYXVs dHM7IG1ha2UgaW5zdGFsbA0KaW5zdGFsbCAtbyByb290IC1nIHdoZWVsICAtbSA0NDQgYmx1ZXRv b3RoLmRldmljZS5jb25mIGRldmZzLnJ1bGVzDQpwZXJpb2RpYy5jb25mIHJjLmNvbmYgL3Vzci90 ZnRwYm9vdDEvL2V0Yy9kZWZhdWx0cw0KY2QgL3Vzci9zcmMvZXRjL2RldmQ7IG1ha2UgaW5zdGFs bA0KaW5zdGFsbCAtbyByb290IC1nIHdoZWVsICAtbSA2NDQgYXN1cy5jb25mIC91c3IvdGZ0cGJv b3QxLy9ldGMvZGV2ZA0KY2QgL3Vzci9zcmMvZXRjL2dzczsgbWFrZSBpbnN0YWxsDQppbnN0YWxs IC1vIHJvb3QgLWcgd2hlZWwgIC1tIDQ0NCBtZWNoIHFvcCAvdXNyL3RmdHBib290MS8vZXRjL2dz cw0KY2QgL3Vzci9zcmMvZXRjL3BlcmlvZGljOyBtYWtlIGluc3RhbGwNCj09PT4gZGFpbHkgKGlu c3RhbGwpDQppbnN0YWxsIC1vIHJvb3QgLWcgd2hlZWwgIC1tIDc1NSAxMDAuY2xlYW4tZGlza3Mg MTEwLmNsZWFuLXRtcHMNCjEyMC5jbGVhbi1wcmVzZXJ2ZSAyMDAuYmFja3VwLXBhc3N3ZCAzMzAu bmV3cyA0MDAuc3RhdHVzLWRpc2tzDQo0MDQuc3RhdHVzLXpmcyA0MDUuc3RhdHVzLWF0YS1yYWlk IDQwNi5zdGF0dXMtZ21pcnJvciA0MDcuc3RhdHVzLWdyYWlkMw0KNDA4LnN0YXR1cy1nc3RyaXBl IDQwOS5zdGF0dXMtZ2NvbmNhdCA0MjAuc3RhdHVzLW5ldHdvcmsNCjQ1MC5zdGF0dXMtc2VjdXJp dHkgOTk5LmxvY2FsIDMxMC5hY2NvdW50aW5nIDQ3MC5zdGF0dXMtbmFtZWQNCjMwMC5jYWxlbmRh ciAxMzAuY2xlYW4tbXNncyA0ODAuc3RhdHVzLW50cGQgMTQwLmNsZWFuLXJ3aG8NCjQzMC5zdGF0 dXMtcndobyAxNTAuY2xlYW4taG9zdHN0YXQgMjEwLmJhY2t1cC1hbGlhc2VzIDQ0MC5zdGF0dXMt bWFpbHENCjQ2MC5zdGF0dXMtbWFpbC1yZWplY3RzIDUwMC5xdWV1ZXJ1biAvdXNyL3RmdHBib290 MS8vZXRjL3BlcmlvZGljL2RhaWx5DQo9PT0+IHNlY3VyaXR5IChpbnN0YWxsKQ0KaW5zdGFsbCAt byByb290IC1nIHdoZWVsICAtbSA3NTUgMTAwLmNoa3NldHVpZCAyMDAuY2hrbW91bnRzIDMwMC5j aGt1aWQwDQo0MDAucGFzc3dkbGVzcyA0MTAubG9naW5jaGVjayA3MDAua2VybmVsbXNnIDgwMC5s b2dpbmZhaWwgOTAwLnRjcHdyYXANCnNlY3VyaXR5LmZ1bmN0aW9ucyA1MTAuaXBmZGVuaWVkIDUw MC5pcGZ3ZGVuaWVkIDU1MC5pcGZ3bGltaXQNCjUyMC5wZmRlbmllZCAvdXNyL3RmdHBib290MS8v ZXRjL3BlcmlvZGljL3NlY3VyaXR5DQo9PT0+IHdlZWtseSAoaW5zdGFsbCkNCmluc3RhbGwgLW8g cm9vdCAtZyB3aGVlbCAgLW0gNzU1IDM0MC5ub2lkIDk5OS5sb2NhbCAzMTAubG9jYXRlDQozMjAu d2hhdGlzIDMzMC5jYXRtYW4gNDAwLnN0YXR1cy1wa2cgL3Vzci90ZnRwYm9vdDEvL2V0Yy9wZXJp b2RpYy93ZWVrbHkNCj09PT4gbW9udGhseSAoaW5zdGFsbCkNCmluc3RhbGwgLW8gcm9vdCAtZyB3 aGVlbCAgLW0gNzU1IDk5OS5sb2NhbA0KMjAwLmFjY291bnRpbmcgL3Vzci90ZnRwYm9vdDEvL2V0 Yy9wZXJpb2RpYy9tb250aGx5DQpjZCAvdXNyL3NyYy9ldGMvcmMuZDsgbWFrZSBpbnN0YWxsDQpp bnN0YWxsIC1vIHJvb3QgLWcgd2hlZWwgIC1tIDU1NSBEQUVNT04gRklMRVNZU1RFTVMgTE9HSU4g TkVUV09SS0lORw0KU0VSVkVSUyBhYmkgYWNjb3VudGluZyBhZGRzd2FwIGFkamtlcm50eiBhbWQg YXBtIGFwbWQgYXJjaGRlcCBhdG0xIGF0bTINCmF0bTMgYXVkaXRkIGF1dG9fbGlua2xvY2FsIGJn ZnNjayBibHVldG9vdGggYm9vdHBhcmFtcyBicmlkZ2UgYnNubXBkDQpidGhpZGQgY2NkIGNsZWFu dmFyIGNsZWFydG1wIGNyb24gZGRiIGRlZmF1bHRyb3V0ZSBkZXZkIGRldmZzIGRoY2xpZW50DQpk bWVzZyBkdW1wb24gZW5jc3dhcCBmc2NrIGZ0cC1wcm94eSBmdHBkIGdiZGUgZ2VsaSBnZWxpMiBn c3NkIGhjc2VjZA0KaG9zdGFwZCBob3N0aWQgaG9zdG5hbWUgaW5ldGQgaW5pdHJhbmRvbSBpcDZh ZGRyY3RsIGlwNmZ3IGlwZmlsdGVyIGlwZnMNCmlwZncgaXBtb24gaXBuYXQgaXBzZWMgaXB4cm91 dGVkIGphaWwga2FkbWluZCBrZXJiZXJvcyBrZXlzZXJ2IGtsZHhyZWYNCmtwYXNzd2RkIGxkY29u ZmlnIGxvY2FsIGxvY2FscGtnIGxvY2tkIGxwZCBtaXhlciBtb3RkIG1vdW50Y3JpdGxvY2FsDQpt b3VudGNyaXRyZW1vdGUgbW91bnRsYXRlIG1kY29uZmlnIG1kY29uZmlnMiBtb3VudGQgbW91c2Vk IG1yb3V0ZTZkDQptcm91dGVkIG1zZ3MgbmFtZWQgbmF0ZCBuZXRpZiBuZXRvcHRpb25zIG5ldHdv cmtfaXB2NiBuZXdzeXNsb2cNCm5mc2NsaWVudCBuZnNjYmQgbmZzZCBuZnNzZXJ2ZXIgbmZzdXNl cmQgbmlzZG9tYWluIG5zc3dpdGNoIG50cGQgbnRwZGF0ZQ0Kb3RoZXJtdGEgcGYgcGZsb2cgcGZz eW5jIHBvd2VyZCBwb3dlcl9wcm9maWxlIHBwcCBwcHBvZWQgcHdjaGVjayBxdW90YQ0KcmFuZG9t IHJhcnBkIHJlc29sdiByZmNvbW1fcHBwZF9zZXJ2ZXIgcm9vdCByb3V0ZTZkIHJvdXRlZCByb3V0 aW5nDQpycGNiaW5kIHJ0YWR2ZCByd2hvIHNhdmVjb3JlIHNkcGQgc2VjdXJlbGV2ZWwgc2VuZG1h aWwgc2VyaWFsIHNwcHAgc3RhdGQNCnN3YXAxIHN5c2NvbnMgc3lzY3RsIHN5c2xvZ2QgdGltZWQg dG1wIHVnaWRmdyB2YXIgdmlyZWNvdmVyIHdhdGNoZG9nZA0Kd3BhX3N1cHBsaWNhbnQgeXBiaW5k IHlwcGFzc3dkZCB5cHNlcnYgeXBzZXQgeXB1cGRhdGVkIHlweGZyZCB6ZnMgc3NoZA0KbnNjZCAv dXNyL3RmdHBib290MS8vZXRjL3JjLmQNCmNkIC91c3Ivc3JjL2V0Yy8uLi9nbnUvdXNyLmJpbi9z ZW5kLXByOyBtYWtlIGV0Yy1nbmF0cy1mcmVlZmFsbA0KaW5zdGFsbCAtbyByb290IC1nIHdoZWVs IC1tDQowNjQ0ICAvdXNyL3NyYy9nbnUvdXNyLmJpbi9zZW5kLXByL2NhdGVnb3JpZXMgIC91c3Iv dGZ0cGJvb3QxLy9ldGMvZ25hdHMvZnJlZWZhbGwNCmNkIC91c3Ivc3JjL2V0Yy8uLi9zaGFyZS90 ZXJtY2FwOyBtYWtlIGV0Yy10ZXJtY2FwDQpsbiAtZnMgL3Vzci9zaGFyZS9taXNjL3Rlcm1jYXAg L3Vzci90ZnRwYm9vdDEvL2V0Yy90ZXJtY2FwDQpjZCAvdXNyL3NyYy9ldGMvLi4vdXNyLnNiaW4v cm10OyBtYWtlIGV0Yy1ybXQNCnJtIC1mIC91c3IvdGZ0cGJvb3QxLy9ldGMvcm10DQpsbiAtcyAv dXNyL3NiaW4vcm10IC91c3IvdGZ0cGJvb3QxLy9ldGMvcm10DQpjZCAvdXNyL3NyYy9ldGMvcGFt LmQ7IG1ha2UgaW5zdGFsbA0KaW5zdGFsbCAtbyByb290ICAtZyB3aGVlbCAtbSA0NDQNClJFQURN RSAgL3Vzci90ZnRwYm9vdDEvL2V0Yy9wYW0uZC9SRUFETUUNCm1ha2U6IGRvbid0IGtub3cgaG93 IHRvIG1ha2UgZ2RtLiBTdG9wDQoqKiogRXJyb3IgY29kZSAyDQpTdG9wIGluIC91c3Ivc3JjL2V0 Yy4NCioqKiBFcnJvciBjb2RlIDENClN0b3AgaW4gL3Vzci9zcmMuDQoqKiogRXJyb3IgY29kZSAx DQpTdG9wIGluIC91c3Ivc3JjLg0KIyBkbWVzZyANCkNvcHlyaWdodCAoYykgMTk5Mi0yMDA5IFRo ZSBGcmVlQlNEIFByb2plY3QuDQpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYs IDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQNCiAgICAgICAgVGhlIFJlZ2VudHMg b2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0cw0KcmVzZXJ2ZWQuDQpG cmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlv bi4NCkZyZWVCU0QgOC4wLUJFVEEyICM3IHIxOTU3NTA6IFNhdCBKdWwgMTggMTI6MTg6MDIgVVRD IDIwMDkNCiAgICByb290QDovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDDQpXQVJOSU5HOiBX SVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJmb3JtYW5jZS4NClRpbWVj b3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwDQpDUFU6IEludGVs KFIpIENlbGVyb24oUikgQ1BVICAgICAgICAgIDQ0MCAgQCAyLjAwR0h6ICgxOTk1LjAxLU1Ieg0K Njg2LWNsYXNzIENQVSkNCiAgT3JpZ2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHgxMDY2MSAg U3RlcHBpbmcgPSAxDQpGZWF0dXJlcz0weGFmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1Is UEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gs RFRTLEFDUEksTU1YLEZYU1IsU1NFLFNTRTIsU1MsVE0sUEJFPg0KICBGZWF0dXJlczI9MHhlMzFk PFNTRTMsRFRFUzY0LE1PTixEU19DUEwsVE0yLFNTU0UzLENYMTYseFRQUixQRENNPg0KICBBTUQg RmVhdHVyZXM9MHgyMDEwMDAwMDxOWCxMTT4NCiAgQU1EIEZlYXR1cmVzMj0weDE8TEFIRj4NCiAg VFNDOiBQLXN0YXRlIGludmFyaWFudA0KcmVhbCBtZW1vcnkgID0gNTM2ODcwOTEyICg1MTIgTUIp DQphdmFpbCBtZW1vcnkgPSAxMDIyNjg5MjgwICg5NzUgTUIpDQpBQ1BJIEFQSUMgVGFibGU6IDxJ bnRlbFIgQVdSREFDUEk+DQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhl cmJvYXJkDQprYmQxIGF0IGtiZG11eDANCmFjcGkwOiA8SW50ZWxSIEFXUkRBQ1BJPiBvbiBtb3Ro ZXJib2FyZA0KYWNwaTA6IFtJVEhSRUFEXQ0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQpDQph Y3BpMDogcmVzZXJ2YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZA0KYWNwaTA6IHJlc2VydmF0 aW9uIG9mIDEwMDAwMCwgM2Y1ZTAwMDAgKDMpIGZhaWxlZA0KVGltZWNvdW50ZXIgIkFDUEktZmFz dCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwDQphY3BpX3RpbWVyMDogPDI0LWJp dCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDQwOC0weDQwYiBvbiBhY3BpMA0KYWNwaV9i dXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMA0KcGNpMDogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjANCnBjaWIxOiA8UENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMS4wIG9uIHBj aTANCnBjaTE6IDxQQ0kgYnVzPiBvbiBwY2liMQ0KcGNpYjI6IDxQQ0ktUENJIGJyaWRnZT4gYXQg ZGV2aWNlIDAuMCBvbiBwY2kxDQpwY2kyOiA8UENJIGJ1cz4gb24gcGNpYjINCnBjaWIzOiA8UENJ LVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjIgb24gcGNpMQ0KcGNpMzogPFBDSSBidXM+IG9uIHBj aWIzDQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweGZmMDAtMHhmZjA3 IG1lbQ0KMHhmY2MwMDAwMC0weGZjY2ZmZmZmLDB4ZDAwMDAwMDAtMHhkZmZmZmZmZiBpcnEgMTYg YXQgZGV2aWNlIDIuMCBvbiBwY2kwDQphZ3AwOiA8SW50ZWwgUTk2NSBTVkdBIGNvbnRyb2xsZXI+ IG9uIHZnYXBjaTANCmFncDA6IGRldGVjdGVkIDc2NzZrIHN0b2xlbiBtZW1vcnkNCmFncDA6IGFw ZXJ0dXJlIHNpemUgaXMgMjU2TQ0KcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYg YXQgZGV2aWNlIDI4LjAgb24gcGNpMA0KcGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQNCmVt MDogPEludGVsKFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA2LjkuMTQ+IHBvcnQgMHg1 ZjAwLTB4NWYxZg0KbWVtIDB4ZmRlZTAwMDAtMHhmZGVmZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDAu MCBvbiBwY2k0DQplbTA6IFVzaW5nIE1TSSBpbnRlcnJ1cHQNCmVtMDogW0ZJTFRFUl0NCmVtMDog RXRoZXJuZXQgYWRkcmVzczogMDA6MTA6ZjM6MTU6YWU6ZTgNCnBjaWI1OiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gaXJxIDE3IGF0IGRldmljZSAyOC4xIG9uIHBjaTANCnBjaTU6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWI1DQplbTE6IDxJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24g Ni45LjE0PiBwb3J0IDB4ZGYwMC0weGRmMWYNCm1lbSAweGZkY2UwMDAwLTB4ZmRjZmZmZmYgaXJx IDE3IGF0IGRldmljZSAwLjAgb24gcGNpNQ0KZW0xOiBVc2luZyBNU0kgaW50ZXJydXB0DQplbTE6 IFtGSUxURVJdDQplbTE6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjEwOmYzOjE1OmFlOmU5DQpwY2li NjogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxOCBhdCBkZXZpY2UgMjguMiBvbiBwY2kwDQpw Y2k2OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNg0KZW0yOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0 d29yayBDb25uZWN0aW9uIDYuOS4xND4gcG9ydCAweGNmMDAtMHhjZjFmDQptZW0gMHhmZGFlMDAw MC0weGZkYWZmZmZmIGlycSAxOCBhdCBkZXZpY2UgMC4wIG9uIHBjaTYNCmVtMjogVXNpbmcgTVNJ IGludGVycnVwdA0KZW0yOiBbRklMVEVSXQ0KZW0yOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxMDpm MzoxNTphZTplYQ0KcGNpYjc6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTkgYXQgZGV2aWNl IDI4LjMgb24gcGNpMA0KcGNpNzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcNCmVtMzogPEludGVs KFIpIFBSTy8xMDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA2LjkuMTQ+IHBvcnQgMHhhZjAwLTB4YWYx Zg0KbWVtIDB4ZmQ4ZTAwMDAtMHhmZDhmZmZmZiBpcnEgMTkgYXQgZGV2aWNlIDAuMCBvbiBwY2k3 DQplbTM6IFVzaW5nIE1TSSBpbnRlcnJ1cHQNCmVtMzogW0ZJTFRFUl0NCmVtMzogRXRoZXJuZXQg YWRkcmVzczogMDA6MTA6ZjM6MTU6YWU6ZWINCnBjaWI4OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4g aXJxIDE2IGF0IGRldmljZSAyOC40IG9uIHBjaTANCnBjaTg6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWI4DQplbTQ6IDxJbnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24gNi45LjE0PiBw b3J0IDB4OWYwMC0weDlmMWYNCm1lbSAweGZkNmUwMDAwLTB4ZmQ2ZmZmZmYgaXJxIDE2IGF0IGRl dmljZSAwLjAgb24gcGNpOA0KZW00OiBVc2luZyBNU0kgaW50ZXJydXB0DQplbTQ6IFtGSUxURVJd DQplbTQ6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjEwOmYzOjE1OmFlOmVjDQpwY2liOTogPEFDUEkg UENJLVBDSSBicmlkZ2U+IGlycSAxNyBhdCBkZXZpY2UgMjguNSBvbiBwY2kwDQpwY2k5OiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liOQ0KZW01OiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25u ZWN0aW9uIDYuOS4xND4gcG9ydCAweDhmMDAtMHg4ZjFmDQptZW0gMHhmZDRlMDAwMC0weGZkNGZm ZmZmIGlycSAxNyBhdCBkZXZpY2UgMC4wIG9uIHBjaTkNCmVtNTogVXNpbmcgTVNJIGludGVycnVw dA0KZW01OiBbRklMVEVSXQ0KZW01OiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxMDpmMzoxNTphZTpl ZA0KdWhjaTA6IDxJbnRlbCA4MjgwMUggKElDSDgpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBwb3J0 IDB4ZmUwMC0weGZlMWYgaXJxDQoyMyBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwDQp1aGNpMDogW0lU SFJFQURdDQp1aGNpMDogTGVnU3VwID0gMHgwMDNiDQp1c2J1czA6IDxJbnRlbCA4MjgwMUggKElD SDgpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBvbiB1aGNpMA0KdWhjaTE6IDxJbnRlbCA4MjgwMUgg KElDSDgpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBwb3J0IDB4ZmQwMC0weGZkMWYgaXJxDQoyMCBh dCBkZXZpY2UgMjkuMSBvbiBwY2kwDQp1aGNpMTogW0lUSFJFQURdDQp1aGNpMTogTGVnU3VwID0g MHgwMDEwDQp1c2J1czE6IDxJbnRlbCA4MjgwMUggKElDSDgpIFVTQiBjb250cm9sbGVyIFVTQi1C PiBvbiB1aGNpMQ0KZWhjaTA6IDxJbnRlbCA4MjgwMUggKElDSDgpIFVTQiAyLjAgY29udHJvbGxl ciBVU0IyLUE+IG1lbQ0KMHhmZGZmZjAwMC0weGZkZmZmM2ZmIGlycSAyMyBhdCBkZXZpY2UgMjku NyBvbiBwY2kwDQplaGNpMDogW0lUSFJFQURdDQp1c2J1czI6IEVIQ0kgdmVyc2lvbiAxLjANCnVz YnVzMjogPEludGVsIDgyODAxSCAoSUNIOCkgVVNCIDIuMCBjb250cm9sbGVyIFVTQjItQT4gb24g ZWhjaTANCnBjaWIxMDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBj aTANCnBjaTEwOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMTANCmVtNjogPEludGVsKFIpIFBSTy8x MDAwIE5ldHdvcmsgQ29ubmVjdGlvbiA2LjkuMTQ+IHBvcnQgMHhiZjAwLTB4YmYzZg0KbWVtIDB4 ZmQwZTAwMDAtMHhmZDBmZmZmZiwweGZkMGMwMDAwLTB4ZmQwZGZmZmYgaXJxIDE4IGF0IGRldmlj ZSAxNC4wIG9uDQpwY2kxMA0KZW02OiBbRklMVEVSXQ0KZW02OiBFdGhlcm5ldCBhZGRyZXNzOiAw MDoxMDpmMzoxNTphZTplZQ0KZW03OiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0 aW9uIDYuOS4xND4gcG9ydCAweGJlMDAtMHhiZTNmDQptZW0gMHhmZDBhMDAwMC0weGZkMGJmZmZm LDB4ZmQwODAwMDAtMHhmZDA5ZmZmZiBpcnEgMTcgYXQgZGV2aWNlIDE1LjAgb24NCnBjaTEwDQpl bTc6IFtGSUxURVJdDQplbTc6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjEwOmYzOjE1OmFlOmVmDQpp c2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwDQppc2EwOiA8SVNB IGJ1cz4gb24gaXNhYjANCmF0YXBjaTA6IDxJbnRlbCBJQ0g4IFNBVEEzMDAgY29udHJvbGxlcj4g cG9ydA0KMHhmYTAwLTB4ZmEwNywweGY5MDAtMHhmOTAzLDB4ZjgwMC0weGY4MDcsMHhmNzAwLTB4 ZjcwMywweGY2MDAtMHhmNjBmLDB4ZjUwMC0weGY1MGYgaXJxIDE5IGF0IGRldmljZSAzMS4yIG9u IHBjaTANCmF0YXBjaTA6IFtJVEhSRUFEXQ0KYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBj aTANCmF0YTI6IFtJVEhSRUFEXQ0KYXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTANCmF0 YTM6IFtJVEhSRUFEXQ0KcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAo bm8gZHJpdmVyIGF0dGFjaGVkKQ0KYXRhcGNpMTogPEludGVsIElDSDggU0FUQTMwMCBjb250cm9s bGVyPiBwb3J0DQoweGYzMDAtMHhmMzA3LDB4ZjIwMC0weGYyMDMsMHhmMTAwLTB4ZjEwNywweGYw MDAtMHhmMDAzLDB4ZWYwMC0weGVmMGYsMHhlZTAwLTB4ZWUwZiBpcnEgMTkgYXQgZGV2aWNlIDMx LjUgb24gcGNpMA0KYXRhcGNpMTogW0lUSFJFQURdDQphdGE0OiA8QVRBIGNoYW5uZWwgMD4gb24g YXRhcGNpMQ0KYXRhNDogW0lUSFJFQURdDQphdGE1OiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNp MQ0KYXRhNTogW0lUSFJFQURdDQphY3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTANCmF0 cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3MyBpcnEgOCBvbiBhY3BpMA0K dWFydDA6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdz IDB4MTAgb24gYWNwaTANCnVhcnQwOiBbRklMVEVSXQ0KdWFydDA6IGNvbnNvbGUgKDk2MDAsbiw4 LDEpDQp1YXJ0MTogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMg b24gYWNwaTANCnVhcnQxOiBbRklMVEVSXQ0KcHBjMDogPFBhcmFsbGVsIHBvcnQ+IHBvcnQgMHgz NzgtMHgzN2YgaXJxIDcgb24gYWNwaTANCnBwYzA6IEdlbmVyaWMgY2hpcHNldCAoTklCQkxFLW9u bHkpIGluIENPTVBBVElCTEUgbW9kZQ0KcHBjMDogW0lUSFJFQURdDQpwcGJ1czA6IDxQYXJhbGxl bCBwb3J0IGJ1cz4gb24gcHBjMA0KcGxpcDA6IDxQTElQIG5ldHdvcmsgaW50ZXJmYWNlPiBvbiBw cGJ1czANCnBsaXAwOiBbSVRIUkVBRF0NCmxwdDA6IDxQcmludGVyPiBvbiBwcGJ1czANCmxwdDA6 IFtJVEhSRUFEXQ0KbHB0MDogSW50ZXJydXB0LWRyaXZlbiBwb3J0DQpwcGkwOiA8UGFyYWxsZWwg SS9PPiBvbiBwcGJ1czANCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTANCnA0dGNjMDogPENQVSBG cmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHUwDQpwbXRpbWVyMCBvbiBpc2EwDQpvcm0w OiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbQ0KMHhjMDAwMC0weGNhZmZmLDB4Y2MwMDAtMHhj Y2ZmZiwweGVmMDAwLTB4ZWZmZmYgcG5waWQgT1JNMDAwMCBvbiBpc2EwDQpzYzA6IDxTeXN0ZW0g Y29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0Kc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29u c29sZXMsIGZsYWdzPTB4MzAwPg0KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNj MC0weDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24NCmlzYTANCmF0YTAgYXQgcG9ydCAweDFm MC0weDFmNywweDNmNiBpcnEgMTQgb24gaXNhMA0KYXRhMDogW0lUSFJFQURdDQphdGExIGF0IHBv cnQgMHgxNzAtMHgxNzcsMHgzNzYgaXJxIDE1IG9uIGlzYTANCmF0YTE6IFtJVEhSRUFEXQ0KYXRr YmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24g aXNhMA0KYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANCmtiZDAgYXQgYXRr YmQwDQphdGtiZDA6IFtHSUFOVC1MT0NLRURdDQphdGtiZDA6IFtJVEhSRUFEXQ0KVGltZWNvdW50 ZXIgIlRTQyIgZnJlcXVlbmN5IDE5OTUwMTI4MzAgSHogcXVhbGl0eSA4MDANClRpbWVjb3VudGVy cyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMNCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYx LjANCnVzYnVzMTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVzYnVzMjogNDgwTWJwcyBI aWdoIFNwZWVkIFVTQiB2Mi4wDQphZDQ6IEZBSUxVUkUgLSBTRVRfTVVMVEkgc3RhdHVzPTUxPFJF QURZLERTQyxFUlJPUj4gZXJyb3I9NDxBQk9SVEVEPg0KYWQ0OiAxOTQzTUIgPFRSQU5TQ0VORCAy MDA3MDQxOD4gYXQgYXRhMi1tYXN0ZXIgU0FUQTE1MA0KdWdlbjAuMTogPEludGVsPiBhdCB1c2J1 czANCnVodWIwOiA8SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAw LCBhZGRyIDE+IG9uIHVzYnVzMA0KdWdlbjEuMTogPEludGVsPiBhdCB1c2J1czENCnVodWIxOiA8 SW50ZWwgVUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9u IHVzYnVzMQ0KdWdlbjIuMTogPEludGVsPiBhdCB1c2J1czINCnVodWIyOiA8SW50ZWwgRUhDSSBy b290IEhVQiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMg0KYWQ4 OiAzMDUyNDVNQiA8U0FNU1VORyBIRDMyMUtKIENQMTAwLTEwPiBhdCBhdGE0LW1hc3RlciBTQVRB MzAwDQpXQVJOSU5HOiBXSVRORVNTIG9wdGlvbiBlbmFibGVkLCBleHBlY3QgcmVkdWNlZCBwZXJm b3JtYW5jZS4NCkdFT006IGFkOHMxOiBnZW9tZXRyeSBkb2VzIG5vdCBtYXRjaCBsYWJlbCAoMjU1 aCw2M3MgIT0gMTZoLDYzcykuDQpSb290IG1vdW50IHdhaXRpbmcgZm9yOiB1c2J1czIgdXNidXMx IHVzYnVzMA0KdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQp1 aHViMTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNClJvb3QgbW91bnQg d2FpdGluZyBmb3I6IHVzYnVzMg0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMyDQp1aHVi MjogNiBwb3J0cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNClRyeWluZyB0byBtb3Vu dCByb290IGZyb20gdWZzOi9kZXYvYWQ4czFhDQpXQVJOSU5HOiAvdG1wIHdhcyBub3QgcHJvcGVy bHkgZGlzbW91bnRlZA0KV0FSTklORzogL3VzciB3YXMgbm90IHByb3Blcmx5IGRpc21vdW50ZWQN CldBUk5JTkc6IC92YXIgd2FzIG5vdCBwcm9wZXJseSBkaXNtb3VudGVkDQplbTA6IGxpbmsgc3Rh dGUgY2hhbmdlZCB0byBVUA0KbG9jayBvcmRlciByZXZlcnNhbDoNCiAxc3QgMHhjNGNhZWFkMCB1 ZnMgKHVmcykgQCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfc25hcHNob3QuYzo0MjMNCiAybmQg MHhkODUxMzNhMCBidWZ3YWl0IChidWZ3YWl0KSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8u YzoyNTU4DQogM3JkIDB4YzRhNmY1OTQgdWZzICh1ZnMpIEAgL3Vzci9zcmMvc3lzL3Vmcy9mZnMv ZmZzX3NuYXBzaG90LmM6NTQ0DQpLREI6IHN0YWNrIGJhY2t0cmFjZToNCmRiX3RyYWNlX3NlbGZf d3JhcHBlcihjMGM2YmMxNCxlNmNlYzQwOCxjMDhiYzlkNSxjMDhhZDcxYixjMGM2ZWFjMiwuLi4p DQphdCBkYl90cmFjZV9zZWxmX3dyYXBwZXIrMHgyNg0Ka2RiX2JhY2t0cmFjZShjMDhhZDcxYixj MGM2ZWFjMixjNDUyYmU5MCxjNDUyZWZiOCxlNmNlYzQ2NCwuLi4pIGF0DQprZGJfYmFja3RyYWNl KzB4MjkNCl93aXRuZXNzX2RlYnVnZ2VyKGMwYzZlYWMyLGM0YTZmNTk0LGMwYzYxN2ZkLGM0NTJl ZmI4LGMwYzhkNDAwLC4uLikgYXQNCl93aXRuZXNzX2RlYnVnZ2VyKzB4MjUNCndpdG5lc3NfY2hl Y2tvcmRlcihjNGE2ZjU5NCw5LGMwYzhkNDAwLDIyMCwwLC4uLikgYXQgd2l0bmVzc19jaGVja29y ZGVyDQorMHg4MzkNCl9fbG9ja21ncl9hcmdzKGM0YTZmNTk0LDgwMTAwLGM0YTZmNWIwLDAsMCwu Li4pIGF0IF9fbG9ja21ncl9hcmdzKzB4N2E3DQpmZnNfbG9jayhlNmNlYzU3NCxjMGVmYmIxOCxj NGNhNjc2NCw4MDEwMCxjNGE2ZjUzYywuLi4pIGF0IGZmc19sb2NrKzB4OGENClZPUF9MT0NLMV9B UFYoYzBkNmU5MDAsZTZjZWM1NzQsZTZjZWM1OTQsYzBkODczODAsYzRhNmY1M2MsLi4uKSBhdA0K Vk9QX0xPQ0sxX0FQVisweGI1DQpfdm5fbG9jayhjNGE2ZjUzYyw4MDEwMCxjMGM4ZDQwMCwyMjAs YzQ1NWI2MDAsLi4uKSBhdCBfdm5fbG9jaysweDVlDQpmZnNfc25hcHNob3QoYzQ5ZGNhMTAsYzQ5 ZGI2MjAsYzBjOGVkNjUsMTVmLGMwYzc1MDZhLC4uLikgYXQNCmZmc19zbmFwc2hvdCsweDE1MGIN CmZmc19tb3VudChjNDlkY2ExMCwwLGMwYzc1NTU3LDNkMiwwLC4uLikgYXQgZmZzX21vdW50KzB4 MTRhYQ0KdmZzX2Rvbm1vdW50KGM0Y2E2NmMwLDIxMTAwMCxjNDViNWIwMCxjNDViNWIwMCxiZmJm ZWNiNCwuLi4pIGF0DQp2ZnNfZG9ubW91bnQrMHgxMDEyDQpubW91bnQoYzRjYTY2YzAsZTZjZWNj ZjgsYyxjNGNhNjZjMCxjMGQ0ZmUzOCwuLi4pIGF0IG5tb3VudCsweDc1DQpzeXNjYWxsKGU2Y2Vj ZDM4KSBhdCBzeXNjYWxsKzB4MmEzDQpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lz Y2FsbCsweDIwDQotLS0gc3lzY2FsbCAoMzc4LCBGcmVlQlNEIEVMRjMyLCBubW91bnQpLCBlaXAg PSAweDI4MGVlNzZiLCBlc3AgPQ0KMHhiZmJmZWFkYywgZWJwID0gMHhiZmJmZWUyOCAtLS0NCmxv Y2sgb3JkZXIgcmV2ZXJzYWw6DQogMXN0IDB4ZDg1MTMzYTAgYnVmd2FpdCAoYnVmd2FpdCkgQCAv dXNyL3NyYy9zeXMva2Vybi92ZnNfYmlvLmM6MjU1OA0KIDJuZCAweGM0YTIxYmRjIHNuYXBsayAo c25hcGxrKQ0KQCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfc25hcHNob3QuYzo3OTMNCktEQjog c3RhY2sgYmFja3RyYWNlOg0KZGJfdHJhY2Vfc2VsZl93cmFwcGVyKGMwYzZiYzE0LGU2Y2VjNDA4 LGMwOGJjOWQ1LGMwOGFkNzFiLGMwYzZlYWE5LC4uLikNCmF0IGRiX3RyYWNlX3NlbGZfd3JhcHBl cisweDI2DQprZGJfYmFja3RyYWNlKGMwOGFkNzFiLGMwYzZlYWE5LGM0NTJiZTkwLGM0NTJmMmY4 LGU2Y2VjNDY0LC4uLikgYXQNCmtkYl9iYWNrdHJhY2UrMHgyOQ0KX3dpdG5lc3NfZGVidWdnZXIo YzBjNmVhYTksYzRhMjFiZGMsYzBjOGQ0NjIsYzQ1MmYyZjgsYzBjOGQ0MDAsLi4uKSBhdA0KX3dp dG5lc3NfZGVidWdnZXIrMHgyNQ0Kd2l0bmVzc19jaGVja29yZGVyKGM0YTIxYmRjLDksYzBjOGQ0 MDAsMzE5LGM0Y2FlYWVjLC4uLikgYXQNCndpdG5lc3NfY2hlY2tvcmRlcisweDgzOQ0KX19sb2Nr bWdyX2FyZ3MoYzRhMjFiZGMsODA0MDAsYzRjYWVhZWMsMCwwLC4uLikgYXQgX19sb2NrbWdyX2Fy Z3MrMHg3YTcNCmZmc19sb2NrKGU2Y2VjNTc0LDAsMCw4MDQwMCxjNGNhZWE3OCwuLi4pIGF0IGZm c19sb2NrKzB4OGENClZPUF9MT0NLMV9BUFYoYzBkNmU5MDAsZTZjZWM1NzQsYzE5NWNiOTAsYzBk ODczODAsYzRjYWVhNzgsLi4uKSBhdA0KVk9QX0xPQ0sxX0FQVisweGI1DQpfdm5fbG9jayhjNGNh ZWE3OCw4MDQwMCxjMGM4ZDQwMCwzMTksMCwuLi4pIGF0IF92bl9sb2NrKzB4NWUNCmZmc19zbmFw c2hvdChjNDlkY2ExMCxjNDlkYjYyMCxjMGM4ZWQ2NSwxNWYsYzBjNzUwNmEsLi4uKSBhdA0KZmZz X3NuYXBzaG90KzB4MjhiNg0KZmZzX21vdW50KGM0OWRjYTEwLDAsYzBjNzU1NTcsM2QyLDAsLi4u KSBhdCBmZnNfbW91bnQrMHgxNGFhDQp2ZnNfZG9ubW91bnQoYzRjYTY2YzAsMjExMDAwLGM0NWI1 YjAwLGM0NWI1YjAwLGJmYmZlY2I0LC4uLikgYXQNCnZmc19kb25tb3VudCsweDEwMTINCm5tb3Vu dChjNGNhNjZjMCxlNmNlY2NmOCxjLGM0Y2E2NmMwLGMwZDRmZTM4LC4uLikgYXQgbm1vdW50KzB4 NzUNCnN5c2NhbGwoZTZjZWNkMzgpIGF0IHN5c2NhbGwrMHgyYTMNClhpbnQweDgwX3N5c2NhbGwo KSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjANCi0tLSBzeXNjYWxsICgzNzgsIEZyZWVCU0QgRUxG MzIsIG5tb3VudCksIGVpcCA9IDB4MjgwZWU3NmIsIGVzcCA9DQoweGJmYmZlYWRjLCBlYnAgPSAw eGJmYmZlZTI4IC0tLQ0KbG9jayBvcmRlciByZXZlcnNhbDoNCiAxc3QgMHhjNGEyMWJkYyBzbmFw bGsgKHNuYXBsaykgQCAvdXNyL3NyYy9zeXMva2Vybi92ZnNfdm5vcHMuYzoyOTYNCiAybmQgMHhj NGNhZWFkMCB1ZnMgKHVmcykgQCAvdXNyL3NyYy9zeXMvdWZzL2Zmcy9mZnNfc25hcHNob3QuYzox NTg3DQpLREI6IHN0YWNrIGJhY2t0cmFjZToNCmRiX3RyYWNlX3NlbGZfd3JhcHBlcihjMGM2YmMx NCxlNmNlYzhiOCxjMDhiYzlkNSxjMDhhZDcxYixjMGM2ZWFhOSwuLi4pDQphdCBkYl90cmFjZV9z ZWxmX3dyYXBwZXIrMHgyNg0Ka2RiX2JhY2t0cmFjZShjMDhhZDcxYixjMGM2ZWFhOSxjNDUyZjJm OCxjNDUyZWZiOCxlNmNlYzkxNCwuLi4pIGF0DQprZGJfYmFja3RyYWNlKzB4MjkNCl93aXRuZXNz X2RlYnVnZ2VyKGMwYzZlYWE5LGM0Y2FlYWQwLGMwYzYxN2ZkLGM0NTJlZmI4LGMwYzhkNDAwLC4u LikgYXQNCl93aXRuZXNzX2RlYnVnZ2VyKzB4MjUNCndpdG5lc3NfY2hlY2tvcmRlcihjNGNhZWFk MCw5LGMwYzhkNDAwLDYzMywwLC4uLikgYXQgd2l0bmVzc19jaGVja29yZGVyDQorMHg4MzkNCl9f bG9ja21ncl9hcmdzKGM0Y2FlYWQwLDgwMDAwLDAsMCwwLC4uLikgYXQgX19sb2NrbWdyX2FyZ3Mr MHg3YTcNCmZmc19zbmFwcmVtb3ZlKGM0Y2FlYTc4LGM0OWRjYTEwLDAsYzBjNzZmMDEsNDFkLC4u LikgYXQgZmZzX3NuYXByZW1vdmUNCisweDExZg0Kc29mdGRlcF9yZWxlYXNlZmlsZShjNGI2ZGQy NCxlNmNlY2E5YywyLGMwZWZiYWU4LGMwZDU1M2RjLC4uLikgYXQNCnNvZnRkZXBfcmVsZWFzZWZp bGUrMHgzYg0KdWZzX2luYWN0aXZlKGU2Y2VjYWRjLGM0Y2FlYWVjLGM0Y2FlYTc4LGM0Y2FlYWVj LGU2Y2VjYWY0LC4uLikgYXQNCnVmc19pbmFjdGl2ZSsweDFiYw0KVk9QX0lOQUNUSVZFX0FQVihj MGQ2ZTkwMCxlNmNlY2FkYyxjMGM3NWQzOCw5MjQsYzBkODczNDAsLi4uKSBhdA0KVk9QX0lOQUNU SVZFX0FQVisweGE1DQp2aW5hY3RpdmUoYzBkNmU5MDAsZTZjZWNiMTAsYzBjNzVkMzgsOGFhLDEy OCwuLi4pIGF0IHZpbmFjdGl2ZSsweDhlDQp2cHV0KGM0Y2FlYTc4LGU2Y2VjYjRjLGMwYzc2ZjAx LDEyOCwwLC4uLikgYXQgdnB1dCsweDFjZA0Kdm5fY2xvc2UoYzRjYWVhNzgsMSxjNDU2ZDEwMCxj NGNhNjZjMCwwLC4uLikgYXQgdm5fY2xvc2UrMHgxOWENCnZuX2Nsb3NlZmlsZShjNDlmMDYyMCxj NGNhNjZjMCwzLDAsYzQ5ZjA2MjAsLi4uKSBhdCB2bl9jbG9zZWZpbGUrMHhlNA0KX2Zkcm9wKGM0 OWYwNjIwLGM0Y2E2NmMwLGU2Y2VjYzE4LGMwOGJjODFjLDAsYzRjYTY3NjQsYzBlZmJhZTgsYzBk NTY5YzAsYzBjNjM1MzgsYzRjYTMwMmMsNDViLGMwYzYzNTM4LGU2Y2VjYzQwLGMwODgzYTgwLGM0 Y2EzMDJjLDgsYzBjNjM1MzgsNDViKSBhdCBfZmRyb3ArMHg0Mw0KY2xvc2VmKGM0OWYwNjIwLGM0 Y2E2NmMwLDQ1Yiw0NDAsYzRjYTMwMmMsLi4uKSBhdCBjbG9zZWYrMHgyOTANCmtlcm5fY2xvc2Uo YzRjYTY2YzAsNCxlNmNlY2QyYyxjMGJhOGU5MyxjNGNhNjZjMCwuLi4pIGF0IGtlcm5fY2xvc2UN CisweDExNw0KY2xvc2UoYzRjYTY2YzAsZTZjZWNjZjgsNCxjMGM2ZjhjMixjMGQ0ZDU4OCwuLi4p IGF0IGNsb3NlKzB4MWENCnN5c2NhbGwoZTZjZWNkMzgpIGF0IHN5c2NhbGwrMHgyYTMNClhpbnQw eDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxsKzB4MjANCi0tLSBzeXNjYWxsICg2LCBG cmVlQlNEIEVMRjMyLCBjbG9zZSksIGVpcCA9IDB4MjgxOTIyNTMsIGVzcCA9DQoweGJmYmZlYWRj LCBlYnAgPSAweGJmYmZlZTI4IC0tLQ0KbG9jayBvcmRlciByZXZlcnNhbDoNCiAxc3QgMHhkODU4 YmJiMCBidWZ3YWl0IChidWZ3YWl0KSBAIC91c3Ivc3JjL3N5cy9rZXJuL3Zmc19iaW8uYzoyNTU4 DQogMm5kIDB4YzQ5YTFhMDAgZGlyaGFzaCAoZGlyaGFzaCkNCkAgL3Vzci9zcmMvc3lzL3Vmcy91 ZnMvdWZzX2Rpcmhhc2guYzoyODUNCktEQjogc3RhY2sgYmFja3RyYWNlOg0KZGJfdHJhY2Vfc2Vs Zl93cmFwcGVyKGMwYzZiYzE0LGU2Y2ZjYTc0LGMwOGJjOWQ1LGMwOGFkNzFiLGMwYzZlYWE5LC4u LikNCmF0IGRiX3RyYWNlX3NlbGZfd3JhcHBlcisweDI2DQprZGJfYmFja3RyYWNlKGMwOGFkNzFi LGMwYzZlYWE5LGM0NTJiZTkwLGM0NTJmMDIwLGU2Y2ZjYWQwLC4uLikgYXQNCmtkYl9iYWNrdHJh Y2UrMHgyOQ0KX3dpdG5lc3NfZGVidWdnZXIoYzBjNmVhYTksYzQ5YTFhMDAsYzBjOGY4ODcsYzQ1 MmYwMjAsYzBjOGY1MjAsLi4uKSBhdA0KX3dpdG5lc3NfZGVidWdnZXIrMHgyNQ0Kd2l0bmVzc19j aGVja29yZGVyKGM0OWExYTAwLDksYzBjOGY1MjAsMTFkLDAsLi4uKSBhdCB3aXRuZXNzX2NoZWNr b3JkZXINCisweDgzOQ0KX3N4X3hsb2NrKGM0OWExYTAwLDAsYzBjOGY1MjAsMTFkLGRhNmNkMDE4 LC4uLikgYXQgX3N4X3hsb2NrKzB4ODUNCnVmc2Rpcmhhc2hfYWNxdWlyZSgwLGUsYzQ3YTYwMDAs ZDg1OGJiNTAsZGE2Y2QwMTgsLi4uKSBhdA0KdWZzZGlyaGFzaF9hY3F1aXJlKzB4MzUNCnVmc2Rp cmhhc2hfcmVtb3ZlKGM0ZGQzMWQwLGRhNmNkMDE4LDE4LGU2Y2ZjYjYwLGU2Y2ZjYjVjLC4uLikg YXQNCnVmc2Rpcmhhc2hfcmVtb3ZlKzB4MTQNCnVmc19kaXJyZW1vdmUoYzRkZDZhNzgsYzRkZWY2 NTgsNTAwODAwYywwLGM0ZGQ2YTc4LC4uLikgYXQgdWZzX2RpcnJlbW92ZQ0KKzB4ZTUNCnVmc19y ZW1vdmUoZTZjZmNjMzQsMCwwLDAsYzRkZWNiODQsLi4uKSBhdCB1ZnNfcmVtb3ZlKzB4NmUNClZP UF9SRU1PVkVfQVBWKGMwZDZlOTAwLGU2Y2ZjYzM0LGM0ZGVjYjg0LGU2Y2ZjYzBjLDI4MjE2MjM4 LC4uLikgYXQNClZPUF9SRU1PVkVfQVBWKzB4YTUNCmtlcm5fdW5saW5rYXQoYzRjYTVkODAsZmZm ZmZmOWMsMjgyMTYyMzgsMCxlNmNmY2M4MCwuLi4pIGF0DQprZXJuX3VubGlua2F0KzB4MTgxDQpr ZXJuX3VubGluayhjNGNhNWQ4MCwyODIxNjIzOCwwLGU2Y2ZjZDJjLGMwYmE4ZTkzLC4uLikgYXQg a2Vybl91bmxpbmsNCisweDI3DQp1bmxpbmsoYzRjYTVkODAsZTZjZmNjZjgsNCxjMGM4OWViNSxj MGQ0ZDVmOCwuLi4pIGF0IHVubGluaysweDIyDQpzeXNjYWxsKGU2Y2ZjZDM4KSBhdCBzeXNjYWxs KzB4MmEzDQpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDIwDQotLS0g c3lzY2FsbCAoMTAsIEZyZWVCU0QgRUxGMzIsIHVubGluayksIGVpcCA9IDB4MjgxNjhkNmYsIGVz cCA9DQoweGJmYmZlYzVjLCBlYnAgPSAweGJmYmZlYzg4IC0tLQ0KIyANCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9t OiAgQnJ1Y2UgU2ltcHNvbiA8Ym1zQGluY3VuYWJ1bHVtLm5ldD4NClRvOiAgRnJlZUJTRCBDdXJy ZW50IDxmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmc+DQpTdWJqZWN0OiAgW1BBVENIXSBGaXgg aW42cF9sZWF2ZV9ncm91cCgpIHBhbmljIGJ5IG1pc2JlaGF2aW5nIGFwcHMNCkRhdGU6ICBTYXQx OCBKdWwgMjAwOSAxNzo0MToxNCArMDEwMA0KSGksDQpJZiBhbnlvbmUgaXMgZXhwZXJpZW5jaW5n IHBhbmljcyB3aXRoIElQdjYgaW4gdGhlIGtlcm5lbCwgYW5kIG11bHRpY2FzdCANCmFwcGxpY2F0 aW9ucyBhY3RpdmUsIHBsZWFzZSB0ZXN0IHRoaXMgcGF0Y2guIEkgdGhpbmsgc29tZSBmb2xrIGhl cmUgc2F3IA0KdGhpcyB3aXRoIFZMQy4NCnJlQDogSWYgdGhpcyBwYXRjaCBpcyBnb29kIChJJ2xs IHRyeSB0byB0ZXN0IGxvY2FsbHkpIHRoZW4gaXQgc2hvdWxkIGdvIA0KaW50byBIRUFEIEFTQVAu DQogICAgU29tZSBwb29ybHkgYmVoYXZlZCBJUHY2IG11bHRpY2FzdCBhcHBsaWNhdGlvbnMgZG9u J3Qgc3BlY2lmeSBhbiANCmludGVyZmFjZSBmb3IgdGhlIGpvaW4sIGFuZCB0aGlzIHRyaWdnZXJz IGEgS0FTU0VSVCBJIHB1dCBpbiB0byBjYXRjaCANCnN1Y2ggY29ybmVyIGNhc2VzLg0KICAgIE11 bHRpY2FzdCBkb2Vzbid0IHdvcmsgdW5sZXNzIGFwcHMgYXJlIGF3YXJlIG9mIHRoZSBsaW5rcyBh Y3RpdmUgaW4gDQp0aGUgc3lzdGVtIHRoZXkncmUgcnVubmluZyBvbiwgYW5kIHRoaXMgaXMgYSBn bGFyaW5nIGhvbGUgaW4gdGhlIA0KQm9vc3QuQVNJTyBBUEksIHNhZGx5LiAgVGhpcyB3YXMgY2F1 Z2h0IGJ5IGEgQm9vc3QgcmVncmVzc2lvbiBydW4gb24gDQpyZWY4LmZyZWVic2Qub3JnLg0KVGhh bmtzIHRvIHNpbW9uQCBmb3IgbG9nZ2luZyB0aGUgcGFuaWMgZnJvbSB0aGUgY2x1c3RlciBjb25z b2xlIHNlcnZlcnMuDQpjaGVlcnMsDQpCTVMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiAgRGFuaWVsIEdlcnpv IDxkYW5nZXJARnJlZUJTRC5vcmc+DQpUbzogIE1hcnRlbiBWaWpuIDxpbmZvQG1hcnRlbnZpam4u bmw+DQpTdWJqZWN0OiAgUmU6IG1ha2UgZGlzdHJpYnV0aW9uIFJlOiA4LjAtQkVUQTIgQXZhaWxh YmxlDQpEYXRlOiAgU2F0MTggSnVsIDIwMDkgMTg6NDg6MDAgKzAyMDANCk1hcnRlbiBWaWpuIHdy b3RlOg0KPiBjZCAvdXNyL3NyYw0KPiBtYWtlIGRpc3RyaWJ1dGlvbiBnaXZlcyBhbiBlcnJvcg0K PiANCj4gZGF0YSBiZWxvdywNCj4gDQo+IFJFQURNRSAgL3Vzci90ZnRwYm9vdDEvL2V0Yy9wYW0u ZC9SRUFETUUNCj4gbWFrZTogZG9uJ3Qga25vdyBob3cgdG8gbWFrZSBnZG0uIFN0b3ANCj4gKioq IEVycm9yIGNvZGUgMg0KPiANCj4gU3RvcCBpbiAvdXNyL3NyYy9ldGMuDQo+ICoqKiBFcnJvciBj b2RlIDENCj4gDQo+IFN0b3AgaW4gL3Vzci9zcmMuDQo+ICoqKiBFcnJvciBjb2RlIDENCj4gDQo+ IFN0b3AgaW4gL3Vzci9zcmMuDQpJIGJlbGlldmUgcjE5NTc1MyBmaXhlcyB0aGlzIHByb2JsZW0u IFBsZWFzZSB1cGRhdGUgeW91ciBzb3VyY2VzLg0KLS0gDQpTIHBvemRyYXZvbSAvIEJlc3QgcmVn YXJkcw0KICAgRGFuaWVsIEdlcnpvLCBGcmVlQlNEIGNvbW1pdHRlcg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZyb206 ICBNYXJ0ZW4gVmlqbiA8aW5mb0BtYXJ0ZW52aWpuLm5sPg0KVG86ICBEYW5pZWwgR2Vyem8gPGRh bmdlckBGcmVlQlNELm9yZz4NClN1YmplY3Q6ICBSZTogbWFrZSBkaXN0cmlidXRpb24gUmU6IDgu MC1CRVRBMiBBdmFpbGFibGUNCkRhdGU6ICBTYXQxOCBKdWwgMjAwOSAxOToxNDoyNyArMDIwMA0K T24gU2F0LCAyMDA5LTA3LTE4IGF0IDE4OjQ4ICswMjAwLCBEYW5pZWwgR2Vyem8gd3JvdGU6DQo+ IE1hcnRlbiBWaWpuIHdyb3RlOg0KPiA+IGNkIC91c3Ivc3JjDQo+ID4gbWFrZSBkaXN0cmlidXRp b24gZ2l2ZXMgYW4gZXJyb3INCj4gPiANCj4gPiBkYXRhIGJlbG93LA0KPiA+IA0KPiANCj4gPiBS RUFETUUgIC91c3IvdGZ0cGJvb3QxLy9ldGMvcGFtLmQvUkVBRE1FDQo+ID4gbWFrZTogZG9uJ3Qg a25vdyBob3cgdG8gbWFrZSBnZG0uIFN0b3ANCj4gPiAqKiogRXJyb3IgY29kZSAyDQo+ID4gDQo+ ID4gU3RvcCBpbiAvdXNyL3NyYy9ldGMuDQo+ID4gKioqIEVycm9yIGNvZGUgMQ0KPiA+IA0KPiA+ IFN0b3AgaW4gL3Vzci9zcmMuDQo+ID4gKioqIEVycm9yIGNvZGUgMQ0KPiA+IA0KPiA+IFN0b3Ag aW4gL3Vzci9zcmMuDQo+IA0KPiBJIGJlbGlldmUgcjE5NTc1MyBmaXhlcyB0aGlzIHByb2JsZW0u IFBsZWFzZSB1cGRhdGUgeW91ciBzb3VyY2VzLg0KSSBzaG91bGQgaGF2ZSBtZW50aW9uZWQgbXkg cmV2OiANCkxhc3QgQ2hhbmdlZCBSZXY6IDE5NTc1Mg0KdXBkYXRpbmcgdG8NCkxhc3QgQ2hhbmdl ZCBSZXY6IDE5NTc1NCBGaXhlcyB0aGUgaXNzdWVzDQp0aGFua3MsDQpNYXJ0ZW4NCj4gDQotLSAN Cmh0dHA6Ly9tYXJ0ZW52aWpuLm5sICAgICAgICAgICAgICAgICBNYXJ0ZW4gVmlqbiANCmh0dHA6 Ly9tYXJ0ZW52aWpuLm5sL3RyYWMvd2lraS9zb2FzICBTdWdhciBvbiBhIFN0aWNrDQpodHRwOi8v YnNkLndpZmlzb2Z0Lm9yZy9uZWsvICAgICAgICAgVGhlIE5ldHdvcmsgRXZlbnQgS2l0DQpodHRw Oi8vaGFyMjAwOS5vcmcgICAgICAgICAgICAgICAgICAgMTN0aC0xNnRoIEF1Z3VzdCANCmh0dHA6 Ly9vcGVuY29tbXVuaXR5Y2FtcC5vcmcgICAgICAgICAyNnRoIEp1bCAtIDJuZCBBdWd1c3QNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpGcm9tOiAgTWNMb25lIDxtY2xvbmVAZ21haWwuY29tPg0KVG86ICBmcmVlYnNkLWN1 cnJlbnRAZnJlZWJzZC5vcmcNClN1YmplY3Q6ICBbYnVnXSBaRlMgenZvbCBkZXYgZW50cnkgZGlz YXBwZWFyaW5nIHVwb24gcmVib290DQpEYXRlOiAgU2F0MTggSnVsIDIwMDkgMjA6Mjc6MDAgKzAz MDANCkhlbGwgTG93Lg0KQXMgZG93bmxvYWRpbmcgdG9ycmVudCBmaWxlcyBmcm9tIG1hbnkgcGVl cnMgdG8gWkZTDQppbXBvc2VzIGZyYWdtZW50YXRpb24gKGFuZCB0aGVyZSdzIG5vIHdheSB0byBk ZWZyYWdtZW50DQpaRlMgdm9sdW1lIC0gd2hhdCBhIHBpdHkhIEhvdyBjb21lIG5vdy1hLWRheXMg RlMgY2FuDQpnbyBsaWtlIHRoaXM/KSwgaSBjcmVhdGVkIHp2b2wgd2l0aCBVRlMyIG9uIGl0IGxh c3QgdGltZQ0KaSB3YW50ZWQgdG8gd2F0Y2ggc29tZSBvbGQgc2NpLWZpLiBJIGhhZCBwbGFucyB0 bw0KbW92ZSBzY2ktZmkgZnJvbSBVRlMyL3p2b2wgdG8gWkZTIHdoZW4gaXQnbGwgYmUgY29tcGxl dGUsDQpidXQgZm9yZ290IGl0LCBhbmQgcmVib290ZWQgbWFjaGluZS4gQWZ0ZXIgcmVib290DQpy dG9ycmVudCBzYWlkIHNjaS1maSBpcyBtYXJrZWQgYXMgY29tcGxldGUsIGJ1dCBpdA0KY2FuIG5v dCBmaW5kIGZpbGVzLiBJIHdhc24ndCBzdXJwcmlzZWQsIGFzIGkgaGF2ZW4ndCBtb2RpZmllZA0K bXkgL2V0Yy9mc3RhYiwgc28gaSBlbnRlcmVkICJtb3VudCAvZGV2L3p2b2wiIGFuZCBwcmVzc2Vk DQpUYWIgaW4gaG9wZSBvZiB0Y3NoIChlZWspIGF1dG9jb21wbGV0ZS4NCkl0IGp1c3QgYmVlcGVk IG9uIG1lLg0KSSd2ZSBkb25lICJscyAvZGV2IiBhbmQgdGhlcmUgd2FzIG5vIGRpcmVjdG9yeSB0 aGVyZSBuYW1lZCB6dm9sLg0KVGhlbiBpJ3ZlIGRvbmUgInpmcyBsaXN0IiBhbmQgbXkgenZvbCB3 YXMgdGhlcmUuDQpQdXp6bGVkLCBpJ3ZlIGRvbmUgInpmcyBzbmFwc2hvdCIgYW5kIHRoZW4gYSBs aXR0bGUgZGFuY2Ugb2YNCiJ6ZnMgc2VuZCB8IHpmcyByZWN2IiB0byBhIG5ldyB2b2x1bWUuIE5v dyBkZXYgZW50cmllcyBhcHBlYXJlZA0KKGJvdGggZm9yIG5ld2x5IGNyZWF0ZWQgc25hcHNob3Qg b2YgYW4gb2xkIHp2b2wgYW5kIGZvciBuZXcgenZvbCkuDQpJIHJlYm9vdGVkLCBhbmQgdGhlcmUg d2FzIG5vIC9kZXYvenZvbCBhZ2Fpbi4NCkkgbG9va2VkIGF0IG15IHVuYW1lIC12IG91dHB1dCAo aXQgd2FzIEhFQUQvYW1kNjQgZnJvbSBKdWwgMSkNCmFuZCBkZWNpZGVkIHRvIHVwZGF0ZS4gVXBk YXRpbmcgZGlkbid0IHNvbHZlZCB0aGlzIHByb2JsZW0uDQpTdHJhbmdlbHksIHNpbXBsZSAiemZz IHJlbmFtZSB6cG9vbC96dm9sIHpwb29sL25ld3p2b2wiDQpjdXJlcyB0aGlzIHdvZSwgYnV0IGkg dGhpbmsgdGhpcyBpcyBhIGJ1Zy4NClN0ZXBzIHRvIHJlcHJvZHVjZToNCnpmcyBjcmVhdGUgLVYg MWcgenBvb2wvenZvbA0KW25ld2ZzIC9kZXYvenZvbC96cG9vbC96dm9sXQ0KcmVib290DQpscyAv ZGV2DQpXb3JrYXJvdW5kOg0KemZzIHJlbmFtZSB6cG9vbC96dm9sIHpwb29sL25ld3p2b2wNCm1v dW50IC9kZXYvenZvbC96cG9vbC96dm9sIC9tbnQNCi0tIA0Kd2JyLCAgICAgICAgICAgICAgICAg ICAgICAgIHxcICAgICAgXywsLC0tLSwsXyAgICAgICAgICAgZG9nIGJsZXNzIHlhIQ0KYCAgICAg ICAgICAgICAgICAgICAgICAgWnp6IC8sYC4tJ2AnICAgIC0uICA7LTs7LF8NCk1jTG9uZSBhdCBH TWFpbCBkb3QgY29tICAgIHwsNC0gICkgKS0sXy4gLFwgKCAgYCctJw0KICBuZXQtIGFuZCAqQlNE IGFkbWluICAgICAnLS0tJycoXy8tLScgIGAtJ1xfKSAgIC4uLnRyYW5zbGl0IHJhd3ghDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KRnJvbTogIFNhbSBMZWZmbGVyIDxzYW1AZXJybm8uY29tPg0KVG86ICBBcnRlbSBOYWx1 emhueXkgPHR1dEBuaGFtb24uY29tLnVhPg0KU3ViamVjdDogIFJlOiBMb3RzIG9mICJhdGgwOiBi YWQgc2VyaWVzMCBod3JhdGUgMHgxYiIgaW4gOC4wLUJFVEEyDQpEYXRlOiAgU2F0MTggSnVsIDIw MDkgMTE6Mzc6MTcgLTA3MDANCkFydGVtIE5hbHV6aG55eSB3cm90ZToNCj4gSGksDQo+IA0KPiBB ZnRlciA3LjItUkxFQVNFIC0+IDguMC1CRVRBMiB1cGRhdGUgbXkgbm90ZWJvb2sgd2lyZWxlc3Mg d29ya3MNCj4gd2l0aG91dCBwcm9ibGVtcyBidXQgdGhlcmUgYXJlIGxvdHMgb2YgYW5ub3lpbmcg ImF0aDA6IGJhZCBzZXJpZXMwDQo+IGh3cmF0ZSAweDFiIi1saWtlIG1lc3NhZ2VzIG9uIGNvbnNv bGUgbm93Lg0KPiANCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KPiBwY2ljb25mOg0KPiANCj4gYXRoMEBwY2kwOjE6MDowOiAgICAgICAgY2xh c3M9MHgwMjAwMDAgY2FyZD0weDMwNjUxNjhjIGNoaXA9MHgwMDFjMTY4Yw0KPiByZXY9MHgwMSBo ZHI9MHgwMA0KPiAgICB2ZW5kb3IgICAgID0gJ0F0aGVyb3MgQ29tbXVuaWNhdGlvbnMgSW5jLicN Cj4gICAgZGV2aWNlICAgICA9DQo+ICdIREFVRElPRlVOQ18wMSZWRU5fMTA5NSZERVZfMTM5MiZT VUJTWVNfMTAyODAyNDImUkVWXzEwMDANCj4gKFVTQlZJRF8xNDdFJlBJRF8yMDE2NSZCNzFBNDQ2 JjAmMSknDQo+ICAgIGNsYXNzICAgICAgPSBuZXR3b3JrDQo+ICAgIHN1YmNsYXNzICAgPSBldGhl cm5ldA0KPiANCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPiBzeXNjdGxzOg0KPiANCj4gaHcuYXRoLmJzdHVjazogNA0KPiBody5hdGgudHhi dWY6IDIwMA0KPiBody5hdGgucnhidWY6IDQwDQo+IGh3LmF0aC5yZXNldGNhbDogMTIwMA0KPiBo dy5hdGguc2hvcnRjYWw6IDEwMA0KPiBody5hdGgubG9uZ2NhbDogMzANCj4gaHcuYXRoLmhhbC5z d2JhX2JhY2tvZmY6IDANCj4gaHcuYXRoLmhhbC5zd19icnQ6IDEwDQo+IGh3LmF0aC5oYWwuZG1h X2JydDogMg0KPiBkZXYuYXRoLjAuJWRlc2M6IEF0aGVyb3MgNTQyNC8yNDI0DQo+IGRldi5hdGgu MC4lZHJpdmVyOiBhdGgNCj4gZGV2LmF0aC4wLiVsb2NhdGlvbjogc2xvdD0wIGZ1bmN0aW9uPTAN Cj4gZGV2LmF0aC4wLiVwbnBpbmZvOiB2ZW5kb3I9MHgxNjhjIGRldmljZT0weDAwMWMgc3VidmVu ZG9yPTB4MTY4Yw0KPiBzdWJkZXZpY2U9MHgzMDY1IGNsYXNzPTB4MDIwMDAwDQo+IGRldi5hdGgu MC4lcGFyZW50OiBwY2kxDQo+IGRldi5hdGguMC5zbW9vdGhpbmdfcmF0ZTogOTUNCj4gZGV2LmF0 aC4wLnNhbXBsZV9yYXRlOiAxMA0KPiBkZXYuYXRoLjAuc2FtcGxlX3N0YXRzOiAwDQo+IGRldi5h dGguMC5jb3VudHJ5Y29kZTogMA0KPiBkZXYuYXRoLjAucmVnZG9tYWluOiA5Ng0KPiBkZXYuYXRo LjAuc2xvdHRpbWU6IDkNCj4gZGV2LmF0aC4wLmFja3RpbWVvdXQ6IDQ4DQo+IGRldi5hdGguMC5j dHN0aW1lb3V0OiA0OA0KPiBkZXYuYXRoLjAuc29mdGxlZDogMA0KPiBkZXYuYXRoLjAubGVkcGlu OiAwDQo+IGRldi5hdGguMC5sZWRvbjogMA0KPiBkZXYuYXRoLjAubGVkaWRsZTogMjcwMA0KPiBk ZXYuYXRoLjAudHhhbnRlbm5hOiAwDQo+IGRldi5hdGguMC5yeGFudGVubmE6IDENCj4gZGV2LmF0 aC4wLmRpdmVyc2l0eTogMQ0KPiBkZXYuYXRoLjAudHhpbnRycGVyaW9kOiA1DQo+IGRldi5hdGgu MC5kaWFnOiAwDQo+IGRldi5hdGguMC50cHNjYWxlOiAwDQo+IGRldi5hdGguMC50cGM6IDANCj4g ZGV2LmF0aC4wLnRwYWNrOiA2Mw0KPiBkZXYuYXRoLjAudHBjdHM6IDYzDQo+IGRldi5hdGguMC5y ZnNpbGVudDogMQ0KPiBkZXYuYXRoLjAucmZraWxsOiAxDQo+IGRldi5hdGguMC5pbnRtaXQ6IDEN Cj4gZGV2LmF0aC4wLm1vbnBhc3M6IDI0DQo+IA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+IGRtZXNnOg0KPiANCj4gYXRoMDogPEF0aGVy b3MgNTQyNC8yNDI0PiBtZW0gMHhiZjdmMDAwMC0weGJmN2ZmZmZmIGlycSAxNyBhdCBkZXZpY2Ug MC4wIG9uIHBjaTENCj4gYXRoMDogW0lUSFJFQURdDQo+IGF0aDA6IEFSNTQxMyBtYWMgMTAuMCBS RjU0MjQgcGh5IDYuMQ0KPiBhdGgwOiBiYWQgc2VyaWVzMCBod3JhdGUgMHgxYiwgdHJpZXMgMSB0 c19zdGF0dXMgMHgwDQo+IGF0aDA6IGJhZCBzZXJpZXMwIGh3cmF0ZSAweDFiLCB0cmllcyAxIHRz X3N0YXR1cyAweDANCj4gYXRoMDogYmFkIHNlcmllczMgaHdyYXRlIDB4MWIsIHRyaWVzIDIgdHNf c3RhdHVzIDB4MA0KPiBhdGgwOiBiYWQgc2VyaWVzMCBod3JhdGUgMHgxYiwgdHJpZXMgMSB0c19z dGF0dXMgMHgwDQo+IGF0aDA6IGJhZCBzZXJpZXMyIGh3cmF0ZSAweDFjLCB0cmllcyA0IHRzX3N0 YXR1cyAweDANCj4gYXRoMDogYmFkIHNlcmllczMgaHdyYXRlIDB4MWIsIHRyaWVzIDIgdHNfc3Rh dHVzIDB4MA0KPiBhdGgwOiBiYWQgc2VyaWVzMyBod3JhdGUgMHgxYiwgdHJpZXMgMiB0c19zdGF0 dXMgMHgwDQo+IGF0aDA6IGJhZCBzZXJpZXMzIGh3cmF0ZSAweDFiLCB0cmllcyAyIHRzX3N0YXR1 cyAweDANCj4gYXRoMDogYmFkIHNlcmllczMgaHdyYXRlIDB4MWIsIHRyaWVzIDIgdHNfc3RhdHVz IDB4MA0KPiANCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPiBpZmNvbmZpZzoNCj4gDQo+IGF0aDA6IGZsYWdzPTg4NDM8VVAsQlJPQURDQVNU LFJVTk5JTkcsU0lNUExFWCxNVUxUSUNBU1Q+IG1ldHJpYyAwIG10dSAyMjkwDQo+ICAgICAgICBl dGhlciAwMDoxNTphZjp4eDp4eDp4eA0KPiAgICAgICAgbWVkaWE6IElFRUUgODAyLjExIFdpcmVs ZXNzIEV0aGVybmV0IGF1dG9zZWxlY3QgbW9kZSAxMWcNCj4gICAgICAgIHN0YXR1czogYXNzb2Np YXRlZA0KPiB3bGFuMDogZmxhZ3M9ODg0MzxVUCxCUk9BRENBU1QsUlVOTklORyxTSU1QTEVYLE1V TFRJQ0FTVD4gbWV0cmljIDAgbXR1IDE1MDANCj4gICAgICAgIGV0aGVyIDAwOjE1OmFmOnh4Onh4 Onh4DQo+ICAgICAgICBpbmV0IHh4Lnh4Lnh4Lnh4IG5ldG1hc2sgMHhmZmZmZmZmOCBicm9hZGNh c3QgeHgueHgueHgueHgNCj4gICAgICAgIG1lZGlhOiBJRUVFIDgwMi4xMSBXaXJlbGVzcyBFdGhl cm5ldCBPRkRNLzU0TWJwcyBtb2RlIDExZw0KPiAgICAgICAgc3RhdHVzOiBhc3NvY2lhdGVkDQo+ ICAgICAgICBzc2lkIHh4IGNoYW5uZWwgMyAoMjQyMiBNaHogMTFnKSBic3NpZCAwMDoxZjoxZjp4 eDp4eDp4eA0KPiAgICAgICAgcmVnZG9tYWluIDk2IGluZG9vciBlY20gYXV0aG1vZGUgV1BBMi84 MDIuMTFpIHByaXZhY3kgT04NCj4gICAgICAgIGRlZnR4a2V5IFVOREVGIFRLSVAgMjoxMjgtYml0 IHR4cG93ZXIgMjAgYm1pc3MgNyBzY2FudmFsaWQgNDUwIGJnc2Nhbg0KPiAgICAgICAgYmdzY2Fu aW50dmwgMzAwIGJnc2NhbmlkbGUgMjUwIHJvYW06cnNzaSA3IHJvYW06cmF0ZSA1IHByb3Rtb2Rl IENUUw0KPiAgICAgICAgd21lIHJvYW1pbmcgTUFOVUFMDQo+ID09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4NCkhvdyBvZnRlbiBpcyAibG90cyI/ ICBodyB0eCByYXRlIDB4MWIgaXMgMU1iL3MgQ0NLIGFuZCAweDFjIGlzIDFNIHcvIA0Kc2hvcnQg cHJlYW1ibGUuICBCb3RoIG9mIHRoZXNlIHJhdGVzIHNob3VsZCBiZSBvayB0byB1c2UgaW4gMTFn IHNvIEkgDQpkb24ndCBzZWUgd2h5IHRoZXJlIGFyZSBjb21wbGFpbnRzIHVubGVzcyB0aGUgYXAg eW91IGFyZSBhc3NvY2lhdGVkIHRvIA0KaXMgZG9pbmcgc29tZXRoaW5nIGxpa2UgZm9yY2luZyAx MWctb25seSBvcGVyYXRpb24gKGkuZS4gT0ZETSBvbmx5LCBubyANCkNDSykuICBIb3dldmVyIGV2 ZW4gd2l0aCB0aGF0IHlvdSBzaG91bGQgYmUgZmluZSB1bmxlc3MgcGVyaGFwcyBmaXhlZCB0eCAN CnJhdGUgcGFyYW1ldGVycyBhcmUgc2V0IHdyb25nLg0KTm90IHN1cmUgdGhlcmUncyBhIHdheSB0 byBkdW1wIHRoZSBuZWdvdGlhdGVkIHJhdGUgc2V0LiAgWW91IGNhbiB0cnkgDQp0dXJuaW5nIG9u IHNvbWV0aGluZyBsaWtlOg0Kd2xhbmRlYnVnIGFzc29jDQp0byBzZWUgaWYgdGhhdCBwcm92aWRl cyB1c2VmdWwgaW5mby4gIE90aGVyd2lzZSB5b3UgbWlnaHQgbmVlZCB0byANCmNvbGxlY3QgYSBw YWNrZXQgdHJhY2Ugd2l0aCBzb21ldGhpbmcgbGlrZToNCnRjcGR1bXAgLWkgd2xhbjAgLXAgLXkg SUVFRTgwMl8xMV9SQURJTyAtdyB0LnBjYXANCndoaWxlIGFzc29jaWF0aW5nLS10aGVuIGluc3Bl Y3QgdGhlIHJlc3VsdHMgKGFuZC9vciBzZW5kIG1lIHRoZSBwY2FwIGZpbGUpLg0KU2FtDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KRnJvbTogIEFub255bW91cyA8c3dlbGwua0BnbWFpbC5jb20+DQpUbzogIFJpY2sgTWFj a2xlbSA8cm1hY2tsZW1AdW9ndWVscGguY2E+DQpTdWJqZWN0OiAgUmU6IFtuZXduZnMvY2xpZW50 XSBTSUdJTkZPIGFib3J0cyB0cmFuc2ZlciBhbmQgcHJvZHVjZXNgcGVybWlzc2lvbiBkZW5pZWQn DQpEYXRlOiAgU2F0MTggSnVsIDIwMDkgMjI6Mzg6MDQgKzA0MDANClJpY2sgTWFja2xlbSA8cm1h Y2tsZW1AdW9ndWVscGguY2E+IHdyaXRlczoNCj4gT24gU2F0LCAxOCBKdWwgMjAwOSwgQW5vbnlt b3VzIHdyb3RlOg0KPg0KPj4NCj4+IFllcCwgSSBjYW4gcmVwcm9kdWNlIGl0IGFzIGVhc2lseSBv biA4LjAtQkVUQTIgc25hcHNob3QgdW5kZXIgcWVtdQ0KPj4NCj4+ICMgdW5hbWUgLXZtDQo+PiBG cmVlQlNEIDguMC1CRVRBMiAjMDogV2VkIEp1bCAxNSAyMzoyNTozMCBVVEMgMjAwOQ0KPj4gcm9v dEBhbG1laWRhLmNzZS5idWZmYWxvLmVkdTovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDICBp Mzg2DQo+Pg0KPiBJJ2xsIHRyeSB0byBnZXQgYXJvdW5kIHRvIHRlc3RpbmcgaXQgdGhpcyB3ZWVr ZW5kLCBidXQgaWYgeW91J2QNCj4gbGlrZSB0byB0ZXN0IHRoZSBmb2xsb3dpbmcgcGF0Y2gsIEkg dGhpbmsgaXQgbWlnaHQgZml4IHRoZSBwcm9ibGVtLg0KPg0KPiBUaGUgbmV3IGtycGMgb25seSBj aGVja3MgTkZTTU5UX0lOVCBhdCBjb25uZWN0IGFuZCBub3QgZXZlcnkgcnBjLg0KPg0KPiByaWNr DQo+IHBzOiBUaGUgbGluZSAjcyBhc3N1bWUgdGhlIG90aGVyIHBhdGNoIHlvdSB0ZXN0ZWQgaXMg YWxyZWFkeSBhcHBsaWVkLg0KPiAtLS0gdW50ZXN0ZWQgZXhwLiBuZnMgY2xpZW50IHBhdGNoIC0t LQ0KWy4uLl0NClRoZSBwYXRjaCBmaXhlZCBteSBwcm9ibGVtIG9uIHIxOTU3NTRNIGFtZDY0LiBJ J20gbm8gbG9uZ2VyIGFibGUgdG8NCnJlcHJvZHVjZSBpdCBieSBoaXR0aW5nIF5UIHdoZW4gY29w eWluZyBtZWRpdW0tc2l6ZWQgZmlsZXMuDQpJIGhvcGUgYm90aCBmaXhlcyB3aWxsIGJlIGluIEhF QUQgYmVmb3JlIDguMC1CRVRBMy4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiAgUGlldGVyIGRlIEdvZWplIDxw aWV0ZXJAZGVnb2VqZS5ubD4NClRvOiAgZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnDQpTdWJq ZWN0OiAgU2VuZGluZyBtdWx0aWNhc3QgZGF0YWdyYW1zIGJyb2tlbiAocmVncmVzc2lvbikNCkRh dGU6ICBTYXQxOCBKdWwgMjAwOSAyMDo1Njo0NyArMDIwMA0KSSdtIG9ic2VydmluZyB0aGF0IG11 bHRpY2FzdCBJUHY0IFVEUCBkYXRhZ3JhbXMgc2VudCBmcm9tIHRoZSBsYXRlc3QgOC4wLUJFVEEy IA0KYXJlIGJlaW5nIGRpc2NhcmRlZC4gVGhlIGNvZGUgYmVsb3cgdXNlZCB0byB3b3JrIHdpdGgg Ny4yLg0KU2VuZGVyIFJlY2VpdmVyIFJlc3VsdA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KOC4w ICAgIDguMCAgICAgIEJyb2tlbiwgYnV0IGxvb3AgYmFjayB0cmFmZmljIHdvcmtzDQo4LjAgICAg Ny4yICAgICAgQnJva2VuDQo3LjIgICAgOC4wICAgICAgV29ya3MNCk9kZGx5IGVub3VnaCwgd2hl biBJIHJ1biB0Y3BkdW1wIG9uIGEgOC4wIHNlbmRlciwgaXQgc2hvd3MgcGFja2V0cyBiZWluZyBz ZW50LCANCmJ1dCBvbiB0aGUgcmVjZWl2ZXIgdGNwZHVtcCBzaG93cyBubyBhY3Rpdml0eSB3aGF0 c29ldmVyLg0KVGhlIHJlY2VpdmVyIHdhcyBwcm9wZXJseSByZWdpc3RlcmluZyBpdCdzIG1lbWJl cnNoaXAgKHdoaWNoIHdhcyB2ZXJpZmllZCB3aXRoIA0KaWZtY3N0YXQpLg0KVGVzdGluZyB3YXMg ZG9uZSBvbiB0aHJlZSBob3N0cywgdHdvIG9mIHdoaWNoIGFyZSBydW5uaW5nIDguMCBhbmQgb25l IDcuMi4gVGhlIA0KaG9zdHMgYXJlIGNvbm5lY3RlZCB1c2luZyBhIHNpbmdsZSBzd2l0Y2guIEkn dmUgdHJpZWQgaWZfZW0gYW5kIGlmX3JlIE5JQ3MsIA0KYm90aCB3aXRoIHRoZSBzYW1lIHJlc3Vs dHMuDQpLaW5kIHJlZ2FyZHMsDQpQaWV0ZXIgZGUgR29lamUNClBTLiANCkkgY2FuIHBvc3QgY29t cGxldGUgY29kZSBpZiBuZWNlc3NhcnkuDQotLS0tDQpmZCBpcyBpbml0aWFsaXplZCB3aXRoIGEg ZnJlc2hseSBjcmVhdGVkIEFGX0lORVQgZGF0YWdyYW0gc29ja2V0LCBtYWRkciANCmNvbnRhaW5z IHRoZSBncm91cCBhZGRyZXNzICgyMzkuMjU1LjkuOSBpbiB0aGUgdGVzdCBjYXNlLCBidXQgSSd2 ZSB0cmllZCANCm11bHRpcGxlIGRpZmZlcmVudCBhZGRyZXNzZXMpLg0Kdm9pZCBkb2l0KGludCBm ZCwgaW5fYWRkcl90IG1hZGRyLCBpbnQgcG9ydCkNCnsNCiAgICAgc3RydWN0IHNvY2thZGRyX2lu IGFkZHI7DQogICAgIGludCBjbnQ7DQogICAgIHN0cnVjdCBpcF9tcmVxIG1yZXE7DQogICAgIGNo YXIgbWVzc2FnZVtdID0gIkhlbGxvIjsNCiAgICAgbWVtc2V0KCZhZGRyLCAwLCBzaXplb2YoYWRk cikpOw0KICAgICBhZGRyLnNpbl9mYW1pbHk9QUZfSU5FVDsNCiAgICAgYWRkci5zaW5fYWRkci5z X2FkZHI9bWFkZHI7DQogICAgIGFkZHIuc2luX3BvcnQ9aHRvbnMocG9ydCk7DQogICAgIHVfY2hh ciB0dGwgPSAyOw0KICAgICBpZihzZXRzb2Nrb3B0KGZkLCBJUFBST1RPX0lQLCBJUF9NVUxUSUNB U1RfVFRMLCAmdHRsLA0KICAgICAgICAgICAgICAgICAgIHNpemVvZih0dGwpKSA9PSAtMSkgew0K ICAgICAgICAgIGVycigxLCAic2V0c29ja29wdCIpOw0KICAgICB9DQogICAgIGZvcig7Oykgew0K ICAgICAgICAgIGlmKHNlbmR0byhmZCwgbWVzc2FnZSwgc2l6ZW9mKG1lc3NhZ2UpIC0gMSwgMCwN CiAgICAgICAgICAgICAgICAgICAgIChzdHJ1Y3Qgc29ja2FkZHIgKikmYWRkciwgc2l6ZW9mKGFk ZHIpKSA9PSAtMSkgew0KICAgICAgICAgICAgICAgZXJyKDEsICJzZW5kdG8iKTsNCiAgICAgICAg ICB9DQogICAgICAgICAgc2xlZXAoMSk7DQogICAgIH0NCn0NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiAgQWxl eGFuZGVyIE1vdGluIDxtYXZARnJlZUJTRC5vcmc+DQpUbzogIEZyZWVCU0QtQ3VycmVudCA8ZnJl ZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnPg0KU3ViamVjdDogIFNpSTMxMjQvMzEzMi8zNTMxIENB TSBkcml2ZXINCkRhdGU6ICBTYXQxOCBKdWwgMjAwOSAyMjowMTo1MiArMDMwMA0KSGkuDQpJJ3Zl IG1hZGUgQ0FNIGRyaXZlciBmb3IgU2lsaWNvbkltYWdlIFNpSTMxMjQvMzEzMi8zNTMxIGNvbnRy b2xsZXJzOg0KaHR0cDovL3Blb3BsZS5mcmVlYnNkLm9yZy9+bWF2L3NpaXMuMjAwOTA3MTgucGF0 Y2gNCkRyaXZlciBzdXBwb3J0cyBTZXJpYWwgQVRBIGFuZCBBVEFQSSBkZXZpY2VzLCBQb3J0IE11 bHRpcGxpZXJzIA0KKGluY2x1ZGluZyBGSVMtYmFzZWQgc3dpdGNoaW5nKSwgaGFyZHdhcmUgY29t bWFuZCBxdWV1ZXMgKDMxIGNvbW1hbmQgcGVyIA0KcG9ydCkgYW5kIE5hdGl2ZSBDb21tYW5kIFF1 ZXVpbmcuDQpUZXN0ZXJzIGFyZSB3ZWxjb21lLg0KLS0gDQpBbGV4YW5kZXIgTW90aW4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpGcm9tOiAgIkRhdmlkIEJveWQiIDxEYXZpZC5Cb3lkQGluc2lnaHRiYi5jb20+DQpUbzog IDxmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmc+DQpTdWJqZWN0OiAgOC4wLUJFVEEyIHN5c2lu c3RhbGwgc3BlbGxpbmcgZXJyb3INCkRhdGU6ICBTYXQxOCBKdWwgMjAwOSAxNDo1Mjo0OSAtMDQw MA0KVGhlIHVzZSBvZiAiZGlzdEV2ZXJ5dGhpbmciIHJlc3VsdHMgaW4gc3lzaW5zdGFsbCB0cnlp bmcgdG8gYWRkIHBhY2thZ2UNCm1uLWZyZWVic2QtZG9jLW1uLTxkYXRlPiB3aGljaCBkb2Vzbid0 IGV4aXN0IGluIHRoZSBJTkRFWA0KKG1uLWZyZWVic2QtZG9jLTxkYXRlPikuDQpJZiBpdHMgdG9v IGVhcmx5IHRvICJwaWNrIG5pdHMiLCBJIGFwb2xvZ2l6ZS4NCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiAgQXJ0 ZW0gTmFsdXpobnl5IDx0dXRAbmhhbW9uLmNvbS51YT4NClRvOiAgU2FtIExlZmZsZXIgPHNhbUBl cnJuby5jb20+DQpTdWJqZWN0OiAgUmU6IExvdHMgb2YgImF0aDA6IGJhZCBzZXJpZXMwIGh3cmF0 ZSAweDFiIiBpbiA4LjAtQkVUQTINCkRhdGU6ICBTYXQxOCBKdWwgMjAwOSAyMjoyOToyNSArMDMw MA0KT24gU2F0LCBKdWwgMTgsIDIwMDkgYXQgMjE6MzcsIFNhbSBMZWZmbGVyPHNhbUBlcnJuby5j b20+IHdyb3RlOg0KPiBIb3cgb2Z0ZW4gaXMgImxvdHMiPw0KVGhlcmUgYXJlIDUtMzAgbWVzc2Fn ZXMgYSBzZWNvbmQgd2hlbiBiYW5kd2lkdGggdXNhZ2UgaXMgaGlnaC4NClRoZSBub25hbWUgQVAg bG9va3MgcmVhbGx5IHN0cmFuZ2UgYW5kIGl0IG1heSBkbyBzb21ldGhpbmcgd3JvbmcuDQpBY3R1 YWxseSB0aGUgcXVlc3Rpb24gaXMgcmF0aGVyIHdoeSBJIGRpZCBub3Qgc2VlIHRoZSBtZXNzYWdl cyBmb3IgdGhlDQpzYW1lIEFQIGluIDcuMi1SIGFuZCBob3cgdG8gKGlmIHBvc3NpYmxlKSBkaXNh YmxlIHRoZSBtZXNzYWdlcyBpbiA4LjAuDQo+IHdsYW5kZWJ1ZyBhc3NvYw0KPiB0Y3BkdW1wIC1p IHdsYW4wIC1wIC15IElFRUU4MDJfMTFfUkFESU8gLXcgdC5wY2FwDQp0Y3BkdW1wIGFuZCB3bGFu ZGVidWcgcmVzdWx0cyBoYXZlIGJlZW4gc2VudCBwcml2YXRlbHkuDQotLSANCkFydGVtIE5hbHV6 aG55eQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkZyb206ICBCcnVjZSBTaW1wc29uIDxibXNAaW5jdW5hYnVsdW0ubmV0 Pg0KVG86ICBQaWV0ZXIgZGUgR29lamUgPHBpZXRlckBkZWdvZWplLm5sPg0KU3ViamVjdDogIFJl OiBTZW5kaW5nIG11bHRpY2FzdCBkYXRhZ3JhbXMgYnJva2VuIChyZWdyZXNzaW9uKQ0KRGF0ZTog IFN1bjE5IEp1bCAyMDA5IDAzOjA5OjI2ICswMTAwDQpQaWV0ZXIgZGUgR29lamUgd3JvdGU6DQo+ IEknbSBvYnNlcnZpbmcgdGhhdCBtdWx0aWNhc3QgSVB2NCBVRFAgZGF0YWdyYW1zIHNlbnQgZnJv bSB0aGUgbGF0ZXN0IDguMC1CRVRBMiANCj4gYXJlIGJlaW5nIGRpc2NhcmRlZC4gVGhlIGNvZGUg YmVsb3cgdXNlZCB0byB3b3JrIHdpdGggNy4yLg0KPiAgIA0KQ2FuIHlvdSB0Y3BkdW1wIHRoaXM/ DQpUaGlzIG1heSBiZSByZWxhdGVkIHRvIGFuIGxsZW50cnkgcmVsYXRlZCByZWdyZXNzaW9uIHdo aWNoIFhpbiBMaSANCnJlY2VudGx5IHBvc3RlZCBhIHBhdGNoIGZvciwgaXQgYXBwZWFycyB0aGF0 IGxheWVyIDIgYWRkcmVzc2VzIGZvciANCm11bHRpY2FzdC9icm9hZGNhc3QgZGF0YWdyYW1zIG1h eSBiZSBicm9rZW4gaW4gOC4wLUJFVEEyLg0KQWx0aG91Z2ggSSBoYXZlbid0IHRlc3RlZCB0aGlz IG15c2VsZiBzaW5jZSBjb21taXR0aW5nIHRoZSBTU00gY29kZSANCmFyb3VuZCBBcHJpbCwgd2hl cmUgSSBvYnNlcnZlZCBzdWNoIHRyYWZmaWMgd2FzIGNvcnJlY3QuDQp0aGFua3MNCkJNUw0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCkZyb206ICBKYW1lcyBCdXRsZXIgPHN3ZWV0bmF2ZWxvcmFuZ2VAZ21haWwuY29tPg0K VG86ICBTYW0gTGVmZmxlciA8c2FtQGVycm5vLmNvbT4NCiBjdXJyZW50QGZyZWVic2Qub3JnDQpT dWJqZWN0OiAgUmU6IGlwdyBpbiA4LjAtQkVUQTENCkRhdGU6ICBTdW4xOSBKdWwgMjAwOSAxOToy NDoyOCArMTIwMA0KMjAwOS83LzE4IFNhbSBMZWZmbGVyIDxzYW1AZXJybm8uY29tPjoNCj4gSmFt ZXMgQnV0bGVyIHdyb3RlOg0KPj4NCj4+IEdyZWV0aW5ncw0KPj4NCj4+IEFyZSBpcHcgZGV2aWNl cyBleHBlY3RlZCB0byB3b3JrIGluIDguMC1CRVRBMT8gTWluZSBhcHBhcmVudGx5DQo+PiBkb2Vz bid0LiBJIGhhdmUgdXBkYXRlZCBteSByYy5jb25mIGFjY29yZGluZyB0byB0aGUgaW5zdHJ1Y3Rp b25zIGluDQo+PiBVUERBVElORyByZWxhdGluZyB0byB3bGFuczsgdGhlIHdsYW4wIGludGVyZmFj ZSBpcyBjcmVhdGVkLCBidXQNCj4+IHdwYV9zdXBwbGljYW50IGRvZXNuJ3QgYXNzb2NpYXRlLg0K Pj4NCj4+IEkgYXNrIGFmdGVyIHNlZWluZyB0aGlzIHNuaXBwZXQgZnJvbSB0aGUgbGlzdCBiYWNr IGluIE1hcmNoOg0KPj4NCj4+PiBVbmZvcnR1bmF0ZWx5IHRoZSB2YXAgY29udmVyc2lvbiBvZiB0 aGUgaXB3IGRyaXZlciBuZXZlciB3YXMgY29tcGxldGVkDQo+Pj4gKGl0J3MgdGhlIG9ubHkgZHJp dmVyIGluIHRoZSB0cmVlIHRoYXQgaXMga25vd24gdG8gYmUgdG90YWxseSBicm9rZW4pLg0KPj4+ ICBJdCdzIG9uDQo+Pj4gbXkgdG9kbyBsaXN0IGZvciA4LjAgYnV0IHdvdWxkIGhhcHBpbHkgZGVm ZXIgdG8gc29tZW9uZSBlbHNlIDopLg0KPj4NCj4+IElmIHRoZSBhbnN3ZXIgaXMgeWVzLCB0aGVu IEknbGwgdHJ5IGEgbGl0dGxlIGhhcmRlci4NCj4NCj4gU29ycnkgdGhlIGRyaXZlciBuZXZlciBn b3QgZml4ZWQgYWZ0ZXIgY29udmVyc2lvbiB0byB2YXBzOyBpdCdzIG9uIHRoZSA4LjANCj4gVE9E TyBsaXN0LiAgSSdtIG5vdCBzdXJlIGl0J3MgZ29pbmcgdG8gYmUgZml4ZWQgYmVmb3JlIDguMC4N Ck9LIHRoYW5rcyBmb3IgdGhlIHJlcGx5LCBhbmQgVElBIGZvciB3aGVuZXZlciB5b3UncmUgYWJs ZSB0byBmaXggaXQuDQotSmFtZXMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpGcm9tOiAgSm9obiBIYXkgPGpoYXlAbWVy YWthLm9yZy56YT4NClRvOiAgVGltIEtpZW50emxlIDxraWVudHpsZUBmcmVlYnNkLm9yZz4NClN1 YmplY3Q6ICBSZTogSm9saWV0IGFuZCByZWxlYXNlIElTT3M/DQpEYXRlOiAgU3VuMTkgSnVsIDIw MDkgMDk6NTQ6NTkgKzAyMDANCk9uIEZyaSwgSnVsIDE3LCAyMDA5IGF0IDA5OjU2OjM0UE0gLTA3 MDAsIFRpbSBLaWVudHpsZSB3cm90ZToNCj4gRG8gd2UgbmVlZCBKb2xpZXQgZXh0ZW5zaW9ucyBv biB0aGUgcmVsZWFzZSBJU09zPw0KPiANCj4gVGhlIHJlYXNvbiBJIGFzayBpcyBhIGxpdHRsZSBp bnZvbHZlZDogIGpraW1AIHJlY2VudGx5DQo+IHBvaW50ZWQgb3V0IHRvIG1lIHRoYXQgdGFyIGlu IC1DVVJSRU5UIGNhbiBubyBsb25nZXINCj4gZXh0cmFjdCBzeW1saW5rcyBmcm9tIHRoZSByZWxl YXNlIElTT3MuDQo+IA0KPiBJIHRyYWNrZWQgdGhpcyBkb3duIHRvIHRoZSBmYWN0IHRoYXQgdGhl IHJlbGVhc2UgSVNPcw0KPiBoYXZlIGJvdGggSm9saWV0IGFuZCBSb2NrUmlkZ2UgZXh0ZW5zaW9u cyBhbmQgdGFyIG5vdw0KPiBzdXBwb3J0cyAoYW5kIGFjdHVhbGx5IHByZWZlcnMpIEpvbGlldCBl eHRlbnNpb25zIHdoZW4NCj4gaXQgc2VlcyB0aGVtLiBKb2xpZXQgZG9lc24ndCBzdXBwb3J0IHN5 bWxpbmtzLCBzbyB0YXINCj4gZG9lc24ndCBzZWUgc3ltbGlua3Mgb24gZGlza3Mgd2l0aCBib3Ro IGtpbmRzIG9mIGV4dGVuc2lvbnMuDQo+IA0KPiBUaGVyZSdzIGEgd29ya2Fyb3VuZCB0aGF0IHBl b3BsZSBjYW4gdXNlIGZvciBub3c6DQo+ICAgICB0YXIgeGYgaW1hZ2UuaXNvIC0tb3B0aW9ucz0h am9saWV0DQo+IGRpc2FibGVzIHRoZSBKb2xpZXQgc3VwcG9ydC4NCj4gDQo+IEknbSBjdXJpb3Vz IHdoZXRoZXIgcmVtb3ZpbmcgdGhlIC1KIG9wdGlvbiBmcm9tDQo+IC91c3Ivc3JjL3JlbGVhc2Uv Ki9ta2lzb2ltYWdlcy5zaCBpcyBhbiBvcHRpb24uDQpXaGF0IGlzIHRoZSByZWFzb24gZm9yIHBy ZWZlcmluZyBKdWxpZXQgaW4gdGFyPyBDYW4ndCB3ZSBqdXN0IHN3YXANCnRoZSBwcmVmZXJlbmNl Pw0KSm9obg0KLS0gDQpKb2huIEhheSAtLSBqaGF5QG1lcmFrYS5jc2lyLmNvLnphIC8gamhheUBG cmVlQlNELm9yZw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZyb206ICBUaW0gS2llbnR6bGUgPGtpZW50emxlQGZyZWVi c2Qub3JnPg0KVG86ICBKb2huIEhheSA8amhheUBtZXJha2Eub3JnLnphPg0KU3ViamVjdDogIFJl OiBKb2xpZXQgYW5kIHJlbGVhc2UgSVNPcz8NCkRhdGU6ICBTdW4xOSBKdWwgMjAwOSAwMToxNzox MyAtMDcwMA0KSm9obiBIYXkgd3JvdGU6DQo+IE9uIEZyaSwgSnVsIDE3LCAyMDA5IGF0IDA5OjU2 OjM0UE0gLTA3MDAsIFRpbSBLaWVudHpsZSB3cm90ZToNCj4+IERvIHdlIG5lZWQgSm9saWV0IGV4 dGVuc2lvbnMgb24gdGhlIHJlbGVhc2UgSVNPcz8NCj4+DQo+PiBUaGUgcmVhc29uIEkgYXNrIGlz IGEgbGl0dGxlIGludm9sdmVkOiAgamtpbUAgcmVjZW50bHkNCj4+IHBvaW50ZWQgb3V0IHRvIG1l IHRoYXQgdGFyIGluIC1DVVJSRU5UIGNhbiBubyBsb25nZXINCj4+IGV4dHJhY3Qgc3ltbGlua3Mg ZnJvbSB0aGUgcmVsZWFzZSBJU09zLg0KPj4NCj4+IEkgdHJhY2tlZCB0aGlzIGRvd24gdG8gdGhl IGZhY3QgdGhhdCB0aGUgcmVsZWFzZSBJU09zDQo+PiBoYXZlIGJvdGggSm9saWV0IGFuZCBSb2Nr UmlkZ2UgZXh0ZW5zaW9ucyBhbmQgdGFyIG5vdw0KPj4gc3VwcG9ydHMgKGFuZCBhY3R1YWxseSBw cmVmZXJzKSBKb2xpZXQgZXh0ZW5zaW9ucyB3aGVuDQo+PiBpdCBzZWVzIHRoZW0uIEpvbGlldCBk b2Vzbid0IHN1cHBvcnQgc3ltbGlua3MsIHNvIHRhcg0KPj4gZG9lc24ndCBzZWUgc3ltbGlua3Mg b24gZGlza3Mgd2l0aCBib3RoIGtpbmRzIG9mIGV4dGVuc2lvbnMuDQo+IA0KPiBXaGF0IGlzIHRo ZSByZWFzb24gZm9yIHByZWZlcmluZyBKdWxpZXQgaW4gdGFyPyBDYW4ndCB3ZQ0KPiBqdXN0IHN3 YXAgdGhlIHByZWZlcmVuY2U/DQpCZWNhdXNlIG9mIHRoZSB3YXkgbGliYXJjaGl2ZSB3b3JrcyBp bnRlcm5hbGx5IGNvdXBsZWQgd2l0aA0KYmFzaWMgZGlmZmVyZW5jZXMgaW4gaG93IEpvbGlldCBh bmQgUm9ja1JpZGdlIGluZm9ybWF0aW9uDQppcyBzdG9yZWQsIGl0IHR1cm5zIG91dCB0aGF0IGxp YmFyY2hpdmUgaGFzIHRvIGRlY2lkZQ0Kd2hldGhlciBvciBub3QgdG8gdXNlIHRoZSBKb2xpZXQg aW5mb3JtYXRpb24gYmVmb3JlIGl0DQpjYW4gdGVsbCB3aGV0aGVyIFJvY2tSaWRnZSBpbmZvcm1h dGlvbiBpcyBhdmFpbGFibGUuDQpTbyBwcmVmZXJyaW5nIFJvY2tSaWRnZSBpcyBhY3R1YWxseSBx dWl0ZSBkaWZmaWN1bHQuDQpJIHdvdWxkIGxpa2UgdG8gY2hhbmdlIHRoaXMsIGJ1dCBpdCdzIGdv aW5nIHRvIGJlDQpxdWl0ZSBhIHdoaWxlIGJlZm9yZSBJIGhhdmUgZW5vdWdoIHRpbWUgdG8gd29y ayBvbiBpdC4NClRpbQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZyb206ICBUaG9tYXMgQmFja21hbiA8c2VyZW5pdHlA ZXhzY2FwZS5vcmc+DQpUbzogIE1jTG9uZSA8bWNsb25lQGdtYWlsLmNvbT4NClN1YmplY3Q6ICBS ZTogW2J1Z10gWkZTIHp2b2wgZGV2IGVudHJ5IGRpc2FwcGVhcmluZyB1cG9uIHJlYm9vdA0KRGF0 ZTogIFN1bjE5IEp1bCAyMDA5IDEzOjA1OjI1ICswMjAwDQpPbiBKdWwgMTgsIDIwMDksIGF0IDE5 OjI3LCBNY0xvbmUgd3JvdGU6DQo+IEhlbGwgTG93Lg0KPg0KPiBBcyBkb3dubG9hZGluZyB0b3Jy ZW50IGZpbGVzIGZyb20gbWFueSBwZWVycyB0byBaRlMNCj4gaW1wb3NlcyBmcmFnbWVudGF0aW9u IChhbmQgdGhlcmUncyBubyB3YXkgdG8gZGVmcmFnbWVudA0KPiBaRlMgdm9sdW1lIC0gd2hhdCBh IHBpdHkhIEhvdyBjb21lIG5vdy1hLWRheXMgRlMgY2FuDQo+IGdvIGxpa2UgdGhpcz8pLCBpIGNy ZWF0ZWQgenZvbCB3aXRoIFVGUzIgb24gaXQgbGFzdCB0aW1lDQo+IGkgd2FudGVkIHRvIHdhdGNo IHNvbWUgb2xkIHNjaS1maS4gSSBoYWQgcGxhbnMgdG8NCj4gbW92ZSBzY2ktZmkgZnJvbSBVRlMy L3p2b2wgdG8gWkZTIHdoZW4gaXQnbGwgYmUgY29tcGxldGUsDQo+IGJ1dCBmb3Jnb3QgaXQsIGFu ZCByZWJvb3RlZCBtYWNoaW5lLiBBZnRlciByZWJvb3QNCj4gcnRvcnJlbnQgc2FpZCBzY2ktZmkg aXMgbWFya2VkIGFzIGNvbXBsZXRlLCBidXQgaXQNCj4gY2FuIG5vdCBmaW5kIGZpbGVzLiBJIHdh c24ndCBzdXJwcmlzZWQsIGFzIGkgaGF2ZW4ndCBtb2RpZmllZA0KPiBteSAvZXRjL2ZzdGFiLCBz byBpIGVudGVyZWQgIm1vdW50IC9kZXYvenZvbCIgYW5kIHByZXNzZWQNCj4gVGFiIGluIGhvcGUg b2YgdGNzaCAoZWVrKSBhdXRvY29tcGxldGUuDQo+IEl0IGp1c3QgYmVlcGVkIG9uIG1lLg0KPiBJ J3ZlIGRvbmUgImxzIC9kZXYiIGFuZCB0aGVyZSB3YXMgbm8gZGlyZWN0b3J5IHRoZXJlIG5hbWVk IHp2b2wuDQo+IFRoZW4gaSd2ZSBkb25lICJ6ZnMgbGlzdCIgYW5kIG15IHp2b2wgd2FzIHRoZXJl Lg0KPiBQdXp6bGVkLCBpJ3ZlIGRvbmUgInpmcyBzbmFwc2hvdCIgYW5kIHRoZW4gYSBsaXR0bGUg ZGFuY2Ugb2YNCj4gInpmcyBzZW5kIHwgemZzIHJlY3YiIHRvIGEgbmV3IHZvbHVtZS4gTm93IGRl diBlbnRyaWVzIGFwcGVhcmVkDQo+IChib3RoIGZvciBuZXdseSBjcmVhdGVkIHNuYXBzaG90IG9m IGFuIG9sZCB6dm9sIGFuZCBmb3IgbmV3IHp2b2wpLg0KPiBJIHJlYm9vdGVkLCBhbmQgdGhlcmUg d2FzIG5vIC9kZXYvenZvbCBhZ2Fpbi4NCj4NCj4gSSBsb29rZWQgYXQgbXkgdW5hbWUgLXYgb3V0 cHV0IChpdCB3YXMgSEVBRC9hbWQ2NCBmcm9tIEp1bCAxKQ0KPiBhbmQgZGVjaWRlZCB0byB1cGRh dGUuIFVwZGF0aW5nIGRpZG4ndCBzb2x2ZWQgdGhpcyBwcm9ibGVtLg0KPg0KPiBTdHJhbmdlbHks IHNpbXBsZSAiemZzIHJlbmFtZSB6cG9vbC96dm9sIHpwb29sL25ld3p2b2wiDQo+IGN1cmVzIHRo aXMgd29lLCBidXQgaSB0aGluayB0aGlzIGlzIGEgYnVnLg0KPg0KPiBTdGVwcyB0byByZXByb2R1 Y2U6DQo+IHpmcyBjcmVhdGUgLVYgMWcgenBvb2wvenZvbA0KPiBbbmV3ZnMgL2Rldi96dm9sL3pw b29sL3p2b2xdDQo+IHJlYm9vdA0KPiBscyAvZGV2DQo+DQo+IFdvcmthcm91bmQ6DQo+IHpmcyBy ZW5hbWUgenBvb2wvenZvbCB6cG9vbC9uZXd6dm9sDQo+IG1vdW50IC9kZXYvenZvbC96cG9vbC96 dm9sIC9tbnQNCkhtbSwgSSBkaWQgYSBxdWljayB0ZXN0IGFuZCB3YXMgdW5hYmxlIHRvIHJlcHJv ZHVjZS4gVGhlcmUgYXJlIEFMTCB0aGUgIA0Kc3RlcHMgSSB0b29rLCBpLmUuIEkgbmV2ZXIgbW91 bnRlZCB0aGUgZnMncyBvciBhbnl0aGluZy4NCltyb290QGNoYW9zIH5dIyB6ZnMgY3JlYXRlIC1W IDFnIHRhbmsvenZvbA0KW3Jvb3RAY2hhb3Mgfl0jIHpmcyBjcmVhdGUgLVYgMWcgdGFuay96dm9s MiAjIyB0byB0ZXN0IGlmIHRoZSBuYW1lICANCiJ6dm9sIiBjYXVzZXMgcHJvYmxlbXMNCltyb290 QGNoYW9zIH5dIyBuZXdmcyAvZGV2L3p2b2wvdGFuay96dm9sDQovZGV2L3p2b2wvdGFuay96dm9s OiAxMDI0LjBNQiAoMjA5NzE1MiBzZWN0b3JzKSBibG9jayBzaXplIDE2Mzg0LCAgDQpmcmFnbWVu dCBzaXplIDIwNDgNCiAgICAgICAgIHVzaW5nIDYgY3lsaW5kZXIgZ3JvdXBzIG9mIDE4My43Mk1C LCAxMTc1OCBibGtzLCAyMzU1MiBpbm9kZXMuDQpzdXBlci1ibG9jayBiYWNrdXBzIChmb3IgZnNj ayAtYiAjKSBhdDoNCiAgMTYwLCAzNzY0MTYsIDc1MjY3MiwgMTEyODkyOCwgMTUwNTE4NCwgMTg4 MTQ0MA0KW3Jvb3RAY2hhb3Mgfl0jIG5ld2ZzIC9kZXYvenZvbC90YW5rL3p2b2wyDQovZGV2L3p2 b2wvdGFuay96dm9sMjogMTAyNC4wTUIgKDIwOTcxNTIgc2VjdG9ycykgYmxvY2sgc2l6ZSAxNjM4 NCwgIA0KZnJhZ21lbnQgc2l6ZSAyMDQ4DQogICAgICAgICB1c2luZyA2IGN5bGluZGVyIGdyb3Vw cyBvZiAxODMuNzJNQiwgMTE3NTggYmxrcywgMjM1NTIgaW5vZGVzLg0Kc3VwZXItYmxvY2sgYmFj a3VwcyAoZm9yIGZzY2sgLWIgIykgYXQ6DQogIDE2MCwgMzc2NDE2LCA3NTI2NzIsIDExMjg5Mjgs IDE1MDUxODQsIDE4ODE0NDANCltyb290QGNoYW9zIH5dIyBscyAtUiAvZGV2L3oqDQovZGV2L3pl cm8gICAgICAgL2Rldi96ZnMNCi9kZXYvenZvbDoNCnRhbmsNCi9kZXYvenZvbC90YW5rOg0KenZv bCAgICB6dm9sMg0KW3Jvb3RAY2hhb3Mgfl0jIHJlYm9vdA0KQ29ubmVjdGlvbiB0byAxOTIuMTY4 LjEuMTAgY2xvc2VkIGJ5IHJlbW90ZSBob3N0Lg0KLS0tLS0tLS0tLS0tLS0tLQ0KW3Jvb3RAY2hh b3Mgfl0jIHVwdGltZQ0KICAxOjA0UE0gIHVwIDI5IHNlY3MsIDIgdXNlcnMsIGxvYWQgYXZlcmFn ZXM6IDAuODcsIDAuMjcsIDAuMTANCltyb290QGNoYW9zIH5dIyBscyAtUiAvZGV2L3oqDQovZGV2 L3plcm8gICAgICAgL2Rldi96ZnMNCi9kZXYvenZvbDoNCnRhbmsNCi9kZXYvenZvbC90YW5rOg0K enZvbCAgICB6dm9sMg0KUmVnYXJkcywNClRob21hcw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZnJlZWJzZC1jdXJyZW50QGZyZWVic2Qub3Jn IG1haWxpbmcgbGlzdA0KaHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8v ZnJlZWJzZC1jdXJyZW50DQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJz ZC1jdXJyZW50LXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0K From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 07:37:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98E1D1065675 for ; Mon, 20 Jul 2009 07:37:45 +0000 (UTC) (envelope-from pvizeli@yahoo.de) Received: from web28610.mail.ukl.yahoo.com (web28610.mail.ukl.yahoo.com [87.248.110.219]) by mx1.freebsd.org (Postfix) with SMTP id DDBC28FC2A for ; Mon, 20 Jul 2009 07:37:44 +0000 (UTC) (envelope-from pvizeli@yahoo.de) Received: (qmail 76636 invoked by uid 60001); 20 Jul 2009 07:11:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.de; s=s1024; t=1248073863; bh=mSL4ePDpqnKHR1iBHcMNrOyJjzczAWMVLogYcB21dn8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=1Qj6b7EiXpTEf6cIRlaP+9f5IgY7FU74v9q8nNAh1XKW99TSPI8mDYupl5O9TifZokyWttp6LsDW+XbmH0ChuXbw0OVPbbAOteS9gztl+vyRvjn9nnbkbtDF7OYuFEceLp0uiu8emKgzTv8tW45lLvdYMMIyX/1O4pHQZ4/Oyp4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.de; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=T0aER+TkGKRpw7zXy2nemXk9gOdi7FwPgU+k9tpu0cyXuRBcRXc69hmkQ665ENGNUi3GoYNtL9qpAKhTDKdDAhqOgx531hqOjdAIjy3EZ/F057m5+hbCASGa4fjg81LdJ8qsIyvWD4UQnnDUScZCd0Z8YYihB4T2zPfHuflDE08=; Message-ID: <145022.76269.qm@web28610.mail.ukl.yahoo.com> X-YMail-OSG: kVm1gJEVM1kQvkyg3XuR_OgvAFGFBNN6mdSplw1kVNo7rtOkGyZWF5djEyvvqlAnFO6IU7VMHisSXG1BbSpnBQx0YgiLftU3EGghChQaHPeKJcmplDVIA6I52wA1Vi8nrTglcVkn18Y_KtDqCWVL4AgMD1Nf5eRK.fucw7HOqe9wKf5FsNdR.xYZPTc6ne.kBiclotchHAs5vx.YDENKB2XkmeZ66MLBfnMMNRKh.0OnmMXbjH92_gFkVBf0rv9Ut0FjiZ4o6EZOt85N Received: from [77.59.201.234] by web28610.mail.ukl.yahoo.com via HTTP; Mon, 20 Jul 2009 07:11:02 GMT X-Mailer: YahooMailRC/1358.22 YahooMailWebService/0.7.289.15 Date: Mon, 20 Jul 2009 07:11:02 +0000 (GMT) From: Vizeli Pascal To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 20 Jul 2009 12:11:17 +0000 Subject: 8.0-Beta2 / Ideapad S10e / bwi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 07:37:46 -0000 Hi=0A=0AI've install freebsd 8.0-Beta2 on my netbook ideapad s10e. It work = nice but the=0Awireless driver dosen't work. I've seen that exists new bwi = drivers. I recompile=0Amy kernel with (device bwi) but he dosn't see them. = Have every body a idea, why=0Athe bwi dosn't work?=0A=0AThe bluetooth drive= r also dosn't work. But that is a nice to have feature. I will porting=0Ath= e bluetooth drivers from openbsd or netbsd (at the moment i've forgotten wi= tch bsd have implement this driver) into the next freebsd version.=0A=0Atha= nks all people for his works! A great version!=0A=0Agreets=0Apascal=0A=0A= =0A=0A From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 12:48:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9BBC1065676 for ; Mon, 20 Jul 2009 12:48:48 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8FC9C8FC19 for ; Mon, 20 Jul 2009 12:48:48 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 2C2983BC308; Mon, 20 Jul 2009 08:30:45 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Mon, 20 Jul 2009 08:30:45 -0400 X-Sasl-enc: vqLFBJGpmPiThNCd3LtUHPgHMHQmX40LQWC+3qIrx4K1 1248093044 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id AFCA1A4E5; Mon, 20 Jul 2009 08:30:44 -0400 (EDT) Message-ID: <4A646373.3050807@FreeBSD.org> Date: Mon, 20 Jul 2009 13:30:43 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Vizeli Pascal References: <145022.76269.qm@web28610.mail.ukl.yahoo.com> In-Reply-To: <145022.76269.qm@web28610.mail.ukl.yahoo.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8.0-Beta2 / Ideapad S10e / bwi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 12:48:49 -0000 Vizeli Pascal wrote: > The bluetooth driver also dosn't work. But that is a nice to have feature. I will porting > the bluetooth drivers from openbsd or netbsd (at the moment i've forgotten witch bsd have implement this driver) into the next freebsd version. > Can you describe exactly how Bluetooth doesn't seem to work for you with the new machine? Maksim Yevmenkin has done sterling work on the FreeBSD Netgraph-based Bluetooth stack. If there is a regression with the Bluetooth drivers in FreeBSD 8.0, then now is the best time to get it sorted out. These are fairly standard parts, however; most Bluetooth chips these days are USB and use the standard HCI interface, so it's difficult to know what's wrong, without detailed debugging information (usbdevs -v output, hccontrol output, dmesg etc). There is another Bluetooth stack in NetBSD, which was written by Iain Hibbert, sponsored by Itronix. It does not use Netgraph, however, it depends heavily on a number of NetBSD-specific system components, e.g. proplib. If you're up for all the porting work, that's great -- I would certainly not be one to discourage you -- but it seems like a lot of work just to fix a driver regression. thanks, BMS From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 12:57:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3F701065670; Mon, 20 Jul 2009 12:57:55 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 3B1928FC0C; Mon, 20 Jul 2009 12:57:55 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 473166226; Mon, 20 Jul 2009 14:57:54 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n6KCvoKv002737; Mon, 20 Jul 2009 14:57:51 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1248094673; bh=6wWeVdLGTQEyXNYLsgpZFy3z83xPKbRWkuES/Fb4P5k=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=0AthG3DLvuQSnsNQCajTLrE+JRTgPhE2/zqYyMGxabNcFz9gRtS2OJw5U4w3yJrl+ 5UjaI/0mnrttI0aOSqb9Q== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=mYWlQDiNUjYJVtyroypxxRhg+NZ8vat0P2g7kaF8+L0MYseTa8IzwjDC/R3Jm9JVc cFyJakPi4uen8ic/vCG5A== Message-ID: <4A6469CE.4060907@restart.be> Date: Mon, 20 Jul 2009 14:57:50 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.22 (X11/20090717) MIME-Version: 1.0 To: "Li, Qing" References: <4A5734C3.3000806@restart.be> <4A5864DC.1070106@restart.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 12:57:56 -0000 Li, Qing wrote: > The patch has been committed, svn revision 195643. > > Thanks, > > -- Qing > Just another case where the route must be created: [root@avoriaz ~]# ifconfig gif0 gif0: flags=8051 metric 0 mtu 1280 tunnel inet 212.239.166.57 --> 94.23.44.41 inet6 fe80::21d:60ff:fead:2ace%gif0 prefixlen 64 scopeid 0x4 inet6 2001:41d0:2:2d29:1:ffff:: --> 2001:41d0:2:2d29:0:ffff:: prefixlen 128 options=1 [root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff:: PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: --> 2001:41d0:2:2d29:1:ffff:: ^C --- 2001:41d0:2:2d29:1:ffff:: ping6 statistics --- 4 packets transmitted, 0 packets received, 100.0% packet loss [root@avoriaz ~]# route add -inet6 2001:41d0:2:2d29:1:ffff:: -interface lo0 add host 2001:41d0:2:2d29:1:ffff::: gateway lo0 [root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff:: PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: --> 2001:41d0:2:2d29:1:ffff:: 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.531 ms 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.884 ms 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.748 ms ^C --- 2001:41d0:2:2d29:1:ffff:: ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.531/0.721/0.884/0.145 ms Thanks Henri > > -----Original Message----- > From: Henri Hennebert [mailto:hlh@restart.be] > Sent: Sat 7/11/2009 3:09 AM > To: Li, Qing > Cc: freebsd-stable@freebsd.org; freebsd-net@freebsd.org > Subject: Re: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections > > Li, Qing wrote: >> Hi, >> >> Please try patch-7-10 in my home directory http://people.freebsd.org/~qingli/ >> and let me know how it works out for you. I thought I had committed the patch >> but turned out I didn't. > > I apply the patch, reset my pf.conf to its previous content and all is > running smoothly. By the way, I discover after my post that my > "solution" was not working for long (many bytes) connections and this is > solved too. > > Many thank for your time > > Henri > > PS please commit as soon as possible > >>> On 8.0-BETA1 there is an assymetry: >>> >>> netstat -rn display >>> >>> 192.168.24.1 link#3 >>> .... >>> no entry for 2001:41d0:2:2d29:1:1:: >>> >> This is by design as part of the new architecture in 8.0, which maintains >> the L2 ARP/ND6 and L3 routing tables separately. >> >> -- Qing >> >> >> >> -----Original Message----- >> From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert >> Sent: Fri 7/10/2009 5:32 AM >> To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org >> Subject: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections >> >> Hello, >> >> After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem when >> connecting with firefox to a local apache server using the global >> unicast IPv6 address of the local machine. pf.conf must be updated! >> >> My configuration: >> >> [root@avoriaz ~]# ifconfig em0 >> >> em0: flags=8843 metric 0 mtu 1500 >> options=19b >> ether 00:1d:60:ad:2a:ce >> inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255 >> inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 >> inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 >> media: Ethernet 100baseTX (100baseTX ) >> status: active >> >> [root@avoriaz ~]# host www.restart.bel >> www.restart.bel is an alias for avoriaz.restart.bel. >> avoriaz.restart.bel has address 192.168.24.1 >> avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: >> >> pf.conf: >> >> int_if="em0" >> block in log all >> block out log all >> set skip on lo0 >> antispoof quick for $int_if inet >> # Allow trafic with physical internal network >> pass in quick on $int_if from ($int_if:network) to ($int_if) keep state >> pass out quick on $int_if from ($int_if) to ($int_if:network) keep state >> >> The problem: >> >> [root@avoriaz ~]# telnet -4 www.restart.bel 80 >> Trying 192.168.24.1... >> Connected to avoriaz.restart.bel. >> Escape character is '^]'. >> ^] >> telnet> quit >> Connection closed. >> [root@avoriaz ~]# telnet -6 www.restart.bel 80 >> Trying 2001:41d0:2:2d29:1:1::... >> --->Never connect and get a timeout! >> >> tcpdump and logging in pf show me that >> >> For a IPv4 connection: >> the packet from telnet to apache pass 2 times on lo0 (out and in) >> the answer packet from apache to telnet pass 2 times on lo0 (out and in) >> >> So no problem, there is `set skip on lo0' >> >> For a IPv6 connection: >> The first packet from telnet to apache pass 2 times on lo0 (out and in) >> The answer packet from apache to telnet path on em0 and is rejected >> due to the default flags S/SA. >> >> So I have to change pf.conf and replace the last line: >> pass out quick on $int_if from ($int_if) to ($int_if:network) \ >> keep state flags any >> >> Then all is OK >> >> By the way, on 7.2 >> >> netstat -rn display >> >> 192.168.24.1 00:1d:60:ad:2a:ce >> .... >> 2001:41d0:2:2d29:1:1:: 00:1d:60:ad:2a:ce >> >> >> On 8.0-BETA1 there is an assymetry: >> >> netstat -rn display >> >> 192.168.24.1 link#3 >> .... >> no entry for 2001:41d0:2:2d29:1:1:: >> >> Hope it may help someone >> >> Henri >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 14:29:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 668A7106564A for ; Mon, 20 Jul 2009 14:29:42 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-fx0-f205.google.com (mail-fx0-f205.google.com [209.85.220.205]) by mx1.freebsd.org (Postfix) with ESMTP id CB9698FC1A for ; Mon, 20 Jul 2009 14:29:41 +0000 (UTC) (envelope-from olivier@gid0.org) Received: by fxm1 with SMTP id 1so435729fxm.43 for ; Mon, 20 Jul 2009 07:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.117.142 with SMTP id r14mr4364379bkq.197.1248100179747; Mon, 20 Jul 2009 07:29:39 -0700 (PDT) In-Reply-To: <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> Date: Mon, 20 Jul 2009 16:29:39 +0200 Message-ID: <367b2c980907200729s57eafbbfw83c8ae5a94f41ffc@mail.gmail.com> From: Olivier SMEDTS To: Thomas Backman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ken Smith , freebsd-stable , FreeBSD current Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 14:29:42 -0000 2009/7/19 Thomas Backman : > On Jul 19, 2009, at 20:16, Ken Smith wrote: >> >> The problem is that as of the next time you update a machine that had >> been running -current you are best off reinstalling all ports or other >> applications you have on the machine. =A0When you reboot after doing the >> update to the base system everything you have installed will still work >> because the old shared library versions will still be there. =A0However >> anything you build on the machine after its base system gets updated >> would be linked against the newer base system shared libraries but any >> libraries that are part of ports or other applications (e.g. the Xorg >> libraries) would have been linked against the older library versions. >> You really don't want to leave things that way. > > So, to be clear: a fresh ports tree and "portupgrade -af" after building = and > installing r195767+ should be enough to solve any problems? (installkerne= l, > installworld, reboot, portupgrade -af) But there won't be any problem until you do a "make delete-old-libs" in /usr/src/, right ? Olivier > > Regards, > Thomas > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 14:34:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71B87106566B; Mon, 20 Jul 2009 14:34:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id D1F318FC0A; Mon, 20 Jul 2009 14:34:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 n6KEYdbF014434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 20 Jul 2009 17:34:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n6KEYdLd098402; Mon, 20 Jul 2009 17:34:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n6KEYd56098401; Mon, 20 Jul 2009 17:34:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 20 Jul 2009 17:34:39 +0300 From: Kostik Belousov To: Olivier SMEDTS Message-ID: <20090720143439.GL55190@deviant.kiev.zoral.com.ua> References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> <367b2c980907200729s57eafbbfw83c8ae5a94f41ffc@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+fye0PR5b9WR6S4/" Content-Disposition: inline In-Reply-To: <367b2c980907200729s57eafbbfw83c8ae5a94f41ffc@mail.gmail.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.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: Ken Smith , freebsd-stable , Thomas Backman , FreeBSD current Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 14:34:55 -0000 --+fye0PR5b9WR6S4/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2009 at 04:29:39PM +0200, Olivier SMEDTS wrote: > 2009/7/19 Thomas Backman : > > So, to be clear: a fresh ports tree and "portupgrade -af" after buildin= g and > > installing r195767+ should be enough to solve any problems? (installker= nel, > > installworld, reboot, portupgrade -af) >=20 > But there won't be any problem until you do a "make delete-old-libs" > in /usr/src/, right ? Cherry-picking of the ports to upgrade is also problematic, as well as a compilation of third party software. --+fye0PR5b9WR6S4/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpkgH8ACgkQC3+MBN1Mb4jd3wCfZcoUpfRt7jY2oCMkSpxH7XP1 2YMAoOd5iXU81GmYPrWKWQ/wt8k2SSV8 =kuqh -----END PGP SIGNATURE----- --+fye0PR5b9WR6S4/-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 15:58:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CB88106566B for ; Mon, 20 Jul 2009 15:58:48 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id B4CA68FC0C for ; Mon, 20 Jul 2009 15:58:47 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: by vwj2 with SMTP id 2so2145060vwj.3 for ; Mon, 20 Jul 2009 08:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=WST6hbzowZIcbJF+7FqfUoGS/0naCXOTCmSwU1Huqu8=; b=qi0eKGEBuMhTkq1g654dlzVWKUCf08o4C99O0dbT7Cnrkbm1CYaIDFiKIZzHvQV572 Hzc3px484kDk4vw6f5a8tSISeCBE4wQhmL7c1Z3TycpvXJRccbSa/CML1a5kVlwGlC00 O11VsPsmumFAoDcaoZ99TvBzzlUzQpN8xOp/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=Eqsa3YsoxqEn/AkcDDSBPdGVg88qhABQilmKrSHmkvDLkvLhaguuiaetz75BaaNFbc SJWKyVREo82kj9aJAKdEN4ZniojgXrtSn9Esh6k/+dPMvK9io5TXzH2TiT84aMuA3GVk 4o2hem6nYG4C8IB4TzVm/j2HKvJ+nCz289itA= MIME-Version: 1.0 Received: by 10.220.46.5 with SMTP id h5mr5093187vcf.18.1248105527123; Mon, 20 Jul 2009 08:58:47 -0700 (PDT) From: Renato Botelho Date: Mon, 20 Jul 2009 12:58:27 -0300 Message-ID: <747dc8f30907200858n330a72a0y3c36c927ac24f79f@mail.gmail.com> To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Error building -current on i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 15:58:48 -0000 # uname -a FreeBSD botelhor.bplab.local 8.0-BETA2 FreeBSD 8.0-BETA2 #78 r195716: Thu Jul 16 08:45:28 BRT 2009 root@botelhor.bplab.local:/usr/obj/usr/src/sys/GARGA i386 I'm trying to build -current r195782 but i got this: I tried to remove /usr/objj, ran make clean twice, but the problem persists. ===> gnu/usr.bin/gperf/doc (depend) c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/bool-array.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/gen-perf.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/hash-table.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/iterator.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/key-list.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/list-node.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/main.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/new.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/read-line.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/trace.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/vectors.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/version.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib/hash.cc c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -static -L/usr/obj/usr/src/tmp/legacy/usr/lib -o gperf bool-array.o gen-perf.o hash-table.o iterator.o key-list.o list-node.o main.o new.o options.o read-line.o trace.o vectors.o version.o hash.o -legacy /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0x98e): In function `.L140': : undefined reference to `__stack_chk_fail_local' /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0xddc): In function `__frame_state_for': : undefined reference to `__stack_chk_fail_local' /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0x1706): In function `.L399': : undefined reference to `__stack_chk_fail_local' /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0x1ba5): In function `_Unwind_Backtrace': : undefined reference to `__stack_chk_fail_local' /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0x1e0d): In function `_Unwind_RaiseException': : undefined reference to `__stack_chk_fail_local' /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0x1fe1): more undefined references to `__stack_chk_fail_local' follow *** Error code 1 Stop in /usr/src/gnu/usr.bin/gperf. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 -- Renato Botelho From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 16:33:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A674B106566B for ; Mon, 20 Jul 2009 16:33:27 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 5659B8FC25 for ; Mon, 20 Jul 2009 16:33:26 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: by vwj2 with SMTP id 2so2176151vwj.3 for ; Mon, 20 Jul 2009 09:33:26 -0700 (PDT) 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 :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=7L4nuGJ2M9ufreFoYz3WsaurvCm8mqwnYDe7kFpyG04=; b=H64eJtWIPaNxKCy9xZAv5oHtYmgsSL487aYuHUiwGu8cjKanVdWQdPMloS5ZMCRiXd Ug5ofzVP7hmPIzPBaz+ZikkF552T7zbdIkKx6k+7T4SXV+WvF2KNCiVZH/9nxOK9xLId 36LYpl5MBYYPZSaOMlxEftrjk/dXw0HnHzBVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=CrfUSdw/Fia6cpKCmx037rTJmvlnHHeOIcrGyv3dhm3QecoornWkawmKgnmKvaw8or DOtVT1LoLvEX2+G0bbEuqXTNXyG+6Xh2aFETlM6gLFa6eLDTK8y/+pDd2HJOiEv1ymok 2L//FZ0ogqpq7ytlo0TyCgtD29cKRpnvKtj2M= MIME-Version: 1.0 Received: by 10.220.74.85 with SMTP id t21mr5952336vcj.105.1248107606144; Mon, 20 Jul 2009 09:33:26 -0700 (PDT) In-Reply-To: <20090720161141.GG77331@bunrab.catwhisker.org> References: <747dc8f30907200858n330a72a0y3c36c927ac24f79f@mail.gmail.com> <20090720161141.GG77331@bunrab.catwhisker.org> From: Renato Botelho Date: Mon, 20 Jul 2009 13:33:06 -0300 Message-ID: <747dc8f30907200933y40bdd364m9305c3ec452eceb1@mail.gmail.com> To: David Wolfskill Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Error building -current on i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 16:33:27 -0000 On Mon, Jul 20, 2009 at 1:11 PM, David Wolfskill wrot= e: > On Mon, Jul 20, 2009 at 12:58:27PM -0300, Renato Botelho wrote: >> # uname -a >> FreeBSD botelhor.bplab.local 8.0-BETA2 FreeBSD 8.0-BETA2 #78 r195716: >> Thu Jul 16 08:45:28 BRT 2009 >> root@botelhor.bplab.local:/usr/obj/usr/src/sys/GARGA =A0i386 >> >> I'm trying to build -current r195782 but i got this: >> >> I tried to remove /usr/objj, ran make clean twice, but the problem persi= sts. >> >> =3D=3D=3D> gnu/usr.bin/gperf/doc (depend) >> c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include >> ... >> /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0x1e0d): In function >> `_Unwind_RaiseException': >> : undefined reference to `__stack_chk_fail_local' >> /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0x1fe1): more undefined >> references to `__stack_chk_fail_local' follow >> *** Error code 1 >> ... > > I encountered this last week, and resolved it (in my case) over the > weekend: =A0I found that > > =A0 =A0 =A0 =A0pushd gnu/lib/libgcc && make clean && make && make install > > allowed my build to proceed. Seems to work here, thank you --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 16:35:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED577106564A for ; Mon, 20 Jul 2009 16:35:36 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id ACDBA8FC2D for ; Mon, 20 Jul 2009 16:35:36 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id n6KGBf32078808; Mon, 20 Jul 2009 09:11:41 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id n6KGBfMJ078807; Mon, 20 Jul 2009 09:11:41 -0700 (PDT) (envelope-from david) Date: Mon, 20 Jul 2009 09:11:41 -0700 From: David Wolfskill To: Renato Botelho Message-ID: <20090720161141.GG77331@bunrab.catwhisker.org> References: <747dc8f30907200858n330a72a0y3c36c927ac24f79f@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PyMzGVE0NRonI6bs" Content-Disposition: inline In-Reply-To: <747dc8f30907200858n330a72a0y3c36c927ac24f79f@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: FreeBSD Current Subject: Re: Error building -current on i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 16:35:37 -0000 --PyMzGVE0NRonI6bs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 20, 2009 at 12:58:27PM -0300, Renato Botelho wrote: > # uname -a > FreeBSD botelhor.bplab.local 8.0-BETA2 FreeBSD 8.0-BETA2 #78 r195716: > Thu Jul 16 08:45:28 BRT 2009 > root@botelhor.bplab.local:/usr/obj/usr/src/sys/GARGA i386 >=20 > I'm trying to build -current r195782 but i got this: >=20 > I tried to remove /usr/objj, ran make clean twice, but the problem persis= ts. >=20 > =3D=3D=3D> gnu/usr.bin/gperf/doc (depend) > c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include > ... > /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0x1e0d): In function > `_Unwind_RaiseException': > : undefined reference to `__stack_chk_fail_local' > /usr/lib/libgcc_eh.a(unwind-dw2.o)(.text+0x1fe1): more undefined > references to `__stack_chk_fail_local' follow > *** Error code 1 > ... I encountered this last week, and resolved it (in my case) over the weekend: I found that pushd gnu/lib/libgcc && make clean && make && make install allowed my build to proceed. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --PyMzGVE0NRonI6bs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkpklz0ACgkQmprOCmdXAD0vLACfXuHAgaJ9b+tXJBylpAMpX8OA IK4An10H8iZRovllsLZTzRtOMAdKu/X0 =nKlX -----END PGP SIGNATURE----- --PyMzGVE0NRonI6bs-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 16:51:24 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id F0011106566C; Mon, 20 Jul 2009 16:51:23 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Mon, 20 Jul 2009 12:51:09 -0400 User-Agent: KMail/1.6.2 References: <4A615602.4090000@freebsd.org> <4A62D689.1050906@freebsd.org> <4463doaifi.fsf@lowell-desk.lan> In-Reply-To: <4463doaifi.fsf@lowell-desk.lan> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907201251.13012.jkim@FreeBSD.org> Cc: John Hay , Tim Kientzle , Lowell Gilbert Subject: Re: Joliet and release ISOs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 16:51:24 -0000 On Sunday 19 July 2009 09:52 am, Lowell Gilbert wrote: > Tim Kientzle writes: > > John Hay wrote: > >> On Fri, Jul 17, 2009 at 09:56:34PM -0700, Tim Kientzle wrote: > >>> Do we need Joliet extensions on the release ISOs? > >>> > >>> The reason I ask is a little involved: jkim@ recently > >>> pointed out to me that tar in -CURRENT can no longer > >>> extract symlinks from the release ISOs. > >>> > >>> I tracked this down to the fact that the release ISOs > >>> have both Joliet and RockRidge extensions and tar now > >>> supports (and actually prefers) Joliet extensions when > >>> it sees them. Joliet doesn't support symlinks, so tar > >>> doesn't see symlinks on disks with both kinds of extensions. > >> > >> What is the reason for prefering Juliet in tar? Can't we > >> just swap the preference? > > > > Because of the way libarchive works internally coupled with > > basic differences in how Joliet and RockRidge information > > is stored, it turns out that libarchive has to decide > > whether or not to use the Joliet information before it > > can tell whether RockRidge information is available. > > So preferring RockRidge is actually quite difficult. > > > > I would like to change this, but it's going to be > > quite a while before I have enough time to work on it. > > Sounds like you're out of good options then. Maybe a good > temporary workaround would be a switch to disable Joliet support? It sounds reasonble to me because libarchive does not have ISO9660 writer yet and Joliet extensions are only useful for M$ OS users, ATM. In fact, many ISO9660 file system manipulation utilities out there do something similar, e.g., #ifdef MS enable_joliet_by_default(); #else disable_joliet_by_default(); #endif. If someone really needs it, it can be turned on by '--option=joliet', right? Thanks for tracking down the problem for me! Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 17:36:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 867BF106566B for ; Mon, 20 Jul 2009 17:36:07 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from mx.utwente.nl (mx2.utsp.utwente.nl [130.89.2.13]) by mx1.freebsd.org (Postfix) with ESMTP id 08A948FC16 for ; Mon, 20 Jul 2009 17:36:06 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by mx.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n6KHZER7032652; Mon, 20 Jul 2009 19:35:14 +0200 From: Pieter de Goeje To: Bruce Simpson Date: Mon, 20 Jul 2009 19:35:14 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; amd64; ; ) References: <200907182056.47383.pieter@degoeje.nl> <4A628056.60009@incunabulum.net> In-Reply-To: <4A628056.60009@incunabulum.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907201935.14389.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Sending multicast datagrams broken (regression) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 17:36:07 -0000 On Sunday 19 July 2009 04:09:26 Bruce Simpson wrote: > Pieter de Goeje wrote: > > I'm observing that multicast IPv4 UDP datagrams sent from the latest > > 8.0-BETA2 are being discarded. The code below used to work with 7.2. > > Can you tcpdump this? > > This may be related to an llentry related regression which Xin Li > recently posted a patch for, it appears that layer 2 addresses for > multicast/broadcast datagrams may be broken in 8.0-BETA2. > > Although I haven't tested this myself since committing the SSM code > around April, where I observed such traffic was correct. Dump from an 8.0 sender: http://unforgiven.student.utwente.nl/~pyotr/dump/mcast Indeed it looks like the destination mac address is different from the dump generated by 7.2. 8.0: 00:00:0c:07:ac:00 7.2: 01:00:5e:7f:09:09 Kind regards, Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 18:13:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 653CA106567E; Mon, 20 Jul 2009 18:13:35 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail2.es.net [IPv6:2001:400:107:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4B7288FC22; Mon, 20 Jul 2009 18:13:35 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n6KIDEiN025043 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Jul 2009 11:13:14 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id DAA6C1CC0B; Mon, 20 Jul 2009 11:13:13 -0700 (PDT) To: Olivier SMEDTS In-reply-to: Your message of "Mon, 20 Jul 2009 16:29:39 +0200." <367b2c980907200729s57eafbbfw83c8ae5a94f41ffc@mail.gmail.com> Date: Mon, 20 Jul 2009 11:13:13 -0700 From: "Kevin Oberman" Message-Id: <20090720181313.DAA6C1CC0B@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-07-20_08:2009-07-03, 2009-07-20, 2009-07-20 signatures=0 Cc: Ken Smith , freebsd-stable , Thomas Backman , FreeBSD current Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 18:13:36 -0000 > Date: Mon, 20 Jul 2009 16:29:39 +0200 > From: Olivier SMEDTS > Sender: owner-freebsd-current@freebsd.org > > 2009/7/19 Thomas Backman : > > On Jul 19, 2009, at 20:16, Ken Smith wrote: > >> > >> The problem is that as of the next time you update a machine that had > >> been running -current you are best off reinstalling all ports or other > >> applications you have on the machine.  When you reboot after doing the > >> update to the base system everything you have installed will still work > >> because the old shared library versions will still be there.  However > >> anything you build on the machine after its base system gets updated > >> would be linked against the newer base system shared libraries but any > >> libraries that are part of ports or other applications (e.g. the Xorg > >> libraries) would have been linked against the older library versions. > >> You really don't want to leave things that way. > > > > So, to be clear: a fresh ports tree and "portupgrade -af" after building and > > installing r195767+ should be enough to solve any problems? (installkernel, > > installworld, reboot, portupgrade -af) > > But there won't be any problem until you do a "make delete-old-libs" > in /usr/src/, right ? Wrong. As soon as you start updating ports you will start getting apps which link to both old and new versions and that does not work. If you don't update any ports which provide shared libs, you are OK. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 19:31:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 076FF10657C3; Mon, 20 Jul 2009 19:31:35 +0000 (UTC) (envelope-from cdillon@wolves.k12.mo.us) Received: from mail.wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by mx1.freebsd.org (Postfix) with ESMTP id CEB988FC2D; Mon, 20 Jul 2009 19:31:34 +0000 (UTC) (envelope-from cdillon@wolves.k12.mo.us) Received: from localhost (localhost [127.0.0.1]) by mail.wolves.k12.mo.us (Postfix) with ESMTP id 58040B893; Mon, 20 Jul 2009 14:11:57 -0500 (CDT) X-Virus-Scanned: amavisd-new at wolves.k12.mo.us Received: from mail.wolves.k12.mo.us ([127.0.0.1]) by localhost (mail.wolves.k12.mo.us [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O9Kx9PV6uNuY; Mon, 20 Jul 2009 14:11:56 -0500 (CDT) Received: from wolves.k12.mo.us (mail.wolves.k12.mo.us [207.160.214.1]) by mail.wolves.k12.mo.us (Postfix) with ESMTP id C213AB892; Mon, 20 Jul 2009 14:11:56 -0500 (CDT) Received: from rstech28.int.wolves.k12.mo.us (rstech28.int.wolves.k12.mo.us [10.1.3.200]) by www.wolves.k12.mo.us (Horde Framework) with HTTP; Mon, 20 Jul 2009 14:11:56 -0500 Message-ID: <20090720141156.357757p2m3l4sxoc@www.wolves.k12.mo.us> Date: Mon, 20 Jul 2009 14:11:56 -0500 From: Chris Dillon To: Ken Smith References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> In-Reply-To: <1248027417.14210.110.camel@neo.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-6.4 Cc: freebsd-current@freebsd.org, freebsd-stable Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 19:31:35 -0000 Quoting Ken Smith : > First I want to apologize. This should have happened a bit sooner in > our release cycle than now. To be honest I had slipped into "We have > symbol versioning for our libraries now" mode. But only a few of the > libraries currently have that turned on and I sorta forgot we still need > to deal with all the shared libraries that do not have symbol versioning > enabled yet. Sorry for the hassle this will cause. ...snip... Wouldn't this be a great opportunity to fix kern/133926 by bumping up the max username length? -- Chris Dillon - NetEng/SysAdm Reeds Spring R-IV School District Technology Department 175 Elementary Rd. Reeds Spring, MO 65737 Voice: 417-272-8266 Fax: 417-272-0015 From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 19:52:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0133D1065670 for ; Mon, 20 Jul 2009 19:52:51 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id 788658FC0C for ; Mon, 20 Jul 2009 19:52:50 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n6KJfEFN015033; Mon, 20 Jul 2009 21:41:14 +0200 From: Pieter de Goeje To: freebsd-current@freebsd.org, d@delphij.net Date: Mon, 20 Jul 2009 21:41:14 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; amd64; ; ) References: <4A5F8010.7050504@delphij.net> <4A61544E.2050208@delphij.net> In-Reply-To: <4A61544E.2050208@delphij.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907202141.14528.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: Ian FREISLICH Subject: Re: CARP broken on -CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 19:52:51 -0000 On Saturday 18 July 2009 06:49:18 Xin LI wrote: > I got it. It was the cached llentry that preventing ether_output() to > choose the right broadcast/multicast address and use the default > gateway's L2 address. Here is a proposed patch. This fixes multicast group joining and sending multicast packets for me :-) -- Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 20:05:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA93B1065670 for ; Mon, 20 Jul 2009 20:05:24 +0000 (UTC) (envelope-from fulanpeng@gmail.com) Received: from mail-vw0-f172.google.com (mail-vw0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 81D248FC1D for ; Mon, 20 Jul 2009 20:05:24 +0000 (UTC) (envelope-from fulanpeng@gmail.com) Received: by vwj2 with SMTP id 2so2329811vwj.3 for ; Mon, 20 Jul 2009 13:05:23 -0700 (PDT) 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:content-transfer-encoding; bh=LP+rmudNtd0E+ExMHp/LX7IkQtWipM2Ag2hG70hD5Ew=; b=bLCSUWuPlxX1Nq/mx1mFWXSEjbWtkKEGDr/IU1fC+nn9QCJO+exSGxEKr8b7ydj6hZ I4YPbJF9LOwVsItmNFAxxyzIqZyvGokfuh9m2Z0oU1UHNVtT368FHJZPVyIDz9hMgsla QXRUisZKyNn99q2fYJLeru8MyIogB4uEosStk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=joFEv865UWL1RMiKRJsm5qfFP/qB55HmKr39Gin/Fvq/jI13F32j+4mK5Hp56AQGpx hHAJYd6zElgyUhUBgE37hqC+iUzOodr3WrxWYzDPi/2Ia8b/Jakpd2wBDZ43bvwzQHPg /Cc8p97G9kbNbMtcQFe7Lg4fYXSJ8LBPkoILw= MIME-Version: 1.0 Received: by 10.220.97.212 with SMTP id m20mr6569927vcn.40.1248118784305; Mon, 20 Jul 2009 12:39:44 -0700 (PDT) Date: Mon, 20 Jul 2009 15:39:44 -0400 Message-ID: From: fulan Peng To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: freebsd-current 8.0BETA2 broken ejabberd-2.0.5 -- an IM application at port net-im X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 20:05:25 -0000 It was ok when OTP is 12B5. Now it is 13B01. Please help. I do not want to downgrade. Thanks. From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 20:13:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6E07106564A for ; Mon, 20 Jul 2009 20:13:34 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8AB6A8FC14 for ; Mon, 20 Jul 2009 20:13:34 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (hyperion.scode.org [85.17.42.115]) by hyperion.scode.org (Postfix) with ESMTPS id 85A9423C4FD for ; Mon, 20 Jul 2009 22:13:33 +0200 (CEST) Date: Mon, 20 Jul 2009 22:13:32 +0200 From: Peter Schuller To: freebsd-current@freebsd.org Message-ID: <20090720201332.GA95896@hyperion.scode.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HcAYCG3uE/tztfnV" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Getting crashdumps to work (trying to submit crash report) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 20:13:35 -0000 --HcAYCG3uE/tztfnV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Short version: Is there a list of reasons why crashdumps might not work? I have dumpdev on a plain (non-gmirror/non-gstripe/etc) device that is equal to RAM size, but I am not getting a dump for unknown reasons. Long version: so a few months ago I started seeing page faults and/or VM page related panics while bulk-building ports. I was updating CURRENT every month or so a the time and using the bulk building as a test case for ZFS stability issues. While I have stopped seeing deadlocks and such, which is presumably due to the fixes taht have gone in, I instead started seeing these crashes. I never got crash dumps and didn't know why, and was hoping to wait it out a bit. With the advent of 8.0 BETA1 I wanted to give it another shot. I finally realized that having the dumpdev on gstripes/gmirrors was not supported, so I reconfigured my system with a dumpdev on a plain device. I also manually ran the dumpdev command. After I finally made the box crash again (of course the *one* time I had hoped to have proper dumpdev configuration it took several days), I still don't have a dump, and I really don't know why. Is there a checklist of things that need to be correct in order for the kernel to do a dump? Are there certain forms of panic where a dump won't be attempted (such as in this case where it was some a VM page insert or similar)? The problem is that I cannot get a stacktrace interactively since the USB keyboard won't work after a panic, so I really want a crashdump. But since it takes at least a day often, possibly several days, to trigger the crash I'm running out of time if I am to produce some kind of report before 8.0... --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --HcAYCG3uE/tztfnV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpkz+sACgkQDNor2+l1i33+bwCeLbD4Ih2cR/vTaUD+6YBzOUoD xJUAoLEKBJXiFrlMmx28FMSEooMMaFCu =YQcc -----END PGP SIGNATURE----- --HcAYCG3uE/tztfnV-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 20:22:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F1AC10657F1 for ; Mon, 20 Jul 2009 20:22:23 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outO.internet-mail-service.net (outo.internet-mail-service.net [216.240.47.238]) by mx1.freebsd.org (Postfix) with ESMTP id EA5D48FC1F for ; Mon, 20 Jul 2009 20:22:22 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id E9EBBACB80; Mon, 20 Jul 2009 13:22:22 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 787932D6010; Mon, 20 Jul 2009 13:22:22 -0700 (PDT) Message-ID: <4A64D1FF.1010207@elischer.org> Date: Mon, 20 Jul 2009 13:22:23 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Peter Schuller References: <20090720201332.GA95896@hyperion.scode.org> In-Reply-To: <20090720201332.GA95896@hyperion.scode.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Getting crashdumps to work (trying to submit crash report) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 20:22:23 -0000 Peter Schuller wrote: > Hello, > > Short version: Is there a list of reasons why crashdumps might not > work? I have dumpdev on a plain (non-gmirror/non-gstripe/etc) device > that is equal to RAM size, but I am not getting a dump for unknown > reasons. hopefuly a bit BIGGER than ram size... not by much but exactly equal wouldn't work.. > From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 20:22:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 488AE10656E8 for ; Mon, 20 Jul 2009 20:22:33 +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 CEB828FC2A for ; Mon, 20 Jul 2009 20:22:32 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 6949 invoked by uid 399); 20 Jul 2009 20:22:28 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Jul 2009 20:22:28 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A64D203.1030908@FreeBSD.org> Date: Mon, 20 Jul 2009 13:22:27 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: Peter Schuller References: <20090720201332.GA95896@hyperion.scode.org> In-Reply-To: <20090720201332.GA95896@hyperion.scode.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Getting crashdumps to work (trying to submit crash report) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 20:22:33 -0000 First question, why do you think that you do not have a dump? Second question, do you have anything in the console log when you boot that indicates a problem with savecore? What happens if you run '/etc/rc.d/savecore start' ? Finally, I'm assuming throughout that your /var/crash directory is on a disk/partition with enough space for a dump? Some more things to look at anyways, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 20:17:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56A37106564A for ; Mon, 20 Jul 2009 20:17:33 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by mx1.freebsd.org (Postfix) with ESMTP id D3CF28FC0A for ; Mon, 20 Jul 2009 20:17:32 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: by fxm11 with SMTP id 11so68038fxm.43 for ; Mon, 20 Jul 2009 13:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=M1mLjsPiRdWp6qdFTnFBRlgf+KQlf3jZSo6iy6ixz8U=; b=rX2+KONsaVUa4ovnLgScBWISxsxkymMucnfp2Ix3o0IZ4z5cH3TlTurwjjQUhwyur7 Mro7AJhlEJgNdof5Vrt5cpxOLbxg5zKBubEwnLNLa8j88elgrsk+aHWNemh3g6lrZtoI MA2OsU/68FzZpccfp/xU83OqraUqivB3GLjhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=JdYhpvjkwB/d/AD1GJhDySccFhh/u5OjrsK/CVN+ie/014rOzWLSo34qJWtFOMpvcj YQfmM86OmEdTJ3rOageB2B+ZqOQ6qKK6fexfH9EaXyScWyxoA99q170wxadTFhXDNwIs aPFH9hdf5i1H0dJ88avvvBCc85G47za/K25Bw= Received: by 10.86.89.6 with SMTP id m6mr3920157fgb.1.1248121051828; Mon, 20 Jul 2009 13:17:31 -0700 (PDT) Received: from dragonmini.dg ([196.34.241.123]) by mx.google.com with ESMTPS id e20sm10899857fga.20.2009.07.20.13.17.29 (version=SSLv3 cipher=RC4-MD5); Mon, 20 Jul 2009 13:17:31 -0700 (PDT) From: David Naylor Organization: Private To: Vizeli Pascal Date: Mon, 20 Jul 2009 22:18:54 +0200 User-Agent: KMail/1.9.10 References: <145022.76269.qm@web28610.mail.ukl.yahoo.com> In-Reply-To: <145022.76269.qm@web28610.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1248122660.zEjISg1G9v"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200907202218.58970.naylor.b.david@gmail.com> X-Mailman-Approved-At: Mon, 20 Jul 2009 20:27:57 +0000 Cc: freebsd-current@freebsd.org Subject: Re: 8.0-Beta2 / Ideapad S10e / bwi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 20:17:33 -0000 --nextPart1248122660.zEjISg1G9v Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 20 July 2009 09:11:02 Vizeli Pascal wrote: > Hi Hello > I've install freebsd 8.0-Beta2 on my netbook ideapad s10e. It work nice b= ut > the wireless driver dosen't work. I've seen that exists new bwi drivers. I > recompile my kernel with (device bwi) but he dosn't see them. Have every > body a idea, why the bwi dosn't work? I use the Windows NDIS drivers without many problems. =20 I do have a problem with the ACPI EC. It often times out resulting in batt= ery=20 and temperature not updating (and often power down doesn't work). Syslog=20 gets spammed with messages from the acpi module. I hacked a crude patch th= at=20 appeared to mostly fix the problems (but I don't believe it addresses the=20 underlying problem). Are you experiencing any problems with ACPI? > The bluetooth driver also dosn't work. But that is a nice to have feature. > I will porting the bluetooth drivers from openbsd or netbsd (at the moment > i've forgotten witch bsd have implement this driver) into the next freebsd > version. Never used bluetooth so can't comment. =20 Regards, David --nextPart1248122660.zEjISg1G9v Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEABECAAYFAkpk0TIACgkQUaaFgP9pFrIxRACfeQCnxJYBetLswczVQgNeQwus SCUAnjTSpnDa7bR8elsMCcod7FIXOGZM =7Fgr -----END PGP SIGNATURE----- --nextPart1248122660.zEjISg1G9v-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 20:43:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADF031065723; Mon, 20 Jul 2009 20:43:25 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6E3368FC0A; Mon, 20 Jul 2009 20:43:25 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (hyperion.scode.org [85.17.42.115]) by hyperion.scode.org (Postfix) with ESMTPS id 766BF23C4FD; Mon, 20 Jul 2009 22:43:24 +0200 (CEST) Date: Mon, 20 Jul 2009 22:43:23 +0200 From: Peter Schuller To: Doug Barton Message-ID: <20090720204323.GA96793@hyperion.scode.org> References: <20090720201332.GA95896@hyperion.scode.org> <4A64D203.1030908@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline In-Reply-To: <4A64D203.1030908@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: Getting crashdumps to work (trying to submit crash report) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 20:43:26 -0000 --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > First question, why do you think that you do not have a dump? Second Nothing in /var/crash after reboot. I checked with 'savecore' manually but of course I realize now that this was pretty useless since by that time swap would have been re-enabled. So really, savecore may have given some kind of message on boot - I'm not entirely sure to what extent I checked the messages on boot after the panic. So I'm not sure what might have been printed during boot this time around. Hmm. Is there a good way to simulate a panic so that I can quicky iterate tweaks until I can be sure I get a dump? > question, do you have anything in the console log when you boot that > indicates a problem with savecore? What happens if you run Possibly but I would probably have missed it this time; previously I had the "no suitable dump device" on setup, presumably because swap was a gmirror. > '/etc/rc.d/savecore start' ? Finally, I'm assuming throughout that > your /var/crash directory is on a disk/partition with enough space for > a dump? Plenty of space (> 100 gig), though it's on ZFS in case that matters (but since this is done by savecore rather than special kernel stuff I was sort of assuming that would not be a problem). --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpk1usACgkQDNor2+l1i339tgCgn/Nk0YdGReYw0WhRW+XxbU1u av4AoJbiFHcyALWdjZEXrpRxcNXqqpPj =ONXe -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 20:45:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74642106564A for ; Mon, 20 Jul 2009 20:45:48 +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 0578A8FC1C for ; Mon, 20 Jul 2009 20:45:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: (qmail 15053 invoked by uid 399); 20 Jul 2009 20:45:46 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Jul 2009 20:45:46 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A64D777.30305@FreeBSD.org> Date: Mon, 20 Jul 2009 13:45:43 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: Peter Schuller References: <20090720201332.GA95896@hyperion.scode.org> <4A64D203.1030908@FreeBSD.org> In-Reply-To: <4A64D203.1030908@FreeBSD.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Getting crashdumps to work (trying to submit crash report) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 20:45:48 -0000 Forgot to add, try toggling the value of debug.minidump. You might also want to try dumping in the debugger to see if the infrastructure you have is able to work at all. Break to the debugger (Ctrl-Alt-Esc at the console, or whatever you need to do for a serial terminal) and then at the prompt type: call doadump(0) If it works, you can then just type 'reboot' and make sure that savecore can do its job. hope this also helps, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 20:46:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9709B1065702 for ; Mon, 20 Jul 2009 20:46:00 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 26BBF8FC1E for ; Mon, 20 Jul 2009 20:46:00 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (hyperion.scode.org [85.17.42.115]) by hyperion.scode.org (Postfix) with ESMTPS id 6630223C4FD; Mon, 20 Jul 2009 22:45:59 +0200 (CEST) Date: Mon, 20 Jul 2009 22:45:58 +0200 From: Peter Schuller To: Julian Elischer Message-ID: <20090720204558.GB96793@hyperion.scode.org> References: <20090720201332.GA95896@hyperion.scode.org> <4A64D1FF.1010207@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5/uDoXvLw7AC5HRs" Content-Disposition: inline In-Reply-To: <4A64D1FF.1010207@elischer.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: Getting crashdumps to work (trying to submit crash report) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 20:46:01 -0000 --5/uDoXvLw7AC5HRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > hopefuly a bit BIGGER than ram size... not by much but exactly equal=20 > wouldn't work.. It's actually very close to RAM size unfortunately (since I didn't know about the not-on-gmirror/gstripe/etc limitation when setting it up I didn't really care about making each individual dump dev larger). But my understanding has been that one expects some bios reservation anyway. In any case: % dumpon -v /dev/ad16s1b || echo fail kernel dumps on /dev/ad16s1b Should not dumpon be complaining if it is considered too small? I definitely did check dumpon output last time when I thought I fixed the problem (I meant dumpon, not dumpdev, in my other post - sorry). --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --5/uDoXvLw7AC5HRs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpk14UACgkQDNor2+l1i31DUwCgqByHXym6l4bnA6ZPM8LtOffP 5s4AnRBjb0EdlFfbmrOCUUrNhs88JkvS =6iFP -----END PGP SIGNATURE----- --5/uDoXvLw7AC5HRs-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 20:48:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 375DE106567A; Mon, 20 Jul 2009 20:48:49 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id E071B8FC14; Mon, 20 Jul 2009 20:48:48 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (hyperion.scode.org [85.17.42.115]) by hyperion.scode.org (Postfix) with ESMTPS id 29B8C23C4FD; Mon, 20 Jul 2009 22:48:48 +0200 (CEST) Date: Mon, 20 Jul 2009 22:48:47 +0200 From: Peter Schuller To: Doug Barton Message-ID: <20090720204846.GC96793@hyperion.scode.org> References: <20090720201332.GA95896@hyperion.scode.org> <4A64D203.1030908@FreeBSD.org> <4A64D777.30305@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xesSdrSSBC0PokLI" Content-Disposition: inline In-Reply-To: <4A64D777.30305@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: Getting crashdumps to work (trying to submit crash report) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 20:48:50 -0000 --xesSdrSSBC0PokLI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > Forgot to add, try toggling the value of debug.minidump. Might there be a fear that having minidumps enabled may cause a failure to dump because it is more dependent on kernel data structures? > You might also want to try dumping in the debugger to see if the > infrastructure you have is able to work at all. Break to the debugger > (Ctrl-Alt-Esc at the console, or whatever you need to do for a serial > terminal) and then at the prompt type: >=20 > call doadump(0) >=20 > If it works, you can then just type 'reboot' and make sure that > savecore can do its job. Thanks a lot! I'll try to get my hands on a PS/2 keyboard and experiment with this. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --xesSdrSSBC0PokLI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpk2C4ACgkQDNor2+l1i30j7QCeKq9I+qp/VXVyZsy8aPqVW0Uk 2bIAoJKZ/XKnNTTiD9+sFk0j0s32/+1F =+XMO -----END PGP SIGNATURE----- --xesSdrSSBC0PokLI-- From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 21:03:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F0B21065673 for ; Mon, 20 Jul 2009 21:03:40 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id E02D58FC24 for ; Mon, 20 Jul 2009 21:03:39 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by yxe11 with SMTP id 11so4101447yxe.3 for ; Mon, 20 Jul 2009 14:03:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=GSOfWV1rSUq8o+cpNQ+f8gFHWeHClK6B0Hnpo4JZydk=; b=Vn7N/HJ/1N9jjOq/HGEN0bWOh1HIt72Ek9m7ZFT1DraX0BJ4bBmHfEBC9WPOGAmdDG qdxSpeDQBHCyjjuzLwDLnA6BshMp7WGwO9PaJEUanWYOzKsqJ4vGQWxUpdzI4k/dVTVo s7lFQ1pxWO+EoHZUc95zcWxFn1bxAVBAm12tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=nyXg5+HbgzHK4QjqNVHUIMp14WG8p7i5aTZqim5qkuDbKj9q7XoAIcdZOSIr+fmzjl dx2+8+MUpvVEAZ6C3RQTjqYD9GC+fYicTxw5kHPR3D4mCfE5Hym7zLBOjlvv083RaB/k IVAc2UQDGpbce1lvmGrPGVSxHquKyrhSN8jBs= Received: by 10.100.38.17 with SMTP id l17mr6851555anl.62.1248123819169; Mon, 20 Jul 2009 14:03:39 -0700 (PDT) Received: from ?192.168.1.100? ([190.177.213.3]) by mx.google.com with ESMTPS id c23sm285106ana.8.2009.07.20.14.03.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Jul 2009 14:03:37 -0700 (PDT) From: Gonzalo Nemmi To: "Paul B. Mahol" Date: Mon, 20 Jul 2009 18:03:31 -0300 User-Agent: KMail/1.9.10 References: <4A5D27F2.50208@voicenet.com> <19e9a5dc0907191530s679c0b37v49a836cc00bbf58a@mail.gmail.com> <3a142e750907191553u1fd266a4q286e7168b74ee889@mail.gmail.com> In-Reply-To: <3a142e750907191553u1fd266a4q286e7168b74ee889@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907201803.32053.gnemmi@gmail.com> Cc: freebsd-current@freebsd.org, Adam K Kirchhoff Subject: Re: bge problems when resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 21:03:40 -0000 On Sunday 19 July 2009 7:53:52 pm Paul B. Mahol wrote: > On 7/20/09, Gonzalo Nemmi wrote: > > On Sat, Jul 18, 2009 at 12:09 AM, Paul B. Mahol wrote: > >> On 7/17/09, Gonzalo Nemmi wrote: > >> > On Wednesday 15 July 2009 8:13:47 am Adam K Kirchhoff wrote: > >> >> On Wednesday 15 July 2009 03:20:45 Paul B. Mahol wrote: > >> >> > On 7/15/09, Adam K Kirchhoff wrote: > >> >> > > Hello all, > >> >> > > > >> >> > > I have a Dell Latitude D610 laptop with 8.0-BETA1 > >> >> > > installed. I hadn't tried suspend/resume for a while and > >> >> > > decided to give it a shot. I was pleasantly surprised to > >> >> > > see that I could suspend to ram, resume, and have a > >> >> > > (relatively) working system (previously the display would > >> >> > > never come back up and the serial console I had hooked up > >> >> > > remained dead). Great job to everyone who helped make that > >> >> > > possible. > >> >> > > > >> >> > > The only real issue that I seem to have now is that bge is > >> >> > > completely unusable after resume. Another individual seems > >> >> > > to have reported similar problems with bge and resume, but > >> >> > > he also had other issues that apparently trumped his > >> >> > > networking issues: > >> >> > > > >> >> > > http://lists.freebsd.org/pipermail/freebsd-current/2009-Jul > >> >> > >y/0090 23.html > >> >> > > > >> >> > > Like him, resuming from suspend gives me: > >> >> > > > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> > > (phy 1, reg 0, val 32768) > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY read timed out > >> >> > > (phy 1, reg 0, val 0xffffffff) > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> > > (phy 1, reg 24, val 3072) > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> > > (phy 1, reg 23, val 10) > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> > > (phy 1, reg 21, val 12555) > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> > > (phy 1, reg 23, val 8223) > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> > > (phy 1, reg 21, val 38150) > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> > > (phy 1, reg 23, val 16415) > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> > > (phy 1, reg 21, val 5346) > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> > > (phy 1, reg 24, val 1024) > >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> > > (phy 1, reg 24, val 7) > >> >> > > > >> >> > > And so on and so forth. > >> >> > > > >> >> > > I thought that compiling if_bge as a module, unloading it > >> >> > > before suspend, and reloading it after resume, might get > >> >> > > this working. However, doing a "kldload if_bge" after the > >> >> > > resume does nothing. Well, the module gets loaded, but the > >> >> > > device doesn't show up. No errors from kldload, and there > >> >> > > is nothing new in dmesg. > >> >> > > > >> >> > > Before the suspend, the device shows up as: > >> >> > > > >> >> > > bge0@pci0:2:0:0: class=0x020000 card=0x01821028 > >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 > >> >> > > vendor = 'Broadcom Corporation' > >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express > >> >> > > (BCM5750A1)' class = network > >> >> > > subclass = ethernet > >> >> > > > >> >> > > After resuming, and reloading the module, it's: > >> >> > > > >> >> > > none1@pci0:2:0:0: class=0x020000 card=0x01821028 > >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 > >> >> > > vendor = 'Broadcom Corporation' > >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express > >> >> > > (BCM5750A1)' class = network > >> >> > > subclass = ethernet > >> >> > > > >> >> > > If there are no ideas, I'll go ahead and open up a pr. I > >> >> > > assume this is just one bug, since both problems (the PHY > >> >> > > issues and the inability to reload the driver) are both > >> >> > > related to the network device. > >> >> > > >> >> > Put this lines into loader.conf and reboot. > >> >> > > >> >> > hw.pci.do_power_nodriver="3" > >> >> > hw.pci.do_power_resume="1" > >> >> > > >> >> > Now, before suspend, unload if_bge and some another driver > >> >> > (sound drivers are best candidate) and load sound driver > >> >> > again, suspend and resume. > >> >> > Now loading if_bge should make it succesfully attach. > >> >> > >> >> Unfortunately, after doing this, reloading the if_bge driver > >> >> causes the laptop to completely lock up... It gets as far as: > >> >> > >> >> bge0: >> >> ASIC rev. 0xffff> > >> >> mem 0xdfdf0000-0xdfdfffff irq 16 at device 0.0 on pci2 > >> >> > >> >> And then the entire machine hangs. I'm on ttyv0, so I'd see > >> >> any kernel panic, but nothing like that happens. The screen > >> >> stays on, but nothing else happens till I force a reboot. > >> >> > >> >> Adam > >> > > >> > Hi Adam, Paul ... > >> > I'm the "another individual" from you OP. > >> > I have the same problems you have regarding bge, but they > >> > weren't trumped .. I just had an order of priorities ;) > >> > > >> > Anyways, I tried the solution Paul posted and, just as in your > >> > case, I got a hard lock too ... > >> > > >> > I tried loading if_bge through /boot/loader.conf > >> > Then issued a: > >> > > >> > kldunload if_bge coretemp > >> > >> coretemp is wrong module, it must be one of modules that attach to > >> pci. > > > > Sorry Paul! > > I gave it a go with snd_hda and I got the same result except that > > this time I also got the following message: > > After unloading snd_hda you loaded it again before suspending? Doing so yielded a Fatal trap 12 on BETA2. Yesterday I install BETA2 and here are the results: kldstat Id Refs Address Size Name 1 28 0xc0400000 cf6c70 kernel 2 1 0xc10f7000 11bc0 if_bge.ko 3 1 0xc1109000 1ac4c snd_hda.ko 4 2 0xc1124000 61f78 sound.ko 5 1 0xc1186000 2af4 coretemp.ko 6 1 0xc1189000 a6d8 i915.ko 7 2 0xc1194000 177d4 drm.ko kldunload if_bge snd_hda Jul 20 17:50:49 gargoyle login: ROOT LOGIN (root) ON ttyv0 Jul 20 17:51:06 gargoyle kernel: brgphy0: detached Jul 20 17:51:06 gargoyle kernel: lock order reversal: Jul 20 17:51:06 gargoyle kernel: 1st 0xc0dba45c kernel linker (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1079 Jul 20 17:51:06 gargoyle kernel: 2nd 0xc0dbbc64 sysctl lock (sysctl lock) @ /usr/src/sys/kern/kern_sysctl.c:257 Jul 20 17:51:06 gargoyle kernel: KDB: stack backtrace: Jul 20 17:51:06 gargoyle kernel: db_trace_self_wrapper(c0c6baf4,e6daba34,c08bc995,c08ad6db,c0c6e989,...) at db_trace_self_wrapper+0x26 Jul 20 17:51:06 gargoyle kernel: kdb_backtrace(c08ad6db,c0c6e989,c452bc88,c4529e10,e6daba90,...) at kdb_backtrace+0x29 Jul 20 17:51:06 gargoyle kernel: _witness_debugger(c0c6e989,c0dbbc64,c0c69667,c4529e10,c0c6956e,...) at _witness_debugger+0x25 Jul 20 17:51:06 gargoyle kernel: witness_checkorder(c0dbbc64,9,c0c6956e,101,0,...) at witness_checkorder+0x839 Jul 20 17:51:06 gargoyle kernel: _sx_xlock(c0dbbc64,0,c0c6956e,101,c4722c00,...) at _sx_xlock+0x85 Jul 20 17:51:06 gargoyle kernel: sysctl_ctx_free(c4722c4c,c4722c00,e6dabb18,c08a3c85,c4722c00,...) at sysctl_ctx_free+0x30 Jul 20 17:51:06 gargoyle kernel: device_sysctl_fini(c4722c00,0,c0d4c848,c472a810,c4ab3400,...) at device_sysctl_fini+0x1a Jul 20 17:51:06 gargoyle kernel: device_detach(c4722c00,c4722b80,e6dabb38,c06bc622,c4722b80,...) at device_detach+0x1f5 Jul 20 17:51:06 gargoyle kernel: bus_generic_detach(c4722b80,c4722b80,e6dabb64,c08a3b1c,c4722b80,...) at bus_generic_detach+0x29 Jul 20 17:51:06 gargoyle kernel: miibus_detach(c4722b80,c45d6060,c0d4ca68,a3c,c0c76f47,...) at miibus_detach+0x12 Jul 20 17:51:06 gargoyle kernel: device_detach(c4722b80,c472b008,e6dabb98,c10ff7ff,c4722300,...) at device_detach+0x8c Jul 20 17:51:06 gargoyle kernel: bus_generic_detach(c4722300,1,c1104b66,aec,c4722300,...) at bus_generic_detach+0x29 Jul 20 17:51:06 gargoyle kernel: bge_detach(c4722300,c4677060,c0d4ca68,a3c,c4526300,...) at bge_detach+0xbf Jul 20 17:51:06 gargoyle kernel: device_detach(c4722300,c086c843,c0dbb570,c1106c20,c456fb80,...) at device_detach+0x8c Jul 20 17:51:06 gargoyle kernel: driver_module_handler(c4526300,1,c1106c20,109,0,...) at driver_module_handler+0x29c Jul 20 17:51:06 gargoyle kernel: module_unload(c4526300,c0c652ef,273,270,c08604b6,...) at module_unload+0x43 Jul 20 17:51:06 gargoyle kernel: linker_file_unload(c4544200,0,c0c652ef,437,c10f7000,...) at linker_file_unload+0x15e Jul 20 17:51:06 gargoyle kernel: kern_kldunload(c4b346c0,2,0,e6dabd2c,c0ba8dd3,...) at kern_kldunload+0xd5 Jul 20 17:51:06 gargoyle kernel: kldunloadf(c4b346c0,e6dabcf8,8,c0c6fa4b,c0d50450,...) at kldunloadf+0x2b Jul 20 17:51:06 gargoyle kernel: syscall(e6dabd38) at syscall+0x2a3 Jul 20 17:51:06 gargoyle kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 20 17:51:06 gargoyle kernel: --- syscall (444, FreeBSD ELF32, kldunloadf), eip = 0x280d516b, esp = 0xbfbfe47c, ebp = 0xbfbfecc8 --- Jul 20 17:51:06 gargoyle kernel: miibus0: detached Jul 20 17:51:06 gargoyle kernel: bge0: detached Jul 20 17:51:06 gargoyle kernel: sysctl_unregister_oid: failed to unregister sysctl Jul 20 17:51:06 gargoyle kernel: pcm0: detached Jul 20 17:51:06 gargoyle kernel: hdac0: detached kld snd_hda Jul 20 17:52:16 gargoyle kernel: hdac0: mem 0xf6dfc000-0xf6dfffff irq 21 at device 27.0 on pci0 Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Driver Revision: 20090624_0136 Jul 20 17:52:16 gargoyle kernel: hdac0: [ITHREAD] Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel STAC9228X Jul 20 17:52:16 gargoyle kernel: bge0: mem 0xf69f0000-0xf69fffff irq 17 at device 0.0 on pci9 Jul 20 17:52:16 gargoyle kernel: miibus0: on bge0 Jul 20 17:52:16 gargoyle kernel: brgphy0: PHY 1 on miibus0 Jul 20 17:52:16 gargoyle kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Jul 20 17:52:16 gargoyle kernel: bge0: Ethernet address: 00:23:ae:04:ba:ca Jul 20 17:52:16 gargoyle kernel: bge0: [ITHREAD] Jul 20 17:52:16 gargoyle kernel: pcm0: at cad 0 nid 1 on hdac0 Jul 20 17:52:16 gargoyle kernel: bge0: link state changed to DOWN Jul 20 17:52:18 gargoyle kernel: bge0: link state changed to UP acpiconf -s 3 Jul 20 17:53:51 gargoyle acpi: suspend at 20090720 17:53:51 Jul 20 17:53:56 gargoyle kernel: fwohci0: fwohci_pci_suspend Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 0, val 32768) Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, val 0xffffffff) Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 24, val 0xffffffff) Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 16, val 0xffffffff) Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 16, val 0) Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg 23, val 18) Jul 20 17:54:25 gargoyle kernel: bge0: flow-through queue init failed Jul 20 17:54:25 gargoyle kernel: bge0: initialization failure Jul 20 17:54:25 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 ports. Jul 20 17:54:25 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. Jul 20 17:54:25 gargoyle kernel: fwohci0: Initiate bus reset Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode Jul 20 17:54:25 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) Jul 20 17:54:25 gargoyle kernel: firewire0: bus manager 0 Jul 20 17:54:25 gargoyle kernel: fwohci0: unrecoverable error Jul 20 17:54:25 gargoyle kernel: wakeup from sleeping state (slept 00:00:29) Jul 20 17:54:25 gargoyle acpi: resumed at 20090720 17:54:25 Should a PR on fwohci and firewire also be filed?? Best Regards Gonzalo Nemmi > > fwohci0: ... > > firewire0: ... > > fwohci0: ... > > pci0: < multimedia HDA > at device 27.0 ( no driver attached ) > > bge0 ... > > > > Then, the same hard lock :( > > > > Will install BETA2 today ! > > > > Best Regards > > Gonzalo > > > >> > acpiconf -s 3 > >> > > >> > machine suspended > >> > > >> > As soon as I woke it up I got the following message followed by > >> > a hard lock: > >> > > >> > fwohci0: Phy 1394a available S400, 1 ports. > >> > fwohci0: Link S400, max_rec 2048 bytes. > >> > fwohci0: Initiate bus reset > >> > fwohci0: fwohci_intr_core: BUS reset > >> > fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, > >> > CYCLEMASTER mode > >> > firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) > >> > firewire0: bus manager 0 > >> > fwohci0: unrecoverable error > >> > bge0: >> > rev, 0xffff> mem 0xf69f0000-0xf69fffff irq 17 at device 0.0 on > >> > pci9 > >> > > >> > All this happens on a Dell 1318, FreeBSD 8.0-BETA1, i386, > >> > Intel(R) Celeron(R) CPU 560@2.13GHz. > >> > > >> > bge0@pci0:9:0:0: class=0x020000 card=0x02861028 > >> > chip=0x171314e4 > >> > >> rev=0x02 > >> > >> > hdr=0x00 > >> > vendor = 'Broadcom Corporation' > >> > device = 'Broadcom NetLink (TM) Fast Ethernet > >> > (BCM5906m)' class = network > >> > subclass = ethernet > >> > bar [10] = type Memory, range 64, base 0xf69f0000, size > >> > 65536, enabled > >> > 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) > >> > > >> > If somebody needs more info, just ask me for it and I'll try to > >> > answer as soon as I can. > >> > > >> > Adam, if you do file a PR, please let me know so I can follow > >> > it. > >> > > >> > Best Regards > >> > -- > >> > Blessings > >> > Gonzalo Nemmi > >> > >> -- > >> Paul -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 21:36:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1137106566C for ; Mon, 20 Jul 2009 21:36:00 +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 855E98FC12 for ; Mon, 20 Jul 2009 21:36:00 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 44BA846B58; Mon, 20 Jul 2009 17:36:00 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 6ACDF8A09C; Mon, 20 Jul 2009 17:35:58 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 20 Jul 2009 10:57:03 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907201057.03777.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 20 Jul 2009 17:35:58 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_06_12,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Edho P Arief Subject: Re: broken pmbr? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 21:36:00 -0000 On Friday 17 July 2009 10:42:07 pm Edho P Arief wrote: > I just managed to, um, break my installation boot using these steps: > > 1. system with at least two disks (say ad0 and ad4) > 2. create gpt partition on ad0 > 3. create at least one freebsd-ufs on ad0 > 4. install freebsd on ad4 using gpt ( http://m8d.de/news/freebsd-on-gpt.php ) > 5. reboot and boot to ad4 > 6. 'Missing boot loader' > > (Rearranging ad0 to adX where X>4 or removing ad0 solves the problem, btw) > > Does pmbr only search first drive with gpt it found? /boot/pmbr only looks on the current disk, yes. You could put the boot partition on ad0 and then put a /boot.config in the UFS partition on ad0 that points to ad4 if you want it to find the boot loader from ad4 instead of ad0. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 22:01:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A60571065673 for ; Mon, 20 Jul 2009 22:01:23 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 5CCC28FC0C for ; Mon, 20 Jul 2009 22:01:23 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so1201637and.13 for ; Mon, 20 Jul 2009 15:01:22 -0700 (PDT) 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:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=pkYI9TiPP1cD5czWbXE6Ja/Ls49gZBIHAQWewOCBVeg=; b=v3Xod76Nqvo02DVw1oTEoNyJq6q7lEDgbf0vbSQzZE0ITi5529ePtz8a8cVr5jacNR SKuV1m5SymWgHihkQXRa2YFaBoZcPoh+ukzlgFcXBZ9qQok9KsLP3GpTNE37isBaJ7Rp FJSP1ktIOpJ9o5xPQs7jmdw/Eqw1rsH7dxlAg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ud7CSf4glHxV+wubf0wZWgLO+TchJb5KMR5G+T+YHNWthgJA5ADvz6+L63pndv7ZxD ZLhPjxkGsViK4RKMMI1qZJcm4D47leJgdp5jAJV/zN5o53SIgRrcsC/MSjKJvkeU5Nuo TFQpJJbkODKcquvZQ1lTZEd6MoDw9HsTU6oTI= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.92.2 with SMTP id p2mr6827479anb.7.1248127282613; Mon, 20 Jul 2009 15:01:22 -0700 (PDT) In-Reply-To: <4A5D4D25.3040908@ish.com.au> References: <4A5D4D25.3040908@ish.com.au> Date: Mon, 20 Jul 2009 15:01:22 -0700 X-Google-Sender-Auth: e0581bfce1345154 Message-ID: <3c1674c90907201501j42f29bfbl987419edf04b1a8b@mail.gmail.com> From: Kip Macy To: Aristedes Maniatis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jurgen Weber Subject: Re: Problematic upgrade from 7.2 to 8.0 with ZFS file system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 22:01:24 -0000 On Tue, Jul 14, 2009 at 8:29 PM, Aristedes Maniatis wrote: > Last night we upgraded one of our servers from 7.2 to 8.0-beta1 using the > freebsd-update tool and following the instructions on Colin's blog. I > believe this problem will occur even if we had used a source update > mechanism. > > The usual upgrade path is to install the new kernel, reboot, then install > world. This fails because when rebooting into the 8.0 kernel with 7.2 > userland, ZFS is unable to properly initialise and the file systems are not > mounted. In our case we are booting with a small UFS partition to load the > kernel, and then mounting /usr /var, etc from ZFS as per these instructions > [1]. > > The problem with ZFS userland being out of sync with the kernel has been > seen before [2] [3]. However now with lots of people running ZFS and > starting to upgrade to 8.0, I think this will bite many more. > > The workaround is to drop into single user mode, mount all the zfs > partitions, and do the userland install. > > mount -t zfs /usr > mount -t zfs /var > mount -o rw tank/root / > > Those mount commands are slightly non-obvious and took a little guessing to > get right. You can't use the 'zfs mount' command since it is broken at this > point in time. > > The other solution is to install userland BEFORE you reboot into the new > kernel, although that may cause its own set of problems. Whatever the final > solution, this needs to be clearly documented and ideally freebsd-update > needs to detect the problem and advise the user about what to do. Do to the large version jump (v6 -> v13) the kernel interfaces aren't backward compatible with the tools. How do you think it could be most gracefully handled? -Kip From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 22:09:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C838D106566C; Mon, 20 Jul 2009 22:09:38 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B54F88FC14; Mon, 20 Jul 2009 22:09:38 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id E09411A3C3A; Mon, 20 Jul 2009 14:51:41 -0700 (PDT) Date: Mon, 20 Jul 2009 14:51:41 -0700 From: Alfred Perlstein To: Hans Petter Selasky Message-ID: <20090720215141.GL49724@elvis.mu.org> References: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> <200907111710.18843.hselasky@c2i.net> <1280352d0907111217r5c218cdctf158dbfc588da304@mail.gmail.com> <200907152236.58049.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907152236.58049.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i Cc: usb@freebsd.org, freebsd-current@freebsd.org, Andrew Thompson Subject: Re: USB polling (75% done) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 22:09:39 -0000 * Hans Petter Selasky [090715 13:37] wrote: > Hi, > > I've added minimal polling support to the USB P4 repository now. Patch can be > found here: > > http://perforce.freebsd.org/chv.cgi?CH=166148 > > Dumping core to USB disk: Tested and works. > > Using USB keyboard in KDB: Does not work because Giant is not locked when > calling into the UKBD's get char routine. UKBD is Giant locked. Someone > familiar with the keyboard system on FreeBSD please step forward and fix this > so that UKBD gets independent of the Giant mutex. the ukbd driver needs giant? What happens? -- - Alfred Perlstein VMOA #5191, 03 vmax, 92 gs500, ch250 - FreeBSD From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 22:13:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A06DE106564A for ; Mon, 20 Jul 2009 22:13:39 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id 242388FC21 for ; Mon, 20 Jul 2009 22:13:38 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id n6KJcRFN013230; Mon, 20 Jul 2009 21:38:27 +0200 From: Pieter de Goeje To: Bruce Simpson Date: Mon, 20 Jul 2009 21:38:27 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; amd64; ; ) References: <200907182056.47383.pieter@degoeje.nl> <4A628056.60009@incunabulum.net> In-Reply-To: <4A628056.60009@incunabulum.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907202138.27671.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Sending multicast datagrams broken (regression) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 22:13:39 -0000 On Sunday 19 July 2009 04:09:26 Bruce Simpson wrote: > Pieter de Goeje wrote: > > I'm observing that multicast IPv4 UDP datagrams sent from the latest > > 8.0-BETA2 are being discarded. The code below used to work with 7.2. > > Can you tcpdump this? > > This may be related to an llentry related regression which Xin Li > recently posted a patch for, it appears that layer 2 addresses for > multicast/broadcast datagrams may be broken in 8.0-BETA2. Ok, I've just tested that patch and everything is working again. Hurray! Thanks, Pieter de Goeje From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 22:44:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F2FE1065670 for ; Mon, 20 Jul 2009 22:44:48 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 271068FC16 for ; Mon, 20 Jul 2009 22:44:47 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from [10.29.62.4] (port=62665 helo=Aris-MacBook-Pro.local) by fish.ish.com.au with esmtpa (Exim 4.69) (envelope-from ) id 1MT2fq-0006nI-2S; Tue, 21 Jul 2009 09:53:38 +1000 Message-ID: <4A64F35E.6070501@ish.com.au> Date: Tue, 21 Jul 2009 08:44:46 +1000 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090714 Shredder/3.0b3pre MIME-Version: 1.0 To: Kip Macy References: <4A5D4D25.3040908@ish.com.au> <3c1674c90907201501j42f29bfbl987419edf04b1a8b@mail.gmail.com> In-Reply-To: <3c1674c90907201501j42f29bfbl987419edf04b1a8b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jurgen Weber Subject: Re: Problematic upgrade from 7.2 to 8.0 with ZFS file system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 22:44:48 -0000 On 21/07/09 8:01 AM, Kip Macy wrote: >> The other solution is to install userland BEFORE you reboot into the new >> > kernel, although that may cause its own set of problems. Whatever the final >> > solution, this needs to be clearly documented and ideally freebsd-update >> > needs to detect the problem and advise the user about what to do. > > > Do to the large version jump (v6 -> v13) the kernel interfaces aren't > backward compatible with the tools. How do you think it could be most > gracefully handled? I honestly don't know how the right way to solve the problem, but here are some ideas: * the kernel ABI *should* be compatible with userland tools at least one major version backward. I understand that this might now be impossible, but it is possible to bring back enough of the old ABI to allow for zfs to mount? * freebsd-update could automatically detect this situation and install the new zfs userland at the same time as the new kernel * lots of of clear documentation about what course of action a user should follow if they are performing a source update. Should the recommendation be changed to install userland *before* rebooting, and then immediately reboot before some of that userland explodes against the old kernel in memory? The existing recommendation is based on the fact that the new kernel will continue to work after reboot with the old userland. If that assumption is not always true then the whole FreeBSD installation process needs rethinking. Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 22:56:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0FD631065672 for ; Mon, 20 Jul 2009 22:56:45 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id BCF618FC17 for ; Mon, 20 Jul 2009 22:56:44 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yxe11 with SMTP id 11so4217789yxe.3 for ; Mon, 20 Jul 2009 15:56:44 -0700 (PDT) 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:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=EcEMYlruMKRbmRW8BGhrMOyaBUyBq92k5zC8Cc47wfc=; b=jK3/VjRzmqLMxqnU0fM4IZOiIGGeBQrG88CWnd7JBmmvTRAsTjU5FKsgl9Ln36jDQr GT9BPhloRwDvnQnptos21GvQejkFigdd4J27LR328QWJiY1HhR16HwMlbu7oeZQh8ajn HQDv5nV4GQCvbrd4HCJcsImU1oaMfk3NA5l6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=r1qyGMf6jREBaENkb2mLf3AVdv8vhDw004QnPNl2ZZmjaUdzylMh9FzgYLFLgaiDzT Aha4WgCT2SVeNf6qVdQakiO+rzuYWxG4iv8gOO3lTs2wvxl6B1WTjcaA/51wvDEBJpWI pAgsNrGM0/fHTTcFZbajDGessq/gDyYlY3K3c= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.41.6 with SMTP id o6mr6870267ano.92.1248130604211; Mon, 20 Jul 2009 15:56:44 -0700 (PDT) In-Reply-To: <4A64F35E.6070501@ish.com.au> References: <4A5D4D25.3040908@ish.com.au> <3c1674c90907201501j42f29bfbl987419edf04b1a8b@mail.gmail.com> <4A64F35E.6070501@ish.com.au> Date: Mon, 20 Jul 2009 15:56:44 -0700 X-Google-Sender-Auth: be8a122e649f1e6b Message-ID: <3c1674c90907201556n7dbd385fucb2d49aa2b1a1416@mail.gmail.com> From: Kip Macy To: Aristedes Maniatis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jurgen Weber Subject: Re: Problematic upgrade from 7.2 to 8.0 with ZFS file system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 22:56:45 -0000 > > I honestly don't know how the right way to solve the problem, but here are > some ideas: > > * the kernel ABI *should* be compatible with userland tools at least one > major version backward. I understand that this might now be impossible, but > it is possible to bring back enough of the old ABI to allow for zfs to > mount? No. There are many issues that have much higher priority. > > * freebsd-update could automatically detect this situation and install the > new zfs userland at the same time as the new kernel Need to talk to the update maintainer. > * lots of of clear documentation about what course of action a user should > follow if they are performing a source update. Should the recommendation be > changed to install userland *before* rebooting, and then immediately reboot > before some of that userland explodes against the old kernel in memory? UPDATING explicitly states that the two need to be in sync or the user tools will not work. > The existing recommendation is based on the fact that the new kernel will > continue to work after reboot with the old userland. > If that assumption is > not always true then the whole FreeBSD installation process needs > rethinking. I don't think so. It is well understood that ZFS is an external code base, and like any third party application, users need to to inform themselves when updating. Just because it works fairly well, I don't think we should mislead ourselves in to believing that all the rough edges can be removed in the near future. -Kip From owner-freebsd-current@FreeBSD.ORG Mon Jul 20 23:21:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1E2A1065672 for ; Mon, 20 Jul 2009 23:21:58 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from fish.ish.com.au (eth5921.nsw.adsl.internode.on.net [59.167.240.32]) by mx1.freebsd.org (Postfix) with ESMTP id 561118FC0A for ; Mon, 20 Jul 2009 23:21:58 +0000 (UTC) (envelope-from ari@ish.com.au) Received: from [10.29.62.4] (port=62850 helo=Aris-MacBook-Pro.local) by fish.ish.com.au with esmtpa (Exim 4.69) (envelope-from ) id 1MT3Fp-000770-00; Tue, 21 Jul 2009 10:30:49 +1000 Message-ID: <4A64FC12.9050709@ish.com.au> Date: Tue, 21 Jul 2009 09:21:54 +1000 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1pre) Gecko/20090714 Shredder/3.0b3pre MIME-Version: 1.0 To: Kip Macy References: <4A5D4D25.3040908@ish.com.au> <3c1674c90907201501j42f29bfbl987419edf04b1a8b@mail.gmail.com> <4A64F35E.6070501@ish.com.au> <3c1674c90907201556n7dbd385fucb2d49aa2b1a1416@mail.gmail.com> In-Reply-To: <3c1674c90907201556n7dbd385fucb2d49aa2b1a1416@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jurgen Weber Subject: Re: Problematic upgrade from 7.2 to 8.0 with ZFS file system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 23:21:59 -0000 On 21/07/09 8:56 AM, Kip Macy wrote: >> * lots of of clear documentation about what course of action a user should >> > follow if they are performing a source update. Should the recommendation be >> > changed to install userland*before* rebooting, and then immediately reboot >> > before some of that userland explodes against the old kernel in memory? > UPDATING explicitly states that the two need to be in sync or the user > tools will not work. Since I'm following the binary update process at the moment, I don't have UPDATING anywhere on my system. With the increasing popularity of Colin's freebsd-update, perhaps that file needs to be moved to / or somewhere else prominent and not in /usr/src Also, if the notes say "tools will not work" that should be upgraded to something stronger, like "you will not be able to reboot if you have installed any part of your operating system on ZFS". To me, 'tools' sounds like 'you will not be able to run "zpool status"'. >> > The existing recommendation is based on the fact that the new kernel will >> > continue to work after reboot with the old userland. >> > If that assumption is >> > not always true then the whole FreeBSD installation process needs >> > rethinking. > I don't think so. It is well understood that ZFS is an external code > base, and like any third party application, users need to to inform > themselves when updating. Just because it works fairly well, I don't > think we should mislead ourselves in to believing that all the rough > edges can be removed in the near future. It isn't a third party application like something out of the ports system and FreeBSD users have grown to love how everything in the base distribution works together so well. This is the first time in my 15 years of FreeBSD usage that an upgrade through major releases has had any problem for me, and I don't think it can be written off as "this isn't really part of FreeBSD, so it doesn't count." Users don't see the difference between parts of the FreeBSD system depending on their heritage. That said, you and the other developers have done a fabulous job to get us all ZFS in our favourite operating system. Thank you. Given that you've said keeping backward ABI compatibility is too hard to achieve, then I think the only answer is lots of clear documentation. I am an avid FreeBSD user, read the lists and keep myself informed, but I didn't see any warning in the places where it would have helped me. Are you saying that it is generally more dangerous to install world before rebooting? Would it be safer to: 1. reboot to single user (so there aren't many userland applications running) 2. install both world and kernel 3. reboot My only suggestions are improving the freebsd-update tool (is Colin Percival reading this?) to give relevant feedback, moving UPDATING to somewhere useful for non-source updaters and ensuring the docs clearly state the seriousness of this particular issue. For myself, I know what to do now, so my suggestions are purely to help others avoid similar difficulties. Cheers Ari Maniatis --------------------------> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 00:22:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E308106564A for ; Tue, 21 Jul 2009 00:22:28 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id C5BB88FC15 for ; Tue, 21 Jul 2009 00:22:27 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by yxe11 with SMTP id 11so4298010yxe.3 for ; Mon, 20 Jul 2009 17:22:27 -0700 (PDT) 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:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=VAow3LT8O+VAwhXnTZj60txM4EIA2axJG3qr4GNmdaY=; b=qfGn8rIRue8iDp96W9PXondCi4aDMG5DpOvXBEDCZAzYQqsR58AavOOT7m62wjonOn 0oDf9ljKOtxF9wSIWwyc4/fv/M1VQ81XzenLj01xxmtTOY4rx5NM/FgIwXBw6MvgUtro bp6H48Bmc4Rn7Wbo6znEjFNa8+rdMzpl+CxrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ISBOPK/bv8YsEoSgxWEFjokh3uoWDEsmSp+e1H9gRZW4qd8BcVb4kwP82TFJECn9uf F0440ZH1tYYIRoDltypt8PVBbA56aAsg5n070e2g4N+FAra+tdqhNB7F1jl0pDVR1eO3 cDuU8d6ThOEh1RMNDVZAFKJBhILRtTIeriLXE= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.101.66.17 with SMTP id t17mr7036974ank.41.1248135747067; Mon, 20 Jul 2009 17:22:27 -0700 (PDT) In-Reply-To: <4A64FC12.9050709@ish.com.au> References: <4A5D4D25.3040908@ish.com.au> <3c1674c90907201501j42f29bfbl987419edf04b1a8b@mail.gmail.com> <4A64F35E.6070501@ish.com.au> <3c1674c90907201556n7dbd385fucb2d49aa2b1a1416@mail.gmail.com> <4A64FC12.9050709@ish.com.au> Date: Mon, 20 Jul 2009 17:22:27 -0700 X-Google-Sender-Auth: eaff75b636fad18b Message-ID: <3c1674c90907201722vcff2ea4pb779da6e3524d175@mail.gmail.com> From: Kip Macy To: Aristedes Maniatis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jurgen Weber Subject: Re: Problematic upgrade from 7.2 to 8.0 with ZFS file system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 00:22:29 -0000 > My only suggestions are improving the freebsd-update tool (is Colin Percival > reading this?) to give relevant feedback, moving UPDATING to somewhere > useful for non-source updaters and ensuring the docs clearly state the > seriousness of this particular issue. When the import was done, there should have been a minimal compat layer so that v6 tools wouldn't die when talking to a v13 system. It is too late for 8.0 to do that, depending on time and complexity I'll look in to doing that for 7.3. At this juncture there isn't a convenient stop-gap. Given that there is no central source to read for individuals updating. I think it makes sense for freebsd-update to at the very least check if it is installing on a system running ZFS v6. You'll need to talk to Colin Percival about his availability to do that. Cheers, Kip From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 00:26:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36427106564A for ; Tue, 21 Jul 2009 00:26:45 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id AD3F98FC0C for ; Tue, 21 Jul 2009 00:26:44 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so655507fgb.12 for ; Mon, 20 Jul 2009 17:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:date:from:to :subject:message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=4PPrK7SUx68I8wRRiDMYTvphZXUI4v8GCfEY/j+0Z/k=; b=mWGQOVbymh8yT+jk1lqgEqzQkemeNU2Cq1bWUc9nuUQVCkJ7iFSnjtYHCEP9IelyIp 7NcX9zCshKGau1ScF78UJgMl3wnARYnGC/OUjePQ8VhIATH8KTAPpgPXwuPLfhy5Wnl5 6oiX+lWifTHCW6+nzwuG/vtR6HYEZKopw5zMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; b=t6xYcGge+F4imDb4+DZyIU6Ukvso4iGCEaRCzUu+xguhfbSTs/DSInt5OTrSq6jh9j zLlPR1S+JBy7D8fHG6O12TBobNuqPq5EbJ3mu8B2RgytHJiwr4FsQkzY1ohPqJ8T3tqy x6D8xdEOjNjdHd/JoLo8gNpSrA5P2ME1eKLaU= Received: by 10.86.25.17 with SMTP id 17mr4018068fgy.73.1248136003794; Mon, 20 Jul 2009 17:26:43 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.108.65]) by mx.google.com with ESMTPS id 3sm6016370fge.23.2009.07.20.17.26.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Jul 2009 17:26:42 -0700 (PDT) Sender: Nenhum_de_Nos Received: from arroway (arroway.apartnet [10.1.1.80]) by cygnus.homeunix.com (Postfix) with SMTP id C15D0B8065 for ; Mon, 20 Jul 2009 21:26:31 -0300 (BRT) Date: Mon, 20 Jul 2009 21:26:43 -0300 From: Nenhum_de_Nos To: freebsd-current@freebsd.org Message-Id: <20090720212643.39a248d1.matheus@eternamente.info> In-Reply-To: References: <20090717010813.03477b27.matheus@eternamente.info> <0a394f735684111014877d2b39783693.squirrel@cygnus.homeunix.com> <2fd30e75fbd3e231117ab9f2459f896b.squirrel@10.1.1.10> <066c4b53956bc62c3d6e089861ebddf7.squirrel@10.1.1.10> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: gstripe problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 00:26:45 -0000 On Sun, 19 Jul 2009 15:19:14 +0200 Ivan Voras wrote: > Nenhum_de_Nos wrote: > > > I'd really like to hear on this: I just wiped out all disks data, deleted > > all two partitions and recreated them. created another stripe using the > > same arguments as the other times but it keeps vanishing when I reboot. > > fresh 8-BETA2 and old pc in i386. what to do now ? give up ? > > Did you load geom_stripe.ko? yep I used all the time "create" and not "label" to make the array. the mirror worked fine though in this way (created in 7.2-STABLE). then when I saw that, I turned to label which the man page says to do write metadata and all went ok. so all fine in here, running 8-beta2 and an old PII just fine (moving data to the array, an old PII is really slow :( ). by the way, it was an old 7.1-stable (time where 7.1 was prerelease) and now is 8-beta2. the apache+postfix+mailman+samba+dns will be fine ? (read about changes yesterday that would make all rebuild all ports, but my rev is older and I have little time to this now. will plan to do it as soon as all is fine and 8.0R is out). thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 01:23:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC5F4106566B for ; Tue, 21 Jul 2009 01:23:22 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 4D4478FC1C for ; Tue, 21 Jul 2009 01:23:21 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from fuzz.geek.sh (unknown [196.209.243.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 3BC5E3BDC7 for ; Tue, 21 Jul 2009 03:23:20 +0200 (SAST) Message-ID: <4A65187E.8060505@phat.za.net> Date: Tue, 21 Jul 2009 03:23:10 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.22 (X11/20090628) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: devel/ccache broken in BETA2? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 01:23:22 -0000 Hi, Is anyone able to compile just about anything with ccache on BETA2? I'm experiencing a lot of breakage here. Buildkernel: -------------------------------------------------------------- >>> stage 2.3: build tools -------------------------------------------------------------- cd /usr/obj/usr/src/sys/FUZZ; MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF -f /usr/src/sys/dev/aic7xxx/aicasm/Makefile Warning: Object directory not changed from original /usr/obj/usr/src/sys/FUZZ /usr/local/libexec/ccache/world-cc -O2 -pipe -nostdinc -I/usr/include -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /usr/src/sys/dev/aic7xxx/aicasm/aicasm.c *** Error code 1 Stop in /usr/obj/usr/src/sys/FUZZ. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Random port: ===> Configuring for mtr-nox11-0.75 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether gmake sets $(MAKE)... yes checking for gcc... /usr/local/libexec/ccache/world-cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. ===> Script "configure" failed unexpectedly. Please report the problem to sunpoet@sunpoet.net [maintainer] and attach the "/usr/ports/net/mtr/work/mtr-0.75/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/net/mtr. Any ideas? It /was/ working in BETA1. :) Thanks, Aragon From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 02:16:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0B26106566B for ; Tue, 21 Jul 2009 02:16:44 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by mx1.freebsd.org (Postfix) with SMTP id 9A18A8FC1E for ; Tue, 21 Jul 2009 02:16:44 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: (qmail 76532 invoked from network); 21 Jul 2009 01:50:04 -0000 Received: from unknown (HELO ?10.10.10.3?) (webmaster@69.108.138.13 with plain) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 21 Jul 2009 01:50:03 -0000 X-YMail-OSG: qE4UrZ8VM1meNVTS5TojfInYLv27YBzbz.996Uqitb_um2cT4B9B6tvAniSOP1l1gDC51LlCrWQk5Vloofdw_Q4eXm5.8K8bYDIEbEEQXRpcHBMfNqW9Z3SYfDaZKUyFrTvBdpP0OxQbFclKHW0LajIbVRawcfR2P2bvUgbbxy_wuriqKjMXS7CucVzWVTyNdqVttx3xMy6j_hZZzlexCN8A7M9iMP93n73rCUNn8lvu6ADymQqh6T5LO74rfgEZoeMmPn.8oUbcGOvnWbtKMP09Dx8VbttO_2d7fuIv52ecBVqyO78- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A651E50.6000508@doghouserepair.com> Date: Mon, 20 Jul 2009 18:48:00 -0700 From: Ryan Rogers User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 02:16:45 -0000 I'm running 8.0-BETA2/amd64 on a system that has on-board ethernet. It is detected by FreeBSD as the following: nfe0: port 0xac00-0xac07 mem 0xcfffa000-0xcfffafff,0xcfff9000-0xcfff90ff,0xcfff8000-0xcfff800f irq 22 at device 17.0 on pci0 miibus1: on nfe0 e1000phy0: PHY 1 on miibus1 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto The problem is, I can't get packets to move across the interface. I know that the interface works in Windows as well as Ubuntu, but it looks like it's failing to get fully configured in FreeBSD. The output of ifconfig nfe0 is: nfe0: flags=8843 metric 0 mtu 1500 options=19b ether 00:04:4b:01:8c:0b inet 10.10.10.3 netmask 0xffffff00 broadcast 10.10.10.255 media: Ethernet autoselect (none) status: active The part that I find odd is "media: Ethernet autoselect (none)". If I manually force it to "media 1000baseT mediaopt full-duplex", that line becomes "media: 1000baseT full-duplex (10baseT/UTP half-duplex)". Still, the interface is dead. I found PR kern/127910 which describes the same problem, except for 7.0-RELEASE. There's been no activity on that for 9 months though (aside from my update today). Can anyone offer me any insight on this? Thanks, Ryan From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 02:57:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E025106564A for ; Tue, 21 Jul 2009 02:57:39 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f204.google.com (mail-qy0-f204.google.com [209.85.221.204]) by mx1.freebsd.org (Postfix) with ESMTP id 483428FC12 for ; Tue, 21 Jul 2009 02:57:38 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by qyk42 with SMTP id 42so2204464qyk.3 for ; Mon, 20 Jul 2009 19:57:38 -0700 (PDT) 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 :content-transfer-encoding; bh=/y8FKf8TJ4QaeYkGUmNRf3uErbyLx9bHNOLheLOClCo=; b=eybf4URhNqcRip6KZNOe2d51oe2cOmRfTM9y6G4oFVCteEu8L8SQVPqRU9qTlDn8ay pXn93UVZNgeOo5eHQlfkcfnZkPmq5uX5e+jMS5RuPipYhuU2/3Q2HjNQFML8ZsF/UsqB zVrpecrcjV6fClgjamg+2Xfjr4YEgkX+c0KNM= 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:content-transfer-encoding; b=l6r6GKZTBcrWbkQMj9j0+PpJai019LRF0nTEV/z3yFENV6KJa9dBzlaOCd54k1QvgY JgRdbOpJEXCmGYy8KQApDymwur5lfia6fDjsfNvVo8nwPE7LTQrRFkWutm4aCeCck8gU Mlmzrb3x1xPxusH6+wNhwmAZCgP20Ds/ECiJQ= MIME-Version: 1.0 Received: by 10.229.80.78 with SMTP id s14mr885487qck.101.1248145058442; Mon, 20 Jul 2009 19:57:38 -0700 (PDT) In-Reply-To: <4A651E50.6000508@doghouserepair.com> References: <4A651E50.6000508@doghouserepair.com> Date: Mon, 20 Jul 2009 21:57:38 -0500 Message-ID: <11167f520907201957h380601a7m18109be634da45c7@mail.gmail.com> From: "Sam Fourman Jr." To: Ryan Rogers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 02:57:39 -0000 On Mon, Jul 20, 2009 at 8:48 PM, Ryan Rogers wrote: > I'm running 8.0-BETA2/amd64 on a system that has on-board ethernet. =A0It= is > detected by FreeBSD as the following: > > nfe0: port 0xac00-0xac07 mem > 0xcfffa000-0xcfffafff,0xcfff9000-0xcfff90ff,0xcfff8000-0xcfff800f irq 22 = at > device 17.0 on pci0 > miibus1: on nfe0 > e1000phy0: PHY 1 on miibus1 > e1000phy0: =A010baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > > The problem is, I can't get packets to move across the interface. =A0I kn= ow > that the interface works in Windows as well as Ubuntu, but it looks like > it's failing to get fully configured in FreeBSD. =A0The output of ifconfi= g > nfe0 is: > > nfe0: flags=3D8843 metric 0 mtu 1= 500 > =A0 =A0 =A0 =A0options=3D19b > =A0 =A0 =A0 =A0ether 00:04:4b:01:8c:0b > =A0 =A0 =A0 =A0inet 10.10.10.3 netmask 0xffffff00 broadcast 10.10.10.255 > =A0 =A0 =A0 =A0media: Ethernet autoselect (none) > =A0 =A0 =A0 =A0status: active > > The part that I find odd is "media: Ethernet autoselect (none)". =A0If I > manually force it to "media 1000baseT mediaopt full-duplex", that line > becomes "media: 1000baseT full-duplex (10baseT/UTP half-duplex)". Still, = the > interface is dead. > > I found PR kern/127910 which describes the same problem, except for > 7.0-RELEASE. =A0There's been no activity on that for 9 months though (asi= de > from my update today). =A0Can anyone offer me any insight on this? > > Thanks, > Ryan I can confirm this is a nfe problem, I first reported it to the mailing list a few weeks back under the subject FreeBSD 8 BETA1 DHCP trouble. http://groups.google.co.jp/group/muc.lists.freebsd.current/browse_thread/th= read/ba7b35e561d3e868 I have several different motherboards with nfe nics, My findings are as fol= lows. on a FreeBSD -CURRENT snapshot dated 6-1-2009 dhcp works as expected. somewhere after ~ 6-6-2009 something broke. dhclient nfe0 DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 12 DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 18 DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 No DHCPOFFERS received. No working leases in persistent database - sleeping. the odd thing is that on motherboards that have dual nfe nics nfe1 always works,and nfe0 is always broke. on motherboards that have only a single nfe interface nfe0 is indeed broke. on a dual nic motherboard, if you go into BIOS and disable one of the LAN devices. DHCP will fail if the interface name is nfe0 even though it worked 5 min before when that same nic and MAC address had the nfe1 name. This entire thing is odd :) Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 03:17:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 835371065670 for ; Tue, 21 Jul 2009 03:17:55 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-fx0-f219.google.com (mail-fx0-f219.google.com [209.85.220.219]) by mx1.freebsd.org (Postfix) with ESMTP id 09EB58FC0A for ; Tue, 21 Jul 2009 03:17:54 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: by fxm19 with SMTP id 19so7709fxm.43 for ; Mon, 20 Jul 2009 20:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=0iu61TCof7QxX+s88yoLh3m+yiXfvhxzRW+PfnzSf0s=; b=AgAezawf8fpwS6/vyz16Is8YGaSrFEPRFT/3oDBkBApNwiSbONfprhxj+pP3WmdmTw xpagKezQe4CoNvL95wVwRfCg2YPEqnfPLeApMtDoMLIRieCvghJWYp8DZ+QWxdgSWXfw p5vN9oxnRxSOKMpF/6HZncmwZAb51nzlSbRJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=XwVdwwj/MnQ2X0TZ8GRFe8O68aF6m4MlNRuH/QCW9gznH76sMvzes169ahXjSqKkRv TYVzby5VlpECn7VaZJdOWVVJ6VzOGi71nkLgPoeIGjX6phKFq+J8aN1WykvvIXmrQ+o3 GPEPQT7DL+OnaMsYRLNVG4FUQGDiLZ6SZlLHY= Received: by 10.86.68.18 with SMTP id q18mr3861624fga.68.1248146274056; Mon, 20 Jul 2009 20:17:54 -0700 (PDT) Received: from localhost (95-24-64-233.broadband.corbina.ru [95.24.64.233]) by mx.google.com with ESMTPS id d4sm6544546fga.7.2009.07.20.20.17.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Jul 2009 20:17:53 -0700 (PDT) From: Anonymous To: Aragon Gouveia References: <4A65187E.8060505@phat.za.net> Date: Tue, 21 Jul 2009 07:17:36 +0400 In-Reply-To: <4A65187E.8060505@phat.za.net> (Aragon Gouveia's message of "Tue, 21 Jul 2009 03:23:10 +0200") Message-ID: <86r5wa912n.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: devel/ccache broken in BETA2? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 03:17:55 -0000 Aragon Gouveia writes: > Hi, > > Is anyone able to compile just about anything with ccache on BETA2? > I'm experiencing a lot of breakage here. > > ===> Configuring for mtr-nox11-0.75 > checking for suffix of executables... > checking for suffix of object files... configure: error: cannot > compute suffix of object files: cannot compile > See `config.log' for more details. > > Any ideas? It /was/ working in BETA1. :) > I guess this is because `ccache cc -c ...' returns with 1 not 0 and doesn't produce object file. $ echo 'int main(void) {}' >test.c $ ccache cc -c test.c; echo $? 1 $ cc -c test.c 0 > > Thanks, > Aragon From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 05:51:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E958106564A for ; Tue, 21 Jul 2009 05:51:09 +0000 (UTC) (envelope-from edhoprima@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id 6C07A8FC1E for ; Tue, 21 Jul 2009 05:51:09 +0000 (UTC) (envelope-from edhoprima@gmail.com) Received: by wf-out-1314.google.com with SMTP id 24so809154wfg.7 for ; Mon, 20 Jul 2009 22:51:08 -0700 (PDT) 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 :content-transfer-encoding; bh=ccUuSNg/cVvo6gtixHQg86buV13+GtB0odEMqFx/ajw=; b=FtoJT9RNcTScPGMv7BUCyvaAFkyza4WnlQab//tTqaZEd717vz/Xgrydkly9B5m5et miDpNyqccNPWZ7FIPmkdFXQovviBnupBsNDoMqp25ayTxkmrC/drcD2kEwpdRofLWMCf D0u6iQnNaq4n00Ir0cSXyJP0YF6JlDC08xnec= 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:content-transfer-encoding; b=mPqNAw/m9G5q8yltXegbNyPz/1LwLIFnuJYJ28gTyq0+VHxTYxr1MCVfZq5BXyN+QE AMrswXwxHiWuSdibWhYgPVmE9JUwh40Kbzlm1Dt0IOKlZmvMvlEfk4ac4XGkIQcHbd9b dpCQSr6ghE+BKlJq/3ciCvlxsI2gtC//EOFmg= MIME-Version: 1.0 Received: by 10.142.166.2 with SMTP id o2mr1139404wfe.282.1248155468581; Mon, 20 Jul 2009 22:51:08 -0700 (PDT) In-Reply-To: <200907201057.03777.jhb@freebsd.org> References: <200907201057.03777.jhb@freebsd.org> Date: Tue, 21 Jul 2009 12:51:08 +0700 Message-ID: From: Edho P Arief To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: broken pmbr? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 05:51:09 -0000 On Mon, Jul 20, 2009 at 9:57 PM, John Baldwin wrote: > On Friday 17 July 2009 10:42:07 pm Edho P Arief wrote: >> I just managed to, um, break my installation boot using these steps: >> >> 1. system with at least two disks (say ad0 and ad4) >> 2. create gpt partition on ad0 >> 3. create at least one freebsd-ufs on ad0 >> 4. install freebsd on ad4 using gpt ( > http://m8d.de/news/freebsd-on-gpt.php ) >> 5. reboot and boot to ad4 >> 6. 'Missing boot loader' >> >> (Rearranging ad0 to adX where X>4 or removing ad0 solves the problem, bt= w) >> >> Does pmbr only search first drive with gpt it found? > > /boot/pmbr only looks on the current disk, yes. =C2=A0You could put the b= oot > partition on ad0 and then put a /boot.config in the UFS partition on ad0 = that > points to ad4 if you want it to find the boot loader from ad4 instead of = ad0. I looked to me pmbr only find *first* disk-containing-gpt, not the disk where it's booted from. Which means I'll be in trouble if I added a gpt-partitioned-disk positioned before system disk. --=20 O< ascii ribbon campaign - stop html mail - www.asciiribbon.org From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 08:31:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F664106566C for ; Tue, 21 Jul 2009 08:31:56 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: from mail-bw0-f224.google.com (mail-bw0-f224.google.com [209.85.218.224]) by mx1.freebsd.org (Postfix) with ESMTP id 36E628FC23 for ; Tue, 21 Jul 2009 08:31:54 +0000 (UTC) (envelope-from kraduk@googlemail.com) Received: by bwz24 with SMTP id 24so183216bwz.43 for ; Tue, 21 Jul 2009 01:31:54 -0700 (PDT) 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; bh=IwTBfrNyesr2QlUY5wb0y6+hjnVrqBDryVSYFpzCSBI=; b=AHYYm/QSfo6KxgqoF+vM4G2z3n0i0xXV7iDg/2cSDCwBC+UG3VpzCJ7X+kpew2WXfc bI7n3Ygpqvbqi5a1Pp9hLfBFDRdQ6f/Fq1sIRaLJ7nOHczPqxvrF2sAqzOnv+raKUfYC tYiCdXU19orOOn7P3ZzP18LdtDTvIXJPxrDUo= 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; b=hZ1YerAzdN9vRjN3x1j2M6orZBnOzTuRCZo1DqlYAe/w/LV/6gddgLTO41xBgKm0we p3RrNEKHFJnrikqamy/kg5Mx6DT71Id/qsrXM7Rs4k4FJwUfaWB5oyevxQQrV94SZ2oH jxFc6UCOFEXWzAYjDJySHarKDwSz6kh658nRo= MIME-Version: 1.0 Received: by 10.103.182.1 with SMTP id j1mr2719964mup.119.1248165114098; Tue, 21 Jul 2009 01:31:54 -0700 (PDT) In-Reply-To: <4A64F35E.6070501@ish.com.au> References: <4A5D4D25.3040908@ish.com.au> <3c1674c90907201501j42f29bfbl987419edf04b1a8b@mail.gmail.com> <4A64F35E.6070501@ish.com.au> Date: Tue, 21 Jul 2009 09:31:54 +0100 Message-ID: From: chris scott To: Aristedes Maniatis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Jurgen Weber , Kip Macy Subject: Re: Problematic upgrade from 7.2 to 8.0 with ZFS file system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 08:32:20 -0000 2009/7/20 Aristedes Maniatis > On 21/07/09 8:01 AM, Kip Macy wrote: > >> The other solution is to install userland BEFORE you reboot into the new >>> > kernel, although that may cause its own set of problems. Whatever the >>> final >>> > solution, this needs to be clearly documented and ideally >>> freebsd-update >>> > needs to detect the problem and advise the user about what to do. >>> >> >> >> Do to the large version jump (v6 -> v13) the kernel interfaces aren't >> backward compatible with the tools. How do you think it could be most >> gracefully handled? >> > > I honestly don't know how the right way to solve the problem, but here are > some ideas: > > * the kernel ABI *should* be compatible with userland tools at least one > major version backward. I understand that this might now be impossible, but > it is possible to bring back enough of the old ABI to allow for zfs to > mount? > > * freebsd-update could automatically detect this situation and install the > new zfs userland at the same time as the new kernel > > * lots of of clear documentation about what course of action a user should > follow if they are performing a source update. Should the recommendation be > changed to install userland *before* rebooting, and then immediately reboot > before some of that userland explodes against the old kernel in memory? > > The existing recommendation is based on the fact that the new kernel will > continue to work after reboot with the old userland. If that assumption is > not always true then the whole FreeBSD installation process needs > rethinking. > > > > Ari Maniatis > > > > --------------------------> > ish > http://www.ish.com.au > Level 1, 30 Wilson Street Newtown 2042 Australia > phone +61 2 9550 5001 fax +61 2 9550 4001 > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > how about doing things the opensolaris way. I have a pure zfs system with the root fs stored on system/root. This could cloned, to system/root-8, the new world and kernel installed, then the relevant bits tweaked in the loader.conf and zpool. If all goes wrong you switch the variables back and switch to system/root. It would also be nice to have some option in beastie to select your root fs for completeness From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 08:46:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 832AE1065673 for ; Tue, 21 Jul 2009 08:46:13 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f224.google.com (mail-bw0-f224.google.com [209.85.218.224]) by mx1.freebsd.org (Postfix) with ESMTP id C66648FC16 for ; Tue, 21 Jul 2009 08:46:12 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz24 with SMTP id 24so189312bwz.43 for ; Tue, 21 Jul 2009 01:46:11 -0700 (PDT) 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 :content-transfer-encoding; bh=n4bOdzSye5+Qk4FtJ9e6/+0a8dhgHHNdpq8flr9Zqjs=; b=eMrX5QXM1xgMhkT1UahCfHTEDJtCnqvc5Ex8crTXtRnEFFlx9L9HCON5GkKeJolI7k 5RUdaLxxB88w4ZiEs7i7BFHR8TGIU/FWjjz3jK8CLlehWnaRk4Gp5bnK5PjwfmXYfrPE Yal7JSGLqRlbE3WaWoj1Zug+94NZ3dVkPrtr4= 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:content-transfer-encoding; b=Kfvf6lr2N69u4rPfcPm+vIxDZtsJTeigQ5UNfg4BCfaZeaoX6Gj+lUnAuPZRqBUWun 18l2v0T+EcMNUq4AhGLW1xIkI3Jwe+ZUZqu6Vd4dby4YwSOOXLVSYEFcr6NJbtWn5G4R Jeevw4F+KBwKJFO9OfyQueABJ2pcDTTVnEsDY= MIME-Version: 1.0 Received: by 10.204.51.210 with SMTP id e18mr5302441bkg.69.1248165971553; Tue, 21 Jul 2009 01:46:11 -0700 (PDT) In-Reply-To: <200907201803.32053.gnemmi@gmail.com> References: <4A5D27F2.50208@voicenet.com> <19e9a5dc0907191530s679c0b37v49a836cc00bbf58a@mail.gmail.com> <3a142e750907191553u1fd266a4q286e7168b74ee889@mail.gmail.com> <200907201803.32053.gnemmi@gmail.com> Date: Tue, 21 Jul 2009 10:46:10 +0200 Message-ID: <3a142e750907210146u2ce72cadhbdaa71a89be54607@mail.gmail.com> From: "Paul B. Mahol" To: Gonzalo Nemmi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Adam K Kirchhoff Subject: Re: bge problems when resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 08:46:13 -0000 On 7/20/09, Gonzalo Nemmi wrote: > On Sunday 19 July 2009 7:53:52 pm Paul B. Mahol wrote: >> On 7/20/09, Gonzalo Nemmi wrote: >> > On Sat, Jul 18, 2009 at 12:09 AM, Paul B. Mahol > wrote: >> >> On 7/17/09, Gonzalo Nemmi wrote: >> >> > On Wednesday 15 July 2009 8:13:47 am Adam K Kirchhoff wrote: >> >> >> On Wednesday 15 July 2009 03:20:45 Paul B. Mahol wrote: >> >> >> > On 7/15/09, Adam K Kirchhoff wrote: >> >> >> > > Hello all, >> >> >> > > >> >> >> > > I have a Dell Latitude D610 laptop with 8.0-BETA1 >> >> >> > > installed. I hadn't tried suspend/resume for a while and >> >> >> > > decided to give it a shot. I was pleasantly surprised to >> >> >> > > see that I could suspend to ram, resume, and have a >> >> >> > > (relatively) working system (previously the display would >> >> >> > > never come back up and the serial console I had hooked up >> >> >> > > remained dead). Great job to everyone who helped make that >> >> >> > > possible. >> >> >> > > >> >> >> > > The only real issue that I seem to have now is that bge is >> >> >> > > completely unusable after resume. Another individual seems >> >> >> > > to have reported similar problems with bge and resume, but >> >> >> > > he also had other issues that apparently trumped his >> >> >> > > networking issues: >> >> >> > > >> >> >> > > http://lists.freebsd.org/pipermail/freebsd-current/2009-Jul >> >> >> > >y/0090 23.html >> >> >> > > >> >> >> > > Like him, resuming from suspend gives me: >> >> >> > > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> > > (phy 1, reg 0, val 32768) >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY read timed out >> >> >> > > (phy 1, reg 0, val 0xffffffff) >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> > > (phy 1, reg 24, val 3072) >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> > > (phy 1, reg 23, val 10) >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> > > (phy 1, reg 21, val 12555) >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> > > (phy 1, reg 23, val 8223) >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> > > (phy 1, reg 21, val 38150) >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> > > (phy 1, reg 23, val 16415) >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> > > (phy 1, reg 21, val 5346) >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> > > (phy 1, reg 24, val 1024) >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> > > (phy 1, reg 24, val 7) >> >> >> > > >> >> >> > > And so on and so forth. >> >> >> > > >> >> >> > > I thought that compiling if_bge as a module, unloading it >> >> >> > > before suspend, and reloading it after resume, might get >> >> >> > > this working. However, doing a "kldload if_bge" after the >> >> >> > > resume does nothing. Well, the module gets loaded, but the >> >> >> > > device doesn't show up. No errors from kldload, and there >> >> >> > > is nothing new in dmesg. >> >> >> > > >> >> >> > > Before the suspend, the device shows up as: >> >> >> > > >> >> >> > > bge0@pci0:2:0:0: class=0x020000 card=0x01821028 >> >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 >> >> >> > > vendor = 'Broadcom Corporation' >> >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express >> >> >> > > (BCM5750A1)' class = network >> >> >> > > subclass = ethernet >> >> >> > > >> >> >> > > After resuming, and reloading the module, it's: >> >> >> > > >> >> >> > > none1@pci0:2:0:0: class=0x020000 card=0x01821028 >> >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 >> >> >> > > vendor = 'Broadcom Corporation' >> >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express >> >> >> > > (BCM5750A1)' class = network >> >> >> > > subclass = ethernet >> >> >> > > >> >> >> > > If there are no ideas, I'll go ahead and open up a pr. I >> >> >> > > assume this is just one bug, since both problems (the PHY >> >> >> > > issues and the inability to reload the driver) are both >> >> >> > > related to the network device. >> >> >> > >> >> >> > Put this lines into loader.conf and reboot. >> >> >> > >> >> >> > hw.pci.do_power_nodriver="3" >> >> >> > hw.pci.do_power_resume="1" >> >> >> > >> >> >> > Now, before suspend, unload if_bge and some another driver >> >> >> > (sound drivers are best candidate) and load sound driver >> >> >> > again, suspend and resume. >> >> >> > Now loading if_bge should make it succesfully attach. >> >> >> >> >> >> Unfortunately, after doing this, reloading the if_bge driver >> >> >> causes the laptop to completely lock up... It gets as far as: >> >> >> >> >> >> bge0: > >> >> ASIC rev. 0xffff> >> >> >> mem 0xdfdf0000-0xdfdfffff irq 16 at device 0.0 on pci2 >> >> >> >> >> >> And then the entire machine hangs. I'm on ttyv0, so I'd see >> >> >> any kernel panic, but nothing like that happens. The screen >> >> >> stays on, but nothing else happens till I force a reboot. >> >> >> >> >> >> Adam >> >> > >> >> > Hi Adam, Paul ... >> >> > I'm the "another individual" from you OP. >> >> > I have the same problems you have regarding bge, but they >> >> > weren't trumped .. I just had an order of priorities ;) >> >> > >> >> > Anyways, I tried the solution Paul posted and, just as in your >> >> > case, I got a hard lock too ... >> >> > >> >> > I tried loading if_bge through /boot/loader.conf >> >> > Then issued a: >> >> > >> >> > kldunload if_bge coretemp >> >> >> >> coretemp is wrong module, it must be one of modules that attach to >> >> pci. >> > >> > Sorry Paul! >> > I gave it a go with snd_hda and I got the same result except that >> > this time I also got the following message: >> >> After unloading snd_hda you loaded it again before suspending? > > Doing so yielded a Fatal trap 12 on BETA2. Yesterday I install BETA2 and > here are the results: > > > kldstat > > Id Refs Address Size Name > 1 28 0xc0400000 cf6c70 kernel > 2 1 0xc10f7000 11bc0 if_bge.ko > 3 1 0xc1109000 1ac4c snd_hda.ko > 4 2 0xc1124000 61f78 sound.ko > 5 1 0xc1186000 2af4 coretemp.ko > 6 1 0xc1189000 a6d8 i915.ko > 7 2 0xc1194000 177d4 drm.ko > > > kldunload if_bge snd_hda > > Jul 20 17:50:49 gargoyle login: ROOT LOGIN (root) ON ttyv0 > Jul 20 17:51:06 gargoyle kernel: brgphy0: detached > Jul 20 17:51:06 gargoyle kernel: lock order reversal: > Jul 20 17:51:06 gargoyle kernel: 1st 0xc0dba45c kernel linker (kernel > linker) @ /usr/src/sys/kern/kern_linker.c:1079 > Jul 20 17:51:06 gargoyle kernel: 2nd 0xc0dbbc64 sysctl lock (sysctl > lock) @ /usr/src/sys/kern/kern_sysctl.c:257 > Jul 20 17:51:06 gargoyle kernel: KDB: stack backtrace: > Jul 20 17:51:06 gargoyle kernel: > db_trace_self_wrapper(c0c6baf4,e6daba34,c08bc995,c08ad6db,c0c6e989,...) > at db_trace_self_wrapper+0x26 > Jul 20 17:51:06 gargoyle kernel: > kdb_backtrace(c08ad6db,c0c6e989,c452bc88,c4529e10,e6daba90,...) at > kdb_backtrace+0x29 > Jul 20 17:51:06 gargoyle kernel: > _witness_debugger(c0c6e989,c0dbbc64,c0c69667,c4529e10,c0c6956e,...) at > _witness_debugger+0x25 > Jul 20 17:51:06 gargoyle kernel: > witness_checkorder(c0dbbc64,9,c0c6956e,101,0,...) at > witness_checkorder+0x839 > Jul 20 17:51:06 gargoyle kernel: > _sx_xlock(c0dbbc64,0,c0c6956e,101,c4722c00,...) at _sx_xlock+0x85 > Jul 20 17:51:06 gargoyle kernel: > sysctl_ctx_free(c4722c4c,c4722c00,e6dabb18,c08a3c85,c4722c00,...) at > sysctl_ctx_free+0x30 > Jul 20 17:51:06 gargoyle kernel: > device_sysctl_fini(c4722c00,0,c0d4c848,c472a810,c4ab3400,...) at > device_sysctl_fini+0x1a > Jul 20 17:51:06 gargoyle kernel: > device_detach(c4722c00,c4722b80,e6dabb38,c06bc622,c4722b80,...) at > device_detach+0x1f5 > Jul 20 17:51:06 gargoyle kernel: > bus_generic_detach(c4722b80,c4722b80,e6dabb64,c08a3b1c,c4722b80,...) at > bus_generic_detach+0x29 > Jul 20 17:51:06 gargoyle kernel: > miibus_detach(c4722b80,c45d6060,c0d4ca68,a3c,c0c76f47,...) at > miibus_detach+0x12 > Jul 20 17:51:06 gargoyle kernel: > device_detach(c4722b80,c472b008,e6dabb98,c10ff7ff,c4722300,...) at > device_detach+0x8c > Jul 20 17:51:06 gargoyle kernel: > bus_generic_detach(c4722300,1,c1104b66,aec,c4722300,...) at > bus_generic_detach+0x29 > Jul 20 17:51:06 gargoyle kernel: > bge_detach(c4722300,c4677060,c0d4ca68,a3c,c4526300,...) at > bge_detach+0xbf > Jul 20 17:51:06 gargoyle kernel: > device_detach(c4722300,c086c843,c0dbb570,c1106c20,c456fb80,...) at > device_detach+0x8c > Jul 20 17:51:06 gargoyle kernel: > driver_module_handler(c4526300,1,c1106c20,109,0,...) at > driver_module_handler+0x29c > Jul 20 17:51:06 gargoyle kernel: > module_unload(c4526300,c0c652ef,273,270,c08604b6,...) at > module_unload+0x43 > Jul 20 17:51:06 gargoyle kernel: > linker_file_unload(c4544200,0,c0c652ef,437,c10f7000,...) at > linker_file_unload+0x15e > Jul 20 17:51:06 gargoyle kernel: > kern_kldunload(c4b346c0,2,0,e6dabd2c,c0ba8dd3,...) at > kern_kldunload+0xd5 > Jul 20 17:51:06 gargoyle kernel: > kldunloadf(c4b346c0,e6dabcf8,8,c0c6fa4b,c0d50450,...) at > kldunloadf+0x2b > Jul 20 17:51:06 gargoyle kernel: syscall(e6dabd38) at syscall+0x2a3 > Jul 20 17:51:06 gargoyle kernel: Xint0x80_syscall() at > Xint0x80_syscall+0x20 > Jul 20 17:51:06 gargoyle kernel: --- syscall (444, FreeBSD ELF32, > kldunloadf), eip = 0x280d516b, esp = 0xbfbfe47c, ebp = 0xbfbfecc8 --- > Jul 20 17:51:06 gargoyle kernel: miibus0: detached > Jul 20 17:51:06 gargoyle kernel: bge0: detached > Jul 20 17:51:06 gargoyle kernel: sysctl_unregister_oid: failed to > unregister sysctl if_bge driver looks very problematic to me. Probably it can not detach at all. > Jul 20 17:51:06 gargoyle kernel: pcm0: detached > Jul 20 17:51:06 gargoyle kernel: hdac0: detached > > > kld snd_hda ^^^ You mean kldload. > > Jul 20 17:52:16 gargoyle kernel: hdac0: Audio Controller> mem 0xf6dfc000-0xf6dfffff irq 21 at device 27.0 on > pci0 > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Driver Revision: > 20090624_0136 > Jul 20 17:52:16 gargoyle kernel: hdac0: [ITHREAD] > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel STAC9228X > Jul 20 17:52:16 gargoyle kernel: bge0: 0xc002> mem 0xf69f0000-0xf69fffff irq 17 at device 0.0 on pci9 > Jul 20 17:52:16 gargoyle kernel: miibus0: on bge0 > Jul 20 17:52:16 gargoyle kernel: brgphy0: PHY > 1 on miibus0 > Jul 20 17:52:16 gargoyle kernel: brgphy0: 10baseT, 10baseT-FDX, > 100baseTX, 100baseTX-FDX, auto > Jul 20 17:52:16 gargoyle kernel: bge0: Ethernet address: > 00:23:ae:04:ba:ca > Jul 20 17:52:16 gargoyle kernel: bge0: [ITHREAD] > Jul 20 17:52:16 gargoyle kernel: pcm0: Analog> at cad 0 nid 1 on hdac0 > Jul 20 17:52:16 gargoyle kernel: bge0: link state changed to DOWN > Jul 20 17:52:18 gargoyle kernel: bge0: link state changed to UP Why bge0 appeared again? > > acpiconf -s 3 After this command bge0 should not appear at all because it should not be attached to device. > > Jul 20 17:53:51 gargoyle acpi: suspend at 20090720 17:53:51 > Jul 20 17:53:56 gargoyle kernel: fwohci0: fwohci_pci_suspend > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 0, val 32768) > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0, > val 0xffffffff) > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > 24, val 0xffffffff) > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > 16, val 0xffffffff) > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 16, val 0) > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > 16, val 0xffffffff) > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 16, val 0) > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > 23, val 18) > Jul 20 17:54:25 gargoyle kernel: bge0: flow-through queue init failed > Jul 20 17:54:25 gargoyle kernel: bge0: initialization failure > Jul 20 17:54:25 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 > ports. > Jul 20 17:54:25 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes. > Jul 20 17:54:25 gargoyle kernel: fwohci0: Initiate bus reset > Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset > Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > Jul 20 17:54:25 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 cable > IRM irm(0) (me) > Jul 20 17:54:25 gargoyle kernel: firewire0: bus manager 0 > Jul 20 17:54:25 gargoyle kernel: fwohci0: unrecoverable error > Jul 20 17:54:25 gargoyle kernel: wakeup from sleeping state (slept > 00:00:29) > Jul 20 17:54:25 gargoyle acpi: resumed at 20090720 17:54:25 > > Should a PR on fwohci and firewire also be filed?? Try with custom kernel with smaller number of drivers as possible. (use modules instead) >From your mail I dont see where is problem with firewire. > Best Regards > Gonzalo Nemmi > >> > fwohci0: ... >> > firewire0: ... >> > fwohci0: ... >> > pci0: < multimedia HDA > at device 27.0 ( no driver attached ) >> > bge0 ... >> > >> > Then, the same hard lock :( >> > >> > Will install BETA2 today ! >> > >> > Best Regards >> > Gonzalo >> > >> >> > acpiconf -s 3 >> >> > >> >> > machine suspended >> >> > >> >> > As soon as I woke it up I got the following message followed by >> >> > a hard lock: >> >> > >> >> > fwohci0: Phy 1394a available S400, 1 ports. >> >> > fwohci0: Link S400, max_rec 2048 bytes. >> >> > fwohci0: Initiate bus reset >> >> > fwohci0: fwohci_intr_core: BUS reset >> >> > fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, >> >> > CYCLEMASTER mode >> >> > firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) >> >> > firewire0: bus manager 0 >> >> > fwohci0: unrecoverable error >> >> > bge0: > >> > rev, 0xffff> mem 0xf69f0000-0xf69fffff irq 17 at device 0.0 on >> >> > pci9 >> >> > >> >> > All this happens on a Dell 1318, FreeBSD 8.0-BETA1, i386, >> >> > Intel(R) Celeron(R) CPU 560@2.13GHz. >> >> > >> >> > bge0@pci0:9:0:0: class=0x020000 card=0x02861028 >> >> > chip=0x171314e4 >> >> >> >> rev=0x02 >> >> >> >> > hdr=0x00 >> >> > vendor = 'Broadcom Corporation' >> >> > device = 'Broadcom NetLink (TM) Fast Ethernet >> >> > (BCM5906m)' class = network >> >> > subclass = ethernet >> >> > bar [10] = type Memory, range 64, base 0xf69f0000, size >> >> > 65536, enabled >> >> > 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) >> >> > >> >> > If somebody needs more info, just ask me for it and I'll try to >> >> > answer as soon as I can. >> >> > >> >> > Adam, if you do file a PR, please let me know so I can follow >> >> > it. >> >> > >> >> > Best Regards >> >> > -- >> >> > Blessings >> >> > Gonzalo Nemmi >> >> -- Paul From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 10:59:44 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42C9F106566B; Tue, 21 Jul 2009 10:59:44 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id F15DF8FC13; Tue, 21 Jul 2009 10:59:43 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 8F62678F53; Tue, 21 Jul 2009 14:59:41 +0400 (MSD) Message-ID: <4A659F98.2060007@haruhiism.net> Date: Tue, 21 Jul 2009 14:59:36 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart Subject: [follow-up] Fatal trap 12 in r195146+ in netisr_queue_internal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 10:59:44 -0000 Hello, hope you're having a good day, I've been researching the issue I mentioned in my last message in "r194546 amd64: kernel panic in tcp_sack.c" thread since July 07 and here are some of the findings: The fatal trap triggers inside mtx_lock_sleep() during a dereference of a pointer (owner, points to struct thread @ m->mtx_lock & ~MTX_FLAGMASK). The code goes like this (shortened): v = m->mtx_lock; if (v == MTX_UNOWNED) { turnstile_cancel(ts); continue; } owner = (struct thread *)(v & ~MTX_FLAGMASK); if (TD_IS_RUNNING(owner)) { turnstile_cancel(ts); continue; } Everything goes fine until - under heavy load on an interface, usually - we reach a point where: 1. m->mtx_lock is 4 (== MTX_UNOWNED). 2. v is assigned mtx_lock's value (4 == MTX_UNOWNED). 3. condition (v == MTX_UNOWNED) fails. 4. owner is assigned an address from v. 5. dereference fails as v has a bogus value which is not inside kernel address space. The only affected variable is v; I've added temporary variables around it (i.e. uint64ptr_t foo1, v, foo2;) and those variables are not altered - even though v has moved 64bits further inside the stack. The variable is not only altered at that point; by adding debugging lines along the code I've seen multiple cases of v and mtx_lock being changed during the execution of mtx_lock_sleep(). Moreover, my own test variables were changing inside it. I had the following structure for tests: 1. At the start of the function, foo1 = 0. 2. Before lock_profile_obtain_lock_failed, foo1 = 1. 3. After lock_profile_obtain_lock_failed, foo1 = 2. 4. Before (v == MTX_UNOWNED) conditional, foo1 = 3. During tests, foo1 changed values inside this range (0..3) several times; during heavy lo0/em0 local traffic load, these conditionals failed multiple (up to 100) times in 2-5 seconds. v gets changed like that as well, but in 99.99% cases it gets assigned a value that references kernel memory area so the dereference works. Is this behaviour (variables changing their value inside a single function call) correct? -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 11:03:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 578491065672 for ; Tue, 21 Jul 2009 11:03:48 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE2E8FC12 for ; Tue, 21 Jul 2009 11:03:47 +0000 (UTC) (envelope-from avg@freebsd.org) 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 OAA17883; Tue, 21 Jul 2009 14:03:44 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A65A090.9010105@freebsd.org> Date: Tue, 21 Jul 2009 14:03:44 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Hans Petter Selasky References: <4A63A72F.9020809@boland.org> <4A645489.8050804@andric.com> <200907201332.15530.hselasky@c2i.net> In-Reply-To: <200907201332.15530.hselasky@c2i.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michiel Boland , Dimitry Andric , freebsd-current@freebsd.org Subject: Re: problems with make delete-old(-libs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 11:03:48 -0000 on 20/07/2009 14:32 Hans Petter Selasky said the following: > On Monday 20 July 2009 13:27:05 Dimitry Andric wrote: >> On 2009-07-20 01:07, Michiel Boland wrote: >>> Hi. On recent -CURRENT make delete-old wants to delete the following >>> files >>> >>> /usr/include/dev/usb/usbdi.h >>> /usr/include/dev/usb/usbdi_util.h >>> /usr/include/libusb.h >>> >>> As far as I can see these files are still built/installed >> Yes indeed, they are installed during every installworld, but are still >> in ObsoleteFiles.inc; this looks like an oversight during the USB stack >> switch. > > This is a known issue. And?.. :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 11:09:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B99001065672; Tue, 21 Jul 2009 11:09:31 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 725F58FC17; Tue, 21 Jul 2009 11:09:31 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:50681 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MTDDF-0000RA-3F; Tue, 21 Jul 2009 13:08:50 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id E86A3163D6A; Tue, 21 Jul 2009 13:08:41 +0200 (CEST) Message-Id: <4DC9F3D1-7C33-476E-A304-B318C6784AFE@exscape.org> From: Thomas Backman To: Andriy Gapon In-Reply-To: <4A65A090.9010105@freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 21 Jul 2009 13:08:39 +0200 References: <4A63A72F.9020809@boland.org> <4A645489.8050804@andric.com> <200907201332.15530.hselasky@c2i.net> <4A65A090.9010105@freebsd.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MTDDF-0000RA-3F. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MTDDF-0000RA-3F 3c55dcafdfde8cc4a8066fd36b68f683 Cc: Michiel Boland , Dimitry Andric , freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: problems with make delete-old(-libs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 11:09:32 -0000 On Jul 21, 2009, at 13:03, Andriy Gapon wrote: > on 20/07/2009 14:32 Hans Petter Selasky said the following: >> On Monday 20 July 2009 13:27:05 Dimitry Andric wrote: >>> On 2009-07-20 01:07, Michiel Boland wrote: >>>> Hi. On recent -CURRENT make delete-old wants to delete the >>>> following >>>> files >>>> >>>> /usr/include/dev/usb/usbdi.h >>>> /usr/include/dev/usb/usbdi_util.h >>>> /usr/include/libusb.h >>>> >>>> As far as I can see these files are still built/installed >>> Yes indeed, they are installed during every installworld, but are >>> still >>> in ObsoleteFiles.inc; this looks like an oversight during the USB >>> stack >>> switch. >> >> This is a known issue. > > And?.. :-) A fix was commited recently. :) From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 11:11:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07BD6106568D for ; Tue, 21 Jul 2009 11:11:22 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2F4C08FC13 for ; Tue, 21 Jul 2009 11:11:20 +0000 (UTC) (envelope-from avg@freebsd.org) 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 OAA18056; Tue, 21 Jul 2009 14:11:17 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A65A255.8020509@freebsd.org> Date: Tue, 21 Jul 2009 14:11:17 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Thomas Backman References: <4A63A72F.9020809@boland.org> <4A645489.8050804@andric.com> <200907201332.15530.hselasky@c2i.net> <4A65A090.9010105@freebsd.org> <4DC9F3D1-7C33-476E-A304-B318C6784AFE@exscape.org> In-Reply-To: <4DC9F3D1-7C33-476E-A304-B318C6784AFE@exscape.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: problems with make delete-old(-libs) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 11:11:22 -0000 on 21/07/2009 14:08 Thomas Backman said the following: > On Jul 21, 2009, at 13:03, Andriy Gapon wrote: > >> on 20/07/2009 14:32 Hans Petter Selasky said the following: >>> This is a known issue. >> >> And?.. :-) > A fix was commited recently. :) This is much clearer :) Thanks! -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 11:50:12 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2560106564A for ; Tue, 21 Jul 2009 11:50:12 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id DEBC78FC1B for ; Tue, 21 Jul 2009 11:50:11 +0000 (UTC) (envelope-from ohartman@zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtp (envelope-from ) id <1MTDZD-0003UK-5Q>; Tue, 21 Jul 2009 13:31:31 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) for freebsd-current@FreeBSD.org with esmtpsa (envelope-from ) id <1MTDZD-0000Di-1Z>; Tue, 21 Jul 2009 13:31:31 +0200 Message-ID: <4A65A710.5050508@zedat.fu-berlin.de> Date: Tue, 21 Jul 2009 11:31:28 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.22 (X11/20090720) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org Content-Type: multipart/mixed; boundary="------------080706080008040609070704" X-Originating-IP: 130.133.86.198 Cc: Subject: FreeBSD 8.0-BETA2/amd64 and DELL Poweredge 1930: USB oddities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 11:50:13 -0000 This is a multi-part message in MIME format. --------------080706080008040609070704 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Running FreeBSD 8.0-BETA2/amd64 now a while on a server we use for scientific purposes. I realize problems since a couple of weeks now rendering the box instable. Attaching the USB keyboard to any of the front USB ports seems to induce some issues - only one port is capable of delivering keyboard functionality, the alternative one does not offer a keyboard after reboot. Interestingly, a similar issue is recognized on another FreeBSD 8.0-BETA2/amd64 box. The system is crashing immediately after bootup when moving the USB mouse when the mouse is NOT attached to as specific set of two USB ports (USB is only used for mouse, nothing else, keyboard is PS/2)! Referrring to the problems recognized on the DELL box, I can only provide a most recent dmesg-output after a crash and reattaching the keyboard to another USB port. Any suggestions out there? Thanks in advance, Oliver --------------080706080008040609070704 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" 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 8.0-BETA2 #33 r195797: Tue Jul 21 08:39:16 CEST 2009 root@thusnelda.geoinf.fu-berlin.de:/usr/obj/usr/src/sys/THUSNELDA Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff809dd000. Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0xffffffff809dd1c0. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2496538027 Hz CPU: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz (2496.54-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0xce3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 17179869184 (16384 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x0000000000a18000 - 0x00000000bfb4ffff, 3205726208 bytes (782648 pages) 0x00000000bfb64000 - 0x00000000bfb65fff, 8192 bytes (2 pages) 0x0000000100000000 - 0x00000004200affff, 13422493696 bytes (3276976 pages) avail memory = 16547356672 (15780 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 5 as a target INTR: Adding local APIC 6 as a target INTR: Adding local APIC 7 as a target FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 5 APIC: CPU 2 has ACPI ID 3 APIC: CPU 3 has ACPI ID 7 APIC: CPU 4 has ACPI ID 2 APIC: CPU 5 has ACPI ID 6 APIC: CPU 6 has ACPI ID 4 APIC: CPU 7 has ACPI ID 8 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ULE: setup cpu 4 ULE: setup cpu 5 ULE: setup cpu 6 ULE: setup cpu 7 ACPI: RSDP 0xf21b0 00024 (v2 DELL ) ACPI: XSDT 0xf224c 00084 (v1 DELL PE_SC3 00000001 DELL 00000001) ACPI: FACP 0xbfb83524 000F4 (v3 DELL PE_SC3 00000001 DELL 00000001) ACPI: DSDT 0xbfb66000 04974 (v1 DELL PE_SC3 00000001 INTL 20050624) ACPI: FACS 0xbfb85c00 00040 ACPI: APIC 0xbfb83078 00092 (v1 DELL PE_SC3 00000001 DELL 00000001) ACPI: SPCR 0xbfb83130 00050 (v1 DELL PE_SC3 00000001 DELL 00000001) ACPI: HPET 0xbfb83184 00038 (v1 DELL PE_SC3 00000001 DELL 00000001) ACPI: MCFG 0xbfb831c0 0003C (v1 DELL PE_SC3 00000001 DELL 00000001) ACPI: WD__ 0xbfb83200 00134 (v1 DELL PE_SC3 00000001 DELL 00000001) ACPI: SLIC 0xbfb83338 00024 (v1 DELL PE_SC3 00000001 DELL 00000001) ACPI: ERST 0xbfb6aaf4 00210 (v1 DELL PE_SC3 00000001 DELL 00000001) ACPI: HEST 0xbfb6ad04 0027C (v1 DELL PE_SC3 00000001 DELL 00000001) ACPI: BERT 0xbfb6a974 00030 (v1 DELL PE_SC3 00000001 DELL 00000001) ACPI: EINJ 0xbfb6a9a4 00150 (v1 DELL PE_SC3 00000001 DELL 00000001) ACPI: TCPA 0xbfb834bc 00064 (v1 DELL PE_SC3 00000001 DELL 00000001) MADT: Found IO APIC ID 8, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 8 ioapic0: Routing external 8259A's -> intpin 0 lapic: Routing NMI -> LINT1 lapic: LINT1 trigger: edge lapic: LINT1 polarity: high 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: 0x00010000 pcm: 0x00000400 kbd: new array size 4 kbd1 at kbdmux0 nfslock: pseudo-device mem: crypto: null: random: io: cryptosoft0: on motherboard crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 5 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 16 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 6 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 7 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 18 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 19 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 20 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 8 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 15 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 9 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 10 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 13 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 14 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 11 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 21 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 17 flags 0 maxoplen 0 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff8000032000 pa 0x4000 AcpiOsDerivePciId: \\_SB_.PCI0.MCHM.MCH0 -> bus 0 dev 16 func 1 AcpiOsDerivePciId: \\_SB_.PCI0.MCHD.MCH0 -> bus 0 dev 16 func 0 AcpiOsDerivePciId: \\_SB_.PCI0.ISA_.LPCC -> bus 0 dev 31 func 0 ipmi0: KCS mode found at io 0xca8 on acpi ipmi0: KCS error: ff 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 5 N 0 3 4 5 6 7 10 11 12 Validation 0 5 N 0 3 4 5 6 7 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 Validation 0 10 N 0 3 4 5 6 7 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 Validation 0 255 N 0 3 4 5 6 7 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 5 6 7 10 11 12 Validation 0 6 N 0 3 4 5 6 7 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 6 N 0 3 4 5 6 7 10 11 12 Validation 0 6 N 0 3 4 5 6 7 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 3 4 5 6 7 10 11 12 Validation 0 10 N 0 3 4 5 6 7 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 12 Validation 0 255 N 0 3 4 5 6 7 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 3 4 5 6 7 10 11 12 Validation 0 11 N 0 3 4 5 6 7 10 11 12 After Disable 0 255 N 0 3 4 5 6 7 10 11 12 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 2 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=0x25c0, revid=0x12 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0144, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25e2, revid=0x12 domain=0, bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25e3, revid=0x12 domain=0, bus=0, slot=3, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25f8, revid=0x12 domain=0, bus=0, slot=4, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25e5, revid=0x12 domain=0, bus=0, slot=5, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25f9, revid=0x12 domain=0, bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x25e7, revid=0x12 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 MSI supports 2 messages found-> vendor=0x8086, dev=0x1a38, revid=0x12 domain=0, bus=0, slot=8, func=0 class=08-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0146, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message map[10]: type Memory, range 64, base 0xfc600c00, size 10, enabled pcib0: matched entry for 0.8.INTA pcib0: slot 8 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x25f0, revid=0x12 domain=0, bus=0, slot=16, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f0, revid=0x12 domain=0, bus=0, slot=16, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f0, revid=0x12 domain=0, bus=0, slot=16, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f1, revid=0x12 domain=0, bus=0, slot=17, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f3, revid=0x12 domain=0, bus=0, slot=19, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f5, revid=0x12 domain=0, bus=0, slot=21, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x25f6, revid=0x12 domain=0, bus=0, slot=22, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2690, revid=0x09 domain=0, bus=0, slot=28, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message found-> vendor=0x8086, dev=0x2688, revid=0x09 domain=0, bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, 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 0xcce0, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x2689, revid=0x09 domain=0, bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=6 map[20]: type I/O Port, range 32, base 0xccc0, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 20 found-> vendor=0x8086, dev=0x268a, revid=0x09 domain=0, bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[20]: type I/O Port, range 32, base 0xcca0, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 21 found-> vendor=0x8086, dev=0x268b, revid=0x09 domain=0, bus=0, slot=29, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=6 map[20]: type I/O Port, range 32, base 0xcc80, size 5, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 20 found-> vendor=0x8086, dev=0x268c, revid=0x09 domain=0, bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, 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 map[10]: type Memory, range 32, base 0xfc600800, size 10, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 21 found-> vendor=0x8086, dev=0x244e, revid=0xd9 domain=0, bus=0, slot=30, func=0 class=06-04-01, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0b (2750 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2670, revid=0x09 domain=0, bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0147, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x269e, revid=0x09 domain=0, bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type I/O Port, range 32, base 0xfc00, size 4, enabled found-> vendor=0x8086, dev=0x2680, revid=0x09 domain=0, bus=0, slot=31, func=2 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0047, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xcc78, size 3, enabled map[14]: type I/O Port, range 32, base 0xcc70, size 2, enabled map[18]: type I/O Port, range 32, base 0xcc60, size 3, enabled map[1c]: type I/O Port, range 32, base 0xcc58, size 2, enabled map[20]: type I/O Port, range 32, base 0xcc40, size 4, enabled map[24]: type Memory, range 32, base 0xfc600400, size 10, enabled pcib0: matched entry for 0.31.INTC pcib0: slot 31 INTC hardwired to IRQ 23 pcib1: at device 2.0 on pci0 pcib1: domain 0 pcib1: secondary bus 4 pcib1: subordinate bus 9 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xf2000000-0xf7ffffff pcib1: no prefetched decode pci4: on pcib1 pci4: domain=0, physical bus=4 found-> vendor=0x8086, dev=0x3500, revid=0x01 domain=0, bus=4, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 found-> vendor=0x8086, dev=0x350c, revid=0x01 domain=0, bus=4, slot=0, func=3 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 pcib2: at device 0.0 on pci4 pcib2: domain 0 pcib2: secondary bus 5 pcib2: subordinate bus 8 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xf4000000-0xf7ffffff pcib2: no prefetched decode pci5: on pcib2 pci5: domain=0, physical bus=5 found-> vendor=0x8086, dev=0x3510, revid=0x01 domain=0, bus=5, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit found-> vendor=0x8086, dev=0x3514, revid=0x01 domain=0, bus=5, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit pcib3: at device 0.0 on pci5 pcib3: domain 0 pcib3: secondary bus 6 pcib3: subordinate bus 7 pcib3: I/O decode 0xf000-0xfff pcib3: memory decode 0xf4000000-0xf7ffffff pcib3: no prefetched decode pci6: on pcib3 pci6: domain=0, physical bus=6 found-> vendor=0x1166, dev=0x0103, revid=0xc3 domain=0, bus=6, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 pcib4: at device 0.0 on pci6 pcib4: domain 0 pcib4: secondary bus 7 pcib4: subordinate bus 7 pcib4: I/O decode 0xf000-0xfff pcib4: memory decode 0xf4000000-0xf7ffffff pcib4: no prefetched decode pci7: on pcib4 pci7: domain=0, physical bus=7 found-> vendor=0x14e4, dev=0x164c, revid=0x12 domain=0, bus=7, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x015e, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf4000000, size 25, enabled pcib4: requested memory range 0xf4000000-0xf5ffffff: good pcib3: requested memory range 0xf4000000-0xf5ffffff: good pcib2: requested memory range 0xf4000000-0xf5ffffff: good pcib1: requested memory range 0xf4000000-0xf5ffffff: good pcib3: matched entry for 6.0.INTA pcib3: slot 0 INTA hardwired to IRQ 17 pcib4: slot 0 INTA is routed to irq 17 bce0: mem 0xf4000000-0xf5ffffff irq 17 at device 0.0 on pci7 bce0: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xf4000000 bce0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 49 bce0: using IRQ 256 for MSI miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: OUI 0x000818, model 0x0036, rev. 6 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce0: bpf attached bce0: Ethernet address: 00:1e:c9:b4:6a:6f bce0: [MPSAFE] bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (4.0.3); Flags (MSI|MFW); MFW (UMP 1.1.9) pcib5: at device 1.0 on pci5 pcib5: domain 0 pcib5: secondary bus 8 pcib5: subordinate bus 8 pcib5: I/O decode 0xf000-0xfff pcib5: no prefetched decode pci8: on pcib5 pci8: domain=0, physical bus=8 pcib6: at device 0.3 on pci4 pcib6: domain 0 pcib6: secondary bus 9 pcib6: subordinate bus 9 pcib6: I/O decode 0xf000-0xfff pcib6: no prefetched decode pci9: on pcib6 pci9: domain=0, physical bus=9 pcib7: at device 3.0 on pci0 pcib7: domain 0 pcib7: secondary bus 1 pcib7: subordinate bus 1 pcib7: I/O decode 0xe000-0xefff pcib7: memory decode 0xfc300000-0xfc5fffff pcib7: no prefetched decode pci1: on pcib7 pci1: domain=0, physical bus=1 found-> vendor=0x1000, dev=0x0058, revid=0x08 domain=0, bus=1, slot=0, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit MSI-X supports 1 message in map 0x14 map[10]: type I/O Port, range 32, base 0xec00, size 8, enabled pcib7: requested I/O range 0xec00-0xecff: in range map[14]: type Memory, range 64, base 0xfc4fc000, size 14, enabled pcib7: requested memory range 0xfc4fc000-0xfc4fffff: good map[1c]: type Memory, range 64, base 0xfc4e0000, size 16, enabled pcib7: requested memory range 0xfc4e0000-0xfc4effff: good pcib7: matched entry for 1.0.INTA pcib7: slot 0 INTA hardwired to IRQ 16 mpt0: port 0xec00-0xecff mem 0xfc4fc000-0xfc4fffff,0xfc4e0000-0xfc4effff irq 16 at device 0.0 on pci1 mpt0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xec00 mpt0: Reserved 0x4000 bytes for rid 0x14 type 3 at 0xfc4fc000 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 50 mpt0: [MPSAFE] mpt0: [ITHREAD] mpt0: MPI Version=1.5.14.0 mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x12 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0x16 (ACK not required). mpt0: No Handlers For Any Event Notify Frames. Event 0xf (ACK required). mpt0: No Handlers For Any Event Notify Frames. Event 0xf (ACK required). mpt0: No Handlers For Any Event Notify Frames. Event 0xf (ACK required). mpt0: Capabilities: ( RAID-0 RAID-1E RAID-1 ) mpt0: 0 Active Volumes (2 Max) mpt0: 0 Hidden Drive Members (14 Max) mpt0: No Handlers For Any Event Notify Frames. Event 0xa (ACK not required). pcib8: at device 4.0 on pci0 pcib8: domain 0 pcib8: secondary bus 10 pcib8: subordinate bus 10 pcib8: I/O decode 0xf000-0xfff pcib8: no prefetched decode pci10: on pcib8 pci10: domain=0, physical bus=10 pcib9: at device 5.0 on pci0 pcib9: domain 0 pcib9: secondary bus 11 pcib9: subordinate bus 11 pcib9: I/O decode 0xf000-0xfff pcib9: no prefetched decode pci11: on pcib9 pci11: domain=0, physical bus=11 pcib10: at device 6.0 on pci0 pcib10: domain 0 pcib10: secondary bus 12 pcib10: subordinate bus 12 pcib10: I/O decode 0xf000-0xfff pcib10: no prefetched decode pci12: on pcib10 pci12: domain=0, physical bus=12 pcib11: at device 7.0 on pci0 pcib11: domain 0 pcib11: secondary bus 13 pcib11: subordinate bus 13 pcib11: I/O decode 0xf000-0xfff pcib11: no prefetched decode pci13: on pcib11 pci13: domain=0, physical bus=13 pci0: at device 8.0 (no driver attached) pcib12: at device 28.0 on pci0 pcib12: domain 0 pcib12: secondary bus 2 pcib12: subordinate bus 3 pcib12: I/O decode 0xf000-0xfff pcib12: memory decode 0xf8000000-0xfbffffff pcib12: no prefetched decode pci2: on pcib12 pci2: domain=0, physical bus=2 found-> vendor=0x1166, dev=0x0103, revid=0xc3 domain=0, bus=2, slot=0, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0147, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 pcib13: at device 0.0 on pci2 pcib13: domain 0 pcib13: secondary bus 3 pcib13: subordinate bus 3 pcib13: I/O decode 0xf000-0xfff pcib13: memory decode 0xf8000000-0xfbffffff pcib13: no prefetched decode pci3: on pcib13 pci3: domain=0, physical bus=3 found-> vendor=0x14e4, dev=0x164c, revid=0x12 domain=0, bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x015e, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xf8000000, size 25, enabled pcib13: requested memory range 0xf8000000-0xf9ffffff: good pcib12: requested memory range 0xf8000000-0xf9ffffff: good pcib12: matched entry for 2.0.INTA pcib12: slot 0 INTA hardwired to IRQ 16 pcib13: slot 0 INTA is routed to irq 16 bce1: mem 0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci3 bce1: Reserved 0x2000000 bytes for rid 0x10 type 3 at 0xf8000000 bce1: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 51 bce1: using IRQ 257 for MSI miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: OUI 0x000818, model 0x0036, rev. 6 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce1: bpf attached bce1: Ethernet address: 00:1e:c9:b4:6a:6d bce1: [MPSAFE] bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); B/C (4.0.3); Flags (MSI|MFW); MFW (UMP 1.1.9) uhci0: port 0xcce0-0xccff irq 21 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcce0 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 0 vector 52 uhci0: [MPSAFE] uhci0: [ITHREAD] uhci0: LegSup = 0x0000 usbus0: on uhci0 uhci1: port 0xccc0-0xccdf irq 20 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xccc0 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 0 vector 53 uhci1: [MPSAFE] uhci1: [ITHREAD] uhci1: LegSup = 0x0000 usbus1: on uhci1 uhci2: port 0xcca0-0xccbf irq 21 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcca0 uhci2: [MPSAFE] uhci2: [ITHREAD] uhci2: LegSup = 0x0000 usbus2: on uhci2 uhci3: port 0xcc80-0xcc9f irq 20 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xcc80 uhci3: [MPSAFE] uhci3: [ITHREAD] uhci3: LegSup = 0x0000 usbus3: on uhci3 ehci0: mem 0xfc600800-0xfc600bff irq 21 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xfc600800 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib14: at device 30.0 on pci0 pcib14: domain 0 pcib14: secondary bus 14 pcib14: subordinate bus 14 pcib14: I/O decode 0xd000-0xdfff pcib14: memory decode 0xfc100000-0xfc2fffff pcib14: prefetched decode 0xd8000000-0xdfffffff pcib14: Subtractively decoded bridge. pci14: on pcib14 pci14: domain=0, physical bus=14 found-> vendor=0x1002, dev=0x515e, revid=0x02 domain=0, bus=14, slot=13, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x01a7, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=6 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Prefetchable Memory, range 32, base 0xd8000000, size 27, enabled pcib14: requested memory range 0xd8000000-0xdfffffff: good map[14]: type I/O Port, range 32, base 0xdc00, size 8, enabled pcib14: requested I/O range 0xdc00-0xdcff: in range map[18]: type Memory, range 32, base 0xfc2d0000, size 16, enabled pcib14: requested memory range 0xfc2d0000-0xfc2dffff: good pcib14: matched entry for 14.13.INTA pcib14: slot 13 INTA hardwired to IRQ 19 vgapci0: port 0xdc00-0xdcff mem 0xd8000000-0xdfffffff,0xfc2d0000-0xfc2dffff irq 19 at device 13.0 on pci14 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfc00 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=03 ostat0=00 ostat1=00 ata0: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata0: stat1=0x00 err=0x00 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=00 stat1=00 devices=0x10000 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 54 ata0: [MPSAFE] ata0: [ITHREAD] atapci1: port 0xcc78-0xcc7f,0xcc70-0xcc73,0xcc60-0xcc67,0xcc58-0xcc5b,0xcc40-0xcc4f mem 0xfc600400-0xfc6007ff irq 23 at device 31.2 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xcc40 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 55 atapci1: [MPSAFE] atapci1: [ITHREAD] pci0: child atapci1 requested type 4 for rid 0x24, but the BAR says it is an memio ata2: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0xcc78 atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0xcc70 ata2: reset tp1 mask=03 ostat0=7f ostat1=7f ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat0=0x7f err=0xff lsb=0xff msb=0xff ata2: stat1=0x7f err=0xff lsb=0xff msb=0xff ata2: reset tp2 stat0=ff stat1=ff devices=0x0 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0xcc60 atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0xcc58 ata3: reset tp1 mask=03 ostat0=7f ostat1=7f ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat0=0x7f err=0xff lsb=0xff msb=0xff ata3: stat1=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] ata3: [ITHREAD] atrtc0: port 0x70-0x7f 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: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 56 uart0: [FILTER] uart0: fast interrupt uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 0 vector 57 uart1: [FILTER] uart1: fast interrupt cpu0: on acpi0 cpu0: switching to generic Cx mode coretemp0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 cpu4: on acpi0 coretemp4: on cpu4 cpu5: on acpi0 coretemp5: on cpu5 cpu6: on acpi0 coretemp6: on cpu6 cpu7: on acpi0 coretemp7: on cpu7 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 isa_probe_children: disabling PnP devices ipmi1: on isa0 device_attach: ipmi1 attach returned 16 atrtc: atrtc0 already exists; skipping it fdc: fdc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it uart: uart1 already exists; skipping it isa_probe_children: probing non-PnP devices 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 <8 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0 at vga0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0xffffffff (1) atkbd: failed to reset the keyboard. kbd0: atkbd0, AT 84 (1), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 58 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0065 psm0: failed to reset the aux device. ppc0 failed to probe at irq 7 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 1021109 -> 100000 lapic: Divisor 2, Frequency 166435872 hz Timecounter "TSC" frequency 2496538027 Hz quality -100 Timecounters tick every 1.111 msec crypto: vlan: initialized, using hash tables with chaining IPsec: Initialized Security Association Processing. enc0: bpf attached lo0: bpf attached pflog0: bpf attached ata0: Identifying devices: 00010000 ata0: New devices: 00010000 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on 63XXESB2 chip 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 acd0: setting UDMA33 on 63XXESB2 chip acd0: DVDROM drive at ata0 as master acd0: read 4134KB/s (4134KB/s), 198KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata2: Identifying devices: 00000000 ata2: New devices: 00000000 ata3: Identifying devices: 00000000 ata3: New devices: 00000000 ipmi0: IPMI device rev. 0, firmware rev. 2.2, version 2.0 ipmi0: Number of channels 4 ipmi0: Attached watchdog uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub4: 8 ports with 8 removable, self powered (probe67:mpt0:1:3:0): error 22 (probe67:mpt0:1:3:0): Unretryable Error (probe68:mpt0:1:4:0): error 22 (probe68:mpt0:1:4:0): Unretryable Error (probe69:mpt0:1:5:0): error 22 (probe69:mpt0:1:5:0): Unretryable Error (probe70:mpt0:1:6:0): error 22 (probe70:mpt0:1:6:0): Unretryable Error (probe71:mpt0:1:7:0): error 22 (probe71:mpt0:1:7:0): Unretryable Error (probe64:mpt0:1:0:0): error 22 (probe64:mpt0:1:0:0): Unretryable Error (probe65:mpt0:1:1:0): error 22 (probe65:mpt0:1:1:0): Unretryable Error (probe66:mpt0:1:2:0): error 22 (probe66:mpt0:1:2:0): Unretryable Error (probe72:mpt0:1:8:0): error 22 (probe72:mpt0:1:8:0): Unretryable Error (probe73:mpt0:1:9:0): error 22 (probe73:mpt0:1:9:0): Unretryable Error (probe74:mpt0:1:10:0): error 22 (probe74:mpt0:1:10:0): Unretryable Error (probe75:mpt0:1:11:0): error 22 (probe75:mpt0:1:11:0): Unretryable Error (probe76:mpt0:1:12:0): error 22 (probe76:mpt0:1:12:0): Unretryable Error (probe77:mpt0:1:13:0): error 22 (probe77:mpt0:1:13:0): Unretryable Error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:0:0): error 22 (probe0:ata0:0:0:0): Unretryable Error (probe0:ata0:0:0:0): Down reving Protocol Version from 2 to 0? (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): CAM Status: SCSI Status Error (probe0:ata0:0:0:0): SCSI Status: Check Condition (probe0:ata0:0:0:0): NOT READY asc:3a,1 (probe0:ata0:0:0:0): Medium not present - tray closed (probe0:ata0:0:0:0): (probe0:ata0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata0:0:0:0): NOT READY asc:3a,1 (probe0:ata0:0:0:0): Medium not present - tray closed Unretryable error (probe0:ata0:0:0:0): error 6 (probe0:ata0:0:0:0): Unretryable Error (probe0:ata0:0:0:0): error 6 (probe0:ata0:0:0:0): Unretryable Error acd0: FAILURE - INQUIRY ILLEGAL REQUEST asc=0x24 ascq=0x00 (probe0:ata0:0:0:0): error 22 (probe0:ata0:0:0:0): Unretryable Error (probe9:mpt0:0:8:0): error 22 (probe9:mpt0:0:8:0): Unretryable Error (probe9:mpt0:0:8:0): Unexpected Bus Free (probe9:mpt0:0:8:0): Retrying Command (probe9:mpt0:0:8:0): Unexpected Bus Free (probe9:mpt0:0:8:0): Retrying Command (probe9:mpt0:0:8:0): Unexpected Bus Free (probe9:mpt0:0:8:0): Retrying Command (probe9:mpt0:0:8:0): Unexpected Bus Free (probe9:mpt0:0:8:0): Retrying Command (probe9:mpt0:0:8:0): Unexpected Bus Free (probe9:mpt0:0:8:0): error 5 (probe9:mpt0:0:8:0): Retries Exhausted pass0 at mpt0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-5 device pass0: Serial Number GTF200P8GPK41F pass0: 300.000MB/s transfers pass0: Command Queueing enabled da0 at mpt0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: Serial Number GTF200P8GPK41F da0: 300.000MB/s transfers da0: Command Queueing enabled da0: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) da1 at mpt0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-5 device da1: Serial Number WD-WMATV0911702 da1: 300.000MB/s transfers da1: Command Queueing enabled da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) GEOM: new disk da0 GEOM: new disk da1 pass1 at mpt0 bus 0 target 1 lun 0 pass1: Fixed Direct Access SCSI-5 device pass1: Serial Number WD-WMATV0911702 pass1: 300.000MB/s transfers pass1: Command Queueing enabled pass2 at mpt0 bus 0 target 8 lun 0 pass2: Fixed Enclosure Services SCSI-5 device pass2: 300.000MB/s transfers pass3 at ata0 bus 0 target 0 lun 0 pass3: Removable CD-ROM SCSI-0 device pass3: 33.000MB/s transfers ses0 at mpt0 bus 0 target 8 lun 0 ses0: Fixed Enclosure Services SCSI-5 device ses0: 300.000MB/s transfers ses0: SCSI-3 SES Device ATA PseudoRAID loaded (cd0:ata0:0:0:0): error 6 (cd0:ata0:0:0:0): Unretryable ErrorSMP: AP CPU #1 Launched! cd0 at ata0 bus 0 target 0 lun 0 cpu1 AP: cd0: ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff Removable CD-ROM SCSI-0 device lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff cd0: 33.000MB/s transfers timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #4 Launched! cpu4 AP: ID: 0x04000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #6 Launched! cpu6 AP: ID: 0x06000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #5 Launched! cpu5 AP: ID: 0x05000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #7 Launched! cpu7 AP: ID: 0x07000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: routing intpin 3 (ISA IRQ 3) to lapic 1 vector 48 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 2 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 4 vector 48 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 5 vector 48 ioapic0: routing intpin 20 (PCI IRQ 20) to lapic 6 vector 48 ioapic0: routing intpin 21 (PCI IRQ 21) to lapic 7 vector 48 msi: Assigning MSI IRQ 256 to local APIC 1 vector 49 msi: Assigning MSI IRQ 257 to local APIC 2 vector 49 GEOM: new disk cd0 (cd0:ata0:0:0:0): error 6 (cd0:ata0:0:0:0): Unretryable Error (cd0:ata0:0:0:0): error 6 (cd0:ata0:0:0:0): Unretryable Error ugen4.2: at usbus4 uhub5: on usbus4 (cd0:ata0:0:0:0): error 6 (cd0:ata0:0:0:0): Unretryable Error Root mount waiting for: usbus4 uhub5: 2 ports with 2 removable, self powered ugen4.3: at usbus4 ukbd0: on usbus4 kbd2 at ukbd0 kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000 ums0: on usbus4 ums0: 3 buttons and [Z] coordinates ID=0 Root mount waiting for: usbus4 ugen4.4: at usbus4 uhub6: on usbus4 Root mount waiting for: usbus4 uhub6: 4 ports with 4 removable, self powered usb_alloc_device:1589: set address 5 failed (USB_ERR_STALLED, ignored) Root mount waiting for: usbus4 usb_alloc_device:1627: getting device descriptor at addr 5 failed, USB_ERR_STALLED! usbd_req_re_enumerate:1539: addr=5, set address failed! (USB_ERR_STALLED, ignored) usbd_req_re_enumerate:1553: getting device descriptor at addr 5 failed, USB_ERR_STALLED! Root mount waiting for: usbus4 usbd_req_re_enumerate:1539: addr=5, set address failed! (USB_ERR_STALLED, ignored) usbd_req_re_enumerate:1553: getting device descriptor at addr 5 failed, USB_ERR_STALLED! ugen4.5: <(null)> at usbus4 (disconnected) uhub_reattach_port:435: could not allocate new device! Trying to mount root from ufs:/dev/da0s1a WARNING: / was not properly dismounted ct_to_ts([2009-07-21 10:51:58]) = 1248173518.000000000 start_init: trying /sbin/init WARNING: /var was not properly dismounted WARNING: /compat was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /usr/local was not properly dismounted WARNING: /usr/obj was not properly dismounted WARNING: /usr/ports was not properly dismounted WARNING: /usr/src was not properly dismounted WARNING: /scratch was not properly dismounted procfs registered Linux ELF exec handler installed linprocfs registered linsysfs registered This module (opensolaris) contains code covered by the Common Development and Distribution License (CDDL) see http://opensolaris.org/os/licensing/opensolaris_license/ WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS filesystem version 13 ZFS storage pool version 13 bce0: Gigabit link up! ts_to_ct(1248173534.061403117) = [2009-07-21 10:52:14] e ugen4.5: at usbus4 ukbd1: on usbus4 kbd3 at ukbd1 kbd3: ukbd1, generic (0), config:0x0, flags:0x3d0000 nfs server pid1126@thusnelda:/extern: not responding nfs server pid1126@thusnelda:/extern: is alive again --------------080706080008040609070704-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 12:10:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21E08106566C for ; Tue, 21 Jul 2009 12:10:12 +0000 (UTC) (envelope-from oyvind@rakvag.net) Received: from mail.rakvag.net (rakvag.net [193.75.76.66]) by mx1.freebsd.org (Postfix) with ESMTP id D49F78FC0A for ; Tue, 21 Jul 2009 12:10:11 +0000 (UTC) (envelope-from oyvind@rakvag.net) Received: from serenity.mrfylke.no (unknown [62.92.31.1]) by mail.rakvag.net (Postfix) with ESMTPA id A12AE1760C8 for ; Tue, 21 Jul 2009 13:50:21 +0200 (CEST) Message-ID: <4A65AB7C.9020804@rakvag.net> Date: Tue, 21 Jul 2009 13:50:20 +0200 From: =?ISO-8859-1?Q?=D8yvind_Rakv=E5g?= User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: 8.0-beta freeze when bringing up bge0 on certain HP Proliant servers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 12:10:12 -0000 Hi Setting bge0 to UP causes a freeze on these HP Proliant models: DL380 G4 DL360 G4p I suspect DL380 G4p and DL360 G4 are affected as well, since they're essentially the same, but I can't confirm that. These servers have onboard dual Broadcom NetXtreme Dual Gigabit Adapters (BCM5704), but the problem only occurs on bge0, not bge1. I found no difference between having a cable plugged in or not. I have tested beta1, beta2 and -current as of today. From pciconf -lv bge0@pci0:3:1:0: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' class = network subclass = ethernet bge1@pci0:3:1:1: class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00 vendor = 'Broadcom Corporation' device = 'NetXtreme Dual Gigabit Adapter (BCM5704)' class = network subclass = ethernet From ifconfig (interesting that media on bge0 doesn't say "(none)" as it usually does.) bge0: flags=8802 metric 0 mtu 1500 options=9b ether 00:16:35:04:5b:65 media: Ethernet autoselect status: no carrier bge1: flags=8843 metric 0 mtu 1500 options=9b ether 00:16:35:04:5b:64 inet 10.247.18.15 netmask 0xffffff00 broadcast 10.247.18.255 media: Ethernet autoselect (1000baseT ) status: active From dmesg bge0: mem 0xfdef0000-0xfdefffff irq 25 at device 1.0 on pci3 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:16:35:04:5b:65 bge0: [ITHREAD] bge1: mem 0xfdee0000-0xfdeeffff irq 26 at device 1.1 on pci3 miibus1: on bge1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge1: Ethernet address: 00:16:35:04:5b:64 bge1: [ITHREAD] I hope someone can look into the problem. I can dedicate this box for testing for a while. -- / Øyvind Rakvåg From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 12:20:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 016A01065673; Tue, 21 Jul 2009 12:20:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swip.net [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id BA4358FC15; Tue, 21 Jul 2009 12:20:44 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=gg2W7PyvkLb8p4ie143lBA==:17 a=8kQB0OdkAAAA:8 a=6I5d2MoRAAAA:8 a=qDiRO2zrLxbiixRva8cA:9 a=XpQ1n1eJ-zfCsha2FFf-IJxmWUAA:4 a=9aOQ2cSd83gA:10 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 541094400; Tue, 21 Jul 2009 14:20:43 +0200 From: Hans Petter Selasky To: Alfred Perlstein Date: Tue, 21 Jul 2009 14:20:32 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> <200907152236.58049.hselasky@c2i.net> <20090720215141.GL49724@elvis.mu.org> In-Reply-To: <20090720215141.GL49724@elvis.mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907211420.33571.hselasky@c2i.net> Cc: usb@freebsd.org, freebsd-current@freebsd.org, Andrew Thompson Subject: Re: USB polling (75% done) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 12:20:46 -0000 On Monday 20 July 2009 23:51:41 Alfred Perlstein wrote: > * Hans Petter Selasky [090715 13:37] wrote: > > Hi, > > > > I've added minimal polling support to the USB P4 repository now. Patch > > can be found here: > > > > http://perforce.freebsd.org/chv.cgi?CH=166148 > > > > Dumping core to USB disk: Tested and works. > > > > Using USB keyboard in KDB: Does not work because Giant is not locked when > > calling into the UKBD's get char routine. UKBD is Giant locked. Someone > > familiar with the keyboard system on FreeBSD please step forward and fix > > this so that UKBD gets independent of the Giant mutex. > > the ukbd driver needs giant? I think the keyboard mux is under Giant, and does not have any concept about mutexes. Most simple solution would be that DDB locks Giant before entering into the keyboard code. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 12:33:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0100E106566B for ; Tue, 21 Jul 2009 12:33:34 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.tele2.se [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8BA258FC1E for ; Tue, 21 Jul 2009 12:33:33 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Vi1uYO6-zQMA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=f85HN5h3sGIBDzHoBu8A:9 a=QCRbw0bSbU5x47JbiBIA:7 a=a0fBM9j2RtsENVhr-5_WqHdC41IA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe09.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 935461240; Tue, 21 Jul 2009 14:33:31 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 21 Jul 2009 14:33:19 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <4A65A710.5050508@zedat.fu-berlin.de> In-Reply-To: <4A65A710.5050508@zedat.fu-berlin.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907211433.20088.hselasky@c2i.net> Cc: "O. Hartmann" Subject: Re: FreeBSD 8.0-BETA2/amd64 and DELL Poweredge 1930: USB oddities X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 12:33:34 -0000 On Tuesday 21 July 2009 13:31:28 O. Hartmann wrote: > Running FreeBSD 8.0-BETA2/amd64 now a while on a server we use for > scientific purposes. I realize problems since a couple of weeks now > rendering the box instable. Attaching the USB keyboard to any of the > front USB ports seems to induce some issues - only one port is capable > of delivering keyboard functionality, the alternative one does not offer > a keyboard after reboot. Interestingly, a similar issue is recognized on > another FreeBSD 8.0-BETA2/amd64 box. The system is crashing immediately > after bootup when moving the USB mouse when the mouse is NOT attached to > as specific set of two USB ports (USB is only used for mouse, nothing > else, keyboard is PS/2)! > > Referrring to the problems recognized on the DELL box, I can only > provide a most recent dmesg-output after a crash and reattaching the > keyboard to another USB port. > > Any suggestions out there? It might be that the EHCI does not support addressing 16GBytes of RAM, or even 4GB's of RAM. In your case the EHCI will be moving data using bounce buffers in the lower 4GBytes of RAM. Try reducing the amount of RAM to 2GBytes. Are you able to extract a backtrace from the crash. Sounds like a DMA/Busdma problem. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 13:39:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5081010656C1 for ; Tue, 21 Jul 2009 13:39:18 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swip.net [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id DEAD68FC1F for ; Tue, 21 Jul 2009 13:39:17 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Rlfysp-5d7QA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=DzOjFYJR5QdlAANMzdMA:9 a=J-7XMQe3X6_LXtElwhcpEIjuGmEA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 541108289 for current@freebsd.org; Tue, 21 Jul 2009 14:39:16 +0200 From: Hans Petter Selasky To: current@freebsd.org Date: Tue, 21 Jul 2009 14:39:05 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907211439.05703.hselasky@c2i.net> Cc: Subject: FreeBSD-8-BETA2 on MacBookPro5.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 13:39:18 -0000 Hi, FreeBSD-8-BETA2 does not boot on MacBookPro5.5. It Freezes during kernel load. Is anyone working on this? --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 13:43:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 782BD106566B; Tue, 21 Jul 2009 13:43:51 +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 474578FC08; Tue, 21 Jul 2009 13:43:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EC28D46B49; Tue, 21 Jul 2009 09:43:50 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 424188A09F; Tue, 21 Jul 2009 09:43:50 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 21 Jul 2009 08:47:52 -0400 User-Agent: KMail/1.9.7 References: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> <20090720215141.GL49724@elvis.mu.org> <200907211420.33571.hselasky@c2i.net> In-Reply-To: <200907211420.33571.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907210847.52802.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 21 Jul 2009 09:43:50 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: usb@freebsd.org, Alfred Perlstein , Andrew Thompson , Hans Petter Selasky Subject: Re: USB polling (75% done) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 13:43:52 -0000 On Tuesday 21 July 2009 8:20:32 am Hans Petter Selasky wrote: > On Monday 20 July 2009 23:51:41 Alfred Perlstein wrote: > > * Hans Petter Selasky [090715 13:37] wrote: > > > Hi, > > > > > > I've added minimal polling support to the USB P4 repository now. Patch > > > can be found here: > > > > > > http://perforce.freebsd.org/chv.cgi?CH=166148 > > > > > > Dumping core to USB disk: Tested and works. > > > > > > Using USB keyboard in KDB: Does not work because Giant is not locked when > > > calling into the UKBD's get char routine. UKBD is Giant locked. Someone > > > familiar with the keyboard system on FreeBSD please step forward and fix > > > this so that UKBD gets independent of the Giant mutex. > > > > the ukbd driver needs giant? > > I think the keyboard mux is under Giant, and does not have any concept about > mutexes. Most simple solution would be that DDB locks Giant before entering > into the keyboard code. In general if you are in DDB you should not be using any locks at all. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 13:43:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDE141065678 for ; Tue, 21 Jul 2009 13:43:52 +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 8E2348FC0A for ; Tue, 21 Jul 2009 13:43:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 408B646B4C; Tue, 21 Jul 2009 09:43:52 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 9B18D8A09C; Tue, 21 Jul 2009 09:43:51 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 21 Jul 2009 08:52:09 -0400 User-Agent: KMail/1.9.7 References: <20090720201332.GA95896@hyperion.scode.org> <4A64D1FF.1010207@elischer.org> In-Reply-To: <4A64D1FF.1010207@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907210852.09660.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 21 Jul 2009 09:43:51 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Peter Schuller , Julian Elischer Subject: Re: Getting crashdumps to work (trying to submit crash report) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 13:43:53 -0000 On Monday 20 July 2009 4:22:23 pm Julian Elischer wrote: > Peter Schuller wrote: > > Hello, > > > > Short version: Is there a list of reasons why crashdumps might not > > work? I have dumpdev on a plain (non-gmirror/non-gstripe/etc) device > > that is equal to RAM size, but I am not getting a dump for unknown > > reasons. > > > hopefuly a bit BIGGER than ram size... not by much but exactly equal > wouldn't work.. That hasn't been required for a few years now since minidumps came in, at least for amd64 and i386. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 13:43:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AECF106566C; Tue, 21 Jul 2009 13:43:54 +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 2D1138FC12; Tue, 21 Jul 2009 13:43:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D6AF146B03; Tue, 21 Jul 2009 09:43:53 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 18F718A09E; Tue, 21 Jul 2009 09:43:53 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 21 Jul 2009 08:53:15 -0400 User-Agent: KMail/1.9.7 References: <4A65187E.8060505@phat.za.net> In-Reply-To: <4A65187E.8060505@phat.za.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907210853.16169.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 21 Jul 2009 09:43:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Aragon Gouveia , current@freebsd.org Subject: Re: devel/ccache broken in BETA2? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 13:43:55 -0000 On Monday 20 July 2009 9:23:10 pm Aragon Gouveia wrote: > Hi, > > Is anyone able to compile just about anything with ccache on BETA2? I'm > experiencing a lot of breakage here. It's a bug in ccache in that it expects mmap() with a size of 0 to work. Someone on an earlier thread had a patch for the ccache port to fix it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 13:43:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5AECF106566C; Tue, 21 Jul 2009 13:43:54 +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 2D1138FC12; Tue, 21 Jul 2009 13:43:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D6AF146B03; Tue, 21 Jul 2009 09:43:53 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 18F718A09E; Tue, 21 Jul 2009 09:43:53 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 21 Jul 2009 08:53:15 -0400 User-Agent: KMail/1.9.7 References: <4A65187E.8060505@phat.za.net> In-Reply-To: <4A65187E.8060505@phat.za.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907210853.16169.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 21 Jul 2009 09:43:53 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Aragon Gouveia , current@freebsd.org Subject: Re: devel/ccache broken in BETA2? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 13:43:55 -0000 On Monday 20 July 2009 9:23:10 pm Aragon Gouveia wrote: > Hi, > > Is anyone able to compile just about anything with ccache on BETA2? I'm > experiencing a lot of breakage here. It's a bug in ccache in that it expects mmap() with a size of 0 to work. Someone on an earlier thread had a patch for the ccache port to fix it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 13:43:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5396106564A; Tue, 21 Jul 2009 13:43:56 +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 769658FC13; Tue, 21 Jul 2009 13:43:56 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2D0F646B53; Tue, 21 Jul 2009 09:43:56 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 410B08A0A1; Tue, 21 Jul 2009 09:43:55 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 21 Jul 2009 08:57:01 -0400 User-Agent: KMail/1.9.7 References: <4A659F98.2060007@haruhiism.net> In-Reply-To: <4A659F98.2060007@haruhiism.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907210857.01690.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 21 Jul 2009 09:43:55 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Lawrence Stewart Subject: Re: [follow-up] Fatal trap 12 in r195146+ in netisr_queue_internal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 13:43:57 -0000 On Tuesday 21 July 2009 6:59:36 am Kamigishi Rei wrote: > Hello, hope you're having a good day, > > I've been researching the issue I mentioned in my last message in > "r194546 amd64: kernel panic in tcp_sack.c" thread since July 07 and > here are some of the findings: > The fatal trap triggers inside mtx_lock_sleep() during a dereference of > a pointer (owner, points to struct thread @ m->mtx_lock & > ~MTX_FLAGMASK). The code goes like this (shortened): > > v = m->mtx_lock; > if (v == MTX_UNOWNED) { turnstile_cancel(ts); continue; } > owner = (struct thread *)(v & ~MTX_FLAGMASK); > if (TD_IS_RUNNING(owner)) { turnstile_cancel(ts); continue; } > > Everything goes fine until - under heavy load on an interface, usually - > we reach a point where: > > 1. m->mtx_lock is 4 (== MTX_UNOWNED). > 2. v is assigned mtx_lock's value (4 == MTX_UNOWNED). > 3. condition (v == MTX_UNOWNED) fails. This will not happen. If you look at the disassembly you will see this can't happen either. Do you have a crashdump from a crash? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 13:44:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A727310656A4 for ; Tue, 21 Jul 2009 13:43:59 +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 AD2AA8FC18 for ; Tue, 21 Jul 2009 13:43:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 6337446B66; Tue, 21 Jul 2009 09:43:59 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id A66038A09D; Tue, 21 Jul 2009 09:43:58 -0400 (EDT) From: John Baldwin To: Edho P Arief Date: Tue, 21 Jul 2009 09:36:18 -0400 User-Agent: KMail/1.9.7 References: <200907201057.03777.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907210936.18845.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 21 Jul 2009 09:43:58 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: broken pmbr? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 13:44:06 -0000 On Tuesday 21 July 2009 1:51:08 am Edho P Arief wrote: > On Mon, Jul 20, 2009 at 9:57 PM, John Baldwin wrote: > > On Friday 17 July 2009 10:42:07 pm Edho P Arief wrote: > >> I just managed to, um, break my installation boot using these steps: > >> > >> 1. system with at least two disks (say ad0 and ad4) > >> 2. create gpt partition on ad0 > >> 3. create at least one freebsd-ufs on ad0 > >> 4. install freebsd on ad4 using gpt ( > > http://m8d.de/news/freebsd-on-gpt.php ) > >> 5. reboot and boot to ad4 > >> 6. 'Missing boot loader' > >> > >> (Rearranging ad0 to adX where X>4 or removing ad0 solves the problem, = btw) > >> > >> Does pmbr only search first drive with gpt it found? > > > > /boot/pmbr only looks on the current disk, yes. =C2=A0You could put the= boot > > partition on ad0 and then put a /boot.config in the UFS partition on ad= 0 that > > points to ad4 if you want it to find the boot loader from ad4 instead o= f ad0. >=20 > I looked to me pmbr only find *first* disk-containing-gpt, not the > disk where it's booted from. No, it uses the %dl register from the BIOS to do all it's disk I/O and that= is always the drive that contains the pmbr code itself. =2D-=20 John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 13:59:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F166106566B; Tue, 21 Jul 2009 13:59:52 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3CBFB8FC25; Tue, 21 Jul 2009 13:59:51 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 8733A78F50; Tue, 21 Jul 2009 17:59:50 +0400 (MSD) Message-ID: <4A65C9D1.6080902@haruhiism.net> Date: Tue, 21 Jul 2009 17:59:45 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: John Baldwin References: <4A659F98.2060007@haruhiism.net> <200907210857.01690.jhb@freebsd.org> In-Reply-To: <200907210857.01690.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , freebsd-current@freebsd.org Subject: Re: [follow-up] Fatal trap 12 in r195146+ in netisr_queue_internal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 13:59:52 -0000 John Baldwin wrote: > On Tuesday 21 July 2009 6:59:36 am Kamigishi Rei wrote: > >> Everything goes fine until - under heavy load on an interface, usually - >> we reach a point where: >> 1. m->mtx_lock is 4 (== MTX_UNOWNED). >> 2. v is assigned mtx_lock's value (4 == MTX_UNOWNED). >> 3. condition (v == MTX_UNOWNED) fails. >> > This will not happen. If you look at the disassembly you will see this can't > happen either. Do you have a crashdump from a crash? > I've got about 40 crash dumps on unmodded (without debug code) kernel, and 3 or 4 with debug stuff (KASSERTs added by me). I can reproduce this on my test server (Core2 Duo 3.0, 4GB RAM), on my home PC (Core2 Quad 2.5), and in VMWare with 2 CPUs in VT-x mode on my laptop. It can't be reproduced on single-CPU single-core (including hyperthreaded) systems. Quoting, (kgdb) fr 6 #6 0xffffffff80586255 in _mtx_lock_sleep (m=0xffffffff80e60823, tid=18446742977255365296, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 407 owner = (struct thread *)(v & ~MTX_FLAGMASK); (kgdb) print m->mtx_lock $14 = 4 (kgdb) print v $15 = 21946368 -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 14:27:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA485106566B; Tue, 21 Jul 2009 14:27:12 +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 AAB3C8FC13; Tue, 21 Jul 2009 14:27:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 5D61246B23; Tue, 21 Jul 2009 10:27:12 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id D42C38A09C; Tue, 21 Jul 2009 10:27:11 -0400 (EDT) From: John Baldwin To: Kamigishi Rei Date: Tue, 21 Jul 2009 10:27:06 -0400 User-Agent: KMail/1.9.7 References: <4A659F98.2060007@haruhiism.net> <200907210857.01690.jhb@freebsd.org> <4A65C9D1.6080902@haruhiism.net> In-Reply-To: <4A65C9D1.6080902@haruhiism.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907211027.06589.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 21 Jul 2009 10:27:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Lawrence Stewart , freebsd-current@freebsd.org Subject: Re: [follow-up] Fatal trap 12 in r195146+ in netisr_queue_internal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 14:27:13 -0000 On Tuesday 21 July 2009 9:59:45 am Kamigishi Rei wrote: > John Baldwin wrote: > > On Tuesday 21 July 2009 6:59:36 am Kamigishi Rei wrote: > > > >> Everything goes fine until - under heavy load on an interface, usually - > >> we reach a point where: > >> 1. m->mtx_lock is 4 (== MTX_UNOWNED). > >> 2. v is assigned mtx_lock's value (4 == MTX_UNOWNED). > >> 3. condition (v == MTX_UNOWNED) fails. > >> > > This will not happen. If you look at the disassembly you will see this can't > > happen either. Do you have a crashdump from a crash? > > > I've got about 40 crash dumps on unmodded (without debug code) kernel, > and 3 or 4 with debug stuff (KASSERTs added by me). > I can reproduce this on my test server (Core2 Duo 3.0, 4GB RAM), on my > home PC (Core2 Quad 2.5), and in VMWare with 2 CPUs in VT-x mode on my > laptop. > It can't be reproduced on single-CPU single-core (including > hyperthreaded) systems. > > Quoting, > > (kgdb) fr 6 > #6 0xffffffff80586255 in _mtx_lock_sleep (m=0xffffffff80e60823, > tid=18446742977255365296, opts=Variable "opts" is not available. > ) at /usr/src/sys/kern/kern_mutex.c:407 > 407 owner = (struct thread *)(v & ~MTX_FLAGMASK); > > (kgdb) print m->mtx_lock > $14 = 4 > (kgdb) print v > $15 = 21946368 % printf "%x\n" 21946368 14ee000 Can you print out 'owner' as well? You won't get a panic until you actually dereference 'owner' to get 'owner->td_state' even though gdb will show this as the faulting line (gdb can sometimes get confused by compiler optimization). You are seeing these values because mtx_lock was changed (due to either a mtx_unlock() or a mtx_init()) while you were spinning. That value of v is not what I have typically seen in these panics. Do you also have the original fatal kernel trap messages? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 14:33:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E39B106566B; Tue, 21 Jul 2009 14:33:56 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id DD8908FC0A; Tue, 21 Jul 2009 14:33:55 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id A182778F50; Tue, 21 Jul 2009 18:33:54 +0400 (MSD) Message-ID: <4A65D1CD.40006@haruhiism.net> Date: Tue, 21 Jul 2009 18:33:49 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: John Baldwin References: <4A659F98.2060007@haruhiism.net> <200907210857.01690.jhb@freebsd.org> <4A65C9D1.6080902@haruhiism.net> <200907211027.06589.jhb@freebsd.org> In-Reply-To: <200907211027.06589.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , freebsd-current@freebsd.org Subject: Re: [follow-up] Fatal trap 12 in r195146+ in netisr_queue_internal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 14:33:56 -0000 John Baldwin wrote: > Can you print out 'owner' as well? You won't get a panic until you actually > dereference 'owner' to get 'owner->td_state' even though gdb will show this > as the faulting line (gdb can sometimes get confused by compiler > optimization). You are seeing these values because mtx_lock was changed (due > to either a mtx_unlock() or a mtx_init()) while you were spinning. That > value of v is not what I have typically seen in these panics. Do you also > have the original fatal kernel trap messages? > Why does v change to a non-kernel address then? From what I see, it should never get assigned a value that's not MTX_UNOWNED or 0xfff......(address,flags). However, I can reproduce this trap in all revisions starting with 195146 up to 195484 (and probably more, didn't check yet; at 1956xx these traps stop occurring). vmcore.51 (all cores starting with .9 are related to mtx_lock_sleep() trap): Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x14ee288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80586255 stack pointer = 0x28:0xffffff80787115f0 frame pointer = 0x28:0xffffff8078711620 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 2438 (iperf) trap number = 12 panic: page fault cpuid = 0 Uptime: 43s Physical memory: 4014 MB (kgdb) fr 6 #6 0xffffffff80586255 in _mtx_lock_sleep (m=0xffffffff80e60823, tid=18446742977255365296, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 407 owner = (struct thread *)(v & ~MTX_FLAGMASK); (kgdb) print owner $1 = (volatile struct thread *) 0x14ee000 (kgdb) print v $2 = 21946368 (kgdb) print m->mtx_lock $3 = 4 (kgdb) print owner->td_state Cannot access memory at address 0x14ee288 vmcore.50: Unread portion of the kernel message buffer: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x14ee288 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80586255 stack pointer = 0x28:0xffffff80785005f0 frame pointer = 0x28:0xffffff8078500620 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 2448 (iperf) trap number = 12 panic: page fault cpuid = 0 Uptime: 53s Physical memory: 4014 MB (kgdb) fr 6 #6 0xffffffff80586255 in _mtx_lock_sleep (m=0xffffffff80e60823, tid=18446742974555039520, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 407 owner = (struct thread *)(v & ~MTX_FLAGMASK); (kgdb) print owner $1 = (volatile struct thread *) 0x14ee000 (kgdb) print m->mtx_lock $2 = 4 (kgdb) print v $3 = 21946368 (kgdb) print owner->td_state Cannot access memory at address 0x14ee288 -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 15:18:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC7781065670; Tue, 21 Jul 2009 15:18:26 +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 7D86D8FC13; Tue, 21 Jul 2009 15:18:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1BF7B46B03; Tue, 21 Jul 2009 11:18:26 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 5DFEA8A09C; Tue, 21 Jul 2009 11:18:25 -0400 (EDT) From: John Baldwin To: Kamigishi Rei Date: Tue, 21 Jul 2009 11:14:47 -0400 User-Agent: KMail/1.9.7 References: <4A659F98.2060007@haruhiism.net> <200907211027.06589.jhb@freebsd.org> <4A65D1CD.40006@haruhiism.net> In-Reply-To: <4A65D1CD.40006@haruhiism.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907211114.47691.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 21 Jul 2009 11:18:25 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Lawrence Stewart , freebsd-current@freebsd.org Subject: Re: [follow-up] Fatal trap 12 in r195146+ in netisr_queue_internal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:18:26 -0000 On Tuesday 21 July 2009 10:33:49 am Kamigishi Rei wrote: > John Baldwin wrote: > > Can you print out 'owner' as well? You won't get a panic until you actually > > dereference 'owner' to get 'owner->td_state' even though gdb will show this > > as the faulting line (gdb can sometimes get confused by compiler > > optimization). You are seeing these values because mtx_lock was changed (due > > to either a mtx_unlock() or a mtx_init()) while you were spinning. That > > value of v is not what I have typically seen in these panics. Do you also > > have the original fatal kernel trap messages? > > > Why does v change to a non-kernel address then? From what I see, it > should never get assigned a value that's not MTX_UNOWNED or > 0xfff......(address,flags). However, I can reproduce this trap in all > revisions starting with 195146 up to 195484 (and probably more, didn't > check yet; at 1956xx these traps stop occurring). v didn't change, it was always the busted value. Somehow mtx_lock was corrupted to the value 0x14ee000 perhaps due to a buffer overflow bug or something else. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 15:21:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4297A106568C; Tue, 21 Jul 2009 15:21:35 +0000 (UTC) (envelope-from wael.nasreddine@gmail.com) Received: from mail-fx0-f214.google.com (mail-fx0-f214.google.com [209.85.220.214]) by mx1.freebsd.org (Postfix) with ESMTP id 51FD88FC18; Tue, 21 Jul 2009 15:21:34 +0000 (UTC) (envelope-from wael.nasreddine@gmail.com) Received: by fxm10 with SMTP id 10so151107fxm.43 for ; Tue, 21 Jul 2009 08:21:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=3EinO1TJ+xaKKUGzyXp/UgI82vO7DPHh5zFrW6gnhjM=; b=vKBijt1wSFzuguPJnhIr/30XPqOCLcrd/fHp7GnMSo0MBTlco6TxHwKNKDWyeM0f1y nUD/9Q7m577FWRe8pEbvvk64mTZyWLsOl/MODzuPMJ628bf1i1/TY7Cu1qsXXKHBYQsb yEsH7Ijj1w3nzOB0C+5DEf7gL9xH5ScxNNDY8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=VBCca+Gvu8Ib8pMhhpCI1HXC8wPVUk4/h4zY45UArfhZZXeYtdRaTXiXGlbfwmWvXO KmhK15FvuORJBHkuYKU15e+XwIwcxSpAiSvsZ8/VQLwvX+KQ8np2T9diX2EzVhfpBZam pUkCvgTVVm8/3NKonTYBwqGVt7cRCCwkg9ByY= MIME-Version: 1.0 Sender: wael.nasreddine@gmail.com Received: by 10.103.8.3 with SMTP id l3mr512738mui.104.1248188306121; Tue, 21 Jul 2009 07:58:26 -0700 (PDT) From: "Wael Nasreddine (a.k.a eMxyzptlk)" Date: Tue, 21 Jul 2009 16:58:06 +0200 X-Google-Sender-Auth: 28580a4a5a93ce3b Message-ID: To: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-hardware@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: FreeBSD + HP Pavilion DV7-1299EF, Pre-install questions. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:21:36 -0000 Hello, I recently bought an HP Pavilion DV7-1299EF, it's 2.4Ghz Core 2 DUO, 4G RAM, 2x250 Gb Hard Disk ------- lspci 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07) 00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express Graphics Port (rev 07) 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03) 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03) 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03) 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03) 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03) 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03) 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 03) 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03) 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 03) 00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 6 (rev 03) 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03) 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03) 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03) 00:1d.3 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03) 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev 03) 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller (rev 03) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03) 01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9600M GT] (rev a1) 02:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) 06:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host Controller 06:00.1 System peripheral: JMicron Technology Corp. SD/MMC Host Controller 06:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host Controller 06:00.3 System peripheral: JMicron Technology Corp. MS Host Controller 06:00.4 System peripheral: JMicron Technology Corp. xD Host Controller ------- lspci What is critical for me is: Wifi: Intel 5100 AGN Graphics: Nvidia Geforce 9600M GT Resolution: 1440x900 Sound: Intel High definition Audio, Codec: IDT 92HD71B7X Since I have 2x250Gb, I would like to use ZFS, I heard FreeBSD can boot from ZFS now, is it stable ? Thanks in advance for your feedback. -- Wael Nasreddine Blog : http://wael.nasreddine.com E-mail : wael.nasreddine@gmail.com gTalk : wael.nasreddine@gmail.com Tel : +33.6.32.94.70.13 Skype : eMxyzptlk Twitter : @eMxyzptlk Sabayon Linux Chief Development Officer - http://www.sabayonlinux.org PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 DE12 5565 3945 C8DD 18A2 .: An infinite number of monkeys typing into GNU emacs, would never make a good program. (L. Torvalds 1995) :. From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 15:29:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 656821065676; Tue, 21 Jul 2009 15:29:17 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 1B7168FC1A; Tue, 21 Jul 2009 15:29:16 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 15DF378F50; Tue, 21 Jul 2009 19:29:15 +0400 (MSD) Message-ID: <4A65DEC6.3020608@haruhiism.net> Date: Tue, 21 Jul 2009 19:29:10 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: John Baldwin References: <4A659F98.2060007@haruhiism.net> <200907211027.06589.jhb@freebsd.org> <4A65D1CD.40006@haruhiism.net> <200907211114.47691.jhb@freebsd.org> In-Reply-To: <200907211114.47691.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Lawrence Stewart , freebsd-current@freebsd.org Subject: Re: [follow-up] Fatal trap 12 in r195146+ in netisr_queue_internal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:29:17 -0000 John Baldwin wrote: > v didn't change, it was always the busted value. Somehow mtx_lock was > corrupted to the value 0x14ee000 perhaps due to a buffer overflow bug or > something else. > I see; I'll try to track where exactly it becomes corrupted, then. Thanks for the input. (Then, I suppose, this corruption remains in the seemingly 'fixed' revisions as it's probably just padded somewhere.) Please forgive my lack of knowledge in concurrent execution related stuff. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 15:34:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CCD071065675; Tue, 21 Jul 2009 15:34:27 +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 9DF048FC13; Tue, 21 Jul 2009 15:34:27 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 4D87F46B03; Tue, 21 Jul 2009 11:34:27 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 8350E8A09D; Tue, 21 Jul 2009 11:34:26 -0400 (EDT) From: John Baldwin To: Kamigishi Rei Date: Tue, 21 Jul 2009 11:31:40 -0400 User-Agent: KMail/1.9.7 References: <4A659F98.2060007@haruhiism.net> <200907211114.47691.jhb@freebsd.org> <4A65DEC6.3020608@haruhiism.net> In-Reply-To: <4A65DEC6.3020608@haruhiism.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907211131.40602.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 21 Jul 2009 11:34:26 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Lawrence Stewart , freebsd-current@freebsd.org Subject: Re: [follow-up] Fatal trap 12 in r195146+ in netisr_queue_internal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 15:34:28 -0000 On Tuesday 21 July 2009 11:29:10 am Kamigishi Rei wrote: > John Baldwin wrote: > > v didn't change, it was always the busted value. Somehow mtx_lock was > > corrupted to the value 0x14ee000 perhaps due to a buffer overflow bug or > > something else. > > > I see; I'll try to track where exactly it becomes corrupted, then. > Thanks for the input. > (Then, I suppose, this corruption remains in the seemingly 'fixed' > revisions as it's probably just padded somewhere.) > > Please forgive my lack of knowledge in concurrent execution related stuff. No problem it can be rather confusing. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 16:18:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2488310656A4 for ; Tue, 21 Jul 2009 16:18:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id AE5588FC1D for ; Tue, 21 Jul 2009 16:18:46 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=r3WUKMxKdxcA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=4bfAtGujcemsf9HRL8sA:9 a=U83WwOpsP_SFX0YDwHbTkAx95NcA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1111251825 for freebsd-current@freebsd.org; Tue, 21 Jul 2009 18:18:45 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 21 Jul 2009 18:18:32 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <200907211439.05703.hselasky@c2i.net> In-Reply-To: <200907211439.05703.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907211818.33531.hselasky@c2i.net> Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:18:47 -0000 On Tuesday 21 July 2009 14:39:05 Hans Petter Selasky wrote: > Hi, > > FreeBSD-8-BETA2 does not boot on MacBookPro5.5. It Freezes during kernel > load. Is anyone working on this? Some more information: The kernel loading process gets to a point where ACPI is about to get initialized. I'm currently tracing a little bit and so far it ends up that AcpiEnable() in "contrib/dev/acpica/events/evxfevnt.c" never returns. Somewhere inside AcpiHwSetMode() something triggers a hardware condition, which I cannot see where ends up. Any lights go up? --HPS From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 16:24:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 884F3106564A for ; Tue, 21 Jul 2009 16:24:20 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) Received: from AurraSing.lando.cc (AurraSing.lando.cc [87.106.187.149]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5CE8FC1E for ; Tue, 21 Jul 2009 16:24:20 +0000 (UTC) (envelope-from uwe@grohnwaldt.eu) X-No-Auth: unauthenticated sender Received: from AurraSing.lando.cc (unknown [127.0.0.1]) by AurraSing.lando.cc (Postfix) with ESMTP id DA9E918B61F42 for ; Tue, 21 Jul 2009 16:04:02 +0000 (UTC) Received: from [192.168.1.175] (unknown [139.30.18.101]) by AurraSing.lando.cc (Postfix) with ESMTP for ; Tue, 21 Jul 2009 16:04:02 +0000 (UTC) Message-ID: <4A65E6EB.50308@grohnwaldt.eu> Date: Tue, 21 Jul 2009 18:03:55 +0200 From: Uwe Grohnwaldt User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: cpufreq on VIA C7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:24:20 -0000 Hi, I have a Jetway J7F5M2H-VDE Mainboard with a VIA C7 2GHz CPU. I installed FreeBSD 7.0-RELEASE and updated it to FreeBSD 8.0 Beta2. On FBSD7 dev.cpu.0.freq shows frequencies up to 2000 MHz under FreeBSD8 only 800. Another problem is, that I have some messages like this in dmesg: NMI ISA 3c, EISA 0 NMI ISA 2c, EISA 0 uname -a output: http://www.bsdmeat.net/~lando/fbsd/viac7/uname.txt dmesg output: http://www.bsdmeat.net/~lando/fbsd/viac7/dmesg.txt pciconf -lv output: http://www.bsdmeat.net/~lando/fbsd/viac7/pciconf.txt Any ideas how to fix this? Thanks. :) Chers, -- Uwe Grohnwaldt Max-Planck-Str. 2A, 1.03.2 18059 Rostock -------------------------- Fon: +49 (0)381 1224811 Mobil: +49 (0)172 3209285 -------------------------- eMail: uwe@grohnwaldt.eu www: http://lando.cc ICQ: 149348486 Skype: lando_calr -------------------------- From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 16:45:11 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id C393C106566B; Tue, 21 Jul 2009 16:45:09 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Tue, 21 Jul 2009 12:45:01 -0400 User-Agent: KMail/1.6.2 References: <200907211439.05703.hselasky@c2i.net> <200907211818.33531.hselasky@c2i.net> In-Reply-To: <200907211818.33531.hselasky@c2i.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907211245.02949.jkim@FreeBSD.org> Cc: Rui Paulo , Hans Petter Selasky Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 16:45:11 -0000 On Tuesday 21 July 2009 12:18 pm, Hans Petter Selasky wrote: > On Tuesday 21 July 2009 14:39:05 Hans Petter Selasky wrote: > > Hi, > > > > FreeBSD-8-BETA2 does not boot on MacBookPro5.5. It Freezes during > > kernel load. Is anyone working on this? > > Some more information: > > The kernel loading process gets to a point where ACPI is about to > get initialized. I'm currently tracing a little bit and so far it > ends up that AcpiEnable() in "contrib/dev/acpica/events/evxfevnt.c" > never returns. Somewhere inside AcpiHwSetMode() something triggers > a hardware condition, which I cannot see where ends up. Any lights > go up? Isn't it a new nVidia chipset system? If so, it is a known problem, reported by rpaulo (CC'ed). Unfortunately, I do not have hardware to debug it. Any way, can you comment out the retry loop in the AcpiHwSetMode() from sys/contrib/dev/acpica/hardware/hwacpi.c and try again? Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 18:43:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B73D106566B for ; Tue, 21 Jul 2009 18:43:56 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 9B9FC8FC16 for ; Tue, 21 Jul 2009 18:43:55 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by yxe11 with SMTP id 11so5204145yxe.3 for ; Tue, 21 Jul 2009 11:43:55 -0700 (PDT) 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=ZeoF7/OuKel5UA0j/xlKqvJdh9AktTatdwWYMKTuG1M=; b=VWOJW2uSYP3RX2gfh34gKE5V4SSieW7WbyEt2wp4CGVAEjqIwbLy6T1u41O3N1siwz fXpsInWk1wck9JCFkTrPHmPEOphxr6XCF8j6wSrZaNY6vsr1NymRT+1+tiaRulSJf42d CHM8l7QEmXnMcaGyWg11lgQslp7uV4D8rU568= 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=erTVRKXFj8P0+78kFS947TnK7mDqIFwwakBcjORlgL+nT2jyf9zXPIk5nLKXKj6CP+ 2E0bpiGW9JTwgvN2sQzNK1rzRLsiYXB64tggOLWWppk48xq8mbaflUferBBDubCNVHTS D8F90iQY2TpYAAo4eT331SmIaeBviTDuFHp6E= MIME-Version: 1.0 Received: by 10.90.86.10 with SMTP id j10mr5041agb.2.1248201834989; Tue, 21 Jul 2009 11:43:54 -0700 (PDT) In-Reply-To: <3a142e750907210146u2ce72cadhbdaa71a89be54607@mail.gmail.com> References: <4A5D27F2.50208@voicenet.com> <19e9a5dc0907191530s679c0b37v49a836cc00bbf58a@mail.gmail.com> <3a142e750907191553u1fd266a4q286e7168b74ee889@mail.gmail.com> <200907201803.32053.gnemmi@gmail.com> <3a142e750907210146u2ce72cadhbdaa71a89be54607@mail.gmail.com> Date: Tue, 21 Jul 2009 15:43:54 -0300 Message-ID: <19e9a5dc0907211143p19e7ea25s79c788fd4c95896a@mail.gmail.com> From: Gonzalo Nemmi To: "Paul B. Mahol" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Adam K Kirchhoff Subject: Re: bge problems when resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 18:43:57 -0000 On Tue, Jul 21, 2009 at 5:46 AM, Paul B. Mahol wrote: > On 7/20/09, Gonzalo Nemmi wrote: > > On Sunday 19 July 2009 7:53:52 pm Paul B. Mahol wrote: > >> On 7/20/09, Gonzalo Nemmi wrote: > >> > On Sat, Jul 18, 2009 at 12:09 AM, Paul B. Mahol > > wrote: > >> >> On 7/17/09, Gonzalo Nemmi wrote: > >> >> > On Wednesday 15 July 2009 8:13:47 am Adam K Kirchhoff wrote: > >> >> >> On Wednesday 15 July 2009 03:20:45 Paul B. Mahol wrote: > >> >> >> > On 7/15/09, Adam K Kirchhoff wrote: > >> >> >> > > Hello all, > >> >> >> > > > >> >> >> > > I have a Dell Latitude D610 laptop with 8.0-BETA1 > >> >> >> > > installed. I hadn't tried suspend/resume for a while and > >> >> >> > > decided to give it a shot. I was pleasantly surprised to > >> >> >> > > see that I could suspend to ram, resume, and have a > >> >> >> > > (relatively) working system (previously the display would > >> >> >> > > never come back up and the serial console I had hooked up > >> >> >> > > remained dead). Great job to everyone who helped make that > >> >> >> > > possible. > >> >> >> > > > >> >> >> > > The only real issue that I seem to have now is that bge is > >> >> >> > > completely unusable after resume. Another individual seems > >> >> >> > > to have reported similar problems with bge and resume, but > >> >> >> > > he also had other issues that apparently trumped his > >> >> >> > > networking issues: > >> >> >> > > > >> >> >> > > http://lists.freebsd.org/pipermail/freebsd-current/2009-Jul > >> >> >> > >y/0090 23.html > >> >> >> > > > >> >> >> > > Like him, resuming from suspend gives me: > >> >> >> > > > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 0, val 32768) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY read timed out > >> >> >> > > (phy 1, reg 0, val 0xffffffff) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 24, val 3072) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 23, val 10) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 21, val 12555) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 23, val 8223) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 21, val 38150) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 23, val 16415) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 21, val 5346) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 24, val 1024) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 24, val 7) > >> >> >> > > > >> >> >> > > And so on and so forth. > >> >> >> > > > >> >> >> > > I thought that compiling if_bge as a module, unloading it > >> >> >> > > before suspend, and reloading it after resume, might get > >> >> >> > > this working. However, doing a "kldload if_bge" after the > >> >> >> > > resume does nothing. Well, the module gets loaded, but the > >> >> >> > > device doesn't show up. No errors from kldload, and there > >> >> >> > > is nothing new in dmesg. > >> >> >> > > > >> >> >> > > Before the suspend, the device shows up as: > >> >> >> > > > >> >> >> > > bge0@pci0:2:0:0: class=3D0x020000 card=3D0x01821028 > >> >> >> > > chip=3D0x167714e4 rev=3D0x01 hdr=3D0x00 > >> >> >> > > vendor =3D 'Broadcom Corporation' > >> >> >> > > device =3D 'NetXtreme Gigabit Ethernet PCI Express > >> >> >> > > (BCM5750A1)' class =3D network > >> >> >> > > subclass =3D ethernet > >> >> >> > > > >> >> >> > > After resuming, and reloading the module, it's: > >> >> >> > > > >> >> >> > > none1@pci0:2:0:0: class=3D0x020000 card=3D0x01821028 > >> >> >> > > chip=3D0x167714e4 rev=3D0x01 hdr=3D0x00 > >> >> >> > > vendor =3D 'Broadcom Corporation' > >> >> >> > > device =3D 'NetXtreme Gigabit Ethernet PCI Express > >> >> >> > > (BCM5750A1)' class =3D network > >> >> >> > > subclass =3D ethernet > >> >> >> > > > >> >> >> > > If there are no ideas, I'll go ahead and open up a pr. I > >> >> >> > > assume this is just one bug, since both problems (the PHY > >> >> >> > > issues and the inability to reload the driver) are both > >> >> >> > > related to the network device. > >> >> >> > > >> >> >> > Put this lines into loader.conf and reboot. > >> >> >> > > >> >> >> > hw.pci.do_power_nodriver=3D"3" > >> >> >> > hw.pci.do_power_resume=3D"1" > >> >> >> > > >> >> >> > Now, before suspend, unload if_bge and some another driver > >> >> >> > (sound drivers are best candidate) and load sound driver > >> >> >> > again, suspend and resume. > >> >> >> > Now loading if_bge should make it succesfully attach. > >> >> >> > >> >> >> Unfortunately, after doing this, reloading the if_bge driver > >> >> >> causes the laptop to completely lock up... It gets as far as: > >> >> >> > >> >> >> bge0: >> >> >> ASIC rev. 0xffff> > >> >> >> mem 0xdfdf0000-0xdfdfffff irq 16 at device 0.0 on pci2 > >> >> >> > >> >> >> And then the entire machine hangs. I'm on ttyv0, so I'd see > >> >> >> any kernel panic, but nothing like that happens. The screen > >> >> >> stays on, but nothing else happens till I force a reboot. > >> >> >> > >> >> >> Adam > >> >> > > >> >> > Hi Adam, Paul ... > >> >> > I'm the "another individual" from you OP. > >> >> > I have the same problems you have regarding bge, but they > >> >> > weren't trumped .. I just had an order of priorities ;) > >> >> > > >> >> > Anyways, I tried the solution Paul posted and, just as in your > >> >> > case, I got a hard lock too ... > >> >> > > >> >> > I tried loading if_bge through /boot/loader.conf > >> >> > Then issued a: > >> >> > > >> >> > kldunload if_bge coretemp > >> >> > >> >> coretemp is wrong module, it must be one of modules that attach to > >> >> pci. > >> > > >> > Sorry Paul! > >> > I gave it a go with snd_hda and I got the same result except that > >> > this time I also got the following message: > >> > >> After unloading snd_hda you loaded it again before suspending? > > > > Doing so yielded a Fatal trap 12 on BETA2. Yesterday I install BETA2 an= d > > here are the results: > Sorry, I meant BETA1 yielded a Fatal trap12, not BETA2 > > > > kldstat > > > > Id Refs Address Size Name > > 1 28 0xc0400000 cf6c70 kernel > > 2 1 0xc10f7000 11bc0 if_bge.ko > > 3 1 0xc1109000 1ac4c snd_hda.ko > > 4 2 0xc1124000 61f78 sound.ko > > 5 1 0xc1186000 2af4 coretemp.ko > > 6 1 0xc1189000 a6d8 i915.ko > > 7 2 0xc1194000 177d4 drm.ko > > > > > > kldunload if_bge snd_hda > > > > Jul 20 17:50:49 gargoyle login: ROOT LOGIN (root) ON ttyv0 > > Jul 20 17:51:06 gargoyle kernel: brgphy0: detached > > Jul 20 17:51:06 gargoyle kernel: lock order reversal: > > Jul 20 17:51:06 gargoyle kernel: 1st 0xc0dba45c kernel linker (kernel > > linker) @ /usr/src/sys/kern/kern_linker.c:1079 > > Jul 20 17:51:06 gargoyle kernel: 2nd 0xc0dbbc64 sysctl lock (sysctl > > lock) @ /usr/src/sys/kern/kern_sysctl.c:257 > > Jul 20 17:51:06 gargoyle kernel: KDB: stack backtrace: > > Jul 20 17:51:06 gargoyle kernel: > > db_trace_self_wrapper(c0c6baf4,e6daba34,c08bc995,c08ad6db,c0c6e989,...) > > at db_trace_self_wrapper+0x26 > > Jul 20 17:51:06 gargoyle kernel: > > kdb_backtrace(c08ad6db,c0c6e989,c452bc88,c4529e10,e6daba90,...) at > > kdb_backtrace+0x29 > > Jul 20 17:51:06 gargoyle kernel: > > _witness_debugger(c0c6e989,c0dbbc64,c0c69667,c4529e10,c0c6956e,...) at > > _witness_debugger+0x25 > > Jul 20 17:51:06 gargoyle kernel: > > witness_checkorder(c0dbbc64,9,c0c6956e,101,0,...) at > > witness_checkorder+0x839 > > Jul 20 17:51:06 gargoyle kernel: > > _sx_xlock(c0dbbc64,0,c0c6956e,101,c4722c00,...) at _sx_xlock+0x85 > > Jul 20 17:51:06 gargoyle kernel: > > sysctl_ctx_free(c4722c4c,c4722c00,e6dabb18,c08a3c85,c4722c00,...) at > > sysctl_ctx_free+0x30 > > Jul 20 17:51:06 gargoyle kernel: > > device_sysctl_fini(c4722c00,0,c0d4c848,c472a810,c4ab3400,...) at > > device_sysctl_fini+0x1a > > Jul 20 17:51:06 gargoyle kernel: > > device_detach(c4722c00,c4722b80,e6dabb38,c06bc622,c4722b80,...) at > > device_detach+0x1f5 > > Jul 20 17:51:06 gargoyle kernel: > > bus_generic_detach(c4722b80,c4722b80,e6dabb64,c08a3b1c,c4722b80,...) at > > bus_generic_detach+0x29 > > Jul 20 17:51:06 gargoyle kernel: > > miibus_detach(c4722b80,c45d6060,c0d4ca68,a3c,c0c76f47,...) at > > miibus_detach+0x12 > > Jul 20 17:51:06 gargoyle kernel: > > device_detach(c4722b80,c472b008,e6dabb98,c10ff7ff,c4722300,...) at > > device_detach+0x8c > > Jul 20 17:51:06 gargoyle kernel: > > bus_generic_detach(c4722300,1,c1104b66,aec,c4722300,...) at > > bus_generic_detach+0x29 > > Jul 20 17:51:06 gargoyle kernel: > > bge_detach(c4722300,c4677060,c0d4ca68,a3c,c4526300,...) at > > bge_detach+0xbf > > Jul 20 17:51:06 gargoyle kernel: > > device_detach(c4722300,c086c843,c0dbb570,c1106c20,c456fb80,...) at > > device_detach+0x8c > > Jul 20 17:51:06 gargoyle kernel: > > driver_module_handler(c4526300,1,c1106c20,109,0,...) at > > driver_module_handler+0x29c > > Jul 20 17:51:06 gargoyle kernel: > > module_unload(c4526300,c0c652ef,273,270,c08604b6,...) at > > module_unload+0x43 > > Jul 20 17:51:06 gargoyle kernel: > > linker_file_unload(c4544200,0,c0c652ef,437,c10f7000,...) at > > linker_file_unload+0x15e > > Jul 20 17:51:06 gargoyle kernel: > > kern_kldunload(c4b346c0,2,0,e6dabd2c,c0ba8dd3,...) at > > kern_kldunload+0xd5 > > Jul 20 17:51:06 gargoyle kernel: > > kldunloadf(c4b346c0,e6dabcf8,8,c0c6fa4b,c0d50450,...) at > > kldunloadf+0x2b > > Jul 20 17:51:06 gargoyle kernel: syscall(e6dabd38) at syscall+0x2a3 > > Jul 20 17:51:06 gargoyle kernel: Xint0x80_syscall() at > > Xint0x80_syscall+0x20 > > Jul 20 17:51:06 gargoyle kernel: --- syscall (444, FreeBSD ELF32, > > kldunloadf), eip =3D 0x280d516b, esp =3D 0xbfbfe47c, ebp =3D 0xbfbfecc8= --- > > Jul 20 17:51:06 gargoyle kernel: miibus0: detached > > Jul 20 17:51:06 gargoyle kernel: bge0: detached > > Jul 20 17:51:06 gargoyle kernel: sysctl_unregister_oid: failed to > > unregister sysctl > > if_bge driver looks very problematic to me. Probably it can not detach at > all. > Could be .. will have to recompile the kernel and use if_bge as a module to see what happens ... I just read a mail from =D8yvind Rakv=E5g saying he is experiencing a freez= e when setting bge0 to UP: http://lists.freebsd.org/pipermail/freebsd-current/2009-July/009677.html Maybe bge needs some care :s > > Jul 20 17:51:06 gargoyle kernel: pcm0: detached > > Jul 20 17:51:06 gargoyle kernel: hdac0: detached > > > > > > kld snd_hda > ^^^ > You mean kldload. > Yes, sorry Paul, I guess I typed too fast :s > > > > > Jul 20 17:52:16 gargoyle kernel: hdac0: > Audio Controller> mem 0xf6dfc000-0xf6dfffff irq 21 at device 27.0 on > > pci0 > > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Driver Revision: > > 20090624_0136 > > Jul 20 17:52:16 gargoyle kernel: hdac0: [ITHREAD] > > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel STAC9228= X > > Jul 20 17:52:16 gargoyle kernel: bge0: > 0xc002> mem 0xf69f0000-0xf69fffff irq 17 at device 0.0 on pci9 > > Jul 20 17:52:16 gargoyle kernel: miibus0: on bge0 > > Jul 20 17:52:16 gargoyle kernel: brgphy0: PH= Y > > 1 on miibus0 > > Jul 20 17:52:16 gargoyle kernel: brgphy0: 10baseT, 10baseT-FDX, > > 100baseTX, 100baseTX-FDX, auto > > Jul 20 17:52:16 gargoyle kernel: bge0: Ethernet address: > > 00:23:ae:04:ba:ca > > Jul 20 17:52:16 gargoyle kernel: bge0: [ITHREAD] > > Jul 20 17:52:16 gargoyle kernel: pcm0: > Analog> at cad 0 nid 1 on hdac0 > > Jul 20 17:52:16 gargoyle kernel: bge0: link state changed to DOWN > > Jul 20 17:52:18 gargoyle kernel: bge0: link state changed to UP > > Why bge0 appeared again? > Really don=B4t know ... That=B4s what happened after issuing a kldload snd_hda. > > > > > acpiconf -s 3 > > After this command bge0 should not appear at all because it should not > be attached to > device. > > > > > Jul 20 17:53:51 gargoyle acpi: suspend at 20090720 17:53:51 > > Jul 20 17:53:56 gargoyle kernel: fwohci0: fwohci_pci_suspend > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 0, val 32768) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg 0= , > > val 0xffffffff) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > > 24, val 0xffffffff) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > > 16, val 0xffffffff) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 16, val 0) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, reg > > 16, val 0xffffffff) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 16, val 0) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, reg > > 23, val 18) > > Jul 20 17:54:25 gargoyle kernel: bge0: flow-through queue init failed > > Jul 20 17:54:25 gargoyle kernel: bge0: initialization failure > > Jul 20 17:54:25 gargoyle kernel: fwohci0: Phy 1394a available S400, 1 > > ports. > > Jul 20 17:54:25 gargoyle kernel: fwohci0: Link S400, max_rec 2048 bytes= . > > Jul 20 17:54:25 gargoyle kernel: fwohci0: Initiate bus reset > > Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: BUS reset > > Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: > > node_id=3D0x00000000, SelfID Count=3D1, CYCLEMASTER mode > > Jul 20 17:54:25 gargoyle kernel: firewire0: 1 nodes, maxhop <=3D 0 cabl= e > > IRM irm(0) (me) > > Jul 20 17:54:25 gargoyle kernel: firewire0: bus manager 0 > > Jul 20 17:54:25 gargoyle kernel: fwohci0: unrecoverable error > > Jul 20 17:54:25 gargoyle kernel: wakeup from sleeping state (slept > > 00:00:29) > > Jul 20 17:54:25 gargoyle acpi: resumed at 20090720 17:54:25 > > > > Should a PR on fwohci and firewire also be filed?? > > Try with custom kernel with smaller number of drivers as possible. > (use modules instead) Will do. I=B4be been trying to avoid that in order to test with a custom kernel. Will recompile GENERIC commenting out if_bge only, load it via loader.conf and test it to see what happens. > From your mail I dont see where is problem with firewire. > OK ... I filed a PR on fwohhci (unrecoverable error) though, if I shouldn= =B4t have done that, sorry for the noise then, I don=B4t have firewire devices t= o test it: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D136946 Best Regards Gonzalo From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 18:53:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF1F4106566C for ; Tue, 21 Jul 2009 18:53:00 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 86CB18FC08 for ; Tue, 21 Jul 2009 18:53:00 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n6LIqxK9020555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 21 Jul 2009 14:52:59 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n6LIqxK9020555 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1248202379; bh=RNPxJlBsykS9D04+sJdozUPZSlwgRSaXQ0L8XeEzF5k=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=ALBxdkIdUI18rJC5tLOgKDNLIJXRYQBJb+BKjPp9AluK5P5NW/kfahQAqKrpjl+QP mgEbJ+F8gX6vxNRO1xZcHtJu76BHa/IaCcUEb00UA6F4CbDFKTgIek2bF9TG/L/1BE AOLapaqySZezOFp47fSR8V1oCBL8Slr4CBPb3hv0= Message-ID: <4A660E83.6080004@cs.duke.edu> Date: Tue, 21 Jul 2009 14:52:51 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: loader.conf ignores setting variable ending in _type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 18:53:01 -0000 Hi, I maintain the mxge (10GbE) driver. A user complained to me that one of my driver's tunables was ignored when he set it in /boot/loader.conf. I reproduced his problem both on -current and 7.2. I think there may be some quirk which is causing the loader to ignore this variable, but my 4th skills are non-existent, and I'm looking for some help. To reproduce this bug, I used a loader.conf which looks like this: console=comconsole if_mxge_load="YES" mxge_eth_z8e_load="YES" mxge_rss_eth_z8e_load="YES" hw.mxge.rss_hash_type="2" hw.mxge.max_slices="2" After interrupting the boot, I could confirm that rss_hash_type was not set: .................................................................. Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel] in 8 seconds... Type '?' for a list of commands, 'help' for more detailed help. OK show hw.mxge.max_slices 2 OK show hw.mxge.rss_hash_type variable 'hw.mxge.rss_hash_type' not found ................................................................... I have no problem setting hw.mxge.rss_hash_type while the machine is up via kenv. Also, it seems to stick when set manually from the loader. After poking around for quite a while, I noticed that the loader refuses to honor any variable ending in _type loaded from loader.conf. Is this because the suffix "_type" (for module_type) is somehow reserved and I should not be using a tunable ending in _type Or is this a bug in the loader? Thanks, Drew From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 19:06:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CE46106566B; Tue, 21 Jul 2009 19:06:39 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 445788FC14; Tue, 21 Jul 2009 19:06:39 +0000 (UTC) (envelope-from qingli@FreeBSD.org) Received: from freefall.freebsd.org (qingli@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n6LJ6d2Q035928; Tue, 21 Jul 2009 19:06:39 GMT (envelope-from qingli@freefall.freebsd.org) Received: (from qingli@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n6LJ6dvu035927; Tue, 21 Jul 2009 19:06:39 GMT (envelope-from qingli) Date: Tue, 21 Jul 2009 19:06:39 GMT From: Qing Li Message-Id: <200907211906.n6LJ6dvu035927@freefall.freebsd.org> To: current@freebsd.org Cc: net@freebsd.org Subject: useloopback sysctl vars X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 19:06:39 -0000 Hi, Does anyone set either of the following systl variables to 0? net.link.ether.inet.useloopback net.inet6.icmp6.nd6_useloopback If so, would you mind letting me know your reasons? Thanks, -- Qing From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 19:32:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95DA41065689 for ; Tue, 21 Jul 2009 19:32:38 +0000 (UTC) (envelope-from David.Boyd@insightbb.com) Received: from mxsf08.insightbb.com (mxsf08.insightbb.com [74.128.0.78]) by mx1.freebsd.org (Postfix) with ESMTP id 61C4A8FC1A for ; Tue, 21 Jul 2009 19:32:38 +0000 (UTC) (envelope-from David.Boyd@insightbb.com) X-IronPort-AV: E=Sophos;i="4.43,242,1246852800"; d="scan'208";a="723196466" Received: from unknown (HELO asav00.insightbb.com) ([172.31.249.123]) by mxsf08.insightbb.com with ESMTP; 21 Jul 2009 15:32:37 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEANy0ZUpKgYcH/2dsb2JhbACLCMdmCYQDBYFA X-IronPort-AV: E=Sophos;i="4.43,242,1246852800"; d="scan'208";a="88890473" Received: from 74-129-135-7.dhcp.insightbb.com (HELO sneezy) ([74.129.135.7]) by asav00.insightbb.com with SMTP; 21 Jul 2009 15:32:37 -0400 From: "David Boyd" To: Date: Tue, 21 Jul 2009 15:32:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Importance: Normal Subject: 8.0-BETA2 sysinstall ignoring setting of nonInteractive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 19:32:38 -0000 With 8.0-BETA(1/2) sysinstall ignores setting of nonInteractive variable when using USB-based install. With or without nonInteractive sysinstall issues message "Using USB device: da0a" and waits for confirmation. This breaks unattended installations using USB device. Thanks. From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 20:04:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74B12106564A for ; Tue, 21 Jul 2009 20:04:23 +0000 (UTC) (envelope-from jordan@ostreff.info) Received: from SD84.btc-net.bg (SD84.btc-net.bg [212.39.90.84]) by mx1.freebsd.org (Postfix) with SMTP id 005C68FC08 for ; Tue, 21 Jul 2009 20:04:22 +0000 (UTC) (envelope-from jordan@ostreff.info) Received: (qmail 18033 invoked from network); 21 Jul 2009 19:36:19 -0000 Received: from unknown (HELO ?192.168.0.117?) (83.228.0.108) by 0 with SMTP; 21 Jul 2009 19:36:19 -0000 Message-ID: <4A6618AE.7030704@ostreff.info> Date: Tue, 21 Jul 2009 22:36:14 +0300 From: Jordan Ostreff User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: freebsd 8.0 beta 2 problem with wpi wireless card X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 20:04:23 -0000 Dear All, please note problems with 8.0b2 running on compaq nc6320 laptop and wpi wireless driver and wpi_supplicant. 7.2-stable runs well - only problem with acpi_tz0 :( From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 20:05:48 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id A82F71065687; Tue, 21 Jul 2009 20:05:47 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Tue, 21 Jul 2009 16:05:34 -0400 User-Agent: KMail/1.6.2 References: <4A660E83.6080004@cs.duke.edu> In-Reply-To: <4A660E83.6080004@cs.duke.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907211605.40390.jkim@FreeBSD.org> Cc: Andrew Gallatin Subject: Re: loader.conf ignores setting variable ending in _type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 20:05:48 -0000 On Tuesday 21 July 2009 02:52 pm, Andrew Gallatin wrote: > Hi, > > I maintain the mxge (10GbE) driver. A user complained to me > that one of my driver's tunables was ignored when he set it > in /boot/loader.conf. I reproduced his problem both on -current > and 7.2. I think there may be some quirk which is causing the > loader to ignore this variable, but my 4th skills are non-existent, > and I'm looking for some help. > > To reproduce this bug, I used a loader.conf which > looks like this: > > console=comconsole > if_mxge_load="YES" > mxge_eth_z8e_load="YES" > mxge_rss_eth_z8e_load="YES" > hw.mxge.rss_hash_type="2" > hw.mxge.max_slices="2" > > > > After interrupting the boot, I could confirm that rss_hash_type > was not set: > > .................................................................. > Hit [Enter] to boot immediately, or any other key for command > prompt. Booting [/boot/kernel/kernel] in 8 seconds... > > Type '?' for a list of commands, 'help' for more detailed help. > OK show hw.mxge.max_slices > 2 > OK show hw.mxge.rss_hash_type > variable 'hw.mxge.rss_hash_type' not found > ................................................................... > > I have no problem setting hw.mxge.rss_hash_type while the machine > is up via kenv. Also, it seems to stick when set manually from the > loader. > > > After poking around for quite a while, I noticed that the loader > refuses to honor any variable ending in _type loaded from > loader.conf. > > Is this because the suffix "_type" (for module_type) is somehow > reserved and I should not be using a tunable ending in _type > Or is this a bug in the loader? Yes, it is reserved. loader.conf(5): *_type Defines the module's type. If none is given, it defaults to a kld module. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 20:17:48 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 0907E1065672; Tue, 21 Jul 2009 20:17:48 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Tue, 21 Jul 2009 16:17:37 -0400 User-Agent: KMail/1.6.2 References: <4A660E83.6080004@cs.duke.edu> <200907211605.40390.jkim@FreeBSD.org> In-Reply-To: <200907211605.40390.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907211617.40842.jkim@FreeBSD.org> Cc: Andrew Gallatin Subject: Re: loader.conf ignores setting variable ending in _type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 20:17:48 -0000 On Tuesday 21 July 2009 04:05 pm, Jung-uk Kim wrote: > On Tuesday 21 July 2009 02:52 pm, Andrew Gallatin wrote: > > Hi, > > > > I maintain the mxge (10GbE) driver. A user complained to me > > that one of my driver's tunables was ignored when he set it > > in /boot/loader.conf. I reproduced his problem both on -current > > and 7.2. I think there may be some quirk which is causing the > > loader to ignore this variable, but my 4th skills are > > non-existent, and I'm looking for some help. > > > > To reproduce this bug, I used a loader.conf which > > looks like this: > > > > console=comconsole > > if_mxge_load="YES" > > mxge_eth_z8e_load="YES" > > mxge_rss_eth_z8e_load="YES" > > hw.mxge.rss_hash_type="2" > > hw.mxge.max_slices="2" > > > > > > > > After interrupting the boot, I could confirm that rss_hash_type > > was not set: > > > > ................................................................. > >. Hit [Enter] to boot immediately, or any other key for command > > prompt. Booting [/boot/kernel/kernel] in 8 seconds... > > > > Type '?' for a list of commands, 'help' for more detailed help. > > OK show hw.mxge.max_slices > > 2 > > OK show hw.mxge.rss_hash_type > > variable 'hw.mxge.rss_hash_type' not found > > ................................................................. > >.. > > > > I have no problem setting hw.mxge.rss_hash_type while the machine > > is up via kenv. Also, it seems to stick when set manually from > > the loader. > > > > > > After poking around for quite a while, I noticed that the loader > > refuses to honor any variable ending in _type loaded from > > loader.conf. > > > > Is this because the suffix "_type" (for module_type) is somehow > > reserved and I should not be using a tunable ending in _type > > Or is this a bug in the loader? > > Yes, it is reserved. > > loader.conf(5): > > *_type Defines the module's type. If none is given, it > defaults to a kld module. Actually, I wanted to quote this: loader.conf(5): WARNING: developers should never use these suffixes for any kernel environment variables (tunables) or conflicts will result. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 20:42:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9BA021065673 for ; Tue, 21 Jul 2009 20:42:01 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swipnet.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6818FC18 for ; Tue, 21 Jul 2009 20:41:59 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=r3WUKMxKdxcA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=IqRyCCmQSM234rmcadIA:9 a=l3y96eTnMTPDfWqKlYb_A-JnolYA:4 a=VwQbUJbxAAAA:8 a=20KFwNOVAAAA:8 a=s3sy5F8t62LoYHicDr4A:9 a=aVZCJrg_hw2lrovNhOQA:7 a=yQjRnvaAOhwjlFJYDek0S8irdvMA:4 a=N_fhyN0FbgoA:10 a=jEp0ucaQiEUA:10 a=OesCmeDwpcCqy-c-:21 a=boNZIAGy0VE1O4ED:21 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1110569908; Tue, 21 Jul 2009 22:41:58 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 21 Jul 2009 22:41:43 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <200907211439.05703.hselasky@c2i.net> <200907211818.33531.hselasky@c2i.net> <200907211245.02949.jkim@FreeBSD.org> In-Reply-To: <200907211245.02949.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_JgiZKk5ZjQNCemB" Message-Id: <200907212241.45704.hselasky@c2i.net> Cc: Rui Paulo , Jung-uk Kim Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 20:42:01 -0000 --Boundary-00=_JgiZKk5ZjQNCemB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Tuesday 21 July 2009 18:45:01 Jung-uk Kim wrote: > On Tuesday 21 July 2009 12:18 pm, Hans Petter Selasky wrote: > > On Tuesday 21 July 2009 14:39:05 Hans Petter Selasky wrote: > > > Hi, > > > > > > FreeBSD-8-BETA2 does not boot on MacBookPro5.5. It Freezes during > > > kernel load. Is anyone working on this? > > > > Some more information: > > > > The kernel loading process gets to a point where ACPI is about to > > get initialized. I'm currently tracing a little bit and so far it > > ends up that AcpiEnable() in "contrib/dev/acpica/events/evxfevnt.c" > > never returns. Somewhere inside AcpiHwSetMode() something triggers > > a hardware condition, which I cannot see where ends up. Any lights > > go up? > > Isn't it a new nVidia chipset system? If so, it is a known problem, > reported by rpaulo (CC'ed). Unfortunately, I do not have hardware to > debug it. Any way, can you comment out the retry loop in the > AcpiHwSetMode() from sys/contrib/dev/acpica/hardware/hwacpi.c and try > again? The system hangs before the while loop. Adding more debugging I found out it hangs exactly at the call to AcpiHwWritePort(): Status = AcpiHwWritePort (AcpiGbl_FADT.SmiCommand, (UINT32) AcpiGbl_FADT.AcpiEnable, 8); I've attached dmesg from Ubuntu 9.x booting on the same machine. Anything more you want me to try? --HPS --Boundary-00=_JgiZKk5ZjQNCemB Content-Type: text/plain; charset="iso-8859-1"; name="mac_dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mac_dmesg.txt" [ 0.000000] BIOS EBDA/lowmem at: 0009fc00/0009fc00 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Linux version 2.6.28-11-generic (buildd@palmer) (gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4) ) #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 (Ubuntu 2.6.28-11.42-generic) [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] AMD AuthenticAMD [ 0.000000] NSC Geode by NSC [ 0.000000] Cyrix CyrixInstead [ 0.000000] Centaur CentaurHauls [ 0.000000] Transmeta GenuineTMx86 [ 0.000000] Transmeta TransmetaCPU [ 0.000000] UMC UMC UMC UMC [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) [ 0.000000] BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 000000006e72b000 (usable) [ 0.000000] BIOS-e820: 000000006e72b000 - 000000006e92c000 (ACPI NVS) [ 0.000000] BIOS-e820: 000000006e92c000 - 000000006f000000 (ACPI data) [ 0.000000] BIOS-e820: 000000006f000000 - 000000007f000000 (reserved) [ 0.000000] BIOS-e820: 000000007f000000 - 000000007f0c3000 (ACPI data) [ 0.000000] BIOS-e820: 000000007f0c3000 - 000000007f0c5000 (ACPI NVS) [ 0.000000] BIOS-e820: 000000007f0c5000 - 000000007f0c7000 (ACPI data) [ 0.000000] BIOS-e820: 000000007f0c7000 - 000000007f0c9000 (ACPI NVS) [ 0.000000] BIOS-e820: 000000007f0c9000 - 000000007fec5000 (ACPI data) [ 0.000000] BIOS-e820: 000000007fec5000 - 000000007fec7000 (ACPI NVS) [ 0.000000] BIOS-e820: 000000007fec7000 - 000000007fec8000 (ACPI data) [ 0.000000] BIOS-e820: 000000007fec8000 - 000000007feca000 (ACPI NVS) [ 0.000000] BIOS-e820: 000000007feca000 - 000000007fecd000 (ACPI data) [ 0.000000] BIOS-e820: 000000007fecd000 - 000000007fedf000 (ACPI NVS) [ 0.000000] BIOS-e820: 000000007fedf000 - 000000007fef9000 (ACPI data) [ 0.000000] BIOS-e820: 000000007fef9000 - 000000007feff000 (reserved) [ 0.000000] BIOS-e820: 000000007feff000 - 000000007ff00000 (ACPI data) [ 0.000000] BIOS-e820: 0000000093400000 - 0000000093401000 (reserved) [ 0.000000] BIOS-e820: 00000000f0000000 - 00000000f4000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] DMI 2.4 present. [ 0.000000] last_pfn = 0x6e72b max_arch_pfn = 0x100000 [ 0.000000] Scanning 2 areas for low memory corruption [ 0.000000] modified physical RAM map: [ 0.000000] modified: 0000000000000000 - 0000000000002000 (usable) [ 0.000000] modified: 0000000000002000 - 0000000000006000 (reserved) [ 0.000000] modified: 0000000000006000 - 0000000000007000 (usable) [ 0.000000] modified: 0000000000007000 - 0000000000010000 (reserved) [ 0.000000] modified: 0000000000010000 - 0000000000092c00 (usable) [ 0.000000] modified: 000000000009fc00 - 00000000000a0000 (reserved) [ 0.000000] modified: 00000000000e0000 - 0000000000100000 (reserved) [ 0.000000] modified: 0000000000100000 - 000000006e72b000 (usable) [ 0.000000] modified: 000000006e72b000 - 000000006e92c000 (ACPI NVS) [ 0.000000] modified: 000000006e92c000 - 000000006f000000 (ACPI data) [ 0.000000] modified: 000000006f000000 - 000000007f000000 (reserved) [ 0.000000] modified: 000000007f000000 - 000000007f0c3000 (ACPI data) [ 0.000000] modified: 000000007f0c3000 - 000000007f0c5000 (ACPI NVS) [ 0.000000] modified: 000000007f0c5000 - 000000007f0c7000 (ACPI data) [ 0.000000] modified: 000000007f0c7000 - 000000007f0c9000 (ACPI NVS) [ 0.000000] modified: 000000007f0c9000 - 000000007fec5000 (ACPI data) [ 0.000000] modified: 000000007fec5000 - 000000007fec7000 (ACPI NVS) [ 0.000000] modified: 000000007fec7000 - 000000007fec8000 (ACPI data) [ 0.000000] modified: 000000007fec8000 - 000000007feca000 (ACPI NVS) [ 0.000000] modified: 000000007feca000 - 000000007fecd000 (ACPI data) [ 0.000000] modified: 000000007fecd000 - 000000007fedf000 (ACPI NVS) [ 0.000000] modified: 000000007fedf000 - 000000007fef9000 (ACPI data) [ 0.000000] modified: 000000007fef9000 - 000000007feff000 (reserved) [ 0.000000] modified: 000000007feff000 - 000000007ff00000 (ACPI data) [ 0.000000] modified: 0000000093400000 - 0000000093401000 (reserved) [ 0.000000] modified: 00000000f0000000 - 00000000f4000000 (reserved) [ 0.000000] modified: 00000000fec00000 - 00000000fec01000 (reserved) [ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] modified: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] kernel direct mapping tables up to 373fe000 @ 10000-16000 [ 0.000000] RAMDISK: 6df9c000 - 6e6ff993 [ 0.000000] Allocated new RAMDISK: 00881000 - 00fe4993 [ 0.000000] Move RAMDISK from 000000006df9c000 - 000000006e6ff992 to 00881000 - 00fe4992 [ 0.000000] ACPI: RSDP 000FE020, 0024 (r2 APPLE ) [ 0.000000] ACPI: XSDT 7FEEE1C0, 007C (r1 APPLE Apple00 AC 1000013) [ 0.000000] ACPI: FACP 7FEEC000, 00F4 (r4 APPLE Apple00 AC Loki 5F) [ 0.000000] ACPI: DSDT 7FEDF000, 5B9E (r1 APPLE MacBookP 50005 INTL 20061109) [ 0.000000] ACPI: FACS 7FECD000, 0040 [ 0.000000] ACPI: HPET 7FEEB000, 0038 (r1 APPLE Apple00 1 Loki 5F) [ 0.000000] ACPI: APIC 7FEEA000, 0068 (r1 APPLE Apple00 1 Loki 5F) [ 0.000000] ACPI: APIC 7FEE9000, 0068 (r2 APPLE Apple00 1 Loki 5F) [ 0.000000] ACPI: MCFG 7FEE8000, 003C (r1 APPLE Apple00 1 Loki 5F) [ 0.000000] ACPI: ASF! 7FEE7000, 00A5 (r32 APPLE Apple00 1 Loki 5F) [ 0.000000] ACPI: SBST 7FEE6000, 0030 (r1 APPLE Apple00 1 Loki 5F) [ 0.000000] ACPI: ECDT 7FEE5000, 0053 (r1 APPLE Apple00 1 Loki 5F) [ 0.000000] ACPI: SSDT 7FEC7000, 04DC (r1 APPLE CpuPm 3000 INTL 20061109) [ 0.000000] ACPI: SSDT 7FECC000, 00A5 (r1 SataRe SataPri 1000 INTL 20061109) [ 0.000000] ACPI: SSDT 7FECB000, 009F (r1 SataRe SataSec 1000 INTL 20061109) [ 0.000000] ACPI: BIOS bug: multiple APIC/MADT found, using 0 [ 0.000000] ACPI: If "acpi_apic_instance=2" works better, notify linux-acpi@vger.kernel.org [ 0.000000] ACPI: DMI BIOS year==0, assuming ACPI-capable machine [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] 883MB HIGHMEM available. [ 0.000000] 883MB LOWMEM available. [ 0.000000] mapped low ram: 0 - 373fe000 [ 0.000000] low ram: 00000000 - 373fe000 [ 0.000000] bootmap 00012000 - 00018e80 [ 0.000000] (9 early reservations) ==> bootmem [0000000000 - 00373fe000] [ 0.000000] #0 [0000000000 - 0000001000] BIOS data page ==> [0000000000 - 0000001000] [ 0.000000] #1 [0000001000 - 0000002000] EX TRAMPOLINE ==> [0000001000 - 0000002000] [ 0.000000] #2 [0000006000 - 0000007000] TRAMPOLINE ==> [0000006000 - 0000007000] [ 0.000000] #3 [0000100000 - 000087c52c] TEXT DATA BSS ==> [0000100000 - 000087c52c] [ 0.000000] #4 [000087d000 - 0000881000] INIT_PG_TABLE ==> [000087d000 - 0000881000] [ 0.000000] #5 [000009fc00 - 0000100000] BIOS reserved ==> [000009fc00 - 0000100000] [ 0.000000] #6 [0000010000 - 0000012000] PGTABLE ==> [0000010000 - 0000012000] [ 0.000000] #7 [0000881000 - 0000fe4993] NEW RAMDISK ==> [0000881000 - 0000fe4993] [ 0.000000] #8 [0000012000 - 0000019000] BOOTMAP ==> [0000012000 - 0000019000] [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0x00000000 -> 0x00001000 [ 0.000000] Normal 0x00001000 -> 0x000373fe [ 0.000000] HighMem 0x000373fe -> 0x0006e72b [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[4] active PFN ranges [ 0.000000] 0: 0x00000000 -> 0x00000002 [ 0.000000] 0: 0x00000006 -> 0x00000007 [ 0.000000] 0: 0x00000010 -> 0x00000092 [ 0.000000] 0: 0x00000100 -> 0x0006e72b [ 0.000000] On node 0 totalpages: 452272 [ 0.000000] free_area_init_node: node 0, pgdat c06d0f80, node_mem_map c1000000 [ 0.000000] DMA zone: 32 pages used for memmap [ 0.000000] DMA zone: 0 pages reserved [ 0.000000] DMA zone: 3941 pages, LIFO batch:0 [ 0.000000] Normal zone: 1736 pages used for memmap [ 0.000000] Normal zone: 220470 pages, LIFO batch:31 [ 0.000000] HighMem zone: 1767 pages used for memmap [ 0.000000] HighMem zone: 224326 pages, LIFO batch:31 [ 0.000000] Movable zone: 0 pages used for memmap [ 0.000000] ACPI: PM-Timer IO Port: 0x408 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs [ 0.000000] ACPI: HPET id: 0x10de8201 base: 0xfed00000 [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] SMP: Allowing 2 CPUs, 0 hotplug CPUs [ 0.000000] PM: Registered nosave memory: 0000000000002000 - 0000000000006000 [ 0.000000] PM: Registered nosave memory: 0000000000007000 - 0000000000010000 [ 0.000000] PM: Registered nosave memory: 0000000000092000 - 00000000000a0000 [ 0.000000] PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000 [ 0.000000] PM: Registered nosave memory: 00000000000e0000 - 0000000000100000 [ 0.000000] Allocating PCI resources starting at 98000000 (gap: 93401000:5cbff000) [ 0.000000] PERCPU: Allocating 45056 bytes of per cpu data [ 0.000000] NR_CPUS: 64, nr_cpu_ids: 2, nr_node_ids 1 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 448737 [ 0.000000] Kernel command line: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed boot=casper initrd=/casper/initrd.gz quiet splash -- [ 0.000000] Enabling fast FPU save and restore... done. [ 0.000000] Enabling unmasked SIMD FPU exception support... done. [ 0.000000] Initializing CPU#0 [ 0.000000] xsave/xrstor: enabled xstate_bv 0x3, cntxt size 0x240 [ 0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes) [ 0.000000] Extended CMOS year: 2000 [ 0.000000] Fast TSC calibration using PIT [ 0.000000] Detected 2255.598 MHz processor. [ 0.004000] spurious 8259A interrupt: IRQ7. [ 0.004000] Console: colour VGA+ 80x25 [ 0.004000] console [tty0] enabled [ 0.004000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [ 0.004000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [ 0.004000] allocated 9047900 bytes of page_cgroup [ 0.004000] please try cgroup_disable=memory option if you don't want [ 0.004000] Scanning for low memory corruption every 60 seconds [ 0.004000] Memory: 1769080k/1809580k available (4126k kernel code, 39180k reserved, 2208k data, 532k init, 904372k highmem) [ 0.004000] virtual kernel memory layout: [ 0.004000] fixmap : 0xffc77000 - 0xfffff000 (3616 kB) [ 0.004000] pkmap : 0xff400000 - 0xff800000 (4096 kB) [ 0.004000] vmalloc : 0xf7bfe000 - 0xff3fe000 ( 120 MB) [ 0.004000] lowmem : 0xc0000000 - 0xf73fe000 ( 883 MB) [ 0.004000] .init : 0xc0737000 - 0xc07bc000 ( 532 kB) [ 0.004000] .data : 0xc0507a6f - 0xc072fe60 (2208 kB) [ 0.004000] .text : 0xc0100000 - 0xc0507a6f (4126 kB) [ 0.004000] Checking if this processor honours the WP bit even in supervisor mode...Ok. [ 0.004000] SLUB: Genslabs=12, HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [ 0.004000] hpet clockevent registered [ 0.004000] HPET: 4 timers in total, 0 timers will be used for per-cpu timer [ 0.004000] Calibrating delay loop (skipped), value calculated using timer frequency.. 4511.19 BogoMIPS (lpj=9022392) [ 0.004000] Security Framework initialized [ 0.004000] SELinux: Disabled at boot. [ 0.004000] AppArmor: AppArmor initialized [ 0.004000] Mount-cache hash table entries: 512 [ 0.004000] Initializing cgroup subsys ns [ 0.004000] Initializing cgroup subsys cpuacct [ 0.004000] Initializing cgroup subsys memory [ 0.004000] Initializing cgroup subsys freezer [ 0.004000] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.004000] CPU: L2 cache: 3072K [ 0.004000] CPU: Physical Processor ID: 0 [ 0.004000] CPU: Processor Core ID: 0 [ 0.004000] using mwait in idle threads. [ 0.004000] Checking 'hlt' instruction... OK. [ 0.018274] ACPI: Core revision 20080926 [ 0.020444] ACPI: Checking initramfs for custom DSDT [ 0.292859] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1 [ 0.332557] CPU0: Intel(R) Core(TM)2 Duo CPU P7550 @ 2.26GHz stepping 0a [ 0.336001] Booting processor 1 APIC 0x1 ip 0x6000 [ 0.004000] Initializing CPU#1 [ 0.004000] Calibrating delay using timer specific routine.. 4510.61 BogoMIPS (lpj=9021230) [ 0.004000] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.004000] CPU: L2 cache: 3072K [ 0.004000] CPU: Physical Processor ID: 0 [ 0.004000] CPU: Processor Core ID: 1 [ 0.420561] CPU1: Intel(R) Core(TM)2 Duo CPU P7550 @ 2.26GHz stepping 0a [ 0.420578] checking TSC synchronization [CPU#0 -> CPU#1]: passed. [ 0.424031] Brought up 2 CPUs [ 0.424033] Total of 2 processors activated (9021.81 BogoMIPS). [ 0.424098] CPU0 attaching sched-domain: [ 0.424100] domain 0: span 0-1 level MC [ 0.424102] groups: 0 1 [ 0.424107] CPU1 attaching sched-domain: [ 0.424109] domain 0: span 0-1 level MC [ 0.424110] groups: 1 0 [ 0.424170] net_namespace: 776 bytes [ 0.424170] Booting paravirtualized kernel on bare hardware [ 0.424279] Time: 18:34:04 Date: 07/21/09 [ 0.424279] regulator: core version 0.5 [ 0.424279] NET: Registered protocol family 16 [ 0.424279] EISA bus registered [ 0.424279] ACPI: bus type pci registered [ 0.424453] PCI: MCFG configuration 0: base f0000000 segment 0 buses 0 - 255 [ 0.424456] PCI: MCFG area at f0000000 reserved in E820 [ 0.424458] PCI: updated MCFG configuration 0: base f0000000 segment 0 buses 0 - 63 [ 0.424460] PCI: Using MMCONFIG for extended config space [ 0.424461] PCI: Using configuration type 1 for base access [ 0.425177] ACPI: EC: EC description table is found, configuring boot EC [ 0.425237] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 0.430089] ACPI: BIOS _OSI(Linux) query ignored [ 0.430699] ACPI: Interpreter enabled [ 0.430703] ACPI: (supports S0 S3 S4 S5) [ 0.432016] ACPI: Using IOAPIC for interrupt routing [ 0.452324] ACPI: EC: GPE = 0x3f, I/O: command/status = 0x66, data = 0x62 [ 0.452326] ACPI: EC: driver started in interrupt mode [ 0.452538] ACPI: No dock devices found. [ 0.452548] ACPI: PCI Root Bridge [PCI0] (0000:00) [ 0.452764] pci 0000:00:03.0: reg 10 io port: [0x2000-0x20ff] [ 0.452859] pci 0000:00:03.2: reg 10 io port: [0x2180-0x21bf] [ 0.452872] pci 0000:00:03.2: reg 20 io port: [0x2140-0x217f] [ 0.452877] pci 0000:00:03.2: reg 24 io port: [0x2100-0x213f] [ 0.452889] pci 0000:00:03.2: PME# supported from D3hot D3cold [ 0.452894] pci 0000:00:03.2: PME# disabled [ 0.453048] pci 0000:00:03.5: reg 10 32bit mmio: [0x93400000-0x9347ffff] [ 0.453131] pci 0000:00:04.0: reg 10 32bit mmio: [0x93488000-0x93488fff] [ 0.453155] pci 0000:00:04.0: supports D1 D2 [ 0.453157] pci 0000:00:04.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.453160] pci 0000:00:04.0: PME# disabled [ 0.453187] pci 0000:00:04.1: reg 10 32bit mmio: [0x93489200-0x934892ff] [ 0.453213] pci 0000:00:04.1: supports D1 D2 [ 0.453214] pci 0000:00:04.1: PME# supported from D0 D1 D2 D3hot D3cold [ 0.453218] pci 0000:00:04.1: PME# disabled [ 0.453248] pci 0000:00:06.0: reg 10 32bit mmio: [0x93487000-0x93487fff] [ 0.453272] pci 0000:00:06.0: supports D1 D2 [ 0.453274] pci 0000:00:06.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.453277] pci 0000:00:06.0: PME# disabled [ 0.453305] pci 0000:00:06.1: reg 10 32bit mmio: [0x93489100-0x934891ff] [ 0.453331] pci 0000:00:06.1: supports D1 D2 [ 0.453333] pci 0000:00:06.1: PME# supported from D0 D1 D2 D3hot D3cold [ 0.453336] pci 0000:00:06.1: PME# disabled [ 0.453366] pci 0000:00:08.0: reg 10 32bit mmio: [0x93480000-0x93483fff] [ 0.453391] pci 0000:00:08.0: PME# supported from D3hot D3cold [ 0.453394] pci 0000:00:08.0: PME# disabled [ 0.453445] pci 0000:00:0a.0: reg 10 32bit mmio: [0x93486000-0x93486fff] [ 0.453449] pci 0000:00:0a.0: reg 14 io port: [0x21e0-0x21e7] [ 0.453453] pci 0000:00:0a.0: reg 18 32bit mmio: [0x93489000-0x934890ff] [ 0.453457] pci 0000:00:0a.0: reg 1c 32bit mmio: [0x93489300-0x9348930f] [ 0.453471] pci 0000:00:0a.0: supports D1 D2 [ 0.453473] pci 0000:00:0a.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.453477] pci 0000:00:0a.0: PME# disabled [ 0.453504] pci 0000:00:0b.0: reg 10 io port: [0x21d8-0x21df] [ 0.453508] pci 0000:00:0b.0: reg 14 io port: [0x21ec-0x21ef] [ 0.453512] pci 0000:00:0b.0: reg 18 io port: [0x21d0-0x21d7] [ 0.453516] pci 0000:00:0b.0: reg 1c io port: [0x21e8-0x21eb] [ 0.453520] pci 0000:00:0b.0: reg 20 io port: [0x21c0-0x21cf] [ 0.453524] pci 0000:00:0b.0: reg 24 32bit mmio: [0x93484000-0x93485fff] [ 0.453568] pci 0000:00:10.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.453571] pci 0000:00:10.0: PME# disabled [ 0.453711] pci 0000:00:15.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.453718] pci 0000:00:15.0: PME# disabled [ 0.453879] pci 0000:00:16.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.453886] pci 0000:00:16.0: PME# disabled [ 0.453966] pci 0000:00:09.0: transparent bridge [ 0.453971] pci 0000:00:09.0: bridge 32bit mmio: [0x93300000-0x933fffff] [ 0.454004] pci 0000:02:00.0: reg 10 32bit mmio: [0x92000000-0x92ffffff] [ 0.454014] pci 0000:02:00.0: reg 14 64bit mmio: [0x80000000-0x8fffffff] [ 0.454023] pci 0000:02:00.0: reg 1c 64bit mmio: [0x90000000-0x91ffffff] [ 0.454029] pci 0000:02:00.0: reg 24 io port: [0x1000-0x107f] [ 0.454034] pci 0000:02:00.0: reg 30 32bit mmio: [0x93000000-0x9301ffff] [ 0.454078] pci 0000:00:10.0: bridge io port: [0x1000-0x1fff] [ 0.454081] pci 0000:00:10.0: bridge 32bit mmio: [0x92000000-0x930fffff] [ 0.454085] pci 0000:00:10.0: bridge 64bit mmio pref: [0x80000000-0x91ffffff] [ 0.454294] pci 0000:03:00.0: reg 10 64bit mmio: [0x93200000-0x93203fff] [ 0.454329] pci 0000:03:00.0: supports D1 D2 [ 0.454331] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold [ 0.454335] pci 0000:03:00.0: PME# disabled [ 0.454405] pci 0000:00:15.0: bridge 32bit mmio: [0x93200000-0x932fffff] [ 0.454471] pci 0000:04:00.0: reg 10 64bit mmio: [0x93100000-0x93100fff] [ 0.454508] pci 0000:04:00.0: supports D1 D2 [ 0.454509] pci 0000:04:00.0: PME# supported from D0 D1 D2 D3hot D3cold [ 0.454514] pci 0000:04:00.0: PME# disabled [ 0.454581] pci 0000:00:16.0: bridge 32bit mmio: [0x93100000-0x931fffff] [ 0.454626] bus 00 -> node 0 [ 0.454632] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.455105] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.IXVE._PRT] [ 0.512195] ACPI: PCI Interrupt Link [LNK1] (IRQs 5 7 10 11 14 15) *0, disabled. [ 0.512454] ACPI: PCI Interrupt Link [LNK2] (IRQs 5 7 10 11 14 15) *0, disabled. [ 0.512710] ACPI: PCI Interrupt Link [LNK3] (IRQs 5 7 10 11 14 15) *0, disabled. [ 0.512967] ACPI: PCI Interrupt Link [LNK4] (IRQs 5 7 10 11 14 15) *0, disabled. [ 0.513227] ACPI: PCI Interrupt Link [Z003] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.513486] ACPI: PCI Interrupt Link [Z004] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.513744] ACPI: PCI Interrupt Link [Z005] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.514002] ACPI: PCI Interrupt Link [Z006] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.514261] ACPI: PCI Interrupt Link [Z007] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.514519] ACPI: PCI Interrupt Link [Z008] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.514777] ACPI: PCI Interrupt Link [Z009] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.515035] ACPI: PCI Interrupt Link [Z00A] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.515292] ACPI: PCI Interrupt Link [Z00B] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.515550] ACPI: PCI Interrupt Link [Z00C] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.515808] ACPI: PCI Interrupt Link [Z00D] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.516079] ACPI: PCI Interrupt Link [Z00E] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.516337] ACPI: PCI Interrupt Link [Z00F] (IRQs 16 17 18 19 20 21 22 23) *10 [ 0.516595] ACPI: PCI Interrupt Link [Z00G] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.516853] ACPI: PCI Interrupt Link [Z00H] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.517111] ACPI: PCI Interrupt Link [Z00I] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.517369] ACPI: PCI Interrupt Link [Z00J] (IRQs 16 17 18 19 20 21 22 23) *7 [ 0.517627] ACPI: PCI Interrupt Link [Z00K] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.517886] ACPI: PCI Interrupt Link [Z00L] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.518144] ACPI: PCI Interrupt Link [Z00M] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.518403] ACPI: PCI Interrupt Link [Z00N] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.518662] ACPI: PCI Interrupt Link [Z00O] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.518921] ACPI: PCI Interrupt Link [Z00P] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.519179] ACPI: PCI Interrupt Link [Z00Q] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.519437] ACPI: PCI Interrupt Link [Z00R] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.519695] ACPI: PCI Interrupt Link [Z00S] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.519953] ACPI: PCI Interrupt Link [Z00T] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.520225] ACPI: PCI Interrupt Link [Z00U] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.520484] ACPI: PCI Interrupt Link [LSMB] (IRQs 16 17 18 19 20 21 22 23) *15 [ 0.520740] ACPI: PCI Interrupt Link [LUS0] (IRQs 16 17 18 19 20 21 22 23) *11 [ 0.520998] ACPI: PCI Interrupt Link [LUS2] (IRQs 16 17 18 19 20 21 22 23) *10 [ 0.521257] ACPI: PCI Interrupt Link [LMAC] (IRQs 16 17 18 19 20 21 22 23) *14 [ 0.521514] ACPI: PCI Interrupt Link [LAZA] (IRQs 16 17 18 19 20 21 22 23) *15 [ 0.521774] ACPI: PCI Interrupt Link [LGPU] (IRQs 16 17 18 19 20 21 22 23) *11 [ 0.522032] ACPI: PCI Interrupt Link [LPID] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.522290] ACPI: PCI Interrupt Link [LSI0] (IRQs 16 17 18 19 20 21 22 23) *11 [ 0.522550] ACPI: PCI Interrupt Link [LSI1] (IRQs 16 17 18 19 20 21 22 23) *0, disabled. [ 0.522809] ACPI: PCI Interrupt Link [Z000] (IRQs 16 17 18 19 20 21 22 23) *7 [ 0.523070] ACPI: PCI Interrupt Link [Z001] (IRQs 16 17 18 19 20 21 22 23) *5 [ 0.523331] ACPI: PCI Interrupt Link [LPMU] (IRQs 16 17 18 19 20 21 22 23) *14 [ 0.523570] ACPI: WMI: Mapper loaded [ 0.523599] SCSI subsystem initialized [ 0.523599] libata version 3.00 loaded. [ 0.523599] usbcore: registered new interface driver usbfs [ 0.523599] usbcore: registered new interface driver hub [ 0.523599] usbcore: registered new device driver usb [ 0.523599] PCI: Using ACPI for IRQ routing [ 0.528009] Bluetooth: Core ver 2.13 [ 0.528018] NET: Registered protocol family 31 [ 0.528018] Bluetooth: HCI device and connection manager initialized [ 0.528018] Bluetooth: HCI socket layer initialized [ 0.528018] NET: Registered protocol family 8 [ 0.528018] NET: Registered protocol family 20 [ 0.528027] NetLabel: Initializing [ 0.528029] NetLabel: domain hash size = 128 [ 0.528030] NetLabel: protocols = UNLABELED CIPSOv4 [ 0.528041] NetLabel: unlabeled traffic allowed by default [ 0.528054] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 31, 31 [ 0.528058] hpet0: 4 comparators, 64-bit 25.000000 MHz counter [ 0.532046] AppArmor: AppArmor Filesystem Enabled [ 0.536007] Switched to high resolution mode on CPU 0 [ 0.536612] Switched to high resolution mode on CPU 1 [ 0.540008] pnp: PnP ACPI init [ 0.540014] ACPI: bus type pnp registered [ 0.551412] pnp: PnP ACPI: found 8 devices [ 0.551414] ACPI: ACPI bus type pnp unregistered [ 0.551417] PnPBIOS: Disabled by ACPI PNP [ 0.551425] system 00:01: iomem range 0xf0000000-0xf3ffffff has been reserved [ 0.551431] system 00:04: iomem range 0xfed00000-0xfed003ff has been reserved [ 0.551436] system 00:06: ioport range 0x400-0x47f has been reserved [ 0.551438] system 00:06: ioport range 0x480-0x4ff has been reserved [ 0.551440] system 00:06: ioport range 0x500-0x57f has been reserved [ 0.551442] system 00:06: ioport range 0x580-0x5ff has been reserved [ 0.551444] system 00:06: ioport range 0x800-0x87f has been reserved [ 0.551446] system 00:06: ioport range 0x880-0x8ff has been reserved [ 0.551449] system 00:06: ioport range 0x4d0-0x4d1 has been reserved [ 0.551451] system 00:06: ioport range 0x295-0x296 has been reserved [ 0.586119] pci 0000:00:09.0: PCI bridge, secondary bus 0000:01 [ 0.586121] pci 0000:00:09.0: IO window: disabled [ 0.586125] pci 0000:00:09.0: MEM window: 0x93300000-0x933fffff [ 0.586128] pci 0000:00:09.0: PREFETCH window: disabled [ 0.586132] pci 0000:00:10.0: PCI bridge, secondary bus 0000:02 [ 0.586134] pci 0000:00:10.0: IO window: 0x1000-0x1fff [ 0.586138] pci 0000:00:10.0: MEM window: 0x92000000-0x930fffff [ 0.586141] pci 0000:00:10.0: PREFETCH window: 0x00000080000000-0x00000091ffffff [ 0.586145] pci 0000:00:15.0: PCI bridge, secondary bus 0000:03 [ 0.586146] pci 0000:00:15.0: IO window: disabled [ 0.586156] pci 0000:00:15.0: MEM window: 0x93200000-0x932fffff [ 0.586163] pci 0000:00:15.0: PREFETCH window: disabled [ 0.586176] pci 0000:00:16.0: PCI bridge, secondary bus 0000:04 [ 0.586177] pci 0000:00:16.0: IO window: disabled [ 0.586187] pci 0000:00:16.0: MEM window: 0x93100000-0x931fffff [ 0.586194] pci 0000:00:16.0: PREFETCH window: disabled [ 0.586208] pci 0000:00:09.0: enabling device (0000 -> 0002) [ 0.586214] pci 0000:00:09.0: setting latency timer to 64 [ 0.586219] pci 0000:00:10.0: setting latency timer to 64 [ 0.586590] ACPI: PCI Interrupt Link [Z00F] enabled at IRQ 23 [ 0.586595] pci 0000:00:15.0: PCI INT A -> Link[Z00F] -> GSI 23 (level, low) -> IRQ 23 [ 0.586603] pci 0000:00:15.0: setting latency timer to 64 [ 0.586970] ACPI: PCI Interrupt Link [Z00J] enabled at IRQ 22 [ 0.586974] pci 0000:00:16.0: PCI INT A -> Link[Z00J] -> GSI 22 (level, low) -> IRQ 22 [ 0.586982] pci 0000:00:16.0: setting latency timer to 64 [ 0.586987] bus: 00 index 0 io port: [0x00-0xffff] [ 0.586989] bus: 00 index 1 mmio: [0x000000-0xffffffff] [ 0.586991] bus: 01 index 0 mmio: [0x0-0x0] [ 0.586993] bus: 01 index 1 mmio: [0x93300000-0x933fffff] [ 0.586995] bus: 01 index 2 mmio: [0x0-0x0] [ 0.586996] bus: 01 index 3 io port: [0x00-0xffff] [ 0.586998] bus: 01 index 4 mmio: [0x000000-0xffffffff] [ 0.587000] bus: 02 index 0 io port: [0x1000-0x1fff] [ 0.587001] bus: 02 index 1 mmio: [0x92000000-0x930fffff] [ 0.587003] bus: 02 index 2 mmio: [0x80000000-0x91ffffff] [ 0.587004] bus: 02 index 3 mmio: [0x0-0x0] [ 0.587006] bus: 03 index 0 mmio: [0x0-0x0] [ 0.587008] bus: 03 index 1 mmio: [0x93200000-0x932fffff] [ 0.587009] bus: 03 index 2 mmio: [0x0-0x0] [ 0.587011] bus: 03 index 3 mmio: [0x0-0x0] [ 0.587012] bus: 04 index 0 mmio: [0x0-0x0] [ 0.587014] bus: 04 index 1 mmio: [0x93100000-0x931fffff] [ 0.587015] bus: 04 index 2 mmio: [0x0-0x0] [ 0.587017] bus: 04 index 3 mmio: [0x0-0x0] [ 0.587023] NET: Registered protocol family 2 [ 0.600041] IP route cache hash table entries: 32768 (order: 5, 131072 bytes) [ 0.600233] TCP established hash table entries: 131072 (order: 8, 1048576 bytes) [ 0.600511] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [ 0.600655] TCP: Hash tables configured (established 131072 bind 65536) [ 0.600657] TCP reno registered [ 0.604050] NET: Registered protocol family 1 [ 0.604143] checking if image is initramfs... it is [ 1.153844] Freeing initrd memory: 7566k freed [ 1.154016] cpufreq: No nForce2 chipset. [ 1.154134] audit: initializing netlink socket (disabled) [ 1.154154] type=2000 audit(1248201244.152:1): initialized [ 1.160552] highmem bounce pool size: 64 pages [ 1.160556] HugeTLB registered 4 MB page size, pre-allocated 0 pages [ 1.161658] VFS: Disk quotas dquot_6.5.1 [ 1.161706] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [ 1.162204] fuse init (API version 7.10) [ 1.162273] msgmni has been set to 1705 [ 1.162412] alg: No test for stdrng (krng) [ 1.162421] io scheduler noop registered [ 1.162422] io scheduler anticipatory registered [ 1.162424] io scheduler deadline registered [ 1.162435] io scheduler cfq registered (default) [ 1.176176] pci 0000:02:00.0: Boot video device [ 1.193522] pcieport-driver 0000:00:15.0: setting latency timer to 64 [ 1.193679] pcieport-driver 0000:00:15.0: found MSI capability [ 1.193766] pcieport-driver 0000:00:15.0: irq 2303 for MSI/MSI-X [ 1.193801] pci_express 0000:00:15.0:pcie00: allocate port service [ 1.193970] pcieport-driver 0000:00:16.0: setting latency timer to 64 [ 1.194125] pcieport-driver 0000:00:16.0: found MSI capability [ 1.194209] pcieport-driver 0000:00:16.0: irq 2302 for MSI/MSI-X [ 1.194243] pci_express 0000:00:16.0:pcie00: allocate port service [ 1.194386] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 1.194393] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 1.194502] ACPI: AC Adapter [ADP1] (on-line) [ 1.342799] ACPI: Battery Slot [BAT0] (battery present) [ 1.342858] input: Power Button (FF) as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 [ 1.342860] ACPI: Power Button (FF) [PWRF] [ 1.342895] input: Lid Switch as /devices/LNXSYSTM:00/device:00/PNP0C0D:00/input/input1 [ 1.342956] ACPI: Lid Switch [LID0] [ 1.342994] input: Power Button (CM) as /devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input2 [ 1.342996] ACPI: Power Button (CM) [PWRB] [ 1.343029] input: Sleep Button (CM) as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input3 [ 1.343032] ACPI: Sleep Button (CM) [SLPB] [ 1.343667] ACPI: SSDT 7FEC9C18, 027A (r1 APPLE Cpu0Ist 3000 INTL 20061109) [ 1.344031] ACPI: SSDT 7FEC9918, 02AD (r1 APPLE Cpu0Cst 3001 INTL 20061109) [ 1.344439] Monitor-Mwait will be used to enter C-1 state [ 1.344442] Monitor-Mwait will be used to enter C-2 state [ 1.344444] Monitor-Mwait will be used to enter C-3 state [ 1.344456] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3]) [ 1.344475] processor ACPI_CPU:00: registered as cooling_device0 [ 1.344479] ACPI: Processor [CPU0] (supports 8 throttling states) [ 1.344765] ACPI: SSDT 7FEC9F18, 00C8 (r1 APPLE Cpu1Ist 3000 INTL 20061109) [ 1.345098] ACPI: SSDT 7FEC8F18, 0085 (r1 APPLE Cpu1Cst 3000 INTL 20061109) [ 1.345613] ACPI: CPU1 (power states: C1[C1] C2[C2] C3[C3]) [ 1.345629] processor ACPI_CPU:01: registered as cooling_device1 [ 1.345632] ACPI: Processor [CPU1] (supports 8 throttling states) [ 1.364513] isapnp: Scanning for PnP cards... [ 1.717195] isapnp: No Plug & Play device found [ 1.729203] Serial: 8250/16550 driver4 ports, IRQ sharing enabled [ 1.729992] brd: module loaded [ 1.730248] loop: module loaded [ 1.730298] Fixed MDIO Bus: probed [ 1.730303] PPP generic driver version 2.4.2 [ 1.730346] input: Macintosh mouse button emulation as /devices/virtual/input/input4 [ 1.730369] Driver 'sd' needs updating - please use bus_type methods [ 1.730376] Driver 'sr' needs updating - please use bus_type methods [ 1.730408] ahci 0000:00:0b.0: version 3.0 [ 1.730782] ACPI: PCI Interrupt Link [LSI0] enabled at IRQ 21 [ 1.730788] ahci 0000:00:0b.0: PCI INT A -> Link[LSI0] -> GSI 21 (level, low) -> IRQ 21 [ 1.730820] ahci 0000:00:0b.0: irq 2301 for MSI/MSI-X [ 1.730874] ahci 0000:00:0b.0: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3 impl IDE mode [ 1.730877] ahci 0000:00:0b.0: flags: 64bit ncq sntf pm led pmp pio slum part [ 1.730880] ahci 0000:00:0b.0: setting latency timer to 64 [ 1.731021] scsi0 : ahci [ 1.731086] scsi1 : ahci [ 1.731132] scsi2 : ahci [ 1.731176] scsi3 : ahci [ 1.731220] scsi4 : ahci [ 1.731264] scsi5 : ahci [ 1.731354] ata1: SATA max UDMA/133 abar m8192@0x93484000 port 0x93484100 irq 2301 [ 1.731356] ata2: SATA max UDMA/133 abar m8192@0x93484000 port 0x93484180 irq 2301 [ 1.731358] ata3: DUMMY [ 1.731359] ata4: DUMMY [ 1.731360] ata5: DUMMY [ 1.731361] ata6: DUMMY [ 2.212011] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 2.212317] ata1.00: ATA-8: FUJITSU MJA2160BH FFS G1, 0081001D, max UDMA/100 [ 2.212319] ata1.00: 312581808 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 2.212688] ata1.00: configured for UDMA/100 [ 3.116008] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [ 3.118317] ata2.00: ATAPI: MATSHITADVD-R UJ-868, KB19, max UDMA/66, ATAPI AN [ 3.120800] ata2.00: configured for UDMA/66 [ 3.136110] scsi 0:0:0:0: Direct-Access ATA FUJITSU MJA2160B 0081 PQ: 0 ANSI: 5 [ 3.136182] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors: (160 GB/149 GiB) [ 3.136195] sd 0:0:0:0: [sda] Write Protect is off [ 3.136197] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 3.136217] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 3.136265] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors: (160 GB/149 GiB) [ 3.136276] sd 0:0:0:0: [sda] Write Protect is off [ 3.136278] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 3.136298] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 3.136301] sda: sda1 sda2 sda3 [ 3.506909] sd 0:0:0:0: [sda] Attached SCSI disk [ 3.506943] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 3.508866] scsi 1:0:0:0: CD-ROM MATSHITA DVD-R UJ-868 KB19 PQ: 0 ANSI: 5 [ 3.511044] sr0: scsi3-mmc drive: 24x/24x writer cd/rw xa/form2 cdda tray [ 3.511046] Uniform CD-ROM driver Revision: 3.20 [ 3.511115] sr 1:0:0:0: Attached scsi CD-ROM sr0 [ 3.511145] sr 1:0:0:0: Attached scsi generic sg1 type 5 [ 3.511689] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.512081] ACPI: PCI Interrupt Link [LUS2] enabled at IRQ 20 [ 3.512086] ehci_hcd 0000:00:04.1: PCI INT B -> Link[LUS2] -> GSI 20 (level, low) -> IRQ 20 [ 3.512096] ehci_hcd 0000:00:04.1: setting latency timer to 64 [ 3.512099] ehci_hcd 0000:00:04.1: EHCI Host Controller [ 3.512146] ehci_hcd 0000:00:04.1: new USB bus registered, assigned bus number 1 [ 3.512166] ehci_hcd 0000:00:04.1: debug port 1 [ 3.512170] ehci_hcd 0000:00:04.1: cache line size of 32 is not supported [ 3.512182] ehci_hcd 0000:00:04.1: irq 20, io mem 0x93489200 [ 3.524008] ehci_hcd 0000:00:04.1: USB 2.0 started, EHCI 1.00 [ 3.524065] usb usb1: configuration #1 chosen from 1 choice [ 3.524087] hub 1-0:1.0: USB hub found [ 3.524093] hub 1-0:1.0: 7 ports detected [ 3.524540] ACPI: PCI Interrupt Link [Z001] enabled at IRQ 19 [ 3.524544] ehci_hcd 0000:00:06.1: PCI INT B -> Link[Z001] -> GSI 19 (level, low) -> IRQ 19 [ 3.524553] ehci_hcd 0000:00:06.1: setting latency timer to 64 [ 3.524555] ehci_hcd 0000:00:06.1: EHCI Host Controller [ 3.524589] ehci_hcd 0000:00:06.1: new USB bus registered, assigned bus number 2 [ 3.524608] ehci_hcd 0000:00:06.1: debug port 1 [ 3.524612] ehci_hcd 0000:00:06.1: cache line size of 32 is not supported [ 3.524623] ehci_hcd 0000:00:06.1: irq 19, io mem 0x93489100 [ 3.536008] ehci_hcd 0000:00:06.1: USB 2.0 started, EHCI 1.00 [ 3.536061] usb usb2: configuration #1 chosen from 1 choice [ 3.536083] hub 2-0:1.0: USB hub found [ 3.536089] hub 2-0:1.0: 5 ports detected [ 3.536160] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.536529] ACPI: PCI Interrupt Link [LUS0] enabled at IRQ 18 [ 3.536533] ohci_hcd 0000:00:04.0: PCI INT A -> Link[LUS0] -> GSI 18 (level, low) -> IRQ 18 [ 3.536542] ohci_hcd 0000:00:04.0: setting latency timer to 64 [ 3.536544] ohci_hcd 0000:00:04.0: OHCI Host Controller [ 3.536578] ohci_hcd 0000:00:04.0: new USB bus registered, assigned bus number 3 [ 3.536596] ohci_hcd 0000:00:04.0: irq 18, io mem 0x93488000 [ 3.594033] usb usb3: configuration #1 chosen from 1 choice [ 3.594054] hub 3-0:1.0: USB hub found [ 3.594060] hub 3-0:1.0: 7 ports detected [ 3.594487] ACPI: PCI Interrupt Link [Z000] enabled at IRQ 17 [ 3.594492] ohci_hcd 0000:00:06.0: PCI INT A -> Link[Z000] -> GSI 17 (level, low) -> IRQ 17 [ 3.594500] ohci_hcd 0000:00:06.0: setting latency timer to 64 [ 3.594502] ohci_hcd 0000:00:06.0: OHCI Host Controller [ 3.594536] ohci_hcd 0000:00:06.0: new USB bus registered, assigned bus number 4 [ 3.594553] ohci_hcd 0000:00:06.0: irq 17, io mem 0x93487000 [ 3.650030] usb usb4: configuration #1 chosen from 1 choice [ 3.650050] hub 4-0:1.0: USB hub found [ 3.650057] hub 4-0:1.0: 5 ports detected [ 3.650127] uhci_hcd: USB Universal Host Controller Interface driver [ 3.650168] usbcore: registered new interface driver libusual [ 3.650191] usbcore: registered new interface driver usbserial [ 3.650199] USB Serial support registered for generic [ 3.650210] usbcore: registered new interface driver usbserial_generic [ 3.650212] usbserial: USB Serial Driver core [ 3.650251] PNP: No PS/2 controller found. Probing ports directly. [ 3.651114] i8042.c: No controller found. [ 3.651220] mice: PS/2 mouse device common for all mice [ 3.651371] rtc_cmos 00:07: RTC can wake from S4 [ 3.651397] rtc_cmos 00:07: rtc core: registered rtc_cmos as rtc0 [ 3.651444] rtc0: alarms up to one year, y3k, 242 bytes nvram, hpet irqs [ 3.651486] device-mapper: uevent: version 1.0.3 [ 3.651552] device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com [ 3.651605] device-mapper: multipath: version 1.0.5 loaded [ 3.651607] device-mapper: multipath round-robin: version 1.0.0 loaded [ 3.651667] EISA: Probing bus 0 at eisa.0 [ 3.651671] Cannot allocate resource for EISA slot 1 [ 3.651673] Cannot allocate resource for EISA slot 2 [ 3.651689] EISA: Detected 0 cards. [ 3.651779] cpuidle: using governor ladder [ 3.651874] cpuidle: using governor menu [ 3.652286] TCP cubic registered [ 3.652364] NET: Registered protocol family 10 [ 3.652701] lo: Disabled Privacy Extensions [ 3.652973] NET: Registered protocol family 17 [ 3.652987] Bluetooth: L2CAP ver 2.11 [ 3.652989] Bluetooth: L2CAP socket layer initialized [ 3.652991] Bluetooth: SCO (Voice Link) ver 0.6 [ 3.652993] Bluetooth: SCO socket layer initialized [ 3.653020] Bluetooth: RFCOMM socket layer initialized [ 3.653024] Bluetooth: RFCOMM TTY layer initialized [ 3.653026] Bluetooth: RFCOMM ver 1.10 [ 3.653047] Marking TSC unstable due to TSC halts in idle [ 3.653662] Using IPI No-Shortcut mode [ 3.653715] registered taskstats version 1 [ 3.653805] Magic number: 1:523:595 [ 3.653904] rtc_cmos 00:07: setting system clock to 2009-07-21 18:34:07 UTC (1248201247) [ 3.653907] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found [ 3.653908] EDD information not available. [ 3.654159] Freeing unused kernel memory: 532k freed [ 3.654284] Write protecting the kernel text: 4128k [ 3.654333] Write protecting the kernel read-only data: 1532k [ 3.840021] usb 1-4: new high speed USB device using ehci_hcd and address 2 [ 3.915891] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61. [ 3.916325] ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 16 [ 3.916333] forcedeth 0000:00:0a.0: PCI INT A -> Link[LMAC] -> GSI 16 (level, low) -> IRQ 16 [ 3.916337] forcedeth 0000:00:0a.0: setting latency timer to 64 [ 3.917117] forcedeth 0000:00:0a.0: ifname eth0, PHY OUI 0x732 @ 1, addr 00:25:4b:cd:5a:7e [ 3.917120] forcedeth 0000:00:0a.0: highdma csum pwrctl mgmt timirq gbit lnktim msi desc-v3 [ 3.952289] ohci1394 0000:04:00.0: PCI INT A -> Link[Z00J] -> GSI 22 (level, low) -> IRQ 22 [ 3.952296] ohci1394 0000:04:00.0: setting latency timer to 64 [ 3.979609] usb 1-4: configuration #1 chosen from 1 choice [ 4.004016] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[22] MMIO=[93100000-931007ff] Max Packet=[4096] IR/IT contexts=[8/8] [ 4.385953] usb 2-5: new high speed USB device using ehci_hcd and address 3 [ 4.521455] usb 2-5: configuration #1 chosen from 1 choice [ 4.536423] Initializing USB Mass Storage driver... [ 4.548062] scsi6 : SCSI emulation for USB Mass Storage devices [ 4.548507] usbcore: registered new interface driver usb-storage [ 4.548509] USB Mass Storage support registered. [ 4.548563] usb-storage: device found at 3 [ 4.548565] usb-storage: waiting for device to settle before scanning [ 4.836034] usb 4-1: new full speed USB device using ohci_hcd and address 2 [ 5.000042] Clocksource tsc unstable (delta = -65895898 ns) [ 5.062175] usb 4-1: configuration #1 chosen from 1 choice [ 5.065144] hub 4-1:1.0: USB hub found [ 5.068105] hub 4-1:1.0: 3 ports detected [ 5.280507] ieee1394: Host added: ID:BUS[0-00:1023] GUID[00254bfffecd5a7e] [ 5.384108] usb 3-5: new low speed USB device using ohci_hcd and address 2 [ 5.600170] usb 3-5: configuration #1 chosen from 1 choice [ 5.611119] usbcore: registered new interface driver hiddev [ 5.611159] usbcore: registered new interface driver usbhid [ 5.611161] usbhid: v2.6:USB HID core driver [ 5.625076] apple 0003:05AC:8242.0001: hiddev96,hidraw0: USB HID v1.11 Device [Apple Computer, Inc. IR Receiver] on usb-0000:00:04.0-5/input0 [ 5.772323] ISO 9660 Extensions: Microsoft Joliet Level 3 [ 5.825029] ISO 9660 Extensions: RRIP_1991A [ 5.908107] usb 3-6: new full speed USB device using ohci_hcd and address 3 [ 6.132167] usb 3-6: configuration #1 chosen from 1 choice [ 6.144546] input: Apple Inc. Apple Internal Keyboard / Trackpad as /devices/pci0000:00/0000:00:04.0/usb3/3-6/3-6:1.0/input/input5 [ 6.149157] apple 0003:05AC:0237.0002: input,hidraw1: USB HID v1.11 Keyboard [Apple Inc. Apple Internal Keyboard / Trackpad] on usb-0000:00:04.0-6/input0 [ 6.185393] aufs 20080922 [ 6.500505] squashfs: version 3.3 (2007/10/31) Phillip Lougher [ 6.648151] apple 0003:05AC:0237.0003: hidraw2: USB HID v1.11 Device [Apple Inc. Apple Internal Keyboard / Trackpad] on usb-0000:00:04.0-6/input1 [ 6.658307] input: Apple Inc. Apple Internal Keyboard / Trackpad as /devices/pci0000:00/0000:00:04.0/usb3/3-6/3-6:1.2/input/input6 [ 6.660508] apple 0003:05AC:0237.0004: input,hidraw3: USB HID v1.11 Mouse [Apple Inc. Apple Internal Keyboard / Trackpad] on usb-0000:00:04.0-6/input2 [ 6.738098] usb 4-1.1: new full speed USB device using ohci_hcd and address 3 [ 6.862158] usb 4-1.1: configuration #1 chosen from 1 choice [ 9.548606] usb-storage: device scan complete [ 9.550925] scsi 6:0:0:0: Direct-Access APPLE SD Card Reader 1.00 PQ: 0 ANSI: 0 [ 9.552460] sd 6:0:0:0: [sdb] Attached SCSI removable disk [ 9.552514] sd 6:0:0:0: Attached scsi generic sg2 type 0 [ 79.371052] udev: starting version 141 [ 80.297632] ieee80211_crypt: registered algorithm 'NULL' [ 80.300158] wl: module license '' taints kernel. [ 80.301914] wl 0000:03:00.0: power state changed by ACPI to D0 [ 80.302079] wl 0000:03:00.0: PCI INT A -> Link[Z00F] -> GSI 23 (level, low) -> IRQ 23 [ 80.302084] wl 0000:03:00.0: setting latency timer to 64 [ 81.653880] input: PC Speaker as /devices/platform/pcspkr/input/input7 [ 81.755211] Bluetooth: Generic Bluetooth USB driver ver 0.3 [ 81.755317] usbcore: registered new interface driver btusb [ 81.759598] ieee80211_crypt: registered algorithm 'TKIP' [ 81.760078] eth1: Broadcom BCM432b 802.11 Wireless Controller 5.10.79.10 [ 82.098448] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 [ 82.418140] Linux video capture interface: v2.00 [ 82.484333] applesmc: Apple MacBook Pro 5 detected: [ 82.484336] applesmc: - Model with accelerometer [ 82.484337] applesmc: - Model with light sensors and backlight [ 82.484339] applesmc: - Model with 20 temperature sensors [ 82.485406] applesmc: device has already been initialized (0xe0, 0xf8). [ 82.485408] applesmc: device successfully initialized. [ 82.486071] applesmc: 1 fans found. [ 82.488101] input: applesmc as /devices/platform/applesmc.768/input/input8 [ 82.496142] Registered led device: smc::kbd_backlight [ 82.496160] applesmc: driver successfully loaded. [ 82.695691] uvcvideo: Found UVC 1.00 device Built-in iSight (05ac:8507) [ 82.696957] input: Built-in iSight as /devices/pci0000:00/0000:00:04.1/usb1/1-4/1-4:1.0/input/input9 [ 82.698311] usbcore: registered new interface driver uvcvideo [ 82.698332] USB Video Class driver (v0.1.0) [ 83.082966] ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 23 [ 83.082971] HDA Intel 0000:00:08.0: PCI INT A -> Link[LAZA] -> GSI 23 (level, low) -> IRQ 23 [ 83.083091] HDA Intel 0000:00:08.0: setting latency timer to 64 [ 97.868088] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 97.868090] Bluetooth: BNEP filters: protocol multicast [ 97.891475] Bridge firewalling registered [ 106.422885] lp: driver loaded but no devices found [ 106.480115] eth1: no IPv6 routers present [ 106.634529] ppdev: user-space parallel port driver [ 108.156173] forcedeth 0000:00:0a.0: irq 2300 for MSI/MSI-X [ 108.156370] eth0: no link during initialization. [ 108.156806] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 113.460978] mtrr: no MTRR for 91000000,e00000 found [ 206.340186] usb 1-1: new high speed USB device using ehci_hcd and address 5 [ 206.485937] usb 1-1: configuration #1 chosen from 1 choice [ 206.486552] scsi7 : SCSI emulation for USB Mass Storage devices [ 206.504759] usb-storage: device found at 5 [ 206.504762] usb-storage: waiting for device to settle before scanning [ 211.504762] usb-storage: device scan complete [ 211.507176] scsi 7:0:0:0: Direct-Access Kingston DataTraveler 2.0 PMAP PQ: 0 ANSI: 0 CCS [ 213.416785] sd 7:0:0:0: [sdc] 7868416 512-byte hardware sectors: (4.02 GB/3.75 GiB) [ 213.418432] sd 7:0:0:0: [sdc] Write Protect is off [ 213.418441] sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 213.418446] sd 7:0:0:0: [sdc] Assuming drive cache: write through [ 213.423549] sd 7:0:0:0: [sdc] 7868416 512-byte hardware sectors: (4.02 GB/3.75 GiB) [ 213.425701] sd 7:0:0:0: [sdc] Write Protect is off [ 213.425709] sd 7:0:0:0: [sdc] Mode Sense: 23 00 00 00 [ 213.425715] sd 7:0:0:0: [sdc] Assuming drive cache: write through [ 213.425728] sdc: sdc1 [ 213.427931] sd 7:0:0:0: [sdc] Attached SCSI removable disk [ 213.428079] sd 7:0:0:0: Attached scsi generic sg3 type 0 --Boundary-00=_JgiZKk5ZjQNCemB-- From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 20:50:08 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25A22106564A; Tue, 21 Jul 2009 20:50:08 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id D6BA48FC12; Tue, 21 Jul 2009 20:50:07 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n6LKo7MY025581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jul 2009 16:50:07 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n6LKo7MY025581 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1248209407; bh=G+HsCqghv9XVv6KiYd99ivpynvedEXQEkjFedxsqgbI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=NV4nF3vfKY5oOwQ3VnSPqIPv2jvsUoerCtPnF4TI9xfrfPQh7uDlvOsK3mrhvzTkO i9XG/4G79f/5aFq3bUu1C/EZPJoiIEJGUkAobkYw7GO0IzYIuC7YdNQjc0KQd1/xhL cTSIl9ezk1cmah5wP1v0qGQBJXKBtAamdye+nlqA= Message-ID: <4A6629F8.1090503@cs.duke.edu> Date: Tue, 21 Jul 2009 16:50:00 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Jung-uk Kim References: <4A660E83.6080004@cs.duke.edu> <200907211605.40390.jkim@FreeBSD.org> <200907211617.40842.jkim@FreeBSD.org> In-Reply-To: <200907211617.40842.jkim@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: loader.conf ignores setting variable ending in _type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 20:50:08 -0000 Jung-uk Kim wrote: > On Tuesday 21 July 2009 04:05 pm, Jung-uk Kim wrote: >> *_type Defines the module's type. If none is given, it >> defaults to a kld module. > > Actually, I wanted to quote this: > > loader.conf(5): > > WARNING: developers should never use these suffixes for any > kernel environment variables (tunables) or conflicts > will result. Whoops.. Thanks for pointing that out. Drew From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 20:53:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23DED106564A; Tue, 21 Jul 2009 20:53:18 +0000 (UTC) (envelope-from wael.nasreddine@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 4BFE88FC1A; Tue, 21 Jul 2009 20:53:17 +0000 (UTC) (envelope-from wael.nasreddine@gmail.com) Received: by fxm18 with SMTP id 18so73362fxm.43 for ; Tue, 21 Jul 2009 13:53:16 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=B98+LBPea8I42PeLZGL2cmecZGpCxI6/SA2rMJupAmA=; b=B2rx0zO4kw/bVjNj9RBCDAT8HZ0HMT7iq2NUQVpa1/oln3dmjDQkIYEi5vRk26cpDQ 7zHVeXpo24r7lCu6bRq7la4ZD+eS5k55CG0o2WIWvNsZWvWJe5TTvIbpu4mtNgsOfSJN ptaX7mYYmateqgWleDUGHBw3/g9qA+rnKCg4I= 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:content-type :content-transfer-encoding; b=iEIAqQhdbLvhETzG4X80AMh7Wqi7D01XK8KqyO8CNK55PdIIh3wQ3cIwLJUChSj8rP yfOdKJHR5yxM86XdYq1P9k90aZQikNUMds7ltzky6wjcX5i0RUBEX8gDOGXY/iLUMb9R 9NoX7oLBlrNkIyTN0fg7rsheTc6lmOSGzXLv8= MIME-Version: 1.0 Sender: wael.nasreddine@gmail.com Received: by 10.103.12.2 with SMTP id p2mr51877mui.70.1248209596093; Tue, 21 Jul 2009 13:53:16 -0700 (PDT) In-Reply-To: References: From: "Wael Nasreddine (a.k.a eMxyzptlk)" Date: Tue, 21 Jul 2009 22:52:56 +0200 X-Google-Sender-Auth: 921cf0cf8e65e2d8 Message-ID: To: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-hardware@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: FreeBSD + HP Pavilion DV7-1299EF, Pre-install questions. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 20:53:18 -0000 I have a problem booting the DVD on this laptop, with ACPI enabled, it crashes after the usb part, check the screenshot http://omploader.org/vMjBqbA I tried with ACPI disabled, the whole system stops responding even before the USB part. On Tue, Jul 21, 2009 at 4:58 PM, Wael Nasreddine (a.k.a eMxyzptlk) wrote: > > Hello, > > I recently bought an HP Pavilion DV7-1299EF, it's 2.4Ghz Core 2 DUO, 4G R= AM, 2x250 Gb Hard Disk > > ------- lspci > 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Con= troller Hub (rev 07) > 00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express= Graphics Port (rev 07) > 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI C= ontroller #4 (rev 03) > 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI C= ontroller #5 (rev 03) > 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI = Controller #2 (rev 03) > 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Con= troller (rev 03) > 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Po= rt 1 (rev 03) > 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Po= rt 2 (rev 03) > 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Po= rt 3 (rev 03) > 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Po= rt 4 (rev 03) > 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Po= rt 5 (rev 03) > 00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Po= rt 6 (rev 03) > 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI C= ontroller #1 (rev 03) > 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI C= ontroller #2 (rev 03) > 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI C= ontroller #3 (rev 03) > 00:1d.3 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI C= ontroller #6 (rev 03) > 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI = Controller #1 (rev 03) > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) > 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev= 03) > 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller= (rev 03) > 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (r= ev 03) > 01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9600M = GT] (rev a1) > 02:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shil= oh] Network Connection > 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168= B PCI Express Gigabit Ethernet controller (rev 02) > 06:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host Con= troller > 06:00.1 System peripheral: JMicron Technology Corp. SD/MMC Host Controlle= r > 06:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host Con= troller > 06:00.3 System peripheral: JMicron Technology Corp. MS Host Controller > 06:00.4 System peripheral: JMicron Technology Corp. xD Host Controller > ------- lspci > > What is critical for me is: > > Wifi: Intel 5100 AGN > Graphics: Nvidia Geforce 9600M GT Resolution: 1440x900 > Sound: Intel High definition Audio, Codec: IDT 92HD71B7X > > Since I have 2x250Gb, I would like to use ZFS, I heard FreeBSD can boot f= rom ZFS now, is it stable ? > > Thanks in advance for your feedback. > > -- > Wael Nasreddine > > Blog =C2=A0 =C2=A0: http://wael.nasreddine.com > E-mail =C2=A0: wael.nasreddine@gmail.com > gTalk =C2=A0 : wael.nasreddine@gmail.com > Tel =C2=A0 =C2=A0 : +33.6.32.94.70.13 > Skype =C2=A0 : eMxyzptlk > Twitter : @eMxyzptlk > > Sabayon Linux Chief Development Officer - http://www.sabayonlinux.org > > PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 =C2=A0DE12 5565 3945 C8DD 18= A2 > > .: An infinite number of monkeys typing into GNU emacs, > =C2=A0 would never make a good program. (L. Torvalds 1995) :. > -- Wael Nasreddine Blog =C2=A0 =C2=A0: http://wael.nasreddine.com E-mail =C2=A0: wael.nasreddine@gmail.com gTalk =C2=A0 : wael.nasreddine@gmail.com Tel =C2=A0 =C2=A0 : +33.6.32.94.70.13 Skype =C2=A0 : eMxyzptlk Twitter : @eMxyzptlk Sabayon Linux Chief Development Officer - http://www.sabayonlinux.org PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 =C2=A0DE12 5565 3945 C8DD 18A2 .: An infinite number of monkeys typing into GNU emacs, =C2=A0 would never make a good program. (L. Torvalds 1995) :. From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 20:57:48 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 87A84106564A; Tue, 21 Jul 2009 20:57:47 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Tue, 21 Jul 2009 16:57:37 -0400 User-Agent: KMail/1.6.2 References: <200907211439.05703.hselasky@c2i.net> <200907211245.02949.jkim@FreeBSD.org> <200907212241.45704.hselasky@c2i.net> In-Reply-To: <200907212241.45704.hselasky@c2i.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907211657.39574.jkim@FreeBSD.org> Cc: Rui Paulo , Hans Petter Selasky Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 20:57:48 -0000 On Tuesday 21 July 2009 04:41 pm, Hans Petter Selasky wrote: > On Tuesday 21 July 2009 18:45:01 Jung-uk Kim wrote: > > On Tuesday 21 July 2009 12:18 pm, Hans Petter Selasky wrote: > > > On Tuesday 21 July 2009 14:39:05 Hans Petter Selasky wrote: > > > > Hi, > > > > > > > > FreeBSD-8-BETA2 does not boot on MacBookPro5.5. It Freezes > > > > during kernel load. Is anyone working on this? > > > > > > Some more information: > > > > > > The kernel loading process gets to a point where ACPI is about > > > to get initialized. I'm currently tracing a little bit and so > > > far it ends up that AcpiEnable() in > > > "contrib/dev/acpica/events/evxfevnt.c" never returns. Somewhere > > > inside AcpiHwSetMode() something triggers a hardware condition, > > > which I cannot see where ends up. Any lights go up? > > > > Isn't it a new nVidia chipset system? If so, it is a known > > problem, reported by rpaulo (CC'ed). Unfortunately, I do not > > have hardware to debug it. Any way, can you comment out the > > retry loop in the AcpiHwSetMode() from > > sys/contrib/dev/acpica/hardware/hwacpi.c and try again? > > The system hangs before the while loop. Adding more debugging I > found out it hangs exactly at the call to AcpiHwWritePort(): > > Status = AcpiHwWritePort (AcpiGbl_FADT.SmiCommand, > (UINT32) AcpiGbl_FADT.AcpiEnable, 8); > > > I've attached dmesg from Ubuntu 9.x booting on the same machine. > Anything more you want me to try? Hmmm... Can you show me acpidump output with all tables? Thanks, Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 20:45:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 061B4106564A for ; Tue, 21 Jul 2009 20:45:39 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 862F98FC1A for ; Tue, 21 Jul 2009 20:45:38 +0000 (UTC) (envelope-from ohartman@mail.zedat.fu-berlin.de) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost1.zedat.fu-berlin.de (Exim 4.69) with esmtp (envelope-from ) id <1MTMDQ-0007As-QW>; Tue, 21 Jul 2009 22:45:36 +0200 Received: from e178044086.adsl.alicedsl.de ([85.178.44.86] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1MTMDQ-0003Mm-Nt>; Tue, 21 Jul 2009 22:45:36 +0200 Message-ID: <4A6628F0.6080802@mail.zedat.fu-berlin.de> Date: Tue, 21 Jul 2009 22:45:36 +0200 From: "O. Hartmann" User-Agent: Thunderbird 2.0.0.22 (X11/20090719) MIME-Version: 1.0 To: Olivier SMEDTS References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> <367b2c980907200729s57eafbbfw83c8ae5a94f41ffc@mail.gmail.com> In-Reply-To: <367b2c980907200729s57eafbbfw83c8ae5a94f41ffc@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 85.178.44.86 X-Mailman-Approved-At: Tue, 21 Jul 2009 21:17:31 +0000 Cc: Ken Smith , freebsd-stable , Thomas Backman , FreeBSD current Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 20:45:39 -0000 Olivier SMEDTS wrote: > 2009/7/19 Thomas Backman : >> On Jul 19, 2009, at 20:16, Ken Smith wrote: >>> The problem is that as of the next time you update a machine that had= >>> been running -current you are best off reinstalling all ports or othe= r >>> applications you have on the machine. =EF=BF=BDWhen you reboot after = doing the >>> update to the base system everything you have installed will still wo= rk >>> because the old shared library versions will still be there. =EF=BF=BD= However >>> anything you build on the machine after its base system gets updated >>> would be linked against the newer base system shared libraries but an= y >>> libraries that are part of ports or other applications (e.g. the Xorg= >>> libraries) would have been linked against the older library versions.= >>> You really don't want to leave things that way. >> So, to be clear: a fresh ports tree and "portupgrade -af" after buildi= ng and >> installing r195767+ should be enough to solve any problems? (installke= rnel, >> installworld, reboot, portupgrade -af) >=20 > But there won't be any problem until you do a "make delete-old-libs" > in /usr/src/, right ? >=20 > Olivier >=20 >> Regards, >> Thomas >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.= org" >> >=20 Real fun this moment. It took appoximately 13 hours on a two socket, 8 core Dell PowerEdge 1950 III at 2,5 GHz with 16 GB RAM for 453 ports to be recompiled. I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you imagine how long this box will be occupied by 'portupgrade -af'? I guess 'cherry-picking' is the only solution. FreeBSD 8.0 on AMD64 does have serious performance issues these days, try to compile a compiler (gcc44, for instance) and watch how bumpy your X11 or how network traffic on a 'headless' server becomes. Kernel compilation time has been increased by approx 10 minutes on the 8 core box with 16 GB RAM since ~ 4 months now. I know, this is a kind of off topic for the questiojns discussed at the moment, but I guess those problems and fun are guaranteed for those having lots of ports, FreeBSD 8 running on AMD64 ;-)) Regards, Oliver From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 21:52:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74443106566B; Tue, 21 Jul 2009 21:52:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 30C1D8FC1C; Tue, 21 Jul 2009 21:52:12 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n6LLq1x1062025; Tue, 21 Jul 2009 14:52:01 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n6LLq1mw062024; Tue, 21 Jul 2009 14:52:01 -0700 (PDT) (envelope-from sgk) Date: Tue, 21 Jul 2009 14:52:01 -0700 From: Steve Kargl To: "O. Hartmann" Message-ID: <20090721215201.GA61999@troutmask.apl.washington.edu> References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> <367b2c980907200729s57eafbbfw83c8ae5a94f41ffc@mail.gmail.com> <4A6628F0.6080802@mail.zedat.fu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A6628F0.6080802@mail.zedat.fu-berlin.de> User-Agent: Mutt/1.4.2.3i Cc: Olivier SMEDTS , Ken Smith , freebsd-stable , Thomas Backman , FreeBSD current Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 21:52:12 -0000 On Tue, Jul 21, 2009 at 10:45:36PM +0200, O. Hartmann wrote: > > I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB > RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you > imagine how long this box will be occupied by 'portupgrade -af'? I guess > 'cherry-picking' is the only solution. How many of those 800 ports are actually necessary and used? It would be better to get generate a complete list of your installed ports, use pkg_deinstall or pkg_delete to remove all ports, and then selectively re-install ports that are actually used. > FreeBSD 8.0 on AMD64 does have serious performance issues these days, > try to compile a compiler (gcc44, for instance) and watch how bumpy your > X11 or how network traffic on a 'headless' server becomes. Kernel > compilation time has been increased by approx 10 minutes on the 8 core > box with 16 GB RAM since ~ 4 months now. I know, this is a kind of off > topic for the questiojns discussed at the moment, but I guess those > problems and fun are guaranteed for those having lots of ports, FreeBSD > 8 running on AMD64 ;-)) > I compile gcc trunk on my 2 cpu amd64 based system almost everyday. I don't see the performance issue you seem to have. Do you use ULE? If yes, then switch to 4BSD. -- Steve From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 22:15:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A7DD1065673 for ; Tue, 21 Jul 2009 22:15:26 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 94EC38FC16 for ; Tue, 21 Jul 2009 22:15:25 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from fuzz.geek.sh (unknown [196.209.243.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 87C593C14E; Wed, 22 Jul 2009 00:15:23 +0200 (SAST) Message-ID: <4A663DF0.9060806@phat.za.net> Date: Wed, 22 Jul 2009 00:15:12 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.22 (X11/20090628) MIME-Version: 1.0 To: John Baldwin References: <4A65187E.8060505@phat.za.net> <200907210853.16169.jhb@freebsd.org> In-Reply-To: <200907210853.16169.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: devel/ccache broken in BETA2? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 22:15:26 -0000 John Baldwin wrote: > On Monday 20 July 2009 9:23:10 pm Aragon Gouveia wrote: >> Is anyone able to compile just about anything with ccache on BETA2? I'm >> experiencing a lot of breakage here. > > It's a bug in ccache in that it expects mmap() with a size of 0 to work. > Someone on an earlier thread had a patch for the ccache port to fix it. Thanks John and Mel. I've tested (works for me), repackaged Mel's fix and PR'd it here: http://www.freebsd.org/cgi/query-pr.cgi?pr=136971 Thanks, Aragon From owner-freebsd-current@FreeBSD.ORG Tue Jul 21 23:34:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A22CF1065670 for ; Tue, 21 Jul 2009 23:34:08 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 5601B8FC0A for ; Tue, 21 Jul 2009 23:34:08 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by yxe11 with SMTP id 11so5502815yxe.3 for ; Tue, 21 Jul 2009 16:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=M2rMclf4MW5kqAgg4xhvousD1Aj8KGcJkYkP6WZ5JNg=; b=RfsHDKQhuNVJ0QeCswfxL5rK3ER+9avZUWYB6necabqyV1+hEHu+UG+EHD9fOWRT68 0AjEBDfqkpuqILUUMmahZBuqSnG3s3lBLOXO8SQaYVP981JpxbULSxNiVX+XrZpLNCK7 Xqcp/ZwoxfQdkFZ8j1CcYTp65Y/n1sSchYCHk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=s9DC2coB34q7t5+BdBiy1F7wBV6Tz+ZnaAXRVLNopi9E91keDqQQvedKJQH54Pl3Oj i80nbkDq1ATKpOrijV4PM3YzqSWNJyzPZv8+RnJsX8qswdAyKqG7sT9tbCV1+Tu0xN1x rT06jJPoQQgOjfQJ4vc4uPi81IbF6JzwRKLao= Received: by 10.90.33.20 with SMTP id g20mr186909agg.58.1248219247710; Tue, 21 Jul 2009 16:34:07 -0700 (PDT) Received: from ?192.168.1.100? ([190.177.196.93]) by mx.google.com with ESMTPS id 32sm400119aga.4.2009.07.21.16.34.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Jul 2009 16:34:07 -0700 (PDT) From: Gonzalo Nemmi To: "Paul B. Mahol" Date: Tue, 21 Jul 2009 20:34:04 -0300 User-Agent: KMail/1.9.10 References: <4A5D27F2.50208@voicenet.com> <200907201803.32053.gnemmi@gmail.com> <3a142e750907210146u2ce72cadhbdaa71a89be54607@mail.gmail.com> In-Reply-To: <3a142e750907210146u2ce72cadhbdaa71a89be54607@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907212034.04853.gnemmi@gmail.com> Cc: freebsd-current@freebsd.org, Adam K Kirchhoff Subject: Re: bge problems when resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 23:34:08 -0000 On Tuesday 21 July 2009 5:46:10 am Paul B. Mahol wrote: > On 7/20/09, Gonzalo Nemmi wrote: > > On Sunday 19 July 2009 7:53:52 pm Paul B. Mahol wrote: > >> On 7/20/09, Gonzalo Nemmi wrote: > >> > On Sat, Jul 18, 2009 at 12:09 AM, Paul B. Mahol > >> > > > > > wrote: > >> >> On 7/17/09, Gonzalo Nemmi wrote: > >> >> > On Wednesday 15 July 2009 8:13:47 am Adam K Kirchhoff wrote: > >> >> >> On Wednesday 15 July 2009 03:20:45 Paul B. Mahol wrote: > >> >> >> > On 7/15/09, Adam K Kirchhoff wrote: > >> >> >> > > Hello all, > >> >> >> > > > >> >> >> > > I have a Dell Latitude D610 laptop with 8.0-BETA1 > >> >> >> > > installed. I hadn't tried suspend/resume for a while > >> >> >> > > and decided to give it a shot. I was pleasantly > >> >> >> > > surprised to see that I could suspend to ram, resume, > >> >> >> > > and have a (relatively) working system (previously the > >> >> >> > > display would never come back up and the serial console > >> >> >> > > I had hooked up remained dead). Great job to everyone > >> >> >> > > who helped make that possible. > >> >> >> > > > >> >> >> > > The only real issue that I seem to have now is that bge > >> >> >> > > is completely unusable after resume. Another individual > >> >> >> > > seems to have reported similar problems with bge and > >> >> >> > > resume, but he also had other issues that apparently > >> >> >> > > trumped his networking issues: > >> >> >> > > > >> >> >> > > http://lists.freebsd.org/pipermail/freebsd-current/2009- > >> >> >> > >Jul y/0090 23.html > >> >> >> > > > >> >> >> > > Like him, resuming from suspend gives me: > >> >> >> > > > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 0, val 32768) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY read timed out > >> >> >> > > (phy 1, reg 0, val 0xffffffff) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 24, val 3072) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 23, val 10) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 21, val 12555) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 23, val 8223) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 21, val 38150) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 23, val 16415) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 21, val 5346) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 24, val 1024) > >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> > > (phy 1, reg 24, val 7) > >> >> >> > > > >> >> >> > > And so on and so forth. > >> >> >> > > > >> >> >> > > I thought that compiling if_bge as a module, unloading > >> >> >> > > it before suspend, and reloading it after resume, might > >> >> >> > > get this working. However, doing a "kldload if_bge" > >> >> >> > > after the resume does nothing. Well, the module gets > >> >> >> > > loaded, but the device doesn't show up. No errors from > >> >> >> > > kldload, and there is nothing new in dmesg. > >> >> >> > > > >> >> >> > > Before the suspend, the device shows up as: > >> >> >> > > > >> >> >> > > bge0@pci0:2:0:0: class=0x020000 card=0x01821028 > >> >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 > >> >> >> > > vendor = 'Broadcom Corporation' > >> >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express > >> >> >> > > (BCM5750A1)' class = network > >> >> >> > > subclass = ethernet > >> >> >> > > > >> >> >> > > After resuming, and reloading the module, it's: > >> >> >> > > > >> >> >> > > none1@pci0:2:0:0: class=0x020000 card=0x01821028 > >> >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 > >> >> >> > > vendor = 'Broadcom Corporation' > >> >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express > >> >> >> > > (BCM5750A1)' class = network > >> >> >> > > subclass = ethernet > >> >> >> > > > >> >> >> > > If there are no ideas, I'll go ahead and open up a pr. > >> >> >> > > I assume this is just one bug, since both problems (the > >> >> >> > > PHY issues and the inability to reload the driver) are > >> >> >> > > both related to the network device. > >> >> >> > > >> >> >> > Put this lines into loader.conf and reboot. > >> >> >> > > >> >> >> > hw.pci.do_power_nodriver="3" > >> >> >> > hw.pci.do_power_resume="1" > >> >> >> > > >> >> >> > Now, before suspend, unload if_bge and some another driver > >> >> >> > (sound drivers are best candidate) and load sound driver > >> >> >> > again, suspend and resume. > >> >> >> > Now loading if_bge should make it succesfully attach. > >> >> >> > >> >> >> Unfortunately, after doing this, reloading the if_bge driver > >> >> >> causes the laptop to completely lock up... It gets as far > >> >> >> as: > >> >> >> > >> >> >> bge0: >> >> >> unknown ASIC rev. 0xffff> > >> >> >> mem 0xdfdf0000-0xdfdfffff irq 16 at device 0.0 on pci2 > >> >> >> > >> >> >> And then the entire machine hangs. I'm on ttyv0, so I'd see > >> >> >> any kernel panic, but nothing like that happens. The screen > >> >> >> stays on, but nothing else happens till I force a reboot. > >> >> >> > >> >> >> Adam > >> >> > > >> >> > Hi Adam, Paul ... > >> >> > I'm the "another individual" from you OP. > >> >> > I have the same problems you have regarding bge, but they > >> >> > weren't trumped .. I just had an order of priorities ;) > >> >> > > >> >> > Anyways, I tried the solution Paul posted and, just as in > >> >> > your case, I got a hard lock too ... > >> >> > > >> >> > I tried loading if_bge through /boot/loader.conf > >> >> > Then issued a: > >> >> > > >> >> > kldunload if_bge coretemp > >> >> > >> >> coretemp is wrong module, it must be one of modules that attach > >> >> to pci. > >> > > >> > Sorry Paul! > >> > I gave it a go with snd_hda and I got the same result except > >> > that this time I also got the following message: > >> > >> After unloading snd_hda you loaded it again before suspending? > > > > Doing so yielded a Fatal trap 12 on BETA2. Yesterday I install > > BETA2 and here are the results: > > > > > > kldstat > > > > Id Refs Address Size Name > > 1 28 0xc0400000 cf6c70 kernel > > 2 1 0xc10f7000 11bc0 if_bge.ko > > 3 1 0xc1109000 1ac4c snd_hda.ko > > 4 2 0xc1124000 61f78 sound.ko > > 5 1 0xc1186000 2af4 coretemp.ko > > 6 1 0xc1189000 a6d8 i915.ko > > 7 2 0xc1194000 177d4 drm.ko > > > > > > kldunload if_bge snd_hda > > > > Jul 20 17:50:49 gargoyle login: ROOT LOGIN (root) ON ttyv0 > > Jul 20 17:51:06 gargoyle kernel: brgphy0: detached > > Jul 20 17:51:06 gargoyle kernel: lock order reversal: > > Jul 20 17:51:06 gargoyle kernel: 1st 0xc0dba45c kernel linker > > (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1079 > > Jul 20 17:51:06 gargoyle kernel: 2nd 0xc0dbbc64 sysctl lock (sysctl > > lock) @ /usr/src/sys/kern/kern_sysctl.c:257 > > Jul 20 17:51:06 gargoyle kernel: KDB: stack backtrace: > > Jul 20 17:51:06 gargoyle kernel: > > db_trace_self_wrapper(c0c6baf4,e6daba34,c08bc995,c08ad6db,c0c6e989, > >...) at db_trace_self_wrapper+0x26 > > Jul 20 17:51:06 gargoyle kernel: > > kdb_backtrace(c08ad6db,c0c6e989,c452bc88,c4529e10,e6daba90,...) at > > kdb_backtrace+0x29 > > Jul 20 17:51:06 gargoyle kernel: > > _witness_debugger(c0c6e989,c0dbbc64,c0c69667,c4529e10,c0c6956e,...) > > at _witness_debugger+0x25 > > Jul 20 17:51:06 gargoyle kernel: > > witness_checkorder(c0dbbc64,9,c0c6956e,101,0,...) at > > witness_checkorder+0x839 > > Jul 20 17:51:06 gargoyle kernel: > > _sx_xlock(c0dbbc64,0,c0c6956e,101,c4722c00,...) at _sx_xlock+0x85 > > Jul 20 17:51:06 gargoyle kernel: > > sysctl_ctx_free(c4722c4c,c4722c00,e6dabb18,c08a3c85,c4722c00,...) > > at sysctl_ctx_free+0x30 > > Jul 20 17:51:06 gargoyle kernel: > > device_sysctl_fini(c4722c00,0,c0d4c848,c472a810,c4ab3400,...) at > > device_sysctl_fini+0x1a > > Jul 20 17:51:06 gargoyle kernel: > > device_detach(c4722c00,c4722b80,e6dabb38,c06bc622,c4722b80,...) at > > device_detach+0x1f5 > > Jul 20 17:51:06 gargoyle kernel: > > bus_generic_detach(c4722b80,c4722b80,e6dabb64,c08a3b1c,c4722b80,... > >) at bus_generic_detach+0x29 > > Jul 20 17:51:06 gargoyle kernel: > > miibus_detach(c4722b80,c45d6060,c0d4ca68,a3c,c0c76f47,...) at > > miibus_detach+0x12 > > Jul 20 17:51:06 gargoyle kernel: > > device_detach(c4722b80,c472b008,e6dabb98,c10ff7ff,c4722300,...) at > > device_detach+0x8c > > Jul 20 17:51:06 gargoyle kernel: > > bus_generic_detach(c4722300,1,c1104b66,aec,c4722300,...) at > > bus_generic_detach+0x29 > > Jul 20 17:51:06 gargoyle kernel: > > bge_detach(c4722300,c4677060,c0d4ca68,a3c,c4526300,...) at > > bge_detach+0xbf > > Jul 20 17:51:06 gargoyle kernel: > > device_detach(c4722300,c086c843,c0dbb570,c1106c20,c456fb80,...) at > > device_detach+0x8c > > Jul 20 17:51:06 gargoyle kernel: > > driver_module_handler(c4526300,1,c1106c20,109,0,...) at > > driver_module_handler+0x29c > > Jul 20 17:51:06 gargoyle kernel: > > module_unload(c4526300,c0c652ef,273,270,c08604b6,...) at > > module_unload+0x43 > > Jul 20 17:51:06 gargoyle kernel: > > linker_file_unload(c4544200,0,c0c652ef,437,c10f7000,...) at > > linker_file_unload+0x15e > > Jul 20 17:51:06 gargoyle kernel: > > kern_kldunload(c4b346c0,2,0,e6dabd2c,c0ba8dd3,...) at > > kern_kldunload+0xd5 > > Jul 20 17:51:06 gargoyle kernel: > > kldunloadf(c4b346c0,e6dabcf8,8,c0c6fa4b,c0d50450,...) at > > kldunloadf+0x2b > > Jul 20 17:51:06 gargoyle kernel: syscall(e6dabd38) at syscall+0x2a3 > > Jul 20 17:51:06 gargoyle kernel: Xint0x80_syscall() at > > Xint0x80_syscall+0x20 > > Jul 20 17:51:06 gargoyle kernel: --- syscall (444, FreeBSD ELF32, > > kldunloadf), eip = 0x280d516b, esp = 0xbfbfe47c, ebp = 0xbfbfecc8 > > --- Jul 20 17:51:06 gargoyle kernel: miibus0: detached > > Jul 20 17:51:06 gargoyle kernel: bge0: detached > > Jul 20 17:51:06 gargoyle kernel: sysctl_unregister_oid: failed to > > unregister sysctl > > if_bge driver looks very problematic to me. Probably it can not > detach at all. > > > Jul 20 17:51:06 gargoyle kernel: pcm0: detached > > Jul 20 17:51:06 gargoyle kernel: hdac0: detached > > > > > > kld snd_hda > > ^^^ > You mean kldload. > > > Jul 20 17:52:16 gargoyle kernel: hdac0: > Definition Audio Controller> mem 0xf6dfc000-0xf6dfffff irq 21 at > > device 27.0 on pci0 > > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Driver Revision: > > 20090624_0136 > > Jul 20 17:52:16 gargoyle kernel: hdac0: [ITHREAD] > > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel > > STAC9228X Jul 20 17:52:16 gargoyle kernel: bge0: > A2, ASIC rev. 0xc002> mem 0xf69f0000-0xf69fffff irq 17 at device > > 0.0 on pci9 Jul 20 17:52:16 gargoyle kernel: miibus0: on > > bge0 Jul 20 17:52:16 gargoyle kernel: brgphy0: > 10/100baseTX PHY> PHY 1 on miibus0 > > Jul 20 17:52:16 gargoyle kernel: brgphy0: 10baseT, 10baseT-FDX, > > 100baseTX, 100baseTX-FDX, auto > > Jul 20 17:52:16 gargoyle kernel: bge0: Ethernet address: > > 00:23:ae:04:ba:ca > > Jul 20 17:52:16 gargoyle kernel: bge0: [ITHREAD] > > Jul 20 17:52:16 gargoyle kernel: pcm0: > #0 Analog> at cad 0 nid 1 on hdac0 > > Jul 20 17:52:16 gargoyle kernel: bge0: link state changed to DOWN > > Jul 20 17:52:18 gargoyle kernel: bge0: link state changed to UP > > Why bge0 appeared again? > > > acpiconf -s 3 > > After this command bge0 should not appear at all because it should > not be attached to > device. > > > Jul 20 17:53:51 gargoyle acpi: suspend at 20090720 17:53:51 > > Jul 20 17:53:56 gargoyle kernel: fwohci0: fwohci_pci_suspend > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 0, val 32768) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 0, val 0xffffffff) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 24, val 0xffffffff) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 16, val 0xffffffff) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 16, val 0) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, > > reg 16, val 0xffffffff) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 16, val 0) > > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, > > reg 23, val 18) > > Jul 20 17:54:25 gargoyle kernel: bge0: flow-through queue init > > failed Jul 20 17:54:25 gargoyle kernel: bge0: initialization > > failure Jul 20 17:54:25 gargoyle kernel: fwohci0: Phy 1394a > > available S400, 1 ports. > > Jul 20 17:54:25 gargoyle kernel: fwohci0: Link S400, max_rec 2048 > > bytes. Jul 20 17:54:25 gargoyle kernel: fwohci0: Initiate bus reset > > Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: BUS > > reset Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: > > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > > Jul 20 17:54:25 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 > > cable IRM irm(0) (me) > > Jul 20 17:54:25 gargoyle kernel: firewire0: bus manager 0 > > Jul 20 17:54:25 gargoyle kernel: fwohci0: unrecoverable error > > Jul 20 17:54:25 gargoyle kernel: wakeup from sleeping state (slept > > 00:00:29) > > Jul 20 17:54:25 gargoyle acpi: resumed at 20090720 17:54:25 > > > > Should a PR on fwohci and firewire also be filed?? > > Try with custom kernel with smaller number of drivers as possible. > (use modules instead) > From your mail I dont see where is problem with firewire. Done. Commented if_bge out of GENERIC, recompiled, loaded if_bge via loader.conf, kldunloaded if_bge snd_hda, kloaded snd_hda (if_bge did not show up on dmesg this time), went to sleep (acpiconf -s 3), resumed, no bge timeouts (only fwohci and firewire messages), then kldloaded if_bge and got a solid freeze :( Best Regards Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 00:13:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0D651065688 for ; Wed, 22 Jul 2009 00:13:16 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by mx1.freebsd.org (Postfix) with SMTP id 79B768FC14 for ; Wed, 22 Jul 2009 00:13:16 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: (qmail 91397 invoked from network); 21 Jul 2009 23:46:36 -0000 Received: from unknown (HELO ?10.10.10.3?) (webmaster@69.108.138.13 with plain) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 21 Jul 2009 23:46:35 -0000 X-YMail-OSG: kdaTwk0VM1kxGGw84kOMmU3i0PA6PZCwt2SRxPJiHLEGLGANeoDw.uqLNtIbYjc.Wx4gVT4a9XV1ExkGyHddvI48n8.bZ8D_RSskm9MhaJoyEDHP9.c.vrn6bPgKNhgtIhRYh.f54PvrXI18nSyvxY12L_ZQ7j1NZzRfE33U7OveE_YSoeBNWhXmDI9OqgTslO5lYVSyGPNn62PoBZqb7y5QcMpjK30Lk16epwPy.Id3uKPYnwq60ouWklG_mrL.mJ1ZIkU_77_q6jagCWOS_vBCCK7VP_2f5ZJfz2hwV.bOvQv_I4FR9mJYUAMmAs9vFgslEiLBdhiR9sIv628CeXF6 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6652DF.8080004@doghouserepair.com> Date: Tue, 21 Jul 2009 16:44:31 -0700 From: Ryan Rogers User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "Sam Fourman Jr." References: <4A651E50.6000508@doghouserepair.com> <11167f520907201957h380601a7m18109be634da45c7@mail.gmail.com> In-Reply-To: <11167f520907201957h380601a7m18109be634da45c7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 00:13:17 -0000 Sam Fourman Jr. wrote: > On Mon, Jul 20, 2009 at 8:48 PM, Ryan > Rogers wrote: >> I'm running 8.0-BETA2/amd64 on a system that has on-board ethernet. It is >> detected by FreeBSD as the following: >> >> nfe0: port 0xac00-0xac07 mem >> 0xcfffa000-0xcfffafff,0xcfff9000-0xcfff90ff,0xcfff8000-0xcfff800f irq 22 at >> device 17.0 on pci0 >> miibus1: on nfe0 >> e1000phy0: PHY 1 on miibus1 >> e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> >> The problem is, I can't get packets to move across the interface. I know >> that the interface works in Windows as well as Ubuntu, but it looks like >> it's failing to get fully configured in FreeBSD. The output of ifconfig >> nfe0 is: >> >> nfe0: flags=8843 metric 0 mtu 1500 >> options=19b >> ether 00:04:4b:01:8c:0b >> inet 10.10.10.3 netmask 0xffffff00 broadcast 10.10.10.255 >> media: Ethernet autoselect (none) >> status: active >> >> The part that I find odd is "media: Ethernet autoselect (none)". If I >> manually force it to "media 1000baseT mediaopt full-duplex", that line >> becomes "media: 1000baseT full-duplex (10baseT/UTP half-duplex)". Still, the >> interface is dead. >> >> I found PR kern/127910 which describes the same problem, except for >> 7.0-RELEASE. There's been no activity on that for 9 months though (aside >> from my update today). Can anyone offer me any insight on this? >> >> Thanks, >> Ryan > > > I can confirm this is a nfe problem, I first reported it to the > mailing list a few weeks back > under the subject FreeBSD 8 BETA1 DHCP trouble. > http://groups.google.co.jp/group/muc.lists.freebsd.current/browse_thread/thread/ba7b35e561d3e868 > I have several different motherboards with nfe nics, My findings are as follows. > > on a FreeBSD -CURRENT snapshot dated 6-1-2009 dhcp works as expected. > somewhere after ~ 6-6-2009 something broke. > > dhclient nfe0 > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 4 > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 12 > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 18 > DHCPDISCOVER on nfe0 to 255.255.255.255 port 67 interval 9 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > the odd thing is that on motherboards that have dual nfe nics nfe1 > always works,and nfe0 is always broke. > on motherboards that have only a single nfe interface nfe0 is indeed broke. > > on a dual nic motherboard, if you go into BIOS and disable one of the > LAN devices. DHCP will fail if the interface name is nfe0 > even though it worked 5 min before when that same nic and MAC address > had the nfe1 name. > > This entire thing is odd :) > > > Sam Fourman Jr. > > I have 7.2-RELEASE/i386 running perfectly using the same motherboard that is causing me nfe problems in 8.0-BETA2/amd64. I then decided to see if perhaps it was something with i386 vs amd64, so I downloaded a 7.2-RELEASE/amd64 iso, and the nics worked perfectly there as well. Seeing that nfe apparently worked on June 1st, I headed to the FTP to see which snapshots were available. The earliest -CURRENT June snapshot was dated the 8th, so I grabbed that one. The nics didn't work at all. So, there's a small window where something changed which broke nfe. Looking at the SVN commit logs for if_nfe.c, nothing really fits in that window. To me, this looks like something about general network device handling changed which nfe nics can't cope with. I have no idea what that could be though, so I'm hoping that someone on this list would be able to point me in the right direction. Ryan From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 00:14:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 923301065676 for ; Wed, 22 Jul 2009 00:14:48 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id 464A08FC1B for ; Wed, 22 Jul 2009 00:14:47 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by qyk29 with SMTP id 29so365962qyk.3 for ; Tue, 21 Jul 2009 17:14:47 -0700 (PDT) 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 :content-transfer-encoding; bh=+GJh1NZ3f+8Ac5elSGBoiSxi7HdSJ0KB1tivBH/AyaY=; b=YKOnUCBF4pEAQmDdBB/huMkc+6fSF3vxwKN3Efjsnh3NDmlTPJwOe8n9d2/rDO7pfZ OZKkzQ53ZrfZgJOYpKcZ4jXFzrAcmAAvll+qpfni0bZR05g0WDmRaFEQaHIQWHVsxeFs 9346qGsu+afNrXijPhvpPTSV3Rs8rr9jzD/Hc= 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:content-transfer-encoding; b=XfaaNdxlZYBAMOO2BHLJ3cohH5ikrvOSd9V8+VFZBuhx9rRjYBzwqOkOiY8f1JE9dG xiNrdcAaRgVx6C+rYBD/1se9oMdiHJAumbKzKz7icuC660q3YWKx843O9Nq56FJ7QIIl bQrHuRkZ9pSOFQ+Q8sVZ+kmazQ4Jw/xbYQNz8= MIME-Version: 1.0 Received: by 10.229.110.20 with SMTP id l20mr61475qcp.60.1248221687109; Tue, 21 Jul 2009 17:14:47 -0700 (PDT) In-Reply-To: <4A6652DF.8080004@doghouserepair.com> References: <4A651E50.6000508@doghouserepair.com> <11167f520907201957h380601a7m18109be634da45c7@mail.gmail.com> <4A6652DF.8080004@doghouserepair.com> Date: Tue, 21 Jul 2009 19:14:46 -0500 Message-ID: <11167f520907211714x2d82e503m7c8ff2256beecaaf@mail.gmail.com> From: "Sam Fourman Jr." To: Ryan Rogers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 00:14:49 -0000 > I have 7.2-RELEASE/i386 running perfectly using the same motherboard that= is > causing me nfe problems in 8.0-BETA2/amd64. =A0I then decided to see if > perhaps it was something with i386 vs amd64, so I downloaded a > 7.2-RELEASE/amd64 iso, and the nics worked perfectly there as well. > > Seeing that nfe apparently worked on June 1st, I headed to the FTP to see > which snapshots were available. =A0The earliest -CURRENT June snapshot wa= s > dated the 8th, so I grabbed that one. =A0The nics didn't work at all. > > So, there's a small window where something changed which broke nfe. Looki= ng > at the SVN commit logs for if_nfe.c, nothing really fits in that window. = =A0To > me, this looks like something about general network device handling chang= ed > which nfe nics can't cope with. =A0I have no idea what that could be thou= gh, > so I'm hoping that someone on this list would be able to point me in the > right direction. > > Ryan Yes I can confirm that FreeBSD 7.x works, because PC-BSD 7.1.1 works the only thing I can add is I have a motherboard with MCP73 based nfe nic and that nic works fine with FreeBSD8 BETA2/amd64 What I find odd, is that on MCP55 boards the 2nd nic will work, I am writing this Email on a FreeBSD 8 Beta2/i386 machine. using nfe1. Does anyone have any Ideas? I have 4 of these MCP55 based boards, and public internet ip's I would be willing to set someone up with root ssh access and a firewire connection to another box. here is a dmesg Sam Fourman Jr. dmesg 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 8.0-BETA2 #1: Thu Jul 16 17:03:33 CDT 2009 sfourman@:/usr/obj/usr/src/sys/Ziggy Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz (2666.65-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x1067a Stepping =3D 10 Features=3D0xbfebfbff Features2=3D0x408e3bd AMD Features=3D0x20100000 AMD Features2=3D0x1 TSC: P-state invariant real memory =3D 4294967296 (4096 MB) avail memory =3D 3132448768 (2987 MB) ACPI APIC Table: <022609 APIC1009> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <022609 XSDT1009> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fec00000, 1000 (3) failed acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, bff00000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x2008-0x200b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 25000000 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pci0: at device 1.0 (no driver attached) pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) pci0: at device 1.3 (no driver attached) pci0: at device 1.4 (no driver attached) pci0: at device 1.5 (no driver attached) pci0: at device 1.6 (no driver attached) pci0: at device 1.7 (no driver attached) pcib1: irq 16 at device 2.0 on pci0 pci1: on pcib1 vgapci0: port 0xec00-0xec7f mem 0xfb000000-0xfbffffff,0xd0000000-0xdfffffff,0xf8000000-0xf9ffffff irq 16 at device 0.0 on pci1 nvidia0: on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [GIANT-LOCKED] nvidia0: [ITHREAD] pcib2: irq 17 at device 4.0 on pci0 pci2: on pcib2 pci0: at device 9.0 (no driver attached) isab0: port 0x2f00-0x2f7f at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) ohci0: mem 0xf7ffb000-0xf7ffbfff irq 22 at device 11.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xf7ffac00-0xf7ffacff irq 23 at device 11.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 13.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0xd400-0xd407,0xd080-0xd083,0xd000-0xd007,0xcc00-0xcc03,0xc880-0xc88f mem 0xf7ff9000-0xf7ff9fff irq 21 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0xc800-0xc807,0xc480-0xc483,0xc400-0xc407,0xc080-0xc083,0xc000-0xc00f mem 0xf7ff8000-0xf7ff8fff irq 22 at device 14.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xbc00-0xbc07,0xb880-0xb883,0xb800-0xb807,0xb480-0xb483,0xb400-0xb40f mem 0xf7ff7000-0xf7ff7fff irq 23 at device 14.2 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] pcib3: at device 15.0 on pci0 pci3: on pcib3 hdac0: mem 0xf7ff0000-0xf7ff3fff irq 21 at device 15.1 on pci0 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] nfe0: port 0xb080-0xb087 mem 0xf7ff6000-0xf7ff6fff,0xf7ffa800-0xf7ffa8ff,0xf7ffa400-0xf7ffa40f irq 20 at device 17.0 on pci0 miibus0: on nfe0 e1000phy0: PHY 1 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:23:54:96:dd:8d nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe0: [FILTER] nfe1: port 0xb000-0xb007 mem 0xf7ff5000-0xf7ff5fff,0xf7ffa000-0xf7ffa0ff,0xf7ff4c00-0xf7ff4c0f irq 20 at device 18.0 on pci0 miibus1: on nfe1 e1000phy1: PHY 2 on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe1: Ethernet address: 00:23:54:96:de:2f nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] nfe1: [FILTER] pcib4: at device 19.0 on pci0 pci4: on pcib4 pcib5: at device 22.0 on pci0 pci5: on pcib5 pcib6: at device 23.0 on pci0 pci6: on pcib6 pcib7: at device 24.0 on pci0 pci7: on pcib7 acpi_button0: on acpi0 ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found Package, expected Buffer 20090521 nspredef-1051 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] atrtc1: port 0x70-0x71 on acpi0 cpu0: on acpi0 coretemp0: on cpu0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082506000825 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 coretemp1: on cpu1 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082506000825 device_attach: est1 attach returned 6 p4tcc1: on cpu1 cpu2: on acpi0 coretemp2: on cpu2 est2: on cpu2 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082506000825 device_attach: est2 attach returned 6 p4tcc2: on cpu2 cpu3: on acpi0 coretemp3: on cpu3 est3: on cpu3 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 616082506000825 device_attach: est3 attach returned 6 p4tcc3: on cpu3 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. ppc0: parallel port not found. Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ad4: 152627MB at ata2-master SATA300 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ad6: 152627MB at ata3-master SATA300 GEOM: ad4s1: geometry does not match label (255h,63s !=3D 16h,63s). ad10: 238475MB at ata5-master SATA300 acd0: DVDR at ata6-master SATA150 acd1: DVDR at ata7-master SATA150 hdac0: HDA Codec #0: Analog Devices AD1988B pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 pcm2: at cad 0 nid 1 on hdac0 GEOM: ad6s1: geometry does not match label (255h,63s !=3D 16h,63s). uhub0: 10 ports with 10 removable, self powered (probe0:ata3:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:ata3:0:0:0): CAM Status: SCSI Status Error (probe0:ata3:0:0:0): SCSI Status: Check Condition (probe0:ata3:0:0:0): NOT READY asc:3a,0 (probe0:ata3:0:0:0): Medium not present sks:0x80,0xffff (probe0:ata3:0:0:0): Unretryable error cd1 at ata4 bus 0 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 3.300MB/s transfers cd1: cd present [1 x 2048 byte records] cd0 at ata3 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! acd1: FAILURE - READ_TOC ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 sks=3D0x40 = 0x00 0x02 acd1: FAILURE - READ_TOC ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 sks=3D0x40 = 0x00 0x02 Root mount waiting for: usbus1 Root mount waiting for: usbus1 uhub1: 10 ports with 10 removable, self powered Root mount waiting for: usbus1 ugen0.2: at usbus0 uhub2: on usbus0 ugen1.2: at usbus1 Trying to mount root from ufs:/dev/ad6s1a uhub2: 4 ports with 2 removable, bus powered ugen0.3: at usbus0 ukbd0: on usbus0 kbd2 at ukbd0 uhid0: on usbus0 ugen0.4: at usbus0 ums0: on usbus0 ums0: 8 buttons and [XYZ] coordinates ID=3D0 ugen0.5: at usbus0 hid_get_item:304: Number of items truncated to 255 hid_get_item:304: Number of items truncated to 255 uhid1: on usbus0 hid_get_item:304: Number of items truncated to 255 hid_get_item:304: Number of items truncated to 255 hid_get_item:304: Number of items truncated to 255 acd1: FAILURE - READ_TOC ILLEGAL REQUEST asc=3D0x24 ascq=3D0x00 sks=3D0x40 = 0x00 0x02 nfe1: link state changed to DOWN nfe1: link state changed to UP pid 98341 (vlc), uid 1001: exited on signal 11 (core dumped) WARNING: R/W mount of / denied. Filesystem is not clean - run fsck WARNING: R/W mount of / denied. Filesystem is not clean - run fsck pid 1642 (npviewer.bin), uid 1001: exited on signal 11 (core dumped) nfe0: link state changed to DOWN nfe0: link state changed to UP Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 00:28:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54ECF106564A for ; Wed, 22 Jul 2009 00:28:05 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A078B8FC08 for ; Wed, 22 Jul 2009 00:28:04 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-211-2.lns11.adl2.internode.on.net [121.45.211.2]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n6M0RxYo012934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Jul 2009 09:58:00 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 22 Jul 2009 10:27:47 +1000 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1845827.QMSQQtVLu2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200907221027.57244.doconnor@gsoft.com.au> X-Spam-Score: -1.41 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: David Boyd Subject: Re: 8.0-BETA2 sysinstall ignoring setting of nonInteractive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 00:28:05 -0000 --nextPart1845827.QMSQQtVLu2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 22 Jul 2009, David Boyd wrote: > With 8.0-BETA(1/2) sysinstall ignores setting of nonInteractive > variable when using USB-based install. > > With or without nonInteractive sysinstall issues message "Using USB > device: da0a" and waits for confirmation. > > This breaks unattended installations using USB device. I think this would fix it, can you test it? Index: media.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =2D-- media.c (revision 195813) +++ media.c (working copy) @@ -262,7 +262,8 @@ mediaDevice =3D devs[0]; if (mediaDevice) mediaDevice->private =3D NULL; =2D msgConfirm("Using USB device: %s", mediaDevice->name); + if (!variable_get(VAR_NONINTERACTIVE)) + msgConfirm("Using USB device: %s", mediaDevice->name); return (mediaDevice ? DITEM_LEAVE_MENU : DITEM_FAILURE); } =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1845827.QMSQQtVLu2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKZl0N5ZPcIHs/zowRAoLJAJ9g6jj7/mBUj4NR3SMfh+3MV1g3fACfVZme 1YXKwM71isOudr84BUtk698= =1V92 -----END PGP SIGNATURE----- --nextPart1845827.QMSQQtVLu2-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 04:18:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2C1A1065672 for ; Wed, 22 Jul 2009 04:18:02 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 86B5D8FC0C for ; Wed, 22 Jul 2009 04:18:02 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id DEA803BD0B8; Wed, 22 Jul 2009 00:18:01 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 22 Jul 2009 00:18:01 -0400 X-Sasl-enc: XauY4Rs8kJvaxL+oRTrapHDs3SxjDWBEIIzrAhtnLouZ 1248236281 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 1353C38917; Wed, 22 Jul 2009 00:18:00 -0400 (EDT) Message-ID: <4A6692F7.4080905@incunabulum.net> Date: Wed, 22 Jul 2009 05:17:59 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: d@delphij.net References: <4A5F8010.7050504@delphij.net> <4A5F7540.7070201@delphij.net> <4A5EF889.6040604@delphij.net> <4A61544E.2050208@delphij.net> In-Reply-To: <4A61544E.2050208@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian FREISLICH , FreeBSD Current Subject: Re: CARP broken on -CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 04:18:03 -0000 Hi Xin, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I got it. It was the cached llentry that preventing ether_output() to > choose the right broadcast/multicast address and use the default > gateway's L2 address. Here is a proposed patch. > This patch has been reported to fix a regression with multicast transmission, please can you commit? thanks, BMS From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 04:21:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5619106564A for ; Wed, 22 Jul 2009 04:21:03 +0000 (UTC) (envelope-from i.a.zhuravlev@cbtnet.ru) Received: from mx2.cbtnet.ru (mail.cbtnet.ru [62.33.139.20]) by mx1.freebsd.org (Postfix) with ESMTP id 720078FC0C for ; Wed, 22 Jul 2009 04:21:03 +0000 (UTC) (envelope-from i.a.zhuravlev@cbtnet.ru) Received: from [82.146.37.102] (unknown [82.146.37.102]) by mx2.cbtnet.ru (Eserv/3.4126) with ESMTP id 2058A175C1E for ; Wed, 22 Jul 2009 13:43:01 +0900 (IRKST) Message-ID: <4A668F8A.1060209@cbtnet.ru> Date: Wed, 22 Jul 2009 13:03:22 +0900 From: Ilya Zhuravlev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: acer extensa 5630, btx loader panics (cd boot) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 04:21:04 -0000 I'm trying to install 8.0-beta2 amd64 on this hardware: core 2 duo T5800, 2GB, chipset mobile GM45 express, 160gb sata, wifi Atheros AR5007EG vendor partnumber EX5630-582G16Mi error: BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard panic: free: guard1 fail @0x7b397074 from /usr/src/sys/boot/loader/../../common/console.c:94 -->Press a key on the console for reboot<-- In bios I can change only "load default setting" and ATA-mode (AHCI/IDE) options, and applying any of them doesn't make any sense. Googling doesn't get results for related errors. It seems that console.c was not changed for the last 3 years, 7-releng was skipped and I've tried to boot with 6.0-release i386 (btx loader 1.01) - succesfull. What can I do? From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 04:48:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EBC61065670 for ; Wed, 22 Jul 2009 04:48:59 +0000 (UTC) (envelope-from i.a.zhuravlev@cbtnet.ru) Received: from mx2.cbtnet.ru (mx2.cbtnet.ru [62.33.139.20]) by mx1.freebsd.org (Postfix) with ESMTP id 3AFB88FC27 for ; Wed, 22 Jul 2009 04:48:58 +0000 (UTC) (envelope-from i.a.zhuravlev@cbtnet.ru) Received: from [82.146.37.102] (unknown [82.146.37.102]) by mx2.cbtnet.ru (Eserv/3.4126) with ESMTP id B7FE5175C25 for ; Wed, 22 Jul 2009 14:28:32 +0900 (IRKST) Message-ID: <4A669A36.2030202@cbtnet.ru> Date: Wed, 22 Jul 2009 13:48:54 +0900 From: Ilya Zhuravlev User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ru; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4A668F8A.1060209@cbtnet.ru> In-Reply-To: <4A668F8A.1060209@cbtnet.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: acer extensa 5630, btx loader panics (cd boot) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 04:48:59 -0000 big sorry for noise, checksums for writed and downloaded image are not the same > I'm trying to install 8.0-beta2 amd64 on this hardware: > core 2 duo T5800, 2GB, chipset mobile GM45 express, 160gb sata, wifi > Atheros AR5007EG > vendor partnumber EX5630-582G16Mi > > error: > > BTX loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > panic: free: guard1 fail @0x7b397074 from > /usr/src/sys/boot/loader/../../common/console.c:94 > -->Press a key on the console for reboot<-- > > In bios I can change only "load default setting" and ATA-mode > (AHCI/IDE) options, and applying any of them doesn't make any sense. > Googling doesn't get results for related errors. > It seems that console.c was not changed for the last 3 years, 7-releng > was skipped and I've tried to boot with 6.0-release i386 (btx loader > 1.01) - succesfull. > What can I do? From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 05:11:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC4321065672 for ; Wed, 22 Jul 2009 05:11:49 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5732F8FC14 for ; Wed, 22 Jul 2009 05:11:49 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from pi by home.opsec.eu with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTU7H-00048q-PW for current@freebsd.org; Wed, 22 Jul 2009 07:11:47 +0200 Date: Wed, 22 Jul 2009 07:11:47 +0200 From: Kurt Jaeger To: current@freebsd.org Message-ID: <20090722051147.GD70703@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Cc: Subject: amd64: 8-BETA2 on qemu 0.10.6 on fbsd7.2-stable ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 05:11:50 -0000 Hi! Can anyone share a hint on how to get amd64 FreeBSD 8 BETA2 running inside qemu (from the ports, 0.10.6) on a FreeBSD 7.2-STABLE amd64 ? Or some point on where to start debugging ? I'm starting it with: qemu-system-x86_64 \ -s \ -boot d -cdrom /serv/8.0-BETA2-amd64-disc1.iso \ -hda f8-64.qcow2 -m 512 \ -kernel-kqemu \ -net nic,macaddr=52:54:00:12:34:03 \ -net tap,ifname=tap3,script=/qserv/bin/ifup,downscript=no \ -vnc ":8" \ -no-acpi -name f8-64.opsec.eu -serial stdio It hangs after trying to mount from md0. Thanks! -- pi@opsec.eu +49 171 3101372 11 years to go ! From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 05:19:01 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0044B106564A for ; Wed, 22 Jul 2009 05:19:00 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 831FC8FC13 for ; Wed, 22 Jul 2009 05:19:00 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: by fxm18 with SMTP id 18so213214fxm.43 for ; Tue, 21 Jul 2009 22:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Y3pp/wYx0L6nm6nScChdPlgtbcvipUqqs4O9qh1T8zg=; b=TV+GbVmRDdDrjQUX1bQ5GbdEF+CMt0FJTe/Y9/UMxRM39Sad0omAcCbXUr70RH/xwV bUsecOwt3ZZ8dGCt8Vsp7upRNbWRMftBZN7kKrjizBd0cc7QdHHCt3x4ngPeBy00kCll ifQ+X8NCa5ZxQItae2lXgBizxjav6WVe+QoWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=RBP9f6n7UrtiBJyt7x9dOuc/zyUpWLaTXSpzCjEuPpXJML3hv9AaeB8HDuPoYyQBom xW55y3O9tsJHtEHkbS3TTMv7XGeetqjjsoP+b2dSS7P9RS5CDMK4ixJccAajUyEmNEiT eg84+xpfK6///i4EwO7TnfZ3SA9rLsIShOkbU= MIME-Version: 1.0 Received: by 10.239.159.208 with SMTP id z16mr53572hbc.8.1248239939334; Tue, 21 Jul 2009 22:18:59 -0700 (PDT) Date: Wed, 22 Jul 2009 05:18:59 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 22 Jul 2009 06:17:57 +0000 Cc: sfourman@gmail.com, webmaster@doghouserepair.com Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 05:19:01 -0000 > Seeing that nfe apparently worked on June 1st, I headed to the FTP to see > which snapshots were available. =A0The earliest -CURRENT June snapshot wa= s > dated the 8th, so I grabbed that one. =A0The nics didn't work at all. > > So, there's a small window where something changed which broke nfe. Looki= ng > at the SVN commit logs for if_nfe.c, nothing really fits in that window. = =A0To > me, this looks like something about general network device handling chang= ed > which nfe nics can't cope with. =A0I have no idea what that could be thou= gh, > so I'm hoping that someone on this list would be able to point me in the > right direction. > > Ryan Well, you guys picked a helluva week (June 1-8) in which to narrow down problems. It would help if you gave the exact revisions of the snapshots you are using. And if you are going to hunt this down, I would recommend getting a local subversion repository of the sources, so that you can selectively revert changes and then rebuild to test. I have a MCP61-based NIC using nfe, and I haven't had any problems. Since you both have Marvell 88E1116-based chipsets, I'm going to guess that one of yongari@'s changesets from June 2 was the source of your problems: http://svn.freebsd.org/changeset/base/193289 http://svn.freebsd.org/changeset/base/193291 If you revert these and still can't get your NICs to work, then I think that probably the new ACPI import that began on June 5 with r193529 may be the next likely suspect. Regards, b. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 06:20:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B5E106564A for ; Wed, 22 Jul 2009 06:20:54 +0000 (UTC) (envelope-from yurikoles@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5368FC12 for ; Wed, 22 Jul 2009 06:20:53 +0000 (UTC) (envelope-from yurikoles@gmail.com) Received: by fxm18 with SMTP id 18so228212fxm.43 for ; Tue, 21 Jul 2009 23:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:content-type:to:date:subject :mime-version:content-transfer-encoding:from:organization:message-id :user-agent; bh=FrLkyZC9z6V6ZZ0WqvANmU0Kzrp+UOg4A/6iOScvAcA=; b=K6S/fqWesg0ngmZ0RfuOrqBtYlz2HPuJxdlww8e54WIAAXXO0SfAxBouMIeGBhDNxR +M69L0H5m17VnI5evUg26JC4hDBqVB+6GzdnY25txju5Ot9SqhZf8dWn1SLtpMOBr4xl 6FMZj8yojOgrewwymVrofYAq1gMJDeGVgfqbM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:to:date:subject:mime-version:content-transfer-encoding :from:organization:message-id:user-agent; b=Me/mEe2f5Gro98endkMtPl08KLI5H44UO/UeGTJs+j8E88W5l5h34MFeC8aR/K0UoK 6c1OHaQEUMf++vY8BzeSehKYNnHl9818Cl6UXVdmJHIeXgJY4Mgp8kPO68AhPlh7iHaT D8fBHM+WWuZUf8RDWyGJOXv77t9TuwwUCxwCs= Received: by 10.103.160.9 with SMTP id m9mr236210muo.96.1248242335691; Tue, 21 Jul 2009 22:58:55 -0700 (PDT) Received: from debian-squeeze.donsattv ([78.31.179.210]) by mx.google.com with ESMTPS id y6sm31358130mug.40.2009.07.21.22.58.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Jul 2009 22:58:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "FreeBSD Current" Date: Wed, 22 Jul 2009 08:58:53 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yuriy Kolesniokov" Organization: DonNTU Message-ID: User-Agent: Opera Mail/10.00 (Linux) Subject: Building FreeBSD Current on Debian Squeeze AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 06:20:55 -0000 I wish to build Current system (for the athlon64-sse3) and to install it in /sda1. I already checked-out svn sources in /sda1/src. What the next step? From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 06:32:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 782B8106564A; Wed, 22 Jul 2009 06:32:29 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 043CC8FC17; Wed, 22 Jul 2009 06:32:28 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id CA6175C027; Wed, 22 Jul 2009 14:32:26 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 87EBA55CD8B2; Wed, 22 Jul 2009 14:32:21 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id yOyOr6iLFMQV; Wed, 22 Jul 2009 14:31:27 +0800 (CST) Received: from charlie.delphij.net (c-67-188-2-183.hsd1.ca.comcast.net [67.188.2.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 7E14155CD8AE; Wed, 22 Jul 2009 14:31:21 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=E8mioTCYYiUrO8y/9LQJwgsFMwT+Dj2mNb7anJ/gIVvdLgMMpwO+x0PSM2qeXfS6E xjmBb5EfTsE7fiIp3SDjA== Message-ID: <4A66B227.6010706@delphij.net> Date: Tue, 21 Jul 2009 23:31:03 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: freebsd-net@freebsd.org, FreeBSD Current X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Bjoern A. Zeeb" Subject: LOR: PFil hook read/write mutex vs if_bridge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 06:32:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks like a new one, anybody care about it? (maybe harmless though. I haven't get a chance to exercise it further) lock order reversal: 1st 0xffffffff809ee9c8 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:74 2nd 0xffffff0003326418 if_bridge (if_bridge) @ /usr/src/sys/net/if_bridge.c:1848 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 _mtx_lock_flags() at _mtx_lock_flags+0x78 bridge_output() at bridge_output+0x67 ether_output() at ether_output+0x558 pf_route() at pf_route+0x5ec pf_test() at pf_test+0x7c4 pf_check_in() at pf_check_in+0x39 pfil_run_hooks() at pfil_run_hooks+0xcf ip_input() at ip_input+0x2eb netisr_dispatch_src() at netisr_dispatch_src+0xb8 ether_demux() at ether_demux+0x17d ether_input() at ether_input+0x18e em_rxeof() at em_rxeof+0x254 em_handle_rxtx() at em_handle_rxtx+0x4b taskqueue_run() at taskqueue_run+0x96 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe - --- trap 0, rip = 0, rsp = 0xffffff80000a6d30, rbp = 0 --- - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpmsicACgkQi+vbBBjt66DkhwCgojNp7zSLd/TNGrNg0rzVMpQ4 /XgAmwdOggz33OT8kBNjClVjz8R56Uy8 =7PU5 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 07:05:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07676106566B for ; Wed, 22 Jul 2009 07:05:41 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7D18FC1D for ; Wed, 22 Jul 2009 07:05:40 +0000 (UTC) (envelope-from horst@sxemacs.org) Received: from [114.76.235.20] (c114-76-235-20.farfl3.nsw.optusnet.com.au [114.76.235.20]) (authenticated sender horst.burkhardt) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n6M75bNO013290; Wed, 22 Jul 2009 17:05:38 +1000 From: Horst =?ISO-8859-1?Q?G=FCnther?= Burkhardt III To: FreeBSD PowerPC ML , freeBSD-CURRENT Mailing List Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VEUQmCh/7/Ta87HgKMMl" Date: Wed, 22 Jul 2009 17:07:03 +1000 Message-Id: <1248246423.8056.96.camel@horst-tla> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 Cc: Subject: questions about 8.0-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 07:05:41 -0000 --=-VEUQmCh/7/Ta87HgKMMl Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Ok. So, I heard it on the 'tubes that 8.0 is in BETA atm, and will rock pretty damned hard.=20 But, I have a few questions, being a PowerPC user, and also having some disappointment with the state of things in 7.2 especially on this platform.=20 First, has libm finally had the log2 functions defined in the C99 spec added? (this is an issue dating back to 2005, standards/83845 ) Second, I'm aware that altivec support is implemented in -CURRENT, as of some months ago, will this be stable enough for release?=20 Third (more a support question), what's a good and quick way to clean out every port? I'll need to recompile everything (damn tier 2 ;)) Fourth, how is the new shared versioning meant to work? Thanks in advance,=20 -- Horst. --=-VEUQmCh/7/Ta87HgKMMl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (GNU/Linux) iEYEABECAAYFAkpmupcACgkQRtTtv0BbTe6GDgCghvyCtYzShpol7SUoJ9qQ/Gc8 qOsAn0RGUBsCD+YLj/Zv8PZ85zt1ueuD =Mq3T -----END PGP SIGNATURE----- --=-VEUQmCh/7/Ta87HgKMMl-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 07:24:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A06A1065687 for ; Wed, 22 Jul 2009 07:24:43 +0000 (UTC) (envelope-from phoemix@harmless.hu) Received: from marvin.harmless.hu (marvin.harmless.hu [195.56.55.204]) by mx1.freebsd.org (Postfix) with ESMTP id DCF318FC1A for ; Wed, 22 Jul 2009 07:24:42 +0000 (UTC) (envelope-from phoemix@harmless.hu) Received: from [217.150.130.134] (helo=unknown) by marvin.harmless.hu with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTWBr-0007iC-0c; Wed, 22 Jul 2009 09:24:39 +0200 Date: Wed, 22 Jul 2009 09:24:37 +0200 From: Gergely CZUCZY To: Horst =?ISO-8859-2?Q?G=FCnther?= Burkhardt III Message-ID: <20090722092437.00005d83@unknown> In-Reply-To: <1248246423.8056.96.camel@horst-tla> References: <1248246423.8056.96.camel@horst-tla> Organization: Harmless Digital Bt X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Sender: Czuczy Gergely Cc: List , freeBSD-CURRENT, FreeBSD PowerPC ML Subject: Re: questions about 8.0-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 07:24:43 -0000 Hello, For the ports part: pkg_delete -fa rm -rf /usr/ports/*/*/work That'll result in a clean system, without any ports, and a wiping workdirs. If you also want to remove the currently specified OPTIONS, than also wipe /var/db/ports/ . man pkg_delete; and man ports will help you understand what are these command doing. On Wed, 22 Jul 2009 17:07:03 +1000 Horst G=FCnther Burkhardt III wrote: > Ok. >=20 > So, I heard it on the 'tubes that 8.0 is in BETA atm, and will rock > pretty damned hard.=20 >=20 > But, I have a few questions, being a PowerPC user, and also having > some disappointment with the state of things in 7.2 especially on this > platform.=20 >=20 > First, has libm finally had the log2 functions defined in the C99 spec > added? (this is an issue dating back to 2005, standards/83845 ) >=20 > Second, I'm aware that altivec support is implemented in -CURRENT, as > of some months ago, will this be stable enough for release?=20 >=20 > Third (more a support question), what's a good and quick way to clean > out every port? I'll need to recompile everything (damn tier 2 ;)) >=20 > Fourth, how is the new shared versioning meant to work? >=20 > Thanks in advance,=20 >=20 > -- Horst. >=20 --=20 Sincerely, Gergely CZUCZY Harmless Digital Bt +36-30-9702963 From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 07:57:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F529106564A for ; Wed, 22 Jul 2009 07:57:01 +0000 (UTC) (envelope-from simon@siel.si) Received: from mail.siel.si (mail.siel.si [85.10.14.26]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9CC8FC12 for ; Wed, 22 Jul 2009 07:57:01 +0000 (UTC) (envelope-from simon@siel.si) Received: from localhost (localhost [85.10.14.26]) by mail.siel.si (Postfix) with ESMTP id 0CA6F393628 for ; Wed, 22 Jul 2009 09:39:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at siel.si Received: from mail.siel.si ([85.10.14.26]) by localhost (pu1b.siel.si [85.10.14.26]) (amavisd-new, port 10024) with ESMTP id zecvoUxXlkil for ; Wed, 22 Jul 2009 09:39:01 +0200 (CEST) Received: from [10.0.1.20] (cpe-77.38.25.175.cable.t-1.si [77.38.25.175]) by mail.siel.si (Postfix) with ESMTP id EFD9B393283 for ; Wed, 22 Jul 2009 09:39:00 +0200 (CEST) Message-Id: From: =?WINDOWS-1252?Q?Simon_=8Eekar?= To: List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 22 Jul 2009 09:39:00 +0200 X-Mailer: Apple Mail (2.935.3) Subject: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 07:57:01 -0000 Hello, I'm running into difficulties booting FreeBSD 8.0 BETA2 amd64 CD image on a HP DL380 G6. it freezes right after USB hubs & CD initialization with the messsage: umass0: on usbus5 umass0: 8070i (ATAPI) over Bulk-Only; quirks = 0x0000 umass0:2:0:-1: Attached to scbus2 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config panic: run_interrupt_driven_config_hooks: waited too long cpuid = 0 KDB: enter : panic [thread pid 0 tid 100000] Stopped at kdb_enter+0x3d: movq $0,0x687f60(%rip) db> keyboard freezes here, so no way I can do backtrace. The same error is with 7.2-RELEASE bootable CD, but there it just freezes, no messages about waiting for xpt_config. What's there to be done ? I can provide remote access to iLO of this server if this would somehow help fix things. Thank you, Simon. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 08:01:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A91B7106566B for ; Wed, 22 Jul 2009 08:01:52 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from mail.math.leidenuniv.nl (mail.math.leidenuniv.nl [132.229.231.57]) by mx1.freebsd.org (Postfix) with ESMTP id 732C78FC12 for ; Wed, 22 Jul 2009 08:01:52 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from [132.229.231.13] (polaris.math.leidenuniv.nl [132.229.231.13]) by mail.math.leidenuniv.nl (Postfix) with ESMTP id 83DE66E7CB; Wed, 22 Jul 2009 10:01:50 +0200 (CEST) From: Marten Vijn To: Yuriy Kolesniokov In-Reply-To: References: Content-Type: text/plain Date: Wed, 22 Jul 2009 10:01:50 +0200 Message-Id: <1248249710.3232.19.camel@polaris> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Building FreeBSD Current on Debian Squeeze AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 08:01:52 -0000 On Wed, 2009-07-22 at 08:58 +0300, Yuriy Kolesniokov wrote: > I wish to build Current system (for the athlon64-sse3) and to install it > in /sda1. I already checked-out svn sources in /sda1/src. What the next > step? if your goal is to install FreeBSD I would qemu apt-get install qemu qemu -hda /dev/sda -cdrom freebsd.iso -boot d # note, unless you want to wack your debian install: - make sure you have bootloader and linuxpartion (not mbr) - or find a to boot FreeBSD form grub/lilo and don't install the bootloader. Personally I prefeer grub in the linux partition. cheers Marten > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 08:03:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E94A106566C for ; Wed, 22 Jul 2009 08:03:12 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id F12C88FC1E for ; Wed, 22 Jul 2009 08:03:11 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n6M837QK001849; Wed, 22 Jul 2009 02:03:08 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A66C7BB.6030307@samsco.org> Date: Wed, 22 Jul 2009 02:03:07 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: =?windows-1252?Q?Simon_=8Eekar?= References: In-Reply-To: X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: List Subject: Re: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 08:03:12 -0000 This is probably a CISS P410 controller, right? It'll say exactly what it is further up in the boot messages. I know of the problem here, and I'm working on a fix. However, it might be a few more days before I have anything that can be tested. Scott Simon Žekar wrote: > Hello, > > I'm running into difficulties booting FreeBSD 8.0 BETA2 amd64 CD image > on a HP DL380 G6. > > it freezes right after USB hubs & CD initialization with the messsage: > > umass0: on usbus5 > umass0: 8070i (ATAPI) over Bulk-Only; quirks = 0x0000 > umass0:2:0:-1: Attached to scbus2 > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > panic: run_interrupt_driven_config_hooks: waited too long > cpuid = 0 > KDB: enter : panic > [thread pid 0 tid 100000] > Stopped at kdb_enter+0x3d: movq $0,0x687f60(%rip) > db> > > keyboard freezes here, so no way I can do backtrace. > > The same error is with 7.2-RELEASE bootable CD, but there it just > freezes, no messages about waiting for xpt_config. > > What's there to be done ? > > I can provide remote access to iLO of this server if this would somehow > help fix things. > > Thank you, > Simon. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 08:31:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E664A106564A for ; Wed, 22 Jul 2009 08:31:28 +0000 (UTC) (envelope-from simon@siel.si) Received: from mail.siel.si (mail.siel.si [85.10.14.26]) by mx1.freebsd.org (Postfix) with ESMTP id 9F7E68FC0C for ; Wed, 22 Jul 2009 08:31:28 +0000 (UTC) (envelope-from simon@siel.si) Received: from localhost (localhost [85.10.14.26]) by mail.siel.si (Postfix) with ESMTP id 1EAC9393710 for ; Wed, 22 Jul 2009 10:31:27 +0200 (CEST) X-Virus-Scanned: amavisd-new at siel.si Received: from mail.siel.si ([85.10.14.26]) by localhost (pu1b.siel.si [85.10.14.26]) (amavisd-new, port 10024) with ESMTP id 6yJr+32QHPoz for ; Wed, 22 Jul 2009 10:31:26 +0200 (CEST) Received: from [10.0.1.20] (cpe-77.38.25.175.cable.t-1.si [77.38.25.175]) by mail.siel.si (Postfix) with ESMTP id 756B9393681 for ; Wed, 22 Jul 2009 10:31:26 +0200 (CEST) Message-Id: <79F52CDC-5B40-4023-9158-49518D628AFF@siel.si> From: =?WINDOWS-1252?Q?Simon_=8Eekar?= To: List In-Reply-To: <4A66C7BB.6030307@samsco.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 22 Jul 2009 10:31:26 +0200 References: <4A66C7BB.6030307@samsco.org> X-Mailer: Apple Mail (2.935.3) Subject: Re: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 08:31:29 -0000 Yes, P410 controller. Will try it as soon as possible. Thank you, S. On Jul 22, 2009, at 10:03 AM, Scott Long wrote: > This is probably a CISS P410 controller, right? It'll say exactly > what it is further up in the boot messages. I know of the problem > here, and > I'm working on a fix. However, it might be a few more days before I > have anything that can be tested. > > Scott From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 08:40:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 773C2106564A for ; Wed, 22 Jul 2009 08:40:25 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: from smtp113.sbc.mail.mud.yahoo.com (smtp113.sbc.mail.mud.yahoo.com [68.142.198.212]) by mx1.freebsd.org (Postfix) with SMTP id 3C99F8FC18 for ; Wed, 22 Jul 2009 08:40:24 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: (qmail 78276 invoked from network); 22 Jul 2009 08:40:24 -0000 Received: from unknown (HELO ?10.10.10.3?) (webmaster@69.108.138.13 with plain) by smtp113.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2009 08:40:24 -0000 X-YMail-OSG: Da4jFZYVM1nqwUCW1k0JZXizkrYoMpuSU4Cv8MH0afJMVAeEL3SQl2oIkr5bdVF007FeKAUpbFV80UfyiKl4del1t0jESr0DOybYUvQt_3uYH90essT1bscDnEaz1XdVE5PtOpuHXSPKlmWPf1nSqrTOVIKGJlXXlsQo_OKST9Jb7QQvwVDBqag917OzlrX7DtzS6G6dCdUJiRgaO7UgJ7sEuZD8wK5F2TsjL2tsitLN6A9QmkFDQ3jaHLGkH9sBsFxVROaKeLK3f96wUj4VuadotNn0lU3ofjSIQYRp.jwJ4ZUMSkGtrnm8LqzBSIAP6EHoWfE5pZ.tIpthgsO4BNs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A66CFFC.30601@doghouserepair.com> Date: Wed, 22 Jul 2009 01:38:20 -0700 From: Ryan Rogers User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: "b. f." References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 08:40:25 -0000 b. f. wrote: >> Seeing that nfe apparently worked on June 1st, I headed to the FTP to see >> which snapshots were available. The earliest -CURRENT June snapshot was >> dated the 8th, so I grabbed that one. The nics didn't work at all. >> >> So, there's a small window where something changed which broke nfe. Looking >> at the SVN commit logs for if_nfe.c, nothing really fits in that window. To >> me, this looks like something about general network device handling changed >> which nfe nics can't cope with. I have no idea what that could be though, >> so I'm hoping that someone on this list would be able to point me in the >> right direction. >> >> Ryan > > Well, you guys picked a helluva week (June 1-8) in which to narrow > down problems. It would help if you gave the exact revisions of the > snapshots you are using. And if you are going to hunt this down, I > would recommend getting a local subversion repository of the sources, > so that you can selectively revert changes and then rebuild to test. > > I have a MCP61-based NIC using nfe, and I haven't had any problems. > Since you both have Marvell 88E1116-based chipsets, I'm going to guess > that one of yongari@'s changesets from June 2 was the source of your > problems: > > http://svn.freebsd.org/changeset/base/193289 > http://svn.freebsd.org/changeset/base/193291 > > If you revert these and still can't get your NICs to work, then I > think that probably the new ACPI import that began on June 5 with > r193529 may be the next likely suspect. > > Regards, > b. > > Aha! I updated my 7.2-RELEASE install to r193288, and everything worked fine. I then updated to r193289, and nfe broke! Now that I know what I'm looking for, I'll see what I can do to get it working in the morning. Thanks! Ryan From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 08:41:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4506106564A for ; Wed, 22 Jul 2009 08:41:05 +0000 (UTC) (envelope-from simon@siel.si) Received: from mail.siel.si (mail.siel.si [85.10.14.26]) by mx1.freebsd.org (Postfix) with ESMTP id 7C97D8FC16 for ; Wed, 22 Jul 2009 08:41:05 +0000 (UTC) (envelope-from simon@siel.si) Received: from localhost (localhost [85.10.14.26]) by mail.siel.si (Postfix) with ESMTP id 46959392ED8; Wed, 22 Jul 2009 10:41:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at siel.si Received: from mail.siel.si ([85.10.14.26]) by localhost (pu1b.siel.si [85.10.14.26]) (amavisd-new, port 10024) with ESMTP id vgqdyYABUa9l; Wed, 22 Jul 2009 10:41:01 +0200 (CEST) Received: from [10.0.1.20] (cpe-77.38.25.175.cable.t-1.si [77.38.25.175]) by mail.siel.si (Postfix) with ESMTP id EFCC73937D8; Wed, 22 Jul 2009 10:41:00 +0200 (CEST) Message-Id: <7CEF3215-9B5C-4CC5-BD0B-D9EBD0669419@siel.si> From: =?ISO-8859-2?Q?Simon_=AEekar?= To: "Rajaie Issaid" In-Reply-To: <018e01ca0aa4$30c80690$925813b0$@com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 22 Jul 2009 10:41:00 +0200 References: <018e01ca0aa4$30c80690$925813b0$@com> X-Mailer: Apple Mail (2.935.3) Cc: 'List' Subject: Re: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 08:41:06 -0000 Can't do it right now, since iLO requires USB for keyboard / cd image mount to work. And the server doesn't have CD drive (disk expansion slot) so I have to boot it via USB CD... Can't say no to USB any more... :-( Maybe i'll play a little with PXE install, but this would take some time... Thanks, S. On Jul 22, 2009, at 10:12 AM, Rajaie Issaid wrote: > Hi, > > If you disable the USB ports from the BIOS , would you have the same > problem > ? > > Regards > Rajaie Issaid From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 08:44:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3F3F106564A for ; Wed, 22 Jul 2009 08:44:57 +0000 (UTC) (envelope-from oschonef@techfak.uni-bielefeld.de) Received: from smarthost.TechFak.Uni-Bielefeld.DE (smarthost.TechFak.Uni-Bielefeld.DE [129.70.137.17]) by mx1.freebsd.org (Postfix) with ESMTP id 80FEC8FC18 for ; Wed, 22 Jul 2009 08:44:57 +0000 (UTC) (envelope-from oschonef@techfak.uni-bielefeld.de) Received: from asahi.TechFak.Uni-Bielefeld.DE (asahi.TechFak.Uni-Bielefeld.DE [129.70.137.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smarthost.TechFak.Uni-Bielefeld.DE (Postfix) with ESMTPS id BD01FA3; Wed, 22 Jul 2009 08:29:40 +0000 (UTC) From: oschonef@techfak.uni-bielefeld.de Date: Wed, 22 Jul 2009 10:29:40 +0200 To: Uwe Grohnwaldt Message-ID: <20090722082940.GA18826@asahi.TechFak.Uni-Bielefeld.DE> Mail-Followup-To: oschonef@techfak.uni-bielefeld.de, Uwe Grohnwaldt , freebsd-current@freebsd.org References: <4A65E6EB.50308@grohnwaldt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A65E6EB.50308@grohnwaldt.eu> User-Agent: Mutt/1.4.2i X-Zen: Oooommmmmmmmmmmmmmmmmmmmmmm Cc: freebsd-current@freebsd.org Subject: Re: cpufreq on VIA C7 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 08:44:58 -0000 Hi, Eines schoenen Tages schrieb Uwe Grohnwaldt: > I have a Jetway J7F5M2H-VDE Mainboard with a VIA C7 2GHz CPU. I > installed FreeBSD 7.0-RELEASE and updated it to FreeBSD 8.0 Beta2. [..] > Another problem is, that I have some messages like this in dmesg: > NMI ISA 3c, EISA 0 > NMI ISA 2c, EISA 0 You could try to compile a kernel without the HWPMC_HOOKS option. (see http://www.nabble.com/NMI-ISA-2c,-EISA-ff-td23033469.html) I had similar issues with a Jetway J7F2$something board. The kernel always dropped into DDB after receiving a NMI. I was not able to install CURRENT (respectively 8.0 BETA2) on this system. However, the kernel without the HWPMC_HOOKS options boots successfully. Currently, I am trying to do a source update from STABLE to CURRENT. STABLE does not show this behaviour and just works fine. HTH, Oliver -- -------------------------------------------------------- And remember: "To Infinity And Far Beyond ... Somehow?!" Hi! I'm a .signature virus! Copy me in your ~/.signature to help me spread! <- Save this lifeform ;-) From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 08:56:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0F6A1065672 for ; Wed, 22 Jul 2009 08:56:21 +0000 (UTC) (envelope-from rajaie@palnet.com) Received: from bnet.ps (mail.bnet.ps [93.184.1.1]) by mx1.freebsd.org (Postfix) with ESMTP id 60A9E8FC1A for ; Wed, 22 Jul 2009 08:56:21 +0000 (UTC) (envelope-from rajaie@palnet.com) Received: from [93.184.4.1] (helo=oragon) by bnet.ps with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTWks-000LW3-SW; Wed, 22 Jul 2009 11:00:50 +0300 From: "Rajaie Issaid" To: =?iso-8859-2?Q?'Simon_=AEekar'?= , "'List'" References: In-Reply-To: Date: Wed, 22 Jul 2009 11:12:43 +0300 Message-ID: <018e01ca0aa4$30c80690$925813b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: AcoKoK73GA1QkygYTz2LnhZDLeyC1AAAqygg Cc: Subject: RE: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 08:56:21 -0000 Hi, If you disable the USB ports from the BIOS , would you have the same = problem ? Regards Rajaie Issaid -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Simon =AEekar Sent: Wednesday, July 22, 2009 10:39 AM To: List Subject: run_interrupt_driven_hooks - waiting for xpt_config - booting = on DL380 G6 Hello, I'm running into difficulties booting FreeBSD 8.0 BETA2 amd64 CD image =20 on a HP DL380 G6. it freezes right after USB hubs & CD initialization with the messsage: umass0: on usbus5 umass0: 8070i (ATAPI) over Bulk-Only; quirks =3D 0x0000 umass0:2:0:-1: Attached to scbus2 run_interrupt_driven_hooks: still waiting after 60 seconds for =20 xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for =20 xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for =20 xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for =20 xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for =20 xpt_config panic: run_interrupt_driven_config_hooks: waited too long cpuid =3D 0 KDB: enter : panic [thread pid 0 tid 100000] Stopped at kdb_enter+0x3d: movq $0,0x687f60(%rip) db> keyboard freezes here, so no way I can do backtrace. The same error is with 7.2-RELEASE bootable CD, but there it just =20 freezes, no messages about waiting for xpt_config. What's there to be done ? I can provide remote access to iLO of this server if this would =20 somehow help fix things. Thank you, Simon. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" --=20 This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ----------------------------------------------------- BNET Mail Engine & E-Mail Virus Protection Service =20 ----------------------------------------------------- From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 09:00:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B45E7106564A for ; Wed, 22 Jul 2009 09:00:11 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id 57CAA8FC0A for ; Wed, 22 Jul 2009 09:00:11 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by qyk29 with SMTP id 29so36172qyk.3 for ; Wed, 22 Jul 2009 02:00:10 -0700 (PDT) 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 :content-transfer-encoding; bh=W+9sbSHNDuyOLSRn0Vova7kALMKPyOLrZcH7OL2Ismg=; b=srD6YxtgUKBIef20W7MiI3UZLsKFnL2TBGW8VvAQas2a0jL6HCOnKlMsPnjJI6ZEk9 6+VkMbTthBCG4YneQ8/N4182JL65/8+EZoniRkrGBxmfEfux2GthQACDq80PJa4x785f pOZWHAKeRAwHjA0AKwAXrV5atM10QFJZlGM60= 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:content-transfer-encoding; b=DxtcYtrU3HPUF6fSGiofJ5YDPpzE9boHz4ZyCyJ3duTbBKACouvxJfhnzMzHa7ho0p WDpg04o+Tpyhyv4hsBux44CXSaQ8x2wx5hVnzHG12iFAVv5p+tKUcZqOhYIar5bKU0ej 94A3HrK6IHU8VkKSbA7enQgveHtOxKI9puhaA= MIME-Version: 1.0 Received: by 10.229.95.77 with SMTP id c13mr147711qcn.2.1248253210427; Wed, 22 Jul 2009 02:00:10 -0700 (PDT) In-Reply-To: References: <4A66CFFC.30601@doghouserepair.com> Date: Wed, 22 Jul 2009 04:00:10 -0500 Message-ID: <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> From: "Sam Fourman Jr." To: "b. f." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ryan Rogers , FreeBSD Current Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 09:00:12 -0000 On Wed, Jul 22, 2009 at 3:56 AM, b. f. wrote: > On 7/22/09, Ryan Rogers wrote: > >> >> Aha! =A0I updated my 7.2-RELEASE install to r193288, and everything work= ed >> fine. =A0I then updated to r193289, and nfe broke! =A0Now that I know wh= at >> I'm looking for, I'll see what I can do to get it working in the >> morning. =A0Thanks! >> >> Ryan what do I have to put in my cvs-supfile to get my src tree to have all updates up to r193288? I have never done that before. atm my src is -CURRENT as of like a hour ago= . Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 09:02:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E419E1065689 for ; Wed, 22 Jul 2009 09:02:00 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 99B4D8FC1F for ; Wed, 22 Jul 2009 09:02:00 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 9A31178F52; Wed, 22 Jul 2009 13:01:58 +0400 (MSD) Message-ID: <4A66D587.9060001@haruhiism.net> Date: Wed, 22 Jul 2009 13:01:59 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Sam Fourman Jr." References: <4A66CFFC.30601@doghouserepair.com> <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> In-Reply-To: <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ryan Rogers , FreeBSD Current , "b. f." Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 09:02:01 -0000 Sam Fourman Jr. wrote: > what do I have to put in my cvs-supfile to get my src tree to have all > updates up to r193288? > I have never done that before. atm my src is -CURRENT as of like a hour ago. > In such cases it's advised that you use Subversion (/usr/ports/devel/subversion-freebsd) instead of cvsup. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 09:28:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22583106564A for ; Wed, 22 Jul 2009 09:28:05 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3538FC15 for ; Wed, 22 Jul 2009 09:28:04 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: by bwz19 with SMTP id 19so53029bwz.43 for ; Wed, 22 Jul 2009 02:28:03 -0700 (PDT) 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=z2RK4iq0/mQD3BBue0VKwyjkMzRPiEjggQo/keQM7mg=; b=YPfokTex04Son1eSIu5ANJxYHimCJnK5ewBYWtKdJdsvowjl92NLSpBVf7089Iv8nu xxie1k6E2OMd8/C9ANhNGy7+a9/eF6CbvBjfgeeXYcL5GR7FzycPoTsE0LrpvFadrRWa eCLX9Tm5EJa8Lp3jHaUrA1P/jRuzbVlwRQNe0= 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=XxDizzDor7MyXd6IxXWeynhVa99NjQK5WeskvmoXj5unP7yncQ42MzQugOn57cr/gs cTEwkgxWo0WusgICssRx6FibGJeNn3VB3OJ6Un40ZR5WAMB/5fJvYhxqblMSjsoXG/LM 9Bv8RxgijUMH7hW49Xdm2yfcWagM1ntnZ7A9o= MIME-Version: 1.0 Received: by 10.239.142.3 with SMTP id e3mr72961hba.101.1248254883346; Wed, 22 Jul 2009 02:28:03 -0700 (PDT) In-Reply-To: <4A66D587.9060001@haruhiism.net> References: <4A66CFFC.30601@doghouserepair.com> <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> Date: Wed, 22 Jul 2009 09:28:03 +0000 Message-ID: From: "b. f." To: Kamigishi Rei Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Sam Fourman Jr." , Ryan Rogers , FreeBSD Current Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 09:28:05 -0000 If you are using csup in checkout mode, then you could use a date= ... corresponding to the day prior to the problem commit (see csup(1) ), rather than the usual tag=. , but then you would lose the good changes after that point -- and there have been many. Or, even better, you could place a pattern corresponding to the file that caused the problem in your refuse file, and update that file by hand independently of the rest of your sources, which you would continue to csup. If you are using csup in cvs mode rather than checkout mode then you could use any number of workarounds. But I agree with K. Rei -- subversion is better. Install devel/subversion, and then checkout the sources: svn co svn://svn.freebsd.org/base/head svn merge -c -193289 Thereafter, in the root of the repo: svn up svn merge b. On 7/22/09, Kamigishi Rei wrote: > Sam Fourman Jr. wrote: >> what do I have to put in my cvs-supfile to get my src tree to have all >> updates up to r193288? >> I have never done that before. atm my src is -CURRENT as of like a hour >> ago. >> > > In such cases it's advised that you use Subversion > (/usr/ports/devel/subversion-freebsd) instead of cvsup. > -- > Kamigishi Rei > KREI-RIPE > From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 10:07:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20CA6106566B for ; Wed, 22 Jul 2009 10:07:45 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id CCD0A8FC1F for ; Wed, 22 Jul 2009 10:07:44 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by yxe11 with SMTP id 11so112485yxe.3 for ; Wed, 22 Jul 2009 03:07:44 -0700 (PDT) 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:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=akSdDQc9/Wc2pHQ2eyaFbLUN1mD3zwiNRyuzJR78ab0=; b=nTzR6x43CtqFwWmYfKx01gLb726zjHPP6Ujl6+F57+RrhumoTZdvhd6plTQbiOxfql QWvo+oq64Evc2fR2khEBhEUkdQyZuaP3RzCyac0S1jr1jOcgY6QqnrbKD4BvsmeyOTVQ VkGaSXe1AFOGtUfuaEVJxPQyU7wUmi2XQhnnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=wyXQYKW1luJJ7e+XFFJs4dne2eE8bVvJGAoGq4LxLDnJb+49r+OhuIY3hE9M7Fvriv AgRkhbzSOCZQJ3o7nqvvJYNNLxTNk/7mPMqwrqmN5Aa5qr5Efs1xRtuLLKCjscZRCN4c YyZzizYgd9PpHQXIi1Bu4a5x5wbEzhIqrshco= MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.100.141.20 with SMTP id o20mr948957and.40.1248257264299; Wed, 22 Jul 2009 03:07:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2009 06:07:44 -0400 X-Google-Sender-Auth: 43cd59375d3d5602 Message-ID: From: Justin Hibbits To: Yuriy Kolesniokov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Building FreeBSD Current on Debian Squeeze AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 10:07:45 -0000 On Wed, Jul 22, 2009 at 1:58 AM, Yuriy Kolesniokov wrote: > I wish to build Current system (for the athlon64-sse3) and to install it in > /sda1. I already checked-out svn sources in /sda1/src. What the next step? > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > You can't compile FreeBSD on debian (I was able to compile many of the tools from BSD a while back, against glibc, but that's a different story). Your only way to install FreeBSD is to do a binary install from the CDs. - Justin From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 10:26:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E93C2106566B for ; Wed, 22 Jul 2009 10:26:08 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id 9B3708FC18 for ; Wed, 22 Jul 2009 10:26:08 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by qyk29 with SMTP id 29so67386qyk.3 for ; Wed, 22 Jul 2009 03:26:08 -0700 (PDT) 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 :content-transfer-encoding; bh=9tJQ0IkGto6F38UJtegvHfUvROpUQDqBnacw6eyHtAM=; b=PSFGCNARCYXf7ATFRIqlrMzMJ3ovKPOX6FDaEV6aPbn1Icy4d4kgqy61UV7fD/yOKY CJRknfzENwLx3Kx818cWD+ywXuDABrOgwe/XQI4HTFV9h3OhQf4JxCu8SPlsmigvx7SN l/qqILwP5FSR/mR4LMOVgeBAR96FJIF8Zijvw= 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:content-transfer-encoding; b=v9Fp5VhNeLVdjPVTqDjior/yqEhgI0BBQcfCJT+uNdnLQKY9VR7DpcrvkmcmeWOxC/ iLhu7b7O40nConcq57bwP8RLbQa68khu6py7lekxKoQkPgP5voW25PPM4Ktss/FFROk6 5H8EmFznz8XM76qJ8XcQeljApjbDT7hBGbNHE= MIME-Version: 1.0 Received: by 10.229.89.138 with SMTP id e10mr170193qcm.13.1248258367945; Wed, 22 Jul 2009 03:26:07 -0700 (PDT) In-Reply-To: References: <4A66CFFC.30601@doghouserepair.com> <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> Date: Wed, 22 Jul 2009 05:26:07 -0500 Message-ID: <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> From: "Sam Fourman Jr." To: "b. f." Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ryan Rogers , FreeBSD Current Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 10:26:09 -0000 > svn co svn://svn.freebsd.org/base/head > svn merge -c -193289 > > Thereafter, in the root of the repo: > svn up > svn merge Confirmed, running the above set of commands fixed my 88E1116 nfe problem everything works as it should now. thanks guys for the help. Sam Fourman Jr. ps. svn was WAY faster than csup, I think I am going to use svn all the time now. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 10:36:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B89EE1065675 for ; Wed, 22 Jul 2009 10:36:52 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 40AD08FC17 for ; Wed, 22 Jul 2009 10:36:51 +0000 (UTC) (envelope-from oliver.pntr@gmail.com) Received: by bwz19 with SMTP id 19so84982bwz.43 for ; Wed, 22 Jul 2009 03:36:51 -0700 (PDT) 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 :content-transfer-encoding; bh=Z0Vn0V4evcCfck3jp1ZdDMOWbWW3rdDXTvGUsiqItMc=; b=a1vQViB+e0jck9fIUdOeBy6+bYzBwDGlUraF0h/kVtxseSFOPxkMc5d/yrCpKytdHD 7ck0zgPnbipOaXduUW0eyqNEp9trfpoIzNnD/tSrAXdqEmXN9nuF9JqRwvxMwDAU7Vff R+mweCXkmvW0g7z+dYYIL8jWDIWfiInokactI= 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:content-transfer-encoding; b=hAva8AiesFkK5BTwEHALf50ioDizKbKIj8y4h4KnQvEbj24H29OrA8ZLX2gY+Tw7Gt su3vXN/7iNczhls0U6VMMFjD9LGwHwxT4SVG3+4kXEHskrO+0GHzvLoImG6Hl+OsFp4W jzC5W48eUoVwEz+gilQc+O5YAm/0lqnTp2cBs= MIME-Version: 1.0 Received: by 10.103.212.9 with SMTP id o9mr345655muq.135.1248257534147; Wed, 22 Jul 2009 03:12:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2009 12:12:14 +0200 Message-ID: <6101e8c40907220312i7b899956w643daccf819f9d35@mail.gmail.com> From: Oliver Pinter To: Justin Hibbits Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Yuriy Kolesniokov , FreeBSD Current Subject: Re: Building FreeBSD Current on Debian Squeeze AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 10:36:53 -0000 debian not only linux based: http://www.debian.org/ports/kfreebsd-gnu/ http://www.debian.org/ports/#nonlinux good playing with this ports, but this port have not FreeBSD feeling... and stability and support, and etc... On 7/22/09, Justin Hibbits wrote: > On Wed, Jul 22, 2009 at 1:58 AM, Yuriy Kolesniokov > wrote: >> I wish to build Current system (for the athlon64-sse3) and to install it >> in >> /sda1. I already checked-out svn sources in /sda1/src. What the next step? >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > You can't compile FreeBSD on debian (I was able to compile many of the > tools from BSD a while back, against glibc, but that's a different > story). Your only way to install FreeBSD is to do a binary install > from the CDs. > > - Justin > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 11:13:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A303E106566C for ; Wed, 22 Jul 2009 11:13:18 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id C9CFD8FC18 for ; Wed, 22 Jul 2009 11:13:17 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by fxm18 with SMTP id 18so102537fxm.43 for ; Wed, 22 Jul 2009 04:13:17 -0700 (PDT) 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 :content-transfer-encoding; bh=c7SE+jHA06tGl/y/gXYbObfSql7lDqGFqw8l3hZrv80=; b=vuWMsum3+vmECJ+sO8BF7fe+poKwPs0q0QaDObgEfs7E8CW0PRfyftHdsyzuAT6E5S KqllkHXV9NVSS3o1StOHaLF96sc/CphDK67bHMLEnQWBubWCEQYEbyckBY6nML3Kjw4I fJCMJzTUxtP6ntwWP6CD5UCk/P8xWm5Eblm7Y= 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:content-transfer-encoding; b=JmGYDZvd1v6wd68AHT5IctpEQZdv4NWHowqu0B9+t9vSJn+gw7XH4+toV6ja/FNm2i H43xd7RFjyHSAjTeGO8aPJC2A9NlLIVfD1MXkcCfNHEuLhsmAFJ/DOvj01i+pMOXde7c 9hxXIPJQZqYxDXYZ075TLIdxAjHJwkzaXaHyk= MIME-Version: 1.0 Received: by 10.204.67.146 with SMTP id r18mr756546bki.88.1248261196829; Wed, 22 Jul 2009 04:13:16 -0700 (PDT) In-Reply-To: <200907212034.04853.gnemmi@gmail.com> References: <4A5D27F2.50208@voicenet.com> <200907201803.32053.gnemmi@gmail.com> <3a142e750907210146u2ce72cadhbdaa71a89be54607@mail.gmail.com> <200907212034.04853.gnemmi@gmail.com> Date: Wed, 22 Jul 2009 13:13:16 +0200 Message-ID: <3a142e750907220413o1afff523s83c03d5f7ca0c044@mail.gmail.com> From: "Paul B. Mahol" To: Gonzalo Nemmi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Adam K Kirchhoff Subject: Re: bge problems when resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 11:13:18 -0000 On 7/22/09, Gonzalo Nemmi wrote: > On Tuesday 21 July 2009 5:46:10 am Paul B. Mahol wrote: >> On 7/20/09, Gonzalo Nemmi wrote: >> > On Sunday 19 July 2009 7:53:52 pm Paul B. Mahol wrote: >> >> On 7/20/09, Gonzalo Nemmi wrote: >> >> > On Sat, Jul 18, 2009 at 12:09 AM, Paul B. Mahol >> >> > >> > >> > wrote: >> >> >> On 7/17/09, Gonzalo Nemmi wrote: >> >> >> > On Wednesday 15 July 2009 8:13:47 am Adam K Kirchhoff wrote: >> >> >> >> On Wednesday 15 July 2009 03:20:45 Paul B. Mahol wrote: >> >> >> >> > On 7/15/09, Adam K Kirchhoff wrote: >> >> >> >> > > Hello all, >> >> >> >> > > >> >> >> >> > > I have a Dell Latitude D610 laptop with 8.0-BETA1 >> >> >> >> > > installed. I hadn't tried suspend/resume for a while >> >> >> >> > > and decided to give it a shot. I was pleasantly >> >> >> >> > > surprised to see that I could suspend to ram, resume, >> >> >> >> > > and have a (relatively) working system (previously the >> >> >> >> > > display would never come back up and the serial console >> >> >> >> > > I had hooked up remained dead). Great job to everyone >> >> >> >> > > who helped make that possible. >> >> >> >> > > >> >> >> >> > > The only real issue that I seem to have now is that bge >> >> >> >> > > is completely unusable after resume. Another individual >> >> >> >> > > seems to have reported similar problems with bge and >> >> >> >> > > resume, but he also had other issues that apparently >> >> >> >> > > trumped his networking issues: >> >> >> >> > > >> >> >> >> > > http://lists.freebsd.org/pipermail/freebsd-current/2009- >> >> >> >> > >Jul y/0090 23.html >> >> >> >> > > >> >> >> >> > > Like him, resuming from suspend gives me: >> >> >> >> > > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> >> > > (phy 1, reg 0, val 32768) >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY read timed out >> >> >> >> > > (phy 1, reg 0, val 0xffffffff) >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> >> > > (phy 1, reg 24, val 3072) >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> >> > > (phy 1, reg 23, val 10) >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> >> > > (phy 1, reg 21, val 12555) >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> >> > > (phy 1, reg 23, val 8223) >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> >> > > (phy 1, reg 21, val 38150) >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> >> > > (phy 1, reg 23, val 16415) >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> >> > > (phy 1, reg 21, val 5346) >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> >> > > (phy 1, reg 24, val 1024) >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out >> >> >> >> > > (phy 1, reg 24, val 7) >> >> >> >> > > >> >> >> >> > > And so on and so forth. >> >> >> >> > > >> >> >> >> > > I thought that compiling if_bge as a module, unloading >> >> >> >> > > it before suspend, and reloading it after resume, might >> >> >> >> > > get this working. However, doing a "kldload if_bge" >> >> >> >> > > after the resume does nothing. Well, the module gets >> >> >> >> > > loaded, but the device doesn't show up. No errors from >> >> >> >> > > kldload, and there is nothing new in dmesg. >> >> >> >> > > >> >> >> >> > > Before the suspend, the device shows up as: >> >> >> >> > > >> >> >> >> > > bge0@pci0:2:0:0: class=0x020000 card=0x01821028 >> >> >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 >> >> >> >> > > vendor = 'Broadcom Corporation' >> >> >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express >> >> >> >> > > (BCM5750A1)' class = network >> >> >> >> > > subclass = ethernet >> >> >> >> > > >> >> >> >> > > After resuming, and reloading the module, it's: >> >> >> >> > > >> >> >> >> > > none1@pci0:2:0:0: class=0x020000 card=0x01821028 >> >> >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 >> >> >> >> > > vendor = 'Broadcom Corporation' >> >> >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express >> >> >> >> > > (BCM5750A1)' class = network >> >> >> >> > > subclass = ethernet >> >> >> >> > > >> >> >> >> > > If there are no ideas, I'll go ahead and open up a pr. >> >> >> >> > > I assume this is just one bug, since both problems (the >> >> >> >> > > PHY issues and the inability to reload the driver) are >> >> >> >> > > both related to the network device. >> >> >> >> > >> >> >> >> > Put this lines into loader.conf and reboot. >> >> >> >> > >> >> >> >> > hw.pci.do_power_nodriver="3" >> >> >> >> > hw.pci.do_power_resume="1" >> >> >> >> > >> >> >> >> > Now, before suspend, unload if_bge and some another driver >> >> >> >> > (sound drivers are best candidate) and load sound driver >> >> >> >> > again, suspend and resume. >> >> >> >> > Now loading if_bge should make it succesfully attach. >> >> >> >> >> >> >> >> Unfortunately, after doing this, reloading the if_bge driver >> >> >> >> causes the laptop to completely lock up... It gets as far >> >> >> >> as: >> >> >> >> >> >> >> >> bge0: > >> >> >> unknown ASIC rev. 0xffff> >> >> >> >> mem 0xdfdf0000-0xdfdfffff irq 16 at device 0.0 on pci2 >> >> >> >> >> >> >> >> And then the entire machine hangs. I'm on ttyv0, so I'd see >> >> >> >> any kernel panic, but nothing like that happens. The screen >> >> >> >> stays on, but nothing else happens till I force a reboot. >> >> >> >> >> >> >> >> Adam >> >> >> > >> >> >> > Hi Adam, Paul ... >> >> >> > I'm the "another individual" from you OP. >> >> >> > I have the same problems you have regarding bge, but they >> >> >> > weren't trumped .. I just had an order of priorities ;) >> >> >> > >> >> >> > Anyways, I tried the solution Paul posted and, just as in >> >> >> > your case, I got a hard lock too ... >> >> >> > >> >> >> > I tried loading if_bge through /boot/loader.conf >> >> >> > Then issued a: >> >> >> > >> >> >> > kldunload if_bge coretemp >> >> >> >> >> >> coretemp is wrong module, it must be one of modules that attach >> >> >> to pci. >> >> > >> >> > Sorry Paul! >> >> > I gave it a go with snd_hda and I got the same result except >> >> > that this time I also got the following message: >> >> >> >> After unloading snd_hda you loaded it again before suspending? >> > >> > Doing so yielded a Fatal trap 12 on BETA2. Yesterday I install >> > BETA2 and here are the results: >> > >> > >> > kldstat >> > >> > Id Refs Address Size Name >> > 1 28 0xc0400000 cf6c70 kernel >> > 2 1 0xc10f7000 11bc0 if_bge.ko >> > 3 1 0xc1109000 1ac4c snd_hda.ko >> > 4 2 0xc1124000 61f78 sound.ko >> > 5 1 0xc1186000 2af4 coretemp.ko >> > 6 1 0xc1189000 a6d8 i915.ko >> > 7 2 0xc1194000 177d4 drm.ko >> > >> > >> > kldunload if_bge snd_hda >> > >> > Jul 20 17:50:49 gargoyle login: ROOT LOGIN (root) ON ttyv0 >> > Jul 20 17:51:06 gargoyle kernel: brgphy0: detached >> > Jul 20 17:51:06 gargoyle kernel: lock order reversal: >> > Jul 20 17:51:06 gargoyle kernel: 1st 0xc0dba45c kernel linker >> > (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1079 >> > Jul 20 17:51:06 gargoyle kernel: 2nd 0xc0dbbc64 sysctl lock (sysctl >> > lock) @ /usr/src/sys/kern/kern_sysctl.c:257 >> > Jul 20 17:51:06 gargoyle kernel: KDB: stack backtrace: >> > Jul 20 17:51:06 gargoyle kernel: >> > db_trace_self_wrapper(c0c6baf4,e6daba34,c08bc995,c08ad6db,c0c6e989, >> >...) at db_trace_self_wrapper+0x26 >> > Jul 20 17:51:06 gargoyle kernel: >> > kdb_backtrace(c08ad6db,c0c6e989,c452bc88,c4529e10,e6daba90,...) at >> > kdb_backtrace+0x29 >> > Jul 20 17:51:06 gargoyle kernel: >> > _witness_debugger(c0c6e989,c0dbbc64,c0c69667,c4529e10,c0c6956e,...) >> > at _witness_debugger+0x25 >> > Jul 20 17:51:06 gargoyle kernel: >> > witness_checkorder(c0dbbc64,9,c0c6956e,101,0,...) at >> > witness_checkorder+0x839 >> > Jul 20 17:51:06 gargoyle kernel: >> > _sx_xlock(c0dbbc64,0,c0c6956e,101,c4722c00,...) at _sx_xlock+0x85 >> > Jul 20 17:51:06 gargoyle kernel: >> > sysctl_ctx_free(c4722c4c,c4722c00,e6dabb18,c08a3c85,c4722c00,...) >> > at sysctl_ctx_free+0x30 >> > Jul 20 17:51:06 gargoyle kernel: >> > device_sysctl_fini(c4722c00,0,c0d4c848,c472a810,c4ab3400,...) at >> > device_sysctl_fini+0x1a >> > Jul 20 17:51:06 gargoyle kernel: >> > device_detach(c4722c00,c4722b80,e6dabb38,c06bc622,c4722b80,...) at >> > device_detach+0x1f5 >> > Jul 20 17:51:06 gargoyle kernel: >> > bus_generic_detach(c4722b80,c4722b80,e6dabb64,c08a3b1c,c4722b80,... >> >) at bus_generic_detach+0x29 >> > Jul 20 17:51:06 gargoyle kernel: >> > miibus_detach(c4722b80,c45d6060,c0d4ca68,a3c,c0c76f47,...) at >> > miibus_detach+0x12 >> > Jul 20 17:51:06 gargoyle kernel: >> > device_detach(c4722b80,c472b008,e6dabb98,c10ff7ff,c4722300,...) at >> > device_detach+0x8c >> > Jul 20 17:51:06 gargoyle kernel: >> > bus_generic_detach(c4722300,1,c1104b66,aec,c4722300,...) at >> > bus_generic_detach+0x29 >> > Jul 20 17:51:06 gargoyle kernel: >> > bge_detach(c4722300,c4677060,c0d4ca68,a3c,c4526300,...) at >> > bge_detach+0xbf >> > Jul 20 17:51:06 gargoyle kernel: >> > device_detach(c4722300,c086c843,c0dbb570,c1106c20,c456fb80,...) at >> > device_detach+0x8c >> > Jul 20 17:51:06 gargoyle kernel: >> > driver_module_handler(c4526300,1,c1106c20,109,0,...) at >> > driver_module_handler+0x29c >> > Jul 20 17:51:06 gargoyle kernel: >> > module_unload(c4526300,c0c652ef,273,270,c08604b6,...) at >> > module_unload+0x43 >> > Jul 20 17:51:06 gargoyle kernel: >> > linker_file_unload(c4544200,0,c0c652ef,437,c10f7000,...) at >> > linker_file_unload+0x15e >> > Jul 20 17:51:06 gargoyle kernel: >> > kern_kldunload(c4b346c0,2,0,e6dabd2c,c0ba8dd3,...) at >> > kern_kldunload+0xd5 >> > Jul 20 17:51:06 gargoyle kernel: >> > kldunloadf(c4b346c0,e6dabcf8,8,c0c6fa4b,c0d50450,...) at >> > kldunloadf+0x2b >> > Jul 20 17:51:06 gargoyle kernel: syscall(e6dabd38) at syscall+0x2a3 >> > Jul 20 17:51:06 gargoyle kernel: Xint0x80_syscall() at >> > Xint0x80_syscall+0x20 >> > Jul 20 17:51:06 gargoyle kernel: --- syscall (444, FreeBSD ELF32, >> > kldunloadf), eip = 0x280d516b, esp = 0xbfbfe47c, ebp = 0xbfbfecc8 >> > --- Jul 20 17:51:06 gargoyle kernel: miibus0: detached >> > Jul 20 17:51:06 gargoyle kernel: bge0: detached >> > Jul 20 17:51:06 gargoyle kernel: sysctl_unregister_oid: failed to >> > unregister sysctl >> >> if_bge driver looks very problematic to me. Probably it can not >> detach at all. >> >> > Jul 20 17:51:06 gargoyle kernel: pcm0: detached >> > Jul 20 17:51:06 gargoyle kernel: hdac0: detached >> > >> > >> > kld snd_hda >> >> ^^^ >> You mean kldload. >> >> > Jul 20 17:52:16 gargoyle kernel: hdac0: > > Definition Audio Controller> mem 0xf6dfc000-0xf6dfffff irq 21 at >> > device 27.0 on pci0 >> > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Driver Revision: >> > 20090624_0136 >> > Jul 20 17:52:16 gargoyle kernel: hdac0: [ITHREAD] >> > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel >> > STAC9228X Jul 20 17:52:16 gargoyle kernel: bge0: > > A2, ASIC rev. 0xc002> mem 0xf69f0000-0xf69fffff irq 17 at device >> > 0.0 on pci9 Jul 20 17:52:16 gargoyle kernel: miibus0: on >> > bge0 Jul 20 17:52:16 gargoyle kernel: brgphy0: > > 10/100baseTX PHY> PHY 1 on miibus0 >> > Jul 20 17:52:16 gargoyle kernel: brgphy0: 10baseT, 10baseT-FDX, >> > 100baseTX, 100baseTX-FDX, auto >> > Jul 20 17:52:16 gargoyle kernel: bge0: Ethernet address: >> > 00:23:ae:04:ba:ca >> > Jul 20 17:52:16 gargoyle kernel: bge0: [ITHREAD] >> > Jul 20 17:52:16 gargoyle kernel: pcm0: > > #0 Analog> at cad 0 nid 1 on hdac0 >> > Jul 20 17:52:16 gargoyle kernel: bge0: link state changed to DOWN >> > Jul 20 17:52:18 gargoyle kernel: bge0: link state changed to UP >> >> Why bge0 appeared again? >> >> > acpiconf -s 3 >> >> After this command bge0 should not appear at all because it should >> not be attached to >> device. >> >> > Jul 20 17:53:51 gargoyle acpi: suspend at 20090720 17:53:51 >> > Jul 20 17:53:56 gargoyle kernel: fwohci0: fwohci_pci_suspend >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 0, val 32768) >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 0, val 0xffffffff) >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 24, val 0xffffffff) >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 16, val 0xffffffff) >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 16, val 0) >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, >> > reg 16, val 0xffffffff) >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 16, val 0) >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, >> > reg 23, val 18) >> > Jul 20 17:54:25 gargoyle kernel: bge0: flow-through queue init >> > failed Jul 20 17:54:25 gargoyle kernel: bge0: initialization >> > failure Jul 20 17:54:25 gargoyle kernel: fwohci0: Phy 1394a >> > available S400, 1 ports. >> > Jul 20 17:54:25 gargoyle kernel: fwohci0: Link S400, max_rec 2048 >> > bytes. Jul 20 17:54:25 gargoyle kernel: fwohci0: Initiate bus reset >> > Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: BUS >> > reset Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: >> > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode >> > Jul 20 17:54:25 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 >> > cable IRM irm(0) (me) >> > Jul 20 17:54:25 gargoyle kernel: firewire0: bus manager 0 >> > Jul 20 17:54:25 gargoyle kernel: fwohci0: unrecoverable error >> > Jul 20 17:54:25 gargoyle kernel: wakeup from sleeping state (slept >> > 00:00:29) >> > Jul 20 17:54:25 gargoyle acpi: resumed at 20090720 17:54:25 >> > >> > Should a PR on fwohci and firewire also be filed?? >> >> Try with custom kernel with smaller number of drivers as possible. >> (use modules instead) >> From your mail I dont see where is problem with firewire. > > Done. > > Commented if_bge out of GENERIC, recompiled, loaded if_bge via > loader.conf, kldunloaded if_bge snd_hda, kloaded snd_hda (if_bge did > not show up on dmesg this time), went to sleep (acpiconf -s 3), > resumed, no bge timeouts (only fwohci and firewire messages), then > kldloaded if_bge and got a solid freeze :( Does kldload of if_bge works after boot? (remove if_bge_load="YES" from /boot/loader.conf and load it after boot) Does kldload and kldunload and kldload again of if_bge works (without suspending machine this time)? -- Paul From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 11:39:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52AB21065672 for ; Wed, 22 Jul 2009 11:39:46 +0000 (UTC) (envelope-from adamk@voicenet.com) Received: from QMTA06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by mx1.freebsd.org (Postfix) with ESMTP id E1ED18FC20 for ; Wed, 22 Jul 2009 11:39:45 +0000 (UTC) (envelope-from adamk@voicenet.com) Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA06.westchester.pa.mail.comcast.net with comcast id JymQ1c0060SCNGk56zfm3s; Wed, 22 Jul 2009 11:39:46 +0000 Received: from [192.168.5.101] ([68.45.151.98]) by OMTA09.westchester.pa.mail.comcast.net with comcast id Jzfl1c00327dlBY3VzflLd; Wed, 22 Jul 2009 11:39:46 +0000 From: Adam K Kirchhoff To: "Paul B. Mahol" In-Reply-To: <3a142e750907220413o1afff523s83c03d5f7ca0c044@mail.gmail.com> References: <4A5D27F2.50208@voicenet.com> <200907201803.32053.gnemmi@gmail.com> <3a142e750907210146u2ce72cadhbdaa71a89be54607@mail.gmail.com> <200907212034.04853.gnemmi@gmail.com> <3a142e750907220413o1afff523s83c03d5f7ca0c044@mail.gmail.com> Content-Type: text/plain Date: Wed, 22 Jul 2009 07:39:44 -0400 Message-Id: <1248262784.1724.1.camel@sorrow.ashke.com> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Gonzalo Nemmi Subject: Re: bge problems when resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 11:39:46 -0000 On Wed, 2009-07-22 at 13:13 +0200, Paul B. Mahol wrote: > On 7/22/09, Gonzalo Nemmi wrote: > > On Tuesday 21 July 2009 5:46:10 am Paul B. Mahol wrote: > >> On 7/20/09, Gonzalo Nemmi wrote: > >> > On Sunday 19 July 2009 7:53:52 pm Paul B. Mahol wrote: > >> >> On 7/20/09, Gonzalo Nemmi wrote: > >> >> > On Sat, Jul 18, 2009 at 12:09 AM, Paul B. Mahol > >> >> > > >> > > >> > wrote: > >> >> >> On 7/17/09, Gonzalo Nemmi wrote: > >> >> >> > On Wednesday 15 July 2009 8:13:47 am Adam K Kirchhoff wrote: > >> >> >> >> On Wednesday 15 July 2009 03:20:45 Paul B. Mahol wrote: > >> >> >> >> > On 7/15/09, Adam K Kirchhoff wrote: > >> >> >> >> > > Hello all, > >> >> >> >> > > > >> >> >> >> > > I have a Dell Latitude D610 laptop with 8.0-BETA1 > >> >> >> >> > > installed. I hadn't tried suspend/resume for a while > >> >> >> >> > > and decided to give it a shot. I was pleasantly > >> >> >> >> > > surprised to see that I could suspend to ram, resume, > >> >> >> >> > > and have a (relatively) working system (previously the > >> >> >> >> > > display would never come back up and the serial console > >> >> >> >> > > I had hooked up remained dead). Great job to everyone > >> >> >> >> > > who helped make that possible. > >> >> >> >> > > > >> >> >> >> > > The only real issue that I seem to have now is that bge > >> >> >> >> > > is completely unusable after resume. Another individual > >> >> >> >> > > seems to have reported similar problems with bge and > >> >> >> >> > > resume, but he also had other issues that apparently > >> >> >> >> > > trumped his networking issues: > >> >> >> >> > > > >> >> >> >> > > http://lists.freebsd.org/pipermail/freebsd-current/2009- > >> >> >> >> > >Jul y/0090 23.html > >> >> >> >> > > > >> >> >> >> > > Like him, resuming from suspend gives me: > >> >> >> >> > > > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> >> > > (phy 1, reg 0, val 32768) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY read timed out > >> >> >> >> > > (phy 1, reg 0, val 0xffffffff) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> >> > > (phy 1, reg 24, val 3072) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> >> > > (phy 1, reg 23, val 10) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> >> > > (phy 1, reg 21, val 12555) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> >> > > (phy 1, reg 23, val 8223) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> >> > > (phy 1, reg 21, val 38150) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> >> > > (phy 1, reg 23, val 16415) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> >> > > (phy 1, reg 21, val 5346) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> >> > > (phy 1, reg 24, val 1024) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed out > >> >> >> >> > > (phy 1, reg 24, val 7) > >> >> >> >> > > > >> >> >> >> > > And so on and so forth. > >> >> >> >> > > > >> >> >> >> > > I thought that compiling if_bge as a module, unloading > >> >> >> >> > > it before suspend, and reloading it after resume, might > >> >> >> >> > > get this working. However, doing a "kldload if_bge" > >> >> >> >> > > after the resume does nothing. Well, the module gets > >> >> >> >> > > loaded, but the device doesn't show up. No errors from > >> >> >> >> > > kldload, and there is nothing new in dmesg. > >> >> >> >> > > > >> >> >> >> > > Before the suspend, the device shows up as: > >> >> >> >> > > > >> >> >> >> > > bge0@pci0:2:0:0: class=0x020000 card=0x01821028 > >> >> >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 > >> >> >> >> > > vendor = 'Broadcom Corporation' > >> >> >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express > >> >> >> >> > > (BCM5750A1)' class = network > >> >> >> >> > > subclass = ethernet > >> >> >> >> > > > >> >> >> >> > > After resuming, and reloading the module, it's: > >> >> >> >> > > > >> >> >> >> > > none1@pci0:2:0:0: class=0x020000 card=0x01821028 > >> >> >> >> > > chip=0x167714e4 rev=0x01 hdr=0x00 > >> >> >> >> > > vendor = 'Broadcom Corporation' > >> >> >> >> > > device = 'NetXtreme Gigabit Ethernet PCI Express > >> >> >> >> > > (BCM5750A1)' class = network > >> >> >> >> > > subclass = ethernet > >> >> >> >> > > > >> >> >> >> > > If there are no ideas, I'll go ahead and open up a pr. > >> >> >> >> > > I assume this is just one bug, since both problems (the > >> >> >> >> > > PHY issues and the inability to reload the driver) are > >> >> >> >> > > both related to the network device. > >> >> >> >> > > >> >> >> >> > Put this lines into loader.conf and reboot. > >> >> >> >> > > >> >> >> >> > hw.pci.do_power_nodriver="3" > >> >> >> >> > hw.pci.do_power_resume="1" > >> >> >> >> > > >> >> >> >> > Now, before suspend, unload if_bge and some another driver > >> >> >> >> > (sound drivers are best candidate) and load sound driver > >> >> >> >> > again, suspend and resume. > >> >> >> >> > Now loading if_bge should make it succesfully attach. > >> >> >> >> > >> >> >> >> Unfortunately, after doing this, reloading the if_bge driver > >> >> >> >> causes the laptop to completely lock up... It gets as far > >> >> >> >> as: > >> >> >> >> > >> >> >> >> bge0: >> >> >> >> unknown ASIC rev. 0xffff> > >> >> >> >> mem 0xdfdf0000-0xdfdfffff irq 16 at device 0.0 on pci2 > >> >> >> >> > >> >> >> >> And then the entire machine hangs. I'm on ttyv0, so I'd see > >> >> >> >> any kernel panic, but nothing like that happens. The screen > >> >> >> >> stays on, but nothing else happens till I force a reboot. > >> >> >> >> > >> >> >> >> Adam > >> >> >> > > >> >> >> > Hi Adam, Paul ... > >> >> >> > I'm the "another individual" from you OP. > >> >> >> > I have the same problems you have regarding bge, but they > >> >> >> > weren't trumped .. I just had an order of priorities ;) > >> >> >> > > >> >> >> > Anyways, I tried the solution Paul posted and, just as in > >> >> >> > your case, I got a hard lock too ... > >> >> >> > > >> >> >> > I tried loading if_bge through /boot/loader.conf > >> >> >> > Then issued a: > >> >> >> > > >> >> >> > kldunload if_bge coretemp > >> >> >> > >> >> >> coretemp is wrong module, it must be one of modules that attach > >> >> >> to pci. > >> >> > > >> >> > Sorry Paul! > >> >> > I gave it a go with snd_hda and I got the same result except > >> >> > that this time I also got the following message: > >> >> > >> >> After unloading snd_hda you loaded it again before suspending? > >> > > >> > Doing so yielded a Fatal trap 12 on BETA2. Yesterday I install > >> > BETA2 and here are the results: > >> > > >> > > >> > kldstat > >> > > >> > Id Refs Address Size Name > >> > 1 28 0xc0400000 cf6c70 kernel > >> > 2 1 0xc10f7000 11bc0 if_bge.ko > >> > 3 1 0xc1109000 1ac4c snd_hda.ko > >> > 4 2 0xc1124000 61f78 sound.ko > >> > 5 1 0xc1186000 2af4 coretemp.ko > >> > 6 1 0xc1189000 a6d8 i915.ko > >> > 7 2 0xc1194000 177d4 drm.ko > >> > > >> > > >> > kldunload if_bge snd_hda > >> > > >> > Jul 20 17:50:49 gargoyle login: ROOT LOGIN (root) ON ttyv0 > >> > Jul 20 17:51:06 gargoyle kernel: brgphy0: detached > >> > Jul 20 17:51:06 gargoyle kernel: lock order reversal: > >> > Jul 20 17:51:06 gargoyle kernel: 1st 0xc0dba45c kernel linker > >> > (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1079 > >> > Jul 20 17:51:06 gargoyle kernel: 2nd 0xc0dbbc64 sysctl lock (sysctl > >> > lock) @ /usr/src/sys/kern/kern_sysctl.c:257 > >> > Jul 20 17:51:06 gargoyle kernel: KDB: stack backtrace: > >> > Jul 20 17:51:06 gargoyle kernel: > >> > db_trace_self_wrapper(c0c6baf4,e6daba34,c08bc995,c08ad6db,c0c6e989, > >> >...) at db_trace_self_wrapper+0x26 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > kdb_backtrace(c08ad6db,c0c6e989,c452bc88,c4529e10,e6daba90,...) at > >> > kdb_backtrace+0x29 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > _witness_debugger(c0c6e989,c0dbbc64,c0c69667,c4529e10,c0c6956e,...) > >> > at _witness_debugger+0x25 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > witness_checkorder(c0dbbc64,9,c0c6956e,101,0,...) at > >> > witness_checkorder+0x839 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > _sx_xlock(c0dbbc64,0,c0c6956e,101,c4722c00,...) at _sx_xlock+0x85 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > sysctl_ctx_free(c4722c4c,c4722c00,e6dabb18,c08a3c85,c4722c00,...) > >> > at sysctl_ctx_free+0x30 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > device_sysctl_fini(c4722c00,0,c0d4c848,c472a810,c4ab3400,...) at > >> > device_sysctl_fini+0x1a > >> > Jul 20 17:51:06 gargoyle kernel: > >> > device_detach(c4722c00,c4722b80,e6dabb38,c06bc622,c4722b80,...) at > >> > device_detach+0x1f5 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > bus_generic_detach(c4722b80,c4722b80,e6dabb64,c08a3b1c,c4722b80,... > >> >) at bus_generic_detach+0x29 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > miibus_detach(c4722b80,c45d6060,c0d4ca68,a3c,c0c76f47,...) at > >> > miibus_detach+0x12 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > device_detach(c4722b80,c472b008,e6dabb98,c10ff7ff,c4722300,...) at > >> > device_detach+0x8c > >> > Jul 20 17:51:06 gargoyle kernel: > >> > bus_generic_detach(c4722300,1,c1104b66,aec,c4722300,...) at > >> > bus_generic_detach+0x29 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > bge_detach(c4722300,c4677060,c0d4ca68,a3c,c4526300,...) at > >> > bge_detach+0xbf > >> > Jul 20 17:51:06 gargoyle kernel: > >> > device_detach(c4722300,c086c843,c0dbb570,c1106c20,c456fb80,...) at > >> > device_detach+0x8c > >> > Jul 20 17:51:06 gargoyle kernel: > >> > driver_module_handler(c4526300,1,c1106c20,109,0,...) at > >> > driver_module_handler+0x29c > >> > Jul 20 17:51:06 gargoyle kernel: > >> > module_unload(c4526300,c0c652ef,273,270,c08604b6,...) at > >> > module_unload+0x43 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > linker_file_unload(c4544200,0,c0c652ef,437,c10f7000,...) at > >> > linker_file_unload+0x15e > >> > Jul 20 17:51:06 gargoyle kernel: > >> > kern_kldunload(c4b346c0,2,0,e6dabd2c,c0ba8dd3,...) at > >> > kern_kldunload+0xd5 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > kldunloadf(c4b346c0,e6dabcf8,8,c0c6fa4b,c0d50450,...) at > >> > kldunloadf+0x2b > >> > Jul 20 17:51:06 gargoyle kernel: syscall(e6dabd38) at syscall+0x2a3 > >> > Jul 20 17:51:06 gargoyle kernel: Xint0x80_syscall() at > >> > Xint0x80_syscall+0x20 > >> > Jul 20 17:51:06 gargoyle kernel: --- syscall (444, FreeBSD ELF32, > >> > kldunloadf), eip = 0x280d516b, esp = 0xbfbfe47c, ebp = 0xbfbfecc8 > >> > --- Jul 20 17:51:06 gargoyle kernel: miibus0: detached > >> > Jul 20 17:51:06 gargoyle kernel: bge0: detached > >> > Jul 20 17:51:06 gargoyle kernel: sysctl_unregister_oid: failed to > >> > unregister sysctl > >> > >> if_bge driver looks very problematic to me. Probably it can not > >> detach at all. > >> > >> > Jul 20 17:51:06 gargoyle kernel: pcm0: detached > >> > Jul 20 17:51:06 gargoyle kernel: hdac0: detached > >> > > >> > > >> > kld snd_hda > >> > >> ^^^ > >> You mean kldload. > >> > >> > Jul 20 17:52:16 gargoyle kernel: hdac0: >> > Definition Audio Controller> mem 0xf6dfc000-0xf6dfffff irq 21 at > >> > device 27.0 on pci0 > >> > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Driver Revision: > >> > 20090624_0136 > >> > Jul 20 17:52:16 gargoyle kernel: hdac0: [ITHREAD] > >> > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel > >> > STAC9228X Jul 20 17:52:16 gargoyle kernel: bge0: >> > A2, ASIC rev. 0xc002> mem 0xf69f0000-0xf69fffff irq 17 at device > >> > 0.0 on pci9 Jul 20 17:52:16 gargoyle kernel: miibus0: on > >> > bge0 Jul 20 17:52:16 gargoyle kernel: brgphy0: >> > 10/100baseTX PHY> PHY 1 on miibus0 > >> > Jul 20 17:52:16 gargoyle kernel: brgphy0: 10baseT, 10baseT-FDX, > >> > 100baseTX, 100baseTX-FDX, auto > >> > Jul 20 17:52:16 gargoyle kernel: bge0: Ethernet address: > >> > 00:23:ae:04:ba:ca > >> > Jul 20 17:52:16 gargoyle kernel: bge0: [ITHREAD] > >> > Jul 20 17:52:16 gargoyle kernel: pcm0: >> > #0 Analog> at cad 0 nid 1 on hdac0 > >> > Jul 20 17:52:16 gargoyle kernel: bge0: link state changed to DOWN > >> > Jul 20 17:52:18 gargoyle kernel: bge0: link state changed to UP > >> > >> Why bge0 appeared again? > >> > >> > acpiconf -s 3 > >> > >> After this command bge0 should not appear at all because it should > >> not be attached to > >> device. > >> > >> > Jul 20 17:53:51 gargoyle acpi: suspend at 20090720 17:53:51 > >> > Jul 20 17:53:56 gargoyle kernel: fwohci0: fwohci_pci_suspend > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 0, val 32768) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 0, val 0xffffffff) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 24, val 0xffffffff) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 16, val 0xffffffff) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 16, val 0) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy 1, > >> > reg 16, val 0xffffffff) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 16, val 0) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy 1, > >> > reg 23, val 18) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: flow-through queue init > >> > failed Jul 20 17:54:25 gargoyle kernel: bge0: initialization > >> > failure Jul 20 17:54:25 gargoyle kernel: fwohci0: Phy 1394a > >> > available S400, 1 ports. > >> > Jul 20 17:54:25 gargoyle kernel: fwohci0: Link S400, max_rec 2048 > >> > bytes. Jul 20 17:54:25 gargoyle kernel: fwohci0: Initiate bus reset > >> > Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: BUS > >> > reset Jul 20 17:54:25 gargoyle kernel: fwohci0: fwohci_intr_core: > >> > node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode > >> > Jul 20 17:54:25 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 > >> > cable IRM irm(0) (me) > >> > Jul 20 17:54:25 gargoyle kernel: firewire0: bus manager 0 > >> > Jul 20 17:54:25 gargoyle kernel: fwohci0: unrecoverable error > >> > Jul 20 17:54:25 gargoyle kernel: wakeup from sleeping state (slept > >> > 00:00:29) > >> > Jul 20 17:54:25 gargoyle acpi: resumed at 20090720 17:54:25 > >> > > >> > Should a PR on fwohci and firewire also be filed?? > >> > >> Try with custom kernel with smaller number of drivers as possible. > >> (use modules instead) > >> From your mail I dont see where is problem with firewire. > > > > Done. > > > > Commented if_bge out of GENERIC, recompiled, loaded if_bge via > > loader.conf, kldunloaded if_bge snd_hda, kloaded snd_hda (if_bge did > > not show up on dmesg this time), went to sleep (acpiconf -s 3), > > resumed, no bge timeouts (only fwohci and firewire messages), then > > kldloaded if_bge and got a solid freeze :( > > Does kldload of if_bge works after boot? (remove if_bge_load="YES" > from /boot/loader.conf > and load it after boot) > Does kldload and kldunload and kldload again of if_bge works (without > suspending machine this time)? I can boot up without if_bge loaded and then kldload and kldunload if_bge repeatedly at least 6 times each without any lockups if suspending is not involved (I stopped after the 6th time). Adam From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 11:42:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FDE8106566C; Wed, 22 Jul 2009 11:42:36 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 710488FC18; Wed, 22 Jul 2009 11:42:34 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=fdJvomzR7vYA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=Ji3BvMXWxxaO2p4yc0gA:9 a=faHlwAL8sKWly2CGk6UuwK25AywA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1182220679; Wed, 22 Jul 2009 13:42:33 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 22 Jul 2009 13:42:20 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <200907211439.05703.hselasky@c2i.net> <200907211245.02949.jkim@FreeBSD.org> <200907212241.45704.hselasky@c2i.net> In-Reply-To: <200907212241.45704.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907221342.21588.hselasky@c2i.net> Cc: Rui Paulo , Jung-uk Kim Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 (regression issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 11:42:36 -0000 Hi, I can confirm that FreeBSD/i386 7.2-RELEASE is booting fine on my MacBookPro5.5, so it appears to me like a regression issue that FreeBSD/i386 8.0-BETA2 is not booting fine. The only significant dmesg difference I see is that in 7.2 there is a "kbd0 at kbdmux0" line before acpi0 is probed. --HPS On Tuesday 21 July 2009 22:41:43 Hans Petter Selasky wrote: > > I've attached dmesg from Ubuntu 9.x booting on the same machine. Anything > more you want me to try? > > --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 11:50:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FA36106564A; Wed, 22 Jul 2009 11:50:33 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-ew0-f222.google.com (mail-ew0-f222.google.com [209.85.219.222]) by mx1.freebsd.org (Postfix) with ESMTP id 765E98FC1A; Wed, 22 Jul 2009 11:50:32 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by ewy22 with SMTP id 22so128378ewy.43 for ; Wed, 22 Jul 2009 04:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=3lMpRB9BbxI3Jtw+Mv9nIjJVJnPwe4KOP0DKLI5oPHo=; b=ayek3+rMFlTYxZowv4pgzStKhmQm7iGWrmSLYt62EZD6vFqffS3+ALonwU5XKia9Jz bnAGTwxcS5TBW0tLWYqI68UHuOl54TYG7mnQAYh6qGVssY9cSgNPzIYWByQ9TBtBhvZ8 WOgNJF1haZWsYUHUB/u0EctsPy4wK2msjP5Co= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=mlYRWDV/xjM+z/ky0FpkflJhxeOnhXYKfV1zVakD884YIqTfvpG/eNV4Ki0X1YoiBC GW8IOTgLkne+1CCouwOp1t1ESks7xZhBo2Don5UsSllWxH8ocrijK2EscbpdD1veVgko rnTn1wLecLaXtlk5hBLXnSJ49NiQNVosOs6U4= Received: by 10.211.168.4 with SMTP id v4mr6509619ebo.82.1248263431328; Wed, 22 Jul 2009 04:50:31 -0700 (PDT) Received: from omega.lan (bl6-145-160.dsl.telepac.pt [82.155.145.160]) by mx.google.com with ESMTPS id 24sm1364653eyx.53.2009.07.22.04.50.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 04:50:30 -0700 (PDT) Sender: Rui Paulo Message-Id: From: Rui Paulo To: Hans Petter Selasky In-Reply-To: <200907221342.21588.hselasky@c2i.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 22 Jul 2009 12:50:29 +0100 References: <200907211439.05703.hselasky@c2i.net> <200907211245.02949.jkim@FreeBSD.org> <200907212241.45704.hselasky@c2i.net> <200907221342.21588.hselasky@c2i.net> X-Mailer: Apple Mail (2.935.3) Cc: freebsd-current@freebsd.org, Jung-uk Kim Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 (regression issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 11:50:33 -0000 On 22 Jul 2009, at 12:42, Hans Petter Selasky wrote: > Hi, > > I can confirm that FreeBSD/i386 7.2-RELEASE is booting fine on my > MacBookPro5.5, so it appears to me like a regression issue that > FreeBSD/i386 > 8.0-BETA2 is not booting fine. > > The only significant dmesg difference I see is that in 7.2 there is > a "kbd0 at > kbdmux0" line before acpi0 is probed. set hint.kbdmux.0.disabled=1 But I doubt that this is the problem. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 12:07:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80A89106566C; Wed, 22 Jul 2009 12:07:38 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9158FC18; Wed, 22 Jul 2009 12:07:37 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=mcijKYuA4Z+deDOw4vYW2gtVN0t7HarKpsxkXgh7IFXmk5foG692F7cE5EwYcwjDihgq+f1YyyKsksxZe/zT1mTZiEFiP9waU0Ff1X7MOLSe67QLrsn46xGUnlzTqLJ8PIsjHEud6kkh8mFoC6Stge2BpxNdBk+aP+u4fOdZ44Y=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MTabg-000PeD-GM; Wed, 22 Jul 2009 16:07:36 +0400 Date: Wed, 22 Jul 2009 16:07:34 +0400 From: Eygene Ryabinkin To: Hans Petter Selasky Message-ID: References: <200907211439.05703.hselasky@c2i.net> <200907211245.02949.jkim@FreeBSD.org> <200907212241.45704.hselasky@c2i.net> <200907221342.21588.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907221342.21588.hselasky@c2i.net> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@freebsd.org, Rui Paulo , Jung-uk Kim Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 (regression issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 12:07:39 -0000 Hans Petter, Jung-uk, good day. Wed, Jul 22, 2009 at 01:42:20PM +0200, Hans Petter Selasky wrote: > I can confirm that FreeBSD/i386 7.2-RELEASE is booting fine on my > MacBookPro5.5, so it appears to me like a regression issue that > FreeBSD/i386 8.0-BETA2 is not booting fine. I happen to have MacBook 5,1 and it behaves as your one, but mine versions are 7.2/amd64 and 8.0-BETA/amd64. > The only significant dmesg difference I see is that in 7.2 there is a > "kbd0 at kbdmux0" line before acpi0 is probed. I see this message both for 7.x and 8.0. The thing is that the IRQ for SCI at my MacBook is 9, so it may be really related to the keyboard issues. May be SCI interrupt is posted after ACPI is enabled and this confuses something. I'll try to look at how APIC stuff is routed, but not today. By the way, are you able to use notebook's keyboard? I can use only external USB one -- internal works as if control is always pressed. May this has something to do with the IRQ 9 as well. I will also try to extract acpidump from my book, but external USB drive/stick isn't reachable due to the EINVAL error. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 12:08:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8AA2106564A; Wed, 22 Jul 2009 12:08:41 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id D859C8FC21; Wed, 22 Jul 2009 12:08:40 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=fdJvomzR7vYA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=l_XfXRlaWWF1GxuJww8A:9 a=w58sYOPiOdffd94tiew1acOdsN0A:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1283227638; Wed, 22 Jul 2009 14:08:39 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 22 Jul 2009 14:08:26 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <200907211439.05703.hselasky@c2i.net> <200907221342.21588.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907221408.28785.hselasky@c2i.net> Cc: Rui Paulo , Jung-uk Kim Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 (regression issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 12:08:42 -0000 On Wednesday 22 July 2009 13:50:29 Rui Paulo wrote: > On 22 Jul 2009, at 12:42, Hans Petter Selasky wrote: > > Hi, > > > > I can confirm that FreeBSD/i386 7.2-RELEASE is booting fine on my > > MacBookPro5.5, so it appears to me like a regression issue that > > FreeBSD/i386 > > 8.0-BETA2 is not booting fine. > > > > The only significant dmesg difference I see is that in 7.2 there is > > a "kbd0 at > > kbdmux0" line before acpi0 is probed. > > set hint.kbdmux.0.disabled=1 > No change. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 12:24:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 347EF1065670; Wed, 22 Jul 2009 12:24:13 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 643E78FC13; Wed, 22 Jul 2009 12:24:12 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=fdJvomzR7vYA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=iAKwZwA5HVnL7Sp1-SoA:9 a=Vf26X_JBy3boUyuB_Mz3-neBq-oA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 228420277; Wed, 22 Jul 2009 14:24:11 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, rea-fbsd@codelabs.ru Date: Wed, 22 Jul 2009 14:24:00 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <200907211439.05703.hselasky@c2i.net> <200907221342.21588.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907221424.01337.hselasky@c2i.net> Cc: Rui Paulo , Jung-uk Kim Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 (regression issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 12:24:13 -0000 On Wednesday 22 July 2009 14:07:34 Eygene Ryabinkin wrote: > By the way, are you able to use notebook's keyboard? I can use only > external USB one -- internal works as if control is always pressed. > May this has something to do with the IRQ 9 as well. The new USB stack supports the notebook's keyboard. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 13:12:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8ABB1065670 for ; Wed, 22 Jul 2009 13:12:27 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-pz0-f193.google.com (mail-pz0-f193.google.com [209.85.222.193]) by mx1.freebsd.org (Postfix) with ESMTP id 7E45D8FC08 for ; Wed, 22 Jul 2009 13:12:27 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by pzk31 with SMTP id 31so208818pzk.3 for ; Wed, 22 Jul 2009 06:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=MJfkHMK43pDeBsZ1IEQpHHYFNVehehlrfDpPhXLSCiY=; b=KuWuV/IKY0uF6KComW7GSjRs4Y7oeQPfd2GVz7/L8P3dA5BIWux45ySxYtEJzuF4pw /6Aqdqw3xpcC7s6fC9ph8hDz05voPYK9KYhcvRRoY8hn0QMfjFL8h6iVY9jPPgtKdECr MtoZWIRgCo8lXtBNgbNAmoeBlTIAdyIvqe+RU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=sfODk1W17IwOhhE5QCtP38YtItLhE5YjFq21m47XGDUQyFx86Bor5qtKLRBg7YsViG TBAqFvGGZjG7i20ZFUBLoIA20wI5j2nK2402ZV+9qZiE2u0pj9y3ij0TxgfXpg+hJy9o 0xC0gsWV1R3dmIA0+Yk2CdfMdIJMcLxF9taDE= Received: by 10.140.133.4 with SMTP id g4mr550846rvd.282.1248268346494; Wed, 22 Jul 2009 06:12:26 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.108.65]) by mx.google.com with ESMTPS id c20sm1968747rvf.51.2009.07.22.06.12.24 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 06:12:25 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 0B54BB80C2; Wed, 22 Jul 2009 10:12:19 -0300 (BRT) Received: from 189.93.32.46 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Wed, 22 Jul 2009 10:12:19 -0300 (BRT) Message-ID: In-Reply-To: References: Date: Wed, 22 Jul 2009 10:12:19 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: ZFS pool corrupted on upgrade of -current (probably sata renaming) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 13:12:28 -0000 On Wed, July 15, 2009 13:22, Freddie Cash wrote: > On Tue, Jul 14, 2009 at 8:44 PM, Randy Bush wrote: > >> > # glabel label disk01 /dev/ad4 >> > # glabel label disk02 /dev/ad6 >> > # glabel label disk03 /dev/ad8 >> > # zpool create pool raidz1 label/disk01 label/disk02 label/disk03 >> > >> > After that, you can shuffle the drives around in the system, and the >> pool >> > will continue to work correctly. >> >> ooooooo! i wish i had understood that when i built a large set of >> mirrored raid. >> >> any way to hack it ex post facto? >> > > Yep. It's as simple as: > > * label all the drives using glabel, while they're still attached to the > pool > * use "zpool replace pool ad4 label/disk01" to replace 1 drive > * wait for it to resilver > * use "zpool replace pool ad6 label/disk02" to replace the next drive > * repeat the resilver and replace until all the devices are replaced > > This is what I did to one of our servers. Works quite nicely. > > There's no need to detach anything. was all this supposed to work with raidz ? here it doesn't. harry# zpool status pool: zdados state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM zdados ONLINE 0 0 0 raidz1 ONLINE 0 0 0 ad8 ONLINE 0 0 0 ad10 ONLINE 0 0 0 ad12 ONLINE 0 0 0 errors: No known data errors harry# zpool detach zdados ad8 cannot detach ad8: only applicable to mirror and replacing vdevs thanks, matheus ps: using 7.2R with v13 zfs. got problems when booting current and trying to use zfs on it (dual freebsd boot). -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 08:19:30 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7592106568D for ; Wed, 22 Jul 2009 08:19:30 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 5315B8FC4F for ; Wed, 22 Jul 2009 08:19:29 +0000 (UTC) (envelope-from bf1783@googlemail.com) Received: by bwz19 with SMTP id 19so23188bwz.43 for ; Wed, 22 Jul 2009 01:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=1U0m8CnkigzcMqOzOdWBhhwzJPSwHi58CPq84Rb/BNI=; b=lDfRwuvDcDWaLCGRtMNsRppL/13200pGjcgyzXrxT79YWWRUq3PvfdqofNSaQn6oTp Be3p7zOZJWBy2iSq7laaZA5v//ET4izox+iCr9b0A2XB9vhUrp4uv7DqKfQIJval6oR+ EKnx7RaZvSr03uNYisVfwvHghFVBxy9E2BeQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ACw/RmmT3FFDrIbrTJCUDr91VFBTYQUyzkNF+A0PK+WLUHOY45Y+IwOkJwPOHmQQxw 80E9fFpor9zf8BfS5c9ivhUHEV3p0prXPfv/Z5xQ1kf6dH81LSrJxW7oChf4TLyGBNLt lfqLVLrzxBKXDXikGcQzkhFOgFvMKu2oy5ckQ= MIME-Version: 1.0 Received: by 10.239.162.81 with SMTP id k17mr60330hbd.116.1248250768997; Wed, 22 Jul 2009 01:19:28 -0700 (PDT) Date: Wed, 22 Jul 2009 08:19:28 +0000 Message-ID: From: "b. f." To: freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Jul 2009 13:15:38 +0000 Cc: horst@sxemacs.org Subject: Re: questions about 8.0-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 08:19:31 -0000 >First, has libm finally had the log2 functions defined in the C99 spec >added? (this is an issue dating back to 2005, standards/83845 ) No, nor some other functions in the spec. But you could add it by patching libm or using libmap.conf(5) to divert the loader from libm to a library of your own. Someone posted an implementation for a port derived from Sun sources in: http://lists.freebsd.org/pipermail/freebsd-multimedia/2009-March/009819.html >Second, I'm aware that altivec support is implemented in -CURRENT, as of >some months ago, will this be stable enough for release? I don't know. I haven't seen any complaints about it. >Third (more a support question), what's a good and quick way to clean >out every port? I'll need to recompile everything (damn tier 2 ;)) pkg_delete -af rm -r /usr/local/lib/compat/pkg rm -r /var/db/pkg/* rm -r /usr/local/* (if you don't have any locally-modified configuration files you want to keep..) rm -r /var/db/ports/* (if you want to wipe your recorded port OPTIONS ...) >Fourth, how is the new shared versioning meant to work? Do you mean this?: http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt b. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 13:21:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A582D10656B4; Wed, 22 Jul 2009 13:21:05 +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 717FF8FC16; Wed, 22 Jul 2009 13:21:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1A4A746B58; Wed, 22 Jul 2009 09:21:05 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 640038A09F; Wed, 22 Jul 2009 09:21:04 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 22 Jul 2009 08:14:37 -0400 User-Agent: KMail/1.9.7 References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <4A6628F0.6080802@mail.zedat.fu-berlin.de> <20090721215201.GA61999@troutmask.apl.washington.edu> In-Reply-To: <20090721215201.GA61999@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907220814.38246.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 22 Jul 2009 09:21:04 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: "O. Hartmann" , Thomas Backman , Olivier SMEDTS , FreeBSD current , Steve Kargl , Ken Smith Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 13:21:06 -0000 On Tuesday 21 July 2009 5:52:01 pm Steve Kargl wrote: > On Tue, Jul 21, 2009 at 10:45:36PM +0200, O. Hartmann wrote: > > > > I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB > > RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you > > imagine how long this box will be occupied by 'portupgrade -af'? I guess > > 'cherry-picking' is the only solution. > > How many of those 800 ports are actually necessary and used? > It would be better to get generate a complete list of your > installed ports, use pkg_deinstall or pkg_delete to remove > all ports, and then selectively re-install ports that are > actually used. Xorg takes up ~200 ports alone (not including dependencies like perl, etc.) since the Xorg decided release engineering was too hard. Throw in things like KDE, OOo, Firefox, etc. for a desktop and you can get a fairly high package count. :-/ -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 13:21:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7751010656E5; Wed, 22 Jul 2009 13:21:09 +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 476AA8FC28; Wed, 22 Jul 2009 13:21:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F07EC46B4C; Wed, 22 Jul 2009 09:21:08 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id EFAF28A0A2; Wed, 22 Jul 2009 09:21:07 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 22 Jul 2009 08:28:11 -0400 User-Agent: KMail/1.9.7 References: <4A660E83.6080004@cs.duke.edu> <200907211617.40842.jkim@FreeBSD.org> <4A6629F8.1090503@cs.duke.edu> In-Reply-To: <4A6629F8.1090503@cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907220828.11999.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 22 Jul 2009 09:21:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Andrew Gallatin , Jung-uk Kim , current@freebsd.org Subject: Re: loader.conf ignores setting variable ending in _type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 13:21:10 -0000 On Tuesday 21 July 2009 4:50:00 pm Andrew Gallatin wrote: > Jung-uk Kim wrote: > > On Tuesday 21 July 2009 04:05 pm, Jung-uk Kim wrote: > > >> *_type Defines the module's type. If none is given, it > >> defaults to a kld module. > > > > Actually, I wanted to quote this: > > > > loader.conf(5): > > > > WARNING: developers should never use these suffixes for any > > kernel environment variables (tunables) or conflicts > > will result. > > Whoops.. Thanks for pointing that out. Presumably we could relax that a bit and for the reserved tunables ignore tunables with "." in their name. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 13:21:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7751010656E5; Wed, 22 Jul 2009 13:21:09 +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 476AA8FC28; Wed, 22 Jul 2009 13:21:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F07EC46B4C; Wed, 22 Jul 2009 09:21:08 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id EFAF28A0A2; Wed, 22 Jul 2009 09:21:07 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 22 Jul 2009 08:28:11 -0400 User-Agent: KMail/1.9.7 References: <4A660E83.6080004@cs.duke.edu> <200907211617.40842.jkim@FreeBSD.org> <4A6629F8.1090503@cs.duke.edu> In-Reply-To: <4A6629F8.1090503@cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907220828.11999.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 22 Jul 2009 09:21:08 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Andrew Gallatin , Jung-uk Kim , current@freebsd.org Subject: Re: loader.conf ignores setting variable ending in _type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 13:21:10 -0000 On Tuesday 21 July 2009 4:50:00 pm Andrew Gallatin wrote: > Jung-uk Kim wrote: > > On Tuesday 21 July 2009 04:05 pm, Jung-uk Kim wrote: > > >> *_type Defines the module's type. If none is given, it > >> defaults to a kld module. > > > > Actually, I wanted to quote this: > > > > loader.conf(5): > > > > WARNING: developers should never use these suffixes for any > > kernel environment variables (tunables) or conflicts > > will result. > > Whoops.. Thanks for pointing that out. Presumably we could relax that a bit and for the reserved tunables ignore tunables with "." in their name. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 13:22:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0424106576B; Wed, 22 Jul 2009 13:22:45 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 493A58FC1A; Wed, 22 Jul 2009 13:22:45 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by yxe11 with SMTP id 11so292195yxe.3 for ; Wed, 22 Jul 2009 06:22:44 -0700 (PDT) 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:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=eJOeg9/3PD7CeqOe83cyuArjflWhqH1UVM8cHfZ5Hzs=; b=ZdBEae4ujtlbJ/NlRy1tOiLmT9Plw3P72xiTXLbFrQjFOtXPF3iwqgDfa3BaVjIlXS YCRJbfNHwvfrbeoAhGVJZNdpjO946DpON2W5ga4w7urbG6KoH0tA3WAzSaW8wr/YLCTM mZyUuV9VlkL3s69no2gDsIUv1jmgo6hlaKaBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=qMZAL1M6g6fNbeP4iEg806BX42j53R8n32YRQJ425XLx3mSH7icuERpklok82qupfJ SbDaQp+VR6XJY1lCw3Dw8zDRMux6Itr1MNOWL5KKchSFsa/hAn1waRR/2T5v/ulQ27qM 4sJhezmiPkxyyTtit/uEWrY6jpBtuT6nrvK8I= MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.100.127.17 with SMTP id z17mr1134923anc.153.1248268964516; Wed, 22 Jul 2009 06:22:44 -0700 (PDT) In-Reply-To: <1248246423.8056.96.camel@horst-tla> References: <1248246423.8056.96.camel@horst-tla> Date: Wed, 22 Jul 2009 09:22:44 -0400 X-Google-Sender-Auth: 34a0c09d89040c9a Message-ID: From: Justin Hibbits To: =?ISO-8859-1?Q?Horst_G=FCnther_Burkhardt_III?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freeBSD-CURRENT Mailing List , FreeBSD PowerPC ML Subject: Re: questions about 8.0-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 13:22:47 -0000 On Wed, Jul 22, 2009 at 3:07 AM, Horst G=FCnther Burkhardt III wrote: > Ok. > > So, I heard it on the 'tubes that 8.0 is in BETA atm, and will rock > pretty damned hard. > > But, I have a few questions, being a PowerPC user, and also having some > disappointment with the state of things in 7.2 especially on this > platform. > > First, has libm finally had the log2 functions defined in the C99 spec > added? (this is an issue dating back to 2005, standards/83845 ) > > Second, I'm aware that altivec support is implemented in -CURRENT, as of > some months ago, will this be stable enough for release? I've been compiling everything with altivec for the past few months, with no problems, and I abuse the hell out of my system, so I can safely say that it's stable enough for release. Base won't have it enabled, but you can enable it for ports in make.conf. - Justin From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 13:29:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8772B1065679; Wed, 22 Jul 2009 13:29:34 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 41E058FC0A; Wed, 22 Jul 2009 13:29:34 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n6MDTWeR011794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 09:29:33 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n6MDTWeR011794 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1248269373; bh=hNIXlA2LccAD+7WLApFvDMj/Vx5G2O9oI8fMkiA4I7w=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aFwBmKb1vtBxyV2mtlhvcOaMrKm5DwjI+0/a3yWil6mBO1P6jhIOgm0GcAqrJ3zH3 wSoGo73XH6JCDPeqejHFHr7Wd5rN9pvN0az+flSpUi3gh5eGMWYxgds7NTiebm++S7 mG3epTZC8NtH8IgeuiC1mu3fPvcM+D+EQryiUFX8= Message-ID: <4A671435.2060005@cs.duke.edu> Date: Wed, 22 Jul 2009 09:29:25 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: John Baldwin References: <4A660E83.6080004@cs.duke.edu> <200907211617.40842.jkim@FreeBSD.org> <4A6629F8.1090503@cs.duke.edu> <200907220828.11999.jhb@freebsd.org> In-Reply-To: <200907220828.11999.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Jung-uk Kim Subject: Re: loader.conf ignores setting variable ending in _type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 13:29:35 -0000 John Baldwin wrote: > On Tuesday 21 July 2009 4:50:00 pm Andrew Gallatin wrote: >> Jung-uk Kim wrote: >>> On Tuesday 21 July 2009 04:05 pm, Jung-uk Kim wrote: >>>> *_type Defines the module's type. If none is given, it >>>> defaults to a kld module. >>> Actually, I wanted to quote this: >>> >>> loader.conf(5): >>> >>> WARNING: developers should never use these suffixes for any >>> kernel environment variables (tunables) or conflicts >>> will result. >> Whoops.. Thanks for pointing that out. > > Presumably we could relax that a bit and for the reserved tunables ignore > tunables with "." in their name. > That would be nice. But it is not a big deal to fix it in the mxge driver by changing the tunable name (already done, actually). Drew From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 13:29:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8772B1065679; Wed, 22 Jul 2009 13:29:34 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 41E058FC0A; Wed, 22 Jul 2009 13:29:34 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n6MDTWeR011794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 09:29:33 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu n6MDTWeR011794 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1248269373; bh=hNIXlA2LccAD+7WLApFvDMj/Vx5G2O9oI8fMkiA4I7w=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=aFwBmKb1vtBxyV2mtlhvcOaMrKm5DwjI+0/a3yWil6mBO1P6jhIOgm0GcAqrJ3zH3 wSoGo73XH6JCDPeqejHFHr7Wd5rN9pvN0az+flSpUi3gh5eGMWYxgds7NTiebm++S7 mG3epTZC8NtH8IgeuiC1mu3fPvcM+D+EQryiUFX8= Message-ID: <4A671435.2060005@cs.duke.edu> Date: Wed, 22 Jul 2009 09:29:25 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: John Baldwin References: <4A660E83.6080004@cs.duke.edu> <200907211617.40842.jkim@FreeBSD.org> <4A6629F8.1090503@cs.duke.edu> <200907220828.11999.jhb@freebsd.org> In-Reply-To: <200907220828.11999.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, current@freebsd.org, Jung-uk Kim Subject: Re: loader.conf ignores setting variable ending in _type X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 13:29:35 -0000 John Baldwin wrote: > On Tuesday 21 July 2009 4:50:00 pm Andrew Gallatin wrote: >> Jung-uk Kim wrote: >>> On Tuesday 21 July 2009 04:05 pm, Jung-uk Kim wrote: >>>> *_type Defines the module's type. If none is given, it >>>> defaults to a kld module. >>> Actually, I wanted to quote this: >>> >>> loader.conf(5): >>> >>> WARNING: developers should never use these suffixes for any >>> kernel environment variables (tunables) or conflicts >>> will result. >> Whoops.. Thanks for pointing that out. > > Presumably we could relax that a bit and for the reserved tunables ignore > tunables with "." in their name. > That would be nice. But it is not a big deal to fix it in the mxge driver by changing the tunable name (already done, actually). Drew From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 13:55:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D86D31065692 for ; Wed, 22 Jul 2009 13:55:44 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from mail.math.leidenuniv.nl (84e5e739.math.leidenuniv.nl [132.229.231.57]) by mx1.freebsd.org (Postfix) with ESMTP id A22388FC1C for ; Wed, 22 Jul 2009 13:55:44 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from [132.229.231.13] (polaris.math.leidenuniv.nl [132.229.231.13]) by mail.math.leidenuniv.nl (Postfix) with ESMTP id A7C2C6E8F5 for ; Wed, 22 Jul 2009 15:55:43 +0200 (CEST) From: Marten Vijn To: freebsd-current@freebsd.org Content-Type: text/plain Date: Wed, 22 Jul 2009 15:55:43 +0200 Message-Id: <1248270943.9978.6.camel@polaris> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: thanks for usb install image X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 13:55:45 -0000 ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/8.0/8.0-BETA2-i386-memstick.img work great, thanks Marten -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 14:35:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CECB5106566C for ; Wed, 22 Jul 2009 14:35:43 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id A14858FC18 for ; Wed, 22 Jul 2009 14:35:43 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7.0-5.01 32bit (built Feb 19 2009)) id <0KN600300R3J8700@smtpauth1.wiscmail.wisc.edu>; Wed, 22 Jul 2009 08:35:43 -0500 (CDT) Received: from comporellon.tachypleus.net ([unknown] [76.210.76.212]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7.0-5.01 32bit (built Feb 19 2009)) with ESMTPSA id <0KN600092R3HOJ10@smtpauth1.wiscmail.wisc.edu>; Wed, 22 Jul 2009 08:35:42 -0500 (CDT) Date: Wed, 22 Jul 2009 08:35:40 -0500 From: Nathan Whitehorn In-reply-to: <1248246423.8056.96.camel@horst-tla> To: =?ISO-8859-1?Q?Horst_G=FCnther_Burkhardt_III?= Message-id: <4A6715AC.3000606@freebsd.org> X-Spam-Report: AuthenticatedSender=yes, SenderIP=76.210.76.212 X-Spam-PmxInfo: Server=avs-13, Version=5.5.5.374460, Antispam-Engine: 2.7.1.369594, Antispam-Data: 2009.7.22.132716, SenderIP=76.210.76.212 References: <1248246423.8056.96.camel@horst-tla> User-Agent: Thunderbird 2.0.0.22 (X11/20090625) Cc: freeBSD-CURRENT Mailing List , FreeBSD PowerPC ML Subject: Re: questions about 8.0-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 14:35:44 -0000 Horst Günther Burkhardt III wrote: > Ok. > > So, I heard it on the 'tubes that 8.0 is in BETA atm, and will rock > pretty damned hard. > > But, I have a few questions, being a PowerPC user, and also having some > disappointment with the state of things in 7.2 especially on this > platform. > > First, has libm finally had the log2 functions defined in the C99 spec > added? (this is an issue dating back to 2005, standards/83845 ) > As far as I know, no. Many of the complex functions (e.g. cexp) aren't implemented either, which can be a huge pain. > Second, I'm aware that altivec support is implemented in -CURRENT, as of > some months ago, will this be stable enough for release? There was Altivec in 7.2-RELEASE as well, and it is quite stable. Ports that know about it will use it by themselves, or you can define something like CPUTYPE=7450 in make.conf to have the compiler try to autovectorize things. 8.0 has a bunch of other new PowerPC features like audio, SMP, G5 support, ATA DMA, ADB keyboard and mouse support, some basic power management, including cpufreq, etc. Hopefully it will be a better experience than 7.2 -- the big architectural differences between 8.0 PowerPC and 7.0 PowerPC have made it difficult to MFC things for some time. -Nathan From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 15:12:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEA44106564A for ; Wed, 22 Jul 2009 15:12:09 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 40AEB8FC0C for ; Wed, 22 Jul 2009 15:12:08 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl126-163.kln.forthnet.gr [77.49.245.163]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-9) with ESMTP id n6MFBuZw025176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jul 2009 18:12:04 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n6MFBuQu047100 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 18:11:56 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n6MFBtXb047099; Wed, 22 Jul 2009 18:11:55 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: thompsa@freebsd.org (Andrew Thompson), freebsd-current@freebsd.org Date: Wed, 22 Jul 2009 18:11:54 +0300 Message-ID: <87eis8g3b9.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Hellug-MailScanner-ID: n6MFBuZw025176 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.447, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.05, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: Subject: lagg0 and tcpdump problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 15:12:09 -0000 When I run tcpdump on lagg0 (with em0 and iwn0 as laggports), tcpdump seems to work fine, but typing ^C kills the wireless interface too. My /var/log/messages shows at the time: Jul 22 17:59:29 kobe kernel: --- syscall (6, FreeBSD ELF32, close), eip = 0x28393313, esp = 0xbfbfe78c, ebp = 0xbfbfe7a8 --- Jul 22 17:59:29 kobe kernel: taskqueue_drain with the following non-sleepable locks held: Jul 22 17:59:29 kobe kernel: exclusive rw if_lagg rwlock (if_lagg rwlock) r = 0 (0xcb651704) locked @ /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:953 Jul 22 17:59:29 kobe kernel: exclusive sleep mutex bpf global lock (bpf global lock) r = 0 (0xc0bc1e90) locked @ /usr/src/sys/net/bpf.c:605 Jul 22 17:59:29 kobe kernel: KDB: stack backtrace: Jul 22 17:59:29 kobe kernel: db_trace_self_wrapper(c09a567c,fba428ec,c06be155,c09b0bcd,25d,...) at db_trace_self_wrapper+0x26 Jul 22 17:59:29 kobe kernel: kdb_backtrace(c09b0bcd,25d,ffffffff,c0b90604,fba42924,...) at kdb_backtrace+0x29 Jul 22 17:59:29 kobe kernel: _witness_debugger(c09a7af7,fba42938,4,1,0,...) at _witness_debugger+0x25 Jul 22 17:59:29 kobe kernel: witness_warn(5,0,c0961ec8,137,c673c85c,...) at witness_warn+0x1fd Jul 22 17:59:29 kobe kernel: taskqueue_drain(c673c840,c678c0b8,d5821000,fba42994,c075a5fc,...) at taskqueue_drain+0xa9 Jul 22 17:59:29 kobe kernel: ieee80211_waitfor_parent(c678c000,0,c09b6c55,caf,c678c000,...) at ieee80211_waitfor_parent+0x7b Jul 22 17:59:29 kobe kernel: ieee80211_ioctl(d2633400,80206910,fba429b4,c6515748,8903,...) at ieee80211_ioctl+0x1ac Jul 22 17:59:29 kobe kernel: if_setflag(d2633438,0,fba42a18,c06bdf9c,100,...) at if_setflag+0x10a Jul 22 17:59:29 kobe kernel: ifpromisc(d2633400,0,c7e96a43,431,1,...) at ifpromisc+0x33 Jul 22 17:59:29 kobe kernel: lagg_setflags(cb651704,c7e96a43,3b9,c09b09ad,c650e380,...) at lagg_setflags+0x84 Jul 22 17:59:29 kobe kernel: lagg_ioctl(c7057800,80206910,fba42aec,fba42b1c,8903,...) at lagg_ioctl+0x50c Jul 22 17:59:29 kobe kernel: if_setflag(c7057838,0,c09a0c3d,df,0,...) at if_setflag+0x10a Jul 22 17:59:29 kobe kernel: ifpromisc(c7057800,0,c09b0bcd,236,c6551a4c,...) at ifpromisc+0x33 Jul 22 17:59:29 kobe kernel: bpf_detachd(c0bc1e90,0,c09b0bcd,25d,d93e57a0,...) at bpf_detachd+0x249 Jul 22 17:59:29 kobe kernel: bpf_dtor(ca46a100,0,c099768a,9e,c7789460,...) at bpf_dtor+0xb0 Jul 22 17:59:29 kobe kernel: devfs_destroy_cdevpriv(d93e57a0,0,c099768a,a8,fba42be4,...) at devfs_destroy_cdevpriv+0xac Jul 22 17:59:29 kobe kernel: devfs_fpdrop(c7789460,cd581b40,3,0,c7789460,...) at devfs_fpdrop+0x68 Jul 22 17:59:29 kobe kernel: _fdrop(c7789460,cd581b40,fba42c18,c06bdf9c,0,cd581be4,c0b90600,c0a0afa0,c099cf22,cc5efa2c,45b,c099cf22,fba42c40,c0684440,cc5efa2c,8,c099cf22,45b) at _fdrop+0x53 Jul 22 17:59:29 kobe kernel: closef(c7789460,cd581b40,45b,440,cc5efa2c,...) at closef+0x290 Jul 22 17:59:29 kobe kernel: kern_close(cd581b40,3,fba42d2c,c0932863,cd581b40,...) at kern_close+0x117 Jul 22 17:59:29 kobe kernel: close(cd581b40,fba42cf8,4,c099ed18,c0a01b68,...) at close+0x1a Jul 22 17:59:29 kobe kernel: syscall(fba42d38) at syscall+0x2a3 Jul 22 17:59:29 kobe kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 Jul 22 17:59:29 kobe kernel: --- syscall (6, FreeBSD ELF32, close), eip = 0x28393313, esp = 0xbfbfe78c, ebp = 0xbfbfe7a8 --- Then typing ^C stops tcpdump but the log shows: Jul 22 17:59:29 kobe kernel: wlan0: promiscuous mode disabled Jul 22 17:59:29 kobe kernel: em0: promiscuous mode disabled Jul 22 17:59:29 kobe kernel: iwn0: error, INTR=82000000 STATUS=0x40010000 Jul 22 17:59:29 kobe kernel: lagg0: promiscuous mode disabled Jul 22 17:59:30 kobe kernel: iwn0: iwn_transfer_firmware: timeout waiting for first alive notice, error 35 Jul 22 17:59:30 kobe kernel: iwn0: iwn_init_locked: could not load firmware, error 35 Jul 22 17:59:30 kobe kernel: wlan0: link state changed to DOWN Jul 22 17:59:30 kobe kernel: lagg0: link state changed to DOWN At this point wlan0 is without carrier, and stays that way until I unplumb wlan0 and lagg0 and re-create them. It seems that at this part of if_lagg.c we are locking the lagg softc, but then we call lagg_setflags() -> lagg_setflag(): 953 LAGG_WLOCK(sc); 954 SLIST_FOREACH(lp, &sc->sc_ports, lp_entries) { 955 lagg_setflags(lp, 1); 956 } 957 LAGG_WUNLOCK(sc); but this vectors into the wlan code near if_lagg.c:line 1088. Does it make sense to drop the exclusive lagg lock around the code to the port flag changing code or would this introduce a silly race? %%% --- a/sys/net/if_lagg.c Wed Jul 15 15:29:17 2009 +0300 +++ b/sys/net/if_lagg.c Wed Jul 22 18:10:29 2009 +0300 @@ -1085,7 +1085,9 @@ * in accord with actual ports flags. */ if (status != (lp->lp_ifflags & flag)) { + LAGG_WUNLOCK(sc); error = (*func)(ifp, status); + LAGG_WLOCK(sc); if (error) return (error); lp->lp_ifflags &= ~flag; %%% From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 15:43:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40E441065679 for ; Wed, 22 Jul 2009 15:43:47 +0000 (UTC) (envelope-from vova@sw.ru) Received: from relay.sw.ru (mailhub.sw.ru [195.214.232.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2228FC1C for ; Wed, 22 Jul 2009 15:43:45 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru ([10.30.1.111]) (authenticated bits=0) by relay.sw.ru (8.13.4/8.13.4) with ESMTP id n6MFheVH008777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 19:43:42 +0400 (MSD) Received: from vova by vbook.fbsd.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTdym-0002g1-Dt; Wed, 22 Jul 2009 19:43:40 +0400 From: Vladimir Grebenschikov To: Steve Kargl In-Reply-To: <20090721215201.GA61999@troutmask.apl.washington.edu> References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> <367b2c980907200729s57eafbbfw83c8ae5a94f41ffc@mail.gmail.com> <4A6628F0.6080802@mail.zedat.fu-berlin.de> <20090721215201.GA61999@troutmask.apl.washington.edu> Content-Type: text/plain; charset="KOI8-R" Content-Transfer-Encoding: quoted-printable Date: Wed, 22 Jul 2009 19:43:40 +0400 Message-Id: <1248277420.8644.70.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-stable , "O. Hartmann" , Thomas Backman , Olivier SMEDTS , FreeBSD current , Ken Smith Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 15:43:47 -0000 =F7 =D7=D4, 21/07/2009 =D7 14:52 -0700, Steve Kargl =D0=C9=DB=C5=D4: > On Tue, Jul 21, 2009 at 10:45:36PM +0200, O. Hartmann wrote: > >=20 > > I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB > > RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you > > imagine how long this box will be occupied by 'portupgrade -af'? I gues= s > > 'cherry-picking' is the only solution. >=20 > How many of those 800 ports are actually necessary and used? > It would be better to get generate a complete list of your > installed ports, use pkg_deinstall or pkg_delete to remove > all ports, and then selectively re-install ports that are > actually used. I've found that much faster and cleaner way is to just remove whole /usr/local (preserving /usr/local/etc), and /var/db/pkg and then just install required ports, such process goes much faster. Also it removes all unused ports. As for ports number, it is really crazy, I have 1435 ports for notebook used as usual desktop and as multi-purpose development machine. PS. I am on i386, so can't say anything about amd64 specific performance problems. --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 16:15:49 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 4E029106566B; Wed, 22 Jul 2009 16:15:49 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org, rea-fbsd@codelabs.ru Date: Wed, 22 Jul 2009 12:15:39 -0400 User-Agent: KMail/1.6.2 References: <200907211439.05703.hselasky@c2i.net> <200907221342.21588.hselasky@c2i.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907221215.41757.jkim@FreeBSD.org> Cc: Rui Paulo , Hans Petter Selasky Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 (regression issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:15:49 -0000 On Wednesday 22 July 2009 08:07 am, Eygene Ryabinkin wrote: > Hans Petter, Jung-uk, good day. > > Wed, Jul 22, 2009 at 01:42:20PM +0200, Hans Petter Selasky wrote: > > I can confirm that FreeBSD/i386 7.2-RELEASE is booting fine on my > > MacBookPro5.5, so it appears to me like a regression issue that > > FreeBSD/i386 8.0-BETA2 is not booting fine. > > I happen to have MacBook 5,1 and it behaves as your one, but mine > versions are 7.2/amd64 and 8.0-BETA/amd64. > > > The only significant dmesg difference I see is that in 7.2 there > > is a "kbd0 at kbdmux0" line before acpi0 is probed. > > I see this message both for 7.x and 8.0. > > The thing is that the IRQ for SCI at my MacBook is 9, so it may be > really related to the keyboard issues. May be SCI interrupt is > posted after ACPI is enabled and this confuses something. I'll try > to look at how APIC stuff is routed, but not today. That's quite possible scenario. FYI, all new nVidia chipset Mac's have almost identical ACPI tables. The SMM port is at 0x52e while old Intel Macs were at 0xb2, AFAIK. When we do AcpiEnable(), ACPICA checks if the SCI_EN bit is set. If not, it tries to enable it via writing ACPI_ENABLE value to SMI_CMD port from FADT. In this case, that effectively ends up doing: bus_space_write_1(ACPI_BUS_SPACE_IO, ACPI_BUS_HANDLE, 0x52e, 0xf0); According to HPS, this freezes the system as if it doesn't come back from the SMI handler. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 16:24:50 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 50064106566C; Wed, 22 Jul 2009 16:24:50 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 22 Jul 2009 12:24:36 -0400 User-Agent: KMail/1.6.2 References: <20090722051147.GD70703@home.opsec.eu> In-Reply-To: <20090722051147.GD70703@home.opsec.eu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907221224.40724.jkim@FreeBSD.org> Cc: Kurt Jaeger Subject: Re: amd64: 8-BETA2 on qemu 0.10.6 on fbsd7.2-stable ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:24:50 -0000 On Wednesday 22 July 2009 01:11 am, Kurt Jaeger wrote: > Hi! > > Can anyone share a hint on how to get amd64 FreeBSD 8 BETA2 running > inside qemu (from the ports, 0.10.6) on a FreeBSD 7.2-STABLE amd64 > ? Or some point on where to start debugging ? > > I'm starting it with: > > qemu-system-x86_64 \ > -s \ > -boot d -cdrom /serv/8.0-BETA2-amd64-disc1.iso \ > -hda f8-64.qcow2 -m 512 \ > -kernel-kqemu \ > -net nic,macaddr=52:54:00:12:34:03 \ > -net tap,ifname=tap3,script=/qserv/bin/ifup,downscript=no \ > -vnc ":8" \ > -no-acpi -name f8-64.opsec.eu -serial stdio > > It hangs after trying to mount from md0. Please try without '-no-acpi'. FYI, ACPI is mandatory for FreeBSD/amd64. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 16:35:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B95D106566B for ; Wed, 22 Jul 2009 16:35:35 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id E78058FC14 for ; Wed, 22 Jul 2009 16:35:34 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 483976C0E for ; Wed, 22 Jul 2009 18:35:34 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n6MGZVnV011666 for ; Wed, 22 Jul 2009 18:35:31 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1248280534; bh=d0o+Mu+HHvFblX1F9d4aTk5xLhk4uqSEcE+xeQ0dTwE=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=xOlj0bnVfe/SFHOeN+FE8NZ0oZC9BIR368LWPzsftUPoctLRUm+exQW5csriMApoW Y6GJvwLDT2zpIvUtciAtA== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:content-type:content-transfer-encoding:x-scanned-by; b=EQ3CT9h9tiAmnIkh38LmwCIXVAdC5yTHHJCLpZn84M6NeEk2i/3MrOggWMDflxPAt 5q8l+C03rrKvCxSa6/OQg== Message-ID: <4A673FD3.3020701@restart.be> Date: Wed, 22 Jul 2009 18:35:31 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.22 (X11/20090717) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Subject: 8.0-BETA2r195818M - tar: Out of memory: Cannot allocate memory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:35:35 -0000 Trying to `portupgrade -fu` all my ports I encounter a strange problem: tar: Out of memory: Cannot allocate memory to dig a little: [root@morzine ~]# truss /usr/bin/bsdtar cvf /tmp/etc.tar /etc __sysctl(0x9fbfe604,0x2,0x9fbfe60c,0x9fbfe610,0x0,0x0) = 0 (0x0) mmap(0x0,320,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 671682560 (0x28091000) munmap(0x28091000,320) = 0 (0x0) __acl_get_file(0x2841a100,0x2,0x28474000,0x280c9440,0x2846013c,0x2841a100) ERR#45 'Operation not supported' __acl_get_file(0x2841a100,0x3,0x28474000,0x280c9440,0x0,0x2841a100) ERR#45 'Operation not supported' extattr_list_link(0x2841a100,0x1,0x0,0x0,0x3,0x0) = -1492922980 (0xa703cd9c) mmap(0x0,-1492123648,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) ERR#12 'Cannot allocate memory' bsdtar: write(2,"bsdtar: ",8) = 8 (0x8) Out of memorywrite(2,"Out of memory",13) = 13 (0xd) Strange this negative arg in mmap! I boot from zfs and my root is on zfs. Thanks for any clue Henri PS. I rebuild and reinstall world and kernel to no avail. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 16:47:23 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39FC31065670 for ; Wed, 22 Jul 2009 16:47:23 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) by mx1.freebsd.org (Postfix) with ESMTP id EBFD38FC13 for ; Wed, 22 Jul 2009 16:47:22 +0000 (UTC) (envelope-from lists@c0mplx.org) Received: from pi by home.opsec.eu with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MTeyR-0005qD-4P for freebsd-current@FreeBSD.org; Wed, 22 Jul 2009 18:47:23 +0200 Date: Wed, 22 Jul 2009 18:47:23 +0200 From: Kurt Jaeger To: freebsd-current@FreeBSD.org Message-ID: <20090722164723.GE70703@home.opsec.eu> References: <20090722051147.GD70703@home.opsec.eu> <200907221224.40724.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907221224.40724.jkim@FreeBSD.org> Cc: Subject: Re: amd64: 8-BETA2 on qemu 0.10.6 on fbsd7.2-stable ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:47:23 -0000 Hello, Jung-uk Kim wrote: > > Can anyone share a hint on how to get amd64 FreeBSD 8 BETA2 running > > inside qemu (from the ports, 0.10.6) on a FreeBSD 7.2-STABLE amd64 > > ? Or some point on where to start debugging ? [...] > Please try without '-no-acpi'. FYI, ACPI is mandatory for > FreeBSD/amd64. Thank you very much, that's it! I should have thought about it! -- pi@opsec.eu +49 171 3101372 11 years to go ! From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 16:48:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2455B1065672 for ; Wed, 22 Jul 2009 16:48:01 +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 515778FC12 for ; Wed, 22 Jul 2009 16:48:00 +0000 (UTC) (envelope-from avg@icyb.net.ua) 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 TAA26194; Wed, 22 Jul 2009 19:47:57 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A6742BC.9080602@icyb.net.ua> Date: Wed, 22 Jul 2009 19:47:56 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Henri Hennebert References: <4A673FD3.3020701@restart.be> In-Reply-To: <4A673FD3.3020701@restart.be> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8.0-BETA2r195818M - tar: Out of memory: Cannot allocate memory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 16:48:01 -0000 on 22/07/2009 19:35 Henri Hennebert said the following: > Trying to `portupgrade -fu` all my ports I encounter a strange problem: > > tar: Out of memory: Cannot allocate memory > > This should have just been fixed by r195822. Please try. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 17:01:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B83BA1065673 for ; Wed, 22 Jul 2009 17:01:28 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 78F168FC15 for ; Wed, 22 Jul 2009 17:01:28 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (hyperion.scode.org [85.17.42.115]) by hyperion.scode.org (Postfix) with ESMTPS id D51B323C45D for ; Wed, 22 Jul 2009 19:01:26 +0200 (CEST) Date: Wed, 22 Jul 2009 19:01:25 +0200 From: Peter Schuller To: freebsd-current@freebsd.org Message-ID: <20090722170125.GA17684@hyperion.scode.org> References: <20090720201332.GA95896@hyperion.scode.org> <4A64D1FF.1010207@elischer.org> <20090720204558.GB96793@hyperion.scode.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <20090720204558.GB96793@hyperion.scode.org> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Getting crashdumps to work (trying to submit crash report) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 17:01:29 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Mostly for the ML archive of this thread: Turns out the problem was a misunderstanding on my part all along. No dump was taken because it's not automatic when the kernel is set to dump to debugger (I suppose?). Simply explicitly doing the dump is fine; I guess the auto-dump is only intended for cases when you automatically reboot. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpnReUACgkQDNor2+l1i33dZACgvVMdYwsRfALHAXT/NDn8mC6P iOEAoMtGs+MFBvlMXOAWUzqEgUS4R0Wh =oqjB -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 17:16:43 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 027A0106566B; Wed, 22 Jul 2009 17:16:43 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id A5EEA8FC08; Wed, 22 Jul 2009 17:16:42 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=mXoDGOH3/r8Qla1FGZ3cz4r2cXdRoz0SRSRhZOSHDgM+Q7OSUt4rD4qKbtDgf3xtnRGYwbcDkone4CEZL9Ov4W6xQpH365o07LsHLBXKU5/Mowe8WsYu2cOnh9tmea0juUOUJf9MMNXbt2bRif7P9N27ubhWClB++lzsLhl9Rk0=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MTfQn-0008KZ-IG; Wed, 22 Jul 2009 21:16:41 +0400 Date: Wed, 22 Jul 2009 21:16:39 +0400 From: Eygene Ryabinkin To: Jung-uk Kim Message-ID: <39ZtfvLlZ2mcI6cuGV6y0ET3pbM@CWODRlDR5RMqbkBfR0/UzHcfNhE> References: <200907211439.05703.hselasky@c2i.net> <200907221342.21588.hselasky@c2i.net> <200907221215.41757.jkim@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907221215.41757.jkim@FreeBSD.org> Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@FreeBSD.org, Rui Paulo , Hans Petter Selasky Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 (regression issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 17:16:43 -0000 Wed, Jul 22, 2009 at 12:15:39PM -0400, Jung-uk Kim wrote: > > The thing is that the IRQ for SCI at my MacBook is 9, so it may be > > really related to the keyboard issues. May be SCI interrupt is > > posted after ACPI is enabled and this confuses something. I'll try > > to look at how APIC stuff is routed, but not today. > > That's quite possible scenario. FYI, all new nVidia chipset Mac's > have almost identical ACPI tables. The SMM port is at 0x52e while old > Intel Macs were at 0xb2, AFAIK. When we do AcpiEnable(), ACPICA > checks if the SCI_EN bit is set. If not, it tries to enable it via > writing ACPI_ENABLE value to SMI_CMD port from FADT. In this case, > that effectively ends up doing: > > bus_space_write_1(ACPI_BUS_SPACE_IO, ACPI_BUS_HANDLE, 0x52e, 0xf0); > > According to HPS, this freezes the system as if it doesn't come back > from the SMI handler. That's true: I see this too. SMI_CMD is really 0x52e and prior to calling AcpiHwSetMode() ACPI mode is legacy. Jung-uk, what is the rationale for enabling the SCI mode and to install the interrupt handler only afterwards? Will it break something if the interrupt handler will be installed prior to going to the ACPI native mode switch? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 17:17:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E257E1065694 for ; Wed, 22 Jul 2009 17:17:43 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4F9C98FC26 for ; Wed, 22 Jul 2009 17:17:43 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (hyperion.scode.org [85.17.42.115]) by hyperion.scode.org (Postfix) with ESMTPS id 92FCD23C45D for ; Wed, 22 Jul 2009 19:17:42 +0200 (CEST) Date: Wed, 22 Jul 2009 19:17:41 +0200 From: Peter Schuller To: freebsd-current@freebsd.org Message-ID: <20090722171741.GB17684@hyperion.scode.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s2ZSL+KKDSLx8OML" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: vm_page_remove() crash on sys_exit() (possibly ZFS related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 17:17:44 -0000 --s2ZSL+KKDSLx8OML Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, so I finally got my crash dump. I'll include some more history further down. First off: http://distfiles.scode.org/mlref/crashdump_20090722/core.txt.0 http://distfiles.scode.org/mlref/crashdump_20090722/backtrace.txt Inline version of backtrace appears below[1] (after background). So this is a general protection fault in vm_page_remove called indirectly from sys_exit(). Worth nothing is that at least once (the previous crash, without a dump) I got a "logic" panic rather than a memory error; I'm pretty sure the panic message was related to page *inserts*. Grepping the source indicates: vm_page.c: panic("vm_page_insert: page already inserted"); vm_page.c: panic("vm_page_insert: offset already all= ocated"); However I could not say for sure whether one of these was indeed the exact panic I got and I neither have a crash nor was able to see a track trace at the time. Some further background and speculation: This system is root-on-ZFS where I have been tracking CURRENT for several months. I updated every month or so in part to test improvements to ZFS; specifically the fixes that have gone in for deadlock/hang issues. My "test case" is to run bulk building of all my ports (the port list is a semi-typical desktop; about 700 or so packages in total). It would very often hang (before) or crash (now) at least once during such a build; the building of firefox was in particular extremely over-represented, at least now that I see the crash symptome. Going back to my tracking of current, at some point, I think roughly a couple of months ago by now, I stopped experiencing deadlocks/hangs (or at least have not seen it yet), but instead began seeing panic:s. No longer seeing hangs was expected because the reason I updated that particular time, if I recall correctly, was specifically that I believed that all the work-in-progress ZFS fixes had gone in. However I am not 100% sure of the timing. Since then I've updated a couple of times more, most recently to BETA1, but am still seeing this crash. Wannabe speculation based on insufficient understanding of the VM system: vm_page_remove() requires, according to comments, that the object and page must be locked. The actual crash in this case happens when checking m->oflags: if (m->oflags & VPO_BUSY) { m->oflags &=3D ~VPO_BUSY; vm_page_flash(m); } The "m->oflags & VPO_BUSY" evaluation is the culprit, if line numbers can be trusted. If I recall correctly, at least one of the deadlock/hang fixes for ZFS did involve a change to locking, so I'm thinking the introduction of the crashing may in fact be related to the ZFS fix itself. However now that I think about it perhaps the only locking changes were vnode ones rather than vm objects/pages? Also interestingly reading m->object right before suceeds, and the lock assert on the object does too. Is it possible the vm page was NOT locked even though m->object was locked? [1] Inline backtrace: #0 doadump () at pcpu.h:223 #1 0xffffffff801d248c in db_fncall (dummy1=3DVariable "dummy1" is not avai= lable. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801d27c1 in db_command (last_cmdp=3D0xffffffff80b667a0, cmd_t= able=3DVariable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801d2a10 in db_command_loop () at /usr/src/sys/ddb/db_command= =2Ec:498 #4 0xffffffff801d49a9 in db_trap (type=3DVariable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff805b5f25 in kdb_trap (type=3D9, code=3D0, tf=3D0xffffff805b96= 08d0) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff80812efd in trap_fatal (frame=3D0xffffff805b9608d0, eva=3DVar= iable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:847 #7 0xffffffff80813a1d in trap (frame=3D0xffffff805b9608d0) at /usr/src/sys= /amd64/amd64/trap.c:639 #8 0xffffffff807f9793 in calltrap () at /usr/src/sys/amd64/amd64/exception= =2ES:223 #9 0xffffffff807d941f in vm_page_remove (m=3D0xffffff00bebe7f90) at /usr/s= rc/sys/vm/vm_page.c:730 #10 0xffffffff807d957d in vm_page_free_toq (m=3D0xffffff00bebe7f90) at /usr= /src/sys/vm/vm_page.c:1394 #11 0xffffffff807d7c6b in vm_object_terminate (object=3D0xffffff0066392948)= at /usr/src/sys/vm/vm_object.c:694 #12 0xffffffff807d821c in vm_object_deallocate (object=3D0xffffff0066392948= ) at /usr/src/sys/vm/vm_object.c:592 #13 0xffffffff807cfad0 in _vm_map_unlock (map=3D0xffffff0004811310, file=3D= Variable "file" is not available. ) at /usr/src/sys/vm/vm_map.c:480 #14 0xffffffff807cff8f in vm_map_remove (map=3D0xffffff0004811310, start=3D= Variable "start" is not available. ) at /usr/src/sys/vm/vm_map.c:2765 #15 0xffffffff807d2e44 in vmspace_exit (td=3D0xffffff004eb78ab0) at /usr/sr= c/sys/vm/vm_map.c:329 #16 0xffffffff8055a33e in exit1 (td=3D0xffffff004eb78ab0, rv=3D0) at /usr/s= rc/sys/kern/kern_exit.c:299 #17 0xffffffff8055b43e in sys_exit (td=3DVariable "td" is not available. ) at /usr/src/sys/kern/kern_exit.c:110 #18 0xffffffff80813546 in syscall (frame=3D0xffffff805b960c90) at /usr/src/= sys/amd64/amd64/trap.c:984 #19 0xffffffff807f9a20 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:364 #20 0x000000000047f63c in ?? () Previous frame inner to this frame (corrupt stack?) --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --s2ZSL+KKDSLx8OML Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpnSbMACgkQDNor2+l1i31stwCcDVn4u/Do7JwnSwG9AUO+k3AQ xXIAnimLX6qk7uDVtQrl/dlzX83y20nN =dU7K -----END PGP SIGNATURE----- --s2ZSL+KKDSLx8OML-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 17:31:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE7441065670 for ; Wed, 22 Jul 2009 17:31:53 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id 66EBC8FC08 for ; Wed, 22 Jul 2009 17:31:53 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (mail.upper.net [62.75.224.33]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id n6MHVmKu028915 for ; Wed, 22 Jul 2009 19:31:48 +0200 Received: from ubm.mine.nu ([85.181.49.125] helo=ubm.mine.nu) by ASSP.nospam.UpPeRnEt; 22 Jul 2009 19:31:48 +0200 Date: Wed, 22 Jul 2009 19:31:48 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20090722193148.dfc8f7aa.ubm@u-boot-man.de> In-Reply-To: <4A66C7BB.6030307@samsco.org> References: <4A66C7BB.6030307@samsco.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.10; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Jul 2009 17:56:34 +0000 Subject: Re: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 17:31:54 -0000 On Wed, 22 Jul 2009 02:03:07 -0600 Scott Long wrote: > This is probably a CISS P410 controller, right? It'll say exactly > what it is further up in the boot messages. I know of the problem > here, and I'm working on a fix. However, it might be a few more days > before I have anything that can be tested. Is it likely that your patch will also apply for my RocketRaid 2322 controller? (I seem to have the same problem as the original poster) Thanks a lot for tackling this! Bye Marc -- "A sudden blow: the great wings beating still Above the staggering girl, her thighs caressed By the dark webs, her nape caught in her bill, She holds her helpless breast upon her breast." W.B. Yeats, Leda and the Swan From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 18:17:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BD60106566C for ; Wed, 22 Jul 2009 18:17:51 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id D37F28FC0A for ; Wed, 22 Jul 2009 18:17:50 +0000 (UTC) (envelope-from sektie@gmail.com) Received: by qyk29 with SMTP id 29so484430qyk.3 for ; Wed, 22 Jul 2009 11:17:50 -0700 (PDT) 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:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=8S3Y+0mHMFLdwlOuyMNWrZgDt1+fUggFr0/rwFuLybw=; b=aFVKoC0Ki1DloZTaqu1fEvKepJoIk8reByiLsVhSlnC8TpB3D+Y40KGhIcfHvNrTNl kr6NkvPbWgvBaHaQAMMUGGShY/AWIkBKDLbaOtK/TU7tHL0xsmOAm7HnEh93O/ZgUYRV PMW83u3WAqTR29K0MKOEIsNwlh/Tv4WUMP1J0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=d8UsGsZPMlRdl8awZtpgqItzMptbgkVt7xsKVeso1RyOiHcyIur+d6HDtN5BYoeaAb GydFR2NvLrDSNDnxun0sTcgvciJ00/iN/LNp++PZbukWRn6RPLLIa48M73mJ6i1nnBcV oobWHj/sFTn+Glc5NQyFFVO7BH2qpqLz+4kVI= MIME-Version: 1.0 Sender: sektie@gmail.com Received: by 10.229.82.15 with SMTP id z15mr246252qck.32.1248285326156; Wed, 22 Jul 2009 10:55:26 -0700 (PDT) In-Reply-To: <200907221027.57244.doconnor@gsoft.com.au> References: <200907221027.57244.doconnor@gsoft.com.au> Date: Wed, 22 Jul 2009 10:55:25 -0700 X-Google-Sender-Auth: 404f8407f6813ee2 Message-ID: From: Randi Harper To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: David Boyd , freebsd-current@freebsd.org Subject: Re: 8.0-BETA2 sysinstall ignoring setting of nonInteractive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 18:17:51 -0000 On Tue, Jul 21, 2009 at 5:27 PM, Daniel O'Connor wrote: > On Wed, 22 Jul 2009, David Boyd wrote: > > With 8.0-BETA(1/2) sysinstall ignores setting of nonInteractive > > variable when using USB-based install. > > > > With or without nonInteractive sysinstall issues message "Using USB > > device: da0a" and waits for confirmation. > > > > This breaks unattended installations using USB device. > > I think this would fix it, can you test it? > > Index: media.c > =================================================================== > --- media.c (revision 195813) > +++ media.c (working copy) > @@ -262,7 +262,8 @@ > mediaDevice = devs[0]; > if (mediaDevice) > mediaDevice->private = NULL; > - msgConfirm("Using USB device: %s", mediaDevice->name); > + if (!variable_get(VAR_NONINTERACTIVE)) > + msgConfirm("Using USB device: %s", mediaDevice->name); > return (mediaDevice ? DITEM_LEAVE_MENU : DITEM_FAILURE); > } > Woops. :) I'll test this out later tonight and see if I can get the fix in. Thanks, Daniel. -- randi From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 18:17:56 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3B42106564A; Wed, 22 Jul 2009 18:17:56 +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 A05898FC15; Wed, 22 Jul 2009 18:17:55 +0000 (UTC) (envelope-from avg@icyb.net.ua) 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 VAA27722; Wed, 22 Jul 2009 21:16:22 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A675776.8090207@icyb.net.ua> Date: Wed, 22 Jul 2009 21:16:22 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: rea-fbsd@codelabs.ru References: <200907211439.05703.hselasky@c2i.net> <200907221342.21588.hselasky@c2i.net> <200907221215.41757.jkim@FreeBSD.org> <39ZtfvLlZ2mcI6cuGV6y0ET3pbM@CWODRlDR5RMqbkBfR0/UzHcfNhE> In-Reply-To: <39ZtfvLlZ2mcI6cuGV6y0ET3pbM@CWODRlDR5RMqbkBfR0/UzHcfNhE> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Rui Paulo , Jung-uk Kim , Hans Petter Selasky Subject: Re: FreeBSD-8-BETA2 on MacBookPro5.5 (regression issue) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 18:17:57 -0000 For me it would be curious to see verbose dmesg from 7.X and verbose dmesg from 8 - whatever, if any, gets outputted before the freeze. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 18:17:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 04F83106566C for ; Wed, 22 Jul 2009 18:17:56 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from mail.upper.net (mail.upper.net [62.75.224.33]) by mx1.freebsd.org (Postfix) with ESMTP id 8BEBA8FC12 for ; Wed, 22 Jul 2009 18:17:55 +0000 (UTC) (envelope-from ubm@u-boot-man.de) Received: from ubm.mine.nu (mail.upper.net [62.75.224.33]) (authenticated bits=0) by mail.upper.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id n6MIHpfr031275 for ; Wed, 22 Jul 2009 20:17:51 +0200 Received: from ubm.mine.nu ([85.181.49.125] helo=ubm.mine.nu) by ASSP.nospam.UpPeRnEt; 22 Jul 2009 20:17:51 +0200 Date: Wed, 22 Jul 2009 20:17:50 +0200 From: Marc "UBM" Bocklet To: freebsd-current@freebsd.org Message-Id: <20090722201750.4ff23293.ubm@u-boot-man.de> In-Reply-To: <20090712194547.9e573116.ubm@u-boot-man.de> References: <20090708192642.6b30167e.ubm@u-boot-man.de> <20090708225048.ec9d9cad.ubm@u-boot-man.de> <20090710200352.72ef6804.ubm@u-boot-man.de> <20090711205837.46b11405.ubm@u-boot-man.de> <20090711222304.fc99056a.ubm@u-boot-man.de> <20090712122316.4f63fc62.ubm@u-boot-man.de> <20090712181034.93811d03.ubm@u-boot-man.de> <20090712194547.9e573116.ubm@u-boot-man.de> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.10; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 22 Jul 2009 18:22:42 +0000 Subject: Re: run interrupt driven hooks: still waiting for xpt_config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 18:17:56 -0000 On Sun, 12 Jul 2009 19:45:47 +0200 Marc "UBM" Bocklet wrote: > On Sun, 12 Jul 2009 18:10:34 +0200 > Marc "UBM" Bocklet wrote: > > > > I've got it narrowed down between "2009.06.30.06.00.00" and today. A > > kernel with the "old" date boots, a freshly csupped and compiled > > kernel hangs with the usual symptoms (waiting for interrupt driven > > hooks). > > > > I'll try csupping to just before the big cam commit to see if there > > is any connection. When I said earlier that I was not running with > > the ahci patch, I was partly wrong. I did not have device ahci in my > > kernel config file nor had it loaded as a module, but I had the > > patch applied. > > "2009.07.09.06.00.00" fixes the problem. > Could it be that there are some subtle interactions in the cam > subsystem that are stirred by the recent mega-commit? Is there any other info I can / should provide to help debugging this? Is there anybody on this list who has the same controller but does not suffer from this problem? Bye Marc From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 18:34:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E84D106564A for ; Wed, 22 Jul 2009 18:34:10 +0000 (UTC) (envelope-from galbrig@googlemail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 956C38FC12 for ; Wed, 22 Jul 2009 18:34:09 +0000 (UTC) (envelope-from galbrig@googlemail.com) Received: by bwz19 with SMTP id 19so358814bwz.43 for ; Wed, 22 Jul 2009 11:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :mime-version:content-type:content-disposition:user-agent:message-id; bh=Aeoyzs/v/qA0ZF+bKdGOWAdAv5BAR39Qw+MwPkzyR2o=; b=CwjoZsiwugztyD5yoHrXHK+50wrg2tanpXjAlLl3Q19i4OS1OMKBPb5VjhK5/0c6KP h3RkeBhm25Uk+SsycmHwgkCapH4zACe5GmOuJlohzcI4ZlmAqNJd+yr++w4DrSp0hnPY N5asQyM/aci5yuL9J5E6FWxlyKCl2f8q9uHxQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:mime-version:content-type:content-disposition :user-agent:message-id; b=I6y5NreAzlrTmswY7dRPInIP+xQQW9no1K/5Te2PjFrebmJ1xVF6zclii2IlcumXEn 04Yb4q2lLlIc3esxc13W1q5dSLNtT92SfVdHc3JnGVTWwsQjtik18ZMXk2FyUzTPgXkP oFtLpBvSXCsnBBHnfpZ0OKHDquhGJuZrU7AKc= Received: by 10.204.64.196 with SMTP id f4mr1095585bki.151.1248286431654; Wed, 22 Jul 2009 11:13:51 -0700 (PDT) Received: from mail.net.local (dslb-088-073-053-091.pools.arcor-ip.net [88.73.53.91]) by mx.google.com with ESMTPS id 4sm1030311bwz.79.2009.07.22.11.13.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 11:13:51 -0700 (PDT) Date: Wed, 22 Jul 2009 20:13:43 +0200 From: albri To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: MadCow 110 Message-Id: <20090722181343.6CF695C16@mail.net.local> Subject: 8.0BETAx: drm driver nouveaunot found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 18:34:10 -0000 hello, I tried to compile nouveau kernel module in two ways: first with drm-patch (both latest) but got an compile error with bsd.README(.mk). second I tried to find it in ./src/sys but could not find it. could anybody give a hint? thank you in advance. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 18:41:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 92D6F106564A for ; Wed, 22 Jul 2009 18:41:10 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 427CC8FC18 for ; Wed, 22 Jul 2009 18:41:10 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: by yxe11 with SMTP id 11so632780yxe.3 for ; Wed, 22 Jul 2009 11:41:09 -0700 (PDT) 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=vjWnBgNqQrAIccYyPnBHXiPrIIK1MP0PYebU4tbXTp4=; b=xVZpojoumK/cBQEnXsIW9214cqGzh9BTOtxfQZVubdUC0izY4PmKaXRy9cymjZ44YR 75e5L7pNhAVLcwwNYYBTrswFzmV1p6g/bnfO+cy+ClZBkTWsLj+8zDZ/b8BOmAXrwFfC s8m+B0znSiCw9TFsbrkYOE3ZtoGXB0jbG8tqU= 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=pf0IJWWHpJ0KnQWsMdXGh+33uGH5xz1Kc8s71uNb7ZRufqW54/FdnYXKr7bYiGRovE 2/96Xze9p/KgEk7SE0QturAZRMs0XhRSDr1qTU6oeNAAgltsIni4dxKaG3J0CYauQy0U 1z401SnEpRw/jtB/1ryRBjLhwUjtWhVyhBA3E= MIME-Version: 1.0 Received: by 10.150.146.12 with SMTP id t12mr1431675ybd.199.1248288069751; Wed, 22 Jul 2009 11:41:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 22 Jul 2009 11:41:09 -0700 Message-ID: From: Freddie Cash To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ZFS pool corrupted on upgrade of -current (probably sata renaming) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 18:41:10 -0000 On Wed, Jul 22, 2009 at 6:12 AM, Nenhum_de_Nos wrote: > > On Wed, July 15, 2009 13:22, Freddie Cash wrote: > > On Tue, Jul 14, 2009 at 8:44 PM, Randy Bush wrote: > > > >> > # glabel label disk01 /dev/ad4 > >> > # glabel label disk02 /dev/ad6 > >> > # glabel label disk03 /dev/ad8 > >> > # zpool create pool raidz1 label/disk01 label/disk02 label/disk03 > >> > > >> > After that, you can shuffle the drives around in the system, and the > >> pool > >> > will continue to work correctly. > >> > >> ooooooo! i wish i had understood that when i built a large set of > >> mirrored raid. > >> > >> any way to hack it ex post facto? > >> > > > > Yep. It's as simple as: > > > > * label all the drives using glabel, while they're still attached to > the > > pool > > * use "zpool replace pool ad4 label/disk01" to replace 1 drive > > * wait for it to resilver > > * use "zpool replace pool ad6 label/disk02" to replace the next drive > > * repeat the resilver and replace until all the devices are replaced > > > > This is what I did to one of our servers. Works quite nicely. > > > > There's no need to detach anything. > > was all this supposed to work with raidz ? > > here it doesn't. > > harry# zpool status > pool: zdados > state: ONLINE > scrub: none requested > config: > > NAME STATE READ WRITE CKSUM > zdados ONLINE 0 0 0 > raidz1 ONLINE 0 0 0 > ad8 ONLINE 0 0 0 > ad10 ONLINE 0 0 0 > ad12 ONLINE 0 0 0 > > errors: No known data errors > harry# zpool detach zdados ad8 > cannot detach ad8: only applicable to mirror and replacing vdevs > Reread what you quoted. :) Note how there's no "detach" step. :) Just label and replace. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 19:23:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 927B7106566B for ; Wed, 22 Jul 2009 19:23:08 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 21B598FC20 for ; Wed, 22 Jul 2009 19:23:08 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id 7078E62D9; Wed, 22 Jul 2009 21:23:07 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n6MJN45B014786; Wed, 22 Jul 2009 21:23:04 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1248290586; bh=4QJAzZm3cgDuahzW2TdfgJRJZCbnl79HoVBG95HyF1o=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=GPeRkgTUFIrOZ3Tt9WzTq+ou5Bm6sOmtBr9zppvbbpaujt32nIxkEPgTuy6tIDfQp O7aLZaUWg6hh1guys5h3w== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=xYV9EBOuVYzeD6GP+WEEeVXWq5aQwB2gQr+fWKMKOxrvsxKcgSSC/3zaJXyunrwP6 AZeERmzMSUFfWCdQvHQLA== Message-ID: <4A676717.1030002@restart.be> Date: Wed, 22 Jul 2009 21:23:03 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.22 (X11/20090717) MIME-Version: 1.0 To: Andriy Gapon References: <4A673FD3.3020701@restart.be> <4A6742BC.9080602@icyb.net.ua> In-Reply-To: <4A6742BC.9080602@icyb.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-current@freebsd.org Subject: [SOLVED] 8.0-BETA2r195818M - tar: Out of memory: Cannot allocate memory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 19:23:08 -0000 Andriy Gapon wrote: > on 22/07/2009 19:35 Henri Hennebert said the following: >> Trying to `portupgrade -fu` all my ports I encounter a strange problem: >> >> tar: Out of memory: Cannot allocate memory >> >> > > This should have just been fixed by r195822. > Please try. > OK it works now Thanks a lot Henri From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 19:28:36 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B33C81065679 for ; Wed, 22 Jul 2009 19:28:36 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 1FA318FC18 for ; Wed, 22 Jul 2009 19:28:35 +0000 (UTC) (envelope-from das@FreeBSD.ORG) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.3/8.14.2) with ESMTP id n6MJUZWi083895; Wed, 22 Jul 2009 15:30:35 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by zim.MIT.EDU (8.14.3/8.14.2/Submit) id n6MJUXtS083894; Wed, 22 Jul 2009 15:30:33 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Wed, 22 Jul 2009 15:30:33 -0400 From: David Schultz To: Vladimir Grebenschikov Message-ID: <20090722193033.GA83848@zim.MIT.EDU> Mail-Followup-To: Vladimir Grebenschikov , Steve Kargl , freebsd-stable , "O. Hartmann" , Thomas Backman , Olivier SMEDTS , FreeBSD current , Ken Smith References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> <367b2c980907200729s57eafbbfw83c8ae5a94f41ffc@mail.gmail.com> <4A6628F0.6080802@mail.zedat.fu-berlin.de> <20090721215201.GA61999@troutmask.apl.washington.edu> <1248277420.8644.70.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1248277420.8644.70.camel@localhost> Cc: freebsd-stable , "O. Hartmann" , Thomas Backman , Olivier SMEDTS , FreeBSD current , Steve Kargl , Ken Smith Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 19:28:37 -0000 On Wed, Jul 22, 2009, Vladimir Grebenschikov wrote: > Ð’ вт, 21/07/2009 в 14:52 -0700, Steve Kargl пишет: > > On Tue, Jul 21, 2009 at 10:45:36PM +0200, O. Hartmann wrote: > > > > > > I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB > > > RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you > > > imagine how long this box will be occupied by 'portupgrade -af'? I guess > > > 'cherry-picking' is the only solution. > > > > How many of those 800 ports are actually necessary and used? > > It would be better to get generate a complete list of your > > installed ports, use pkg_deinstall or pkg_delete to remove > > all ports, and then selectively re-install ports that are > > actually used. > > I've found that much faster and cleaner way is to just remove > whole /usr/local (preserving /usr/local/etc), and /var/db/pkg > > and then just install required ports, such process goes much faster. > Also it removes all unused ports. I do the same thing. I wish the ports system kept track of which ports were installed explicitly by me, and which were only dependencies. Then it would be possible to garbage collect ports that are no longer needed. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 19:40:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDDC5106564A for ; Wed, 22 Jul 2009 19:40:22 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 68D558FC18 for ; Wed, 22 Jul 2009 19:40:22 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by yxe11 with SMTP id 11so696080yxe.3 for ; Wed, 22 Jul 2009 12:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=Q+Q+Dz/1qA7Vk98XSMaB7B4e15e4g5WwdSCOJH8AUx8=; b=sZCXtj+KR6lGxBj8wagln5wZhpes0b+S+cnmguJS8g4H12hqnLqNnu72b+QoWv4JJK 1OfrJgOM1diU6Wh8lhYsyGQ9szGPlli3gjt1nUXBlthP/sINDtMYAsG2Ygmxv6VEi/6S QrbJKIBvINJ5PDZw3eOypHOTvwVisgSxlMe1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=DOwJo1P1DVOYW7wuDgtSBJ0mW2WCIG7Ov5mQYFF8KMsGwgNeU/60R5K6djW0+5BATz kmp5wX5CPV5bwnaHbBpVOSA41VmX5iFXvfBulFueqZrfdmhgFIvDBBk+/E6exsA+w8SW 69SkWY9yTq69ulMk6iheO6Hkz/uOWyfufNiDo= Received: by 10.90.98.12 with SMTP id v12mr1063560agb.69.1248291620577; Wed, 22 Jul 2009 12:40:20 -0700 (PDT) Received: from ?192.168.1.100? ([190.177.196.93]) by mx.google.com with ESMTPS id 17sm2939978agd.26.2009.07.22.12.40.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 12:40:20 -0700 (PDT) From: Gonzalo Nemmi To: "Paul B. Mahol" Date: Wed, 22 Jul 2009 16:40:16 -0300 User-Agent: KMail/1.9.10 References: <4A5D27F2.50208@voicenet.com> <200907212034.04853.gnemmi@gmail.com> <3a142e750907220413o1afff523s83c03d5f7ca0c044@mail.gmail.com> In-Reply-To: <3a142e750907220413o1afff523s83c03d5f7ca0c044@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907221640.16908.gnemmi@gmail.com> Cc: freebsd-current@freebsd.org, Adam K Kirchhoff Subject: Re: bge problems when resuming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 19:40:23 -0000 On Wednesday 22 July 2009 8:13:16 am Paul B. Mahol wrote: > On 7/22/09, Gonzalo Nemmi wrote: > > On Tuesday 21 July 2009 5:46:10 am Paul B. Mahol wrote: > >> On 7/20/09, Gonzalo Nemmi wrote: > >> > On Sunday 19 July 2009 7:53:52 pm Paul B. Mahol wrote: > >> >> On 7/20/09, Gonzalo Nemmi wrote: > >> >> > On Sat, Jul 18, 2009 at 12:09 AM, Paul B. Mahol > >> >> > > >> > > >> > wrote: > >> >> >> On 7/17/09, Gonzalo Nemmi wrote: > >> >> >> > On Wednesday 15 July 2009 8:13:47 am Adam K Kirchhoff wrote: > >> >> >> >> On Wednesday 15 July 2009 03:20:45 Paul B. Mahol wrote: > >> >> >> >> > On 7/15/09, Adam K Kirchhoff wrote: > >> >> >> >> > > Hello all, > >> >> >> >> > > > >> >> >> >> > > I have a Dell Latitude D610 laptop with 8.0-BETA1 > >> >> >> >> > > installed. I hadn't tried suspend/resume for a while > >> >> >> >> > > and decided to give it a shot. I was pleasantly > >> >> >> >> > > surprised to see that I could suspend to ram, resume, > >> >> >> >> > > and have a (relatively) working system (previously > >> >> >> >> > > the display would never come back up and the serial > >> >> >> >> > > console I had hooked up remained dead). Great job to > >> >> >> >> > > everyone who helped make that possible. > >> >> >> >> > > > >> >> >> >> > > The only real issue that I seem to have now is that > >> >> >> >> > > bge is completely unusable after resume. Another > >> >> >> >> > > individual seems to have reported similar problems > >> >> >> >> > > with bge and resume, but he also had other issues > >> >> >> >> > > that apparently trumped his networking issues: > >> >> >> >> > > > >> >> >> >> > > http://lists.freebsd.org/pipermail/freebsd-current/20 > >> >> >> >> > >09- Jul y/0090 23.html > >> >> >> >> > > > >> >> >> >> > > Like him, resuming from suspend gives me: > >> >> >> >> > > > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed > >> >> >> >> > > out (phy 1, reg 0, val 32768) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY read timed > >> >> >> >> > > out (phy 1, reg 0, val 0xffffffff) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed > >> >> >> >> > > out (phy 1, reg 24, val 3072) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed > >> >> >> >> > > out (phy 1, reg 23, val 10) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed > >> >> >> >> > > out (phy 1, reg 21, val 12555) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed > >> >> >> >> > > out (phy 1, reg 23, val 8223) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed > >> >> >> >> > > out (phy 1, reg 21, val 38150) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed > >> >> >> >> > > out (phy 1, reg 23, val 16415) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed > >> >> >> >> > > out (phy 1, reg 21, val 5346) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed > >> >> >> >> > > out (phy 1, reg 24, val 1024) > >> >> >> >> > > Jul 14 12:35:53 scroll kernel: bge0: PHY write timed > >> >> >> >> > > out (phy 1, reg 24, val 7) > >> >> >> >> > > > >> >> >> >> > > And so on and so forth. > >> >> >> >> > > > >> >> >> >> > > I thought that compiling if_bge as a module, > >> >> >> >> > > unloading it before suspend, and reloading it after > >> >> >> >> > > resume, might get this working. However, doing a > >> >> >> >> > > "kldload if_bge" after the resume does nothing. Well, > >> >> >> >> > > the module gets loaded, but the device doesn't show > >> >> >> >> > > up. No errors from kldload, and there is nothing new > >> >> >> >> > > in dmesg. > >> >> >> >> > > > >> >> >> >> > > Before the suspend, the device shows up as: > >> >> >> >> > > > >> >> >> >> > > bge0@pci0:2:0:0: class=0x020000 > >> >> >> >> > > card=0x01821028 chip=0x167714e4 rev=0x01 hdr=0x00 > >> >> >> >> > > vendor = 'Broadcom Corporation' > >> >> >> >> > > device = 'NetXtreme Gigabit Ethernet PCI > >> >> >> >> > > Express (BCM5750A1)' class = network > >> >> >> >> > > subclass = ethernet > >> >> >> >> > > > >> >> >> >> > > After resuming, and reloading the module, it's: > >> >> >> >> > > > >> >> >> >> > > none1@pci0:2:0:0: class=0x020000 > >> >> >> >> > > card=0x01821028 chip=0x167714e4 rev=0x01 hdr=0x00 > >> >> >> >> > > vendor = 'Broadcom Corporation' > >> >> >> >> > > device = 'NetXtreme Gigabit Ethernet PCI > >> >> >> >> > > Express (BCM5750A1)' class = network > >> >> >> >> > > subclass = ethernet > >> >> >> >> > > > >> >> >> >> > > If there are no ideas, I'll go ahead and open up a > >> >> >> >> > > pr. I assume this is just one bug, since both > >> >> >> >> > > problems (the PHY issues and the inability to reload > >> >> >> >> > > the driver) are both related to the network device. > >> >> >> >> > > >> >> >> >> > Put this lines into loader.conf and reboot. > >> >> >> >> > > >> >> >> >> > hw.pci.do_power_nodriver="3" > >> >> >> >> > hw.pci.do_power_resume="1" > >> >> >> >> > > >> >> >> >> > Now, before suspend, unload if_bge and some another > >> >> >> >> > driver (sound drivers are best candidate) and load > >> >> >> >> > sound driver again, suspend and resume. > >> >> >> >> > Now loading if_bge should make it succesfully attach. > >> >> >> >> > >> >> >> >> Unfortunately, after doing this, reloading the if_bge > >> >> >> >> driver causes the laptop to completely lock up... It > >> >> >> >> gets as far as: > >> >> >> >> > >> >> >> >> bge0: >> >> >> >> unknown ASIC rev. 0xffff> > >> >> >> >> mem 0xdfdf0000-0xdfdfffff irq 16 at device 0.0 on pci2 > >> >> >> >> > >> >> >> >> And then the entire machine hangs. I'm on ttyv0, so I'd > >> >> >> >> see any kernel panic, but nothing like that happens. The > >> >> >> >> screen stays on, but nothing else happens till I force a > >> >> >> >> reboot. > >> >> >> >> > >> >> >> >> Adam > >> >> >> > > >> >> >> > Hi Adam, Paul ... > >> >> >> > I'm the "another individual" from you OP. > >> >> >> > I have the same problems you have regarding bge, but they > >> >> >> > weren't trumped .. I just had an order of priorities ;) > >> >> >> > > >> >> >> > Anyways, I tried the solution Paul posted and, just as in > >> >> >> > your case, I got a hard lock too ... > >> >> >> > > >> >> >> > I tried loading if_bge through /boot/loader.conf > >> >> >> > Then issued a: > >> >> >> > > >> >> >> > kldunload if_bge coretemp > >> >> >> > >> >> >> coretemp is wrong module, it must be one of modules that > >> >> >> attach to pci. > >> >> > > >> >> > Sorry Paul! > >> >> > I gave it a go with snd_hda and I got the same result except > >> >> > that this time I also got the following message: > >> >> > >> >> After unloading snd_hda you loaded it again before suspending? > >> > > >> > Doing so yielded a Fatal trap 12 on BETA2. Yesterday I install > >> > BETA2 and here are the results: > >> > > >> > > >> > kldstat > >> > > >> > Id Refs Address Size Name > >> > 1 28 0xc0400000 cf6c70 kernel > >> > 2 1 0xc10f7000 11bc0 if_bge.ko > >> > 3 1 0xc1109000 1ac4c snd_hda.ko > >> > 4 2 0xc1124000 61f78 sound.ko > >> > 5 1 0xc1186000 2af4 coretemp.ko > >> > 6 1 0xc1189000 a6d8 i915.ko > >> > 7 2 0xc1194000 177d4 drm.ko > >> > > >> > > >> > kldunload if_bge snd_hda > >> > > >> > Jul 20 17:50:49 gargoyle login: ROOT LOGIN (root) ON ttyv0 > >> > Jul 20 17:51:06 gargoyle kernel: brgphy0: detached > >> > Jul 20 17:51:06 gargoyle kernel: lock order reversal: > >> > Jul 20 17:51:06 gargoyle kernel: 1st 0xc0dba45c kernel linker > >> > (kernel linker) @ /usr/src/sys/kern/kern_linker.c:1079 > >> > Jul 20 17:51:06 gargoyle kernel: 2nd 0xc0dbbc64 sysctl lock > >> > (sysctl lock) @ /usr/src/sys/kern/kern_sysctl.c:257 > >> > Jul 20 17:51:06 gargoyle kernel: KDB: stack backtrace: > >> > Jul 20 17:51:06 gargoyle kernel: > >> > db_trace_self_wrapper(c0c6baf4,e6daba34,c08bc995,c08ad6db,c0c6e9 > >> >89, ...) at db_trace_self_wrapper+0x26 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > kdb_backtrace(c08ad6db,c0c6e989,c452bc88,c4529e10,e6daba90,...) > >> > at kdb_backtrace+0x29 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > _witness_debugger(c0c6e989,c0dbbc64,c0c69667,c4529e10,c0c6956e,. > >> >..) at _witness_debugger+0x25 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > witness_checkorder(c0dbbc64,9,c0c6956e,101,0,...) at > >> > witness_checkorder+0x839 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > _sx_xlock(c0dbbc64,0,c0c6956e,101,c4722c00,...) at > >> > _sx_xlock+0x85 Jul 20 17:51:06 gargoyle kernel: > >> > sysctl_ctx_free(c4722c4c,c4722c00,e6dabb18,c08a3c85,c4722c00,... > >> >) at sysctl_ctx_free+0x30 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > device_sysctl_fini(c4722c00,0,c0d4c848,c472a810,c4ab3400,...) at > >> > device_sysctl_fini+0x1a > >> > Jul 20 17:51:06 gargoyle kernel: > >> > device_detach(c4722c00,c4722b80,e6dabb38,c06bc622,c4722b80,...) > >> > at device_detach+0x1f5 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > bus_generic_detach(c4722b80,c4722b80,e6dabb64,c08a3b1c,c4722b80, > >> >... ) at bus_generic_detach+0x29 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > miibus_detach(c4722b80,c45d6060,c0d4ca68,a3c,c0c76f47,...) at > >> > miibus_detach+0x12 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > device_detach(c4722b80,c472b008,e6dabb98,c10ff7ff,c4722300,...) > >> > at device_detach+0x8c > >> > Jul 20 17:51:06 gargoyle kernel: > >> > bus_generic_detach(c4722300,1,c1104b66,aec,c4722300,...) at > >> > bus_generic_detach+0x29 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > bge_detach(c4722300,c4677060,c0d4ca68,a3c,c4526300,...) at > >> > bge_detach+0xbf > >> > Jul 20 17:51:06 gargoyle kernel: > >> > device_detach(c4722300,c086c843,c0dbb570,c1106c20,c456fb80,...) > >> > at device_detach+0x8c > >> > Jul 20 17:51:06 gargoyle kernel: > >> > driver_module_handler(c4526300,1,c1106c20,109,0,...) at > >> > driver_module_handler+0x29c > >> > Jul 20 17:51:06 gargoyle kernel: > >> > module_unload(c4526300,c0c652ef,273,270,c08604b6,...) at > >> > module_unload+0x43 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > linker_file_unload(c4544200,0,c0c652ef,437,c10f7000,...) at > >> > linker_file_unload+0x15e > >> > Jul 20 17:51:06 gargoyle kernel: > >> > kern_kldunload(c4b346c0,2,0,e6dabd2c,c0ba8dd3,...) at > >> > kern_kldunload+0xd5 > >> > Jul 20 17:51:06 gargoyle kernel: > >> > kldunloadf(c4b346c0,e6dabcf8,8,c0c6fa4b,c0d50450,...) at > >> > kldunloadf+0x2b > >> > Jul 20 17:51:06 gargoyle kernel: syscall(e6dabd38) at > >> > syscall+0x2a3 Jul 20 17:51:06 gargoyle kernel: > >> > Xint0x80_syscall() at > >> > Xint0x80_syscall+0x20 > >> > Jul 20 17:51:06 gargoyle kernel: --- syscall (444, FreeBSD > >> > ELF32, kldunloadf), eip = 0x280d516b, esp = 0xbfbfe47c, ebp = > >> > 0xbfbfecc8 --- Jul 20 17:51:06 gargoyle kernel: miibus0: > >> > detached > >> > Jul 20 17:51:06 gargoyle kernel: bge0: detached > >> > Jul 20 17:51:06 gargoyle kernel: sysctl_unregister_oid: failed > >> > to unregister sysctl > >> > >> if_bge driver looks very problematic to me. Probably it can not > >> detach at all. > >> > >> > Jul 20 17:51:06 gargoyle kernel: pcm0: detached > >> > Jul 20 17:51:06 gargoyle kernel: hdac0: detached > >> > > >> > > >> > kld snd_hda > >> > >> ^^^ > >> You mean kldload. > >> > >> > Jul 20 17:52:16 gargoyle kernel: hdac0: >> > Definition Audio Controller> mem 0xf6dfc000-0xf6dfffff irq 21 at > >> > device 27.0 on pci0 > >> > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Driver Revision: > >> > 20090624_0136 > >> > Jul 20 17:52:16 gargoyle kernel: hdac0: [ITHREAD] > >> > Jul 20 17:52:16 gargoyle kernel: hdac0: HDA Codec #0: Sigmatel > >> > STAC9228X Jul 20 17:52:16 gargoyle kernel: bge0: >> > BCM5906 A2, ASIC rev. 0xc002> mem 0xf69f0000-0xf69fffff irq 17 > >> > at device 0.0 on pci9 Jul 20 17:52:16 gargoyle kernel: miibus0: > >> > on bge0 Jul 20 17:52:16 gargoyle kernel: brgphy0: > >> > PHY 1 on miibus0 > >> > Jul 20 17:52:16 gargoyle kernel: brgphy0: 10baseT, 10baseT-FDX, > >> > 100baseTX, 100baseTX-FDX, auto > >> > Jul 20 17:52:16 gargoyle kernel: bge0: Ethernet address: > >> > 00:23:ae:04:ba:ca > >> > Jul 20 17:52:16 gargoyle kernel: bge0: [ITHREAD] > >> > Jul 20 17:52:16 gargoyle kernel: pcm0: >> > PCM #0 Analog> at cad 0 nid 1 on hdac0 > >> > Jul 20 17:52:16 gargoyle kernel: bge0: link state changed to > >> > DOWN Jul 20 17:52:18 gargoyle kernel: bge0: link state changed > >> > to UP > >> > >> Why bge0 appeared again? > >> > >> > acpiconf -s 3 > >> > >> After this command bge0 should not appear at all because it should > >> not be attached to > >> device. > >> > >> > Jul 20 17:53:51 gargoyle acpi: suspend at 20090720 17:53:51 > >> > Jul 20 17:53:56 gargoyle kernel: fwohci0: fwohci_pci_suspend > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy > >> > 1, reg 0, val 32768) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy > >> > 1, reg 0, val 0xffffffff) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy > >> > 1, reg 24, val 0xffffffff) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy > >> > 1, reg 16, val 0xffffffff) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy > >> > 1, reg 16, val 0) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY read timed out (phy > >> > 1, reg 16, val 0xffffffff) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy > >> > 1, reg 16, val 0) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: PHY write timed out (phy > >> > 1, reg 23, val 18) > >> > Jul 20 17:54:25 gargoyle kernel: bge0: flow-through queue init > >> > failed Jul 20 17:54:25 gargoyle kernel: bge0: initialization > >> > failure Jul 20 17:54:25 gargoyle kernel: fwohci0: Phy 1394a > >> > available S400, 1 ports. > >> > Jul 20 17:54:25 gargoyle kernel: fwohci0: Link S400, max_rec > >> > 2048 bytes. Jul 20 17:54:25 gargoyle kernel: fwohci0: Initiate > >> > bus reset Jul 20 17:54:25 gargoyle kernel: fwohci0: > >> > fwohci_intr_core: BUS reset Jul 20 17:54:25 gargoyle kernel: > >> > fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, > >> > CYCLEMASTER mode > >> > Jul 20 17:54:25 gargoyle kernel: firewire0: 1 nodes, maxhop <= 0 > >> > cable IRM irm(0) (me) > >> > Jul 20 17:54:25 gargoyle kernel: firewire0: bus manager 0 > >> > Jul 20 17:54:25 gargoyle kernel: fwohci0: unrecoverable error > >> > Jul 20 17:54:25 gargoyle kernel: wakeup from sleeping state > >> > (slept 00:00:29) > >> > Jul 20 17:54:25 gargoyle acpi: resumed at 20090720 17:54:25 > >> > > >> > Should a PR on fwohci and firewire also be filed?? > >> > >> Try with custom kernel with smaller number of drivers as possible. > >> (use modules instead) > >> From your mail I dont see where is problem with firewire. > > > > Done. > > > > Commented if_bge out of GENERIC, recompiled, loaded if_bge via > > loader.conf, kldunloaded if_bge snd_hda, kloaded snd_hda (if_bge > > did not show up on dmesg this time), went to sleep (acpiconf -s 3), > > resumed, no bge timeouts (only fwohci and firewire messages), then > > kldloaded if_bge and got a solid freeze :( > > Does kldload of if_bge works after boot? (remove if_bge_load="YES" > from /boot/loader.conf > and load it after boot) > Does kldload and kldunload and kldload again of if_bge works (without > suspending machine this time)? Yes it does ... a few LORs but it does load and unload correctly. You'll find the messages in here: http://pastebin.com/f69916d2 If there's anything else you like me to test, just tell me :) Thanks once again for you concern Paul :D Best regards -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 19:53:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956D1106566B for ; Wed, 22 Jul 2009 19:53:45 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from mail-pz0-f193.google.com (mail-pz0-f193.google.com [209.85.222.193]) by mx1.freebsd.org (Postfix) with ESMTP id 5BC4F8FC1F for ; Wed, 22 Jul 2009 19:53:45 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by pzk31 with SMTP id 31so428919pzk.3 for ; Wed, 22 Jul 2009 12:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=WTiXBu09c84Xjf5b0ycCMjnGiwwkgTHkKrldgxlX8tE=; b=iGpFvLf9nWaAgORjHuH+JMgi7r2fb4mDdgREpDckwX6mJApzYgc55am9qQeHWRqF9m yy5RaTWXw/YoVbVFIcFV5oA+GcZqAlsn8dICraiXpCFePTozY0lMstRO0AlOamivCR2Y bUPuqyz2J9uTZxUPnbyFcgiOvuC16/YRWHrUw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=BieWyjCphNU0kBRBK7Q8x7IieoUM8vdMv3QDL/sYWAE47Vf78NvQStxCPGFlzwb3Fb DXQYLqZfvy2KHuRd+eLNZvArhBc4MBcqdS8io5RNcm9IkEHB8bhe33v8La49GEL+kmod 6lh1di5OTcenZOqW93AxnoKQONsg8Q0rwTrmA= Received: by 10.114.61.2 with SMTP id j2mr1046417waa.18.1248292425014; Wed, 22 Jul 2009 12:53:45 -0700 (PDT) Received: from ?10.0.3.231? (pool-70-111-14-92.nwrk.east.verizon.net [70.111.14.92]) by mx.google.com with ESMTPS id j31sm1743243waf.14.2009.07.22.12.53.41 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 12:53:43 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: David Schultz In-Reply-To: <20090722193033.GA83848@zim.MIT.EDU> References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> <367b2c980907200729s57eafbbfw83c8ae5a94f41ffc@mail.gmail.com> <4A6628F0.6080802@mail.zedat.fu-berlin.de> <20090721215201.GA61999@troutmask.apl.washington.edu> <1248277420.8644.70.camel@localhost> <20090722193033.GA83848@zim.MIT.EDU> Content-Type: text/plain; charset="UTF-8" Date: Wed, 22 Jul 2009 15:52:44 -0400 Message-Id: <1248292364.1479.16.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-stable , Vladimir Grebenschikov , "O. Hartmann" , Thomas Backman , Olivier SMEDTS , FreeBSD current , Steve Kargl , Ken Smith Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 19:53:45 -0000 On Wed, 2009-07-22 at 15:30 -0400, David Schultz wrote: > On Wed, Jul 22, 2009, Vladimir Grebenschikov wrote: > > Ð’ вт, 21/07/2009 в 14:52 -0700, Steve Kargl пишет: > > > On Tue, Jul 21, 2009 at 10:45:36PM +0200, O. Hartmann wrote: > > > > > > > > I have another box (of many) running FreeBSD 8.0-BETA2/amd64 with 2 GB > > > > RAM and a Athlon64 2,2GHz CPU having 800(!) ports installed. Can you > > > > imagine how long this box will be occupied by 'portupgrade -af'? I guess > > > > 'cherry-picking' is the only solution. > > > > > > How many of those 800 ports are actually necessary and used? > > > It would be better to get generate a complete list of your > > > installed ports, use pkg_deinstall or pkg_delete to remove > > > all ports, and then selectively re-install ports that are > > > actually used. > > > > I've found that much faster and cleaner way is to just remove > > whole /usr/local (preserving /usr/local/etc), and /var/db/pkg > > > > and then just install required ports, such process goes much faster. > > Also it removes all unused ports. > > I do the same thing. I wish the ports system kept track of which > ports were installed explicitly by me, and which were only > dependencies. ports-mgmt/pkg_cutleaves does not quite do that, but IMHO is pretty close. I does not detect build-time dependencies, though. > Then it would be possible to garbage collect ports > that are no longer needed. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Alexandre Kovalenko (ОлекÑандр Коваленко) From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 19:56:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEA4B1065670 for ; Wed, 22 Jul 2009 19:56:11 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by mx1.freebsd.org (Postfix) with ESMTP id A196F8FC1E for ; Wed, 22 Jul 2009 19:56:11 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so134178rvb.43 for ; Wed, 22 Jul 2009 12:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=iPrQHz1HXF4UM2Pp3FOdxVv1abYkfyK7Mb/In5XiHsg=; b=P6of0i24ucS4yNiKHnLOq40M3+SOQMRAcIBZJK+jM1OF4Q5LKmiszrg6xhEWQr9M9z 3dbjLZ8oPIxWlW7RJqwf1g+oz5zzfRwf5uWwSYbZs45rNWs7Qzl+CbdvIVHorojcdJq1 r6qIv2uEgyy5QLYf1ljPkuqVXxDrZiNHWJFKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=h/csOUzm2es1EUHonqORf2y5N+cVwamkQSN0rULTsvQVORtSxWy6PjOokverD1EuPA 35w4wKo6BWNt5E+0vgJ0wE/d6tAJ0ceFVqk4DSeTUJg5KpI0unhIA3z2NP35Gnxudoao Q5nDrSmeC64QT6h9aMcJDO9DNSdoxriPiOOfA= Received: by 10.140.185.20 with SMTP id i20mr841677rvf.133.1248292112744; Wed, 22 Jul 2009 12:48:32 -0700 (PDT) Received: from ?10.0.3.231? (pool-70-111-14-92.nwrk.east.verizon.net [70.111.14.92]) by mx.google.com with ESMTPS id f42sm3917577rvb.35.2009.07.22.12.48.30 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 12:48:31 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: current@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Wed, 22 Jul 2009 15:47:33 -0400 Message-Id: <1248292053.1479.12.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: Subject: Loading atapicam causes panic on 8.0-BETA2 #0 r195818 (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 19:56:12 -0000 System: FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-BETA2 FreeBSD 8.0-BETA2 #0 r195818: Wed Jul 22 13:50:22 EDT 2009 root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 Hardware: Master: acd0 ATA/ATAPI revision 6 *NOTE*: Curiously enough, I can trigger this without drive being present (it is in the media slice of ThinkPad x60) To reproduce: kldload atapicd; kldload atapicam Crash summary: http://members.verizon.net/~akovalenko/Misc/core.txt.1 Backtrace: (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xa0586614 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xa058692b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xa076ddd5 in trap_fatal (frame=0xfa388678, eva=1180) at /usr/src/sys/i386/i386/trap.c:933 #4 0xa076e0a3 in trap_pfault (frame=0xfa388678, usermode=0, eva=1180) at /usr/src/sys/i386/i386/trap.c:846 #5 0xa076ebab in trap (frame=0xfa388678) at /usr/src/sys/i386/i386/trap.c:528 #6 0xa075281b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xaf5ad125 in atapi_action (sim=0xaf4b3300, ccb=0xfa3887a0) at /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:390 #8 0xa0453e58 in xpt_action_default (start_ccb=0xfa3887a0) at /usr/src/sys/cam/cam_xpt.c:2580 #9 0xa044eb24 in xpt_action (start_ccb=0xfa3887a0) at /usr/src/sys/cam/cam_xpt.c:2403 #10 0xa0450f77 in xpt_bus_register (sim=0xaf4b3300, parent=0xaf4b4780, bus=0) at /usr/src/sys/cam/cam_xpt.c:3794 #11 0xaf5acce6 in atapi_cam_attach (dev=0xaf4b4780) at /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:221 #12 0xa05aff94 in device_attach (dev=0xaf4b4780) at device_if.h:178 #13 0xa05b0f5a in device_probe_and_attach (dev=0xaf4b4780) at /usr/src/sys/kern/subr_bus.c:2552 #14 0xa05b1265 in bus_generic_driver_added (dev=0xa633d980, driver=0xaf5aed7c) at /usr/src/sys/kern/subr_bus.c:3303 #15 0xa05ae5d4 in devclass_driver_added (dc=0xa61ccd40, driver=0xaf5aed7c) at bus_if.h:183 #16 0xa05af9d7 in driver_module_handler (mod=0xa70bcc80, what=0, arg=0xaf5aed64) at /usr/src/sys/kern/subr_bus.c:1036 #17 0xa057471e in module_register_init (arg=0xaf5aed4c) at /usr/src/sys/kern/kern_module.c:124 #18 0xa056ccdf in linker_load_module (kldname=Variable "kldname" is not available. ) at /usr/src/sys/kern/kern_linker.c:233 #19 0xa056d1ed in kern_kldload (td=0xa65aab40, file=0xa61ff000 "atapicam", fileid=0xfa388c6c) at /usr/src/sys/kern/kern_linker.c:1015 #20 0xa056d2bf in kldload (td=0xa65aab40, uap=0xfa388cf8) at /usr/src/sys/kern/kern_linker.c:1043 #21 0xa076e474 in syscall (frame=0xfa388d38) at /usr/src/sys/i386/i386/trap.c:1073 #22 0xa07528b0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #23 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Please, let me know if I can provide any additional information. -- Alexandre Kovalenko (ОлекÑандр Коваленко) From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 20:12:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E156C106564A for ; Wed, 22 Jul 2009 20:12:04 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by mx1.freebsd.org (Postfix) with ESMTP id 9DD498FC16 for ; Wed, 22 Jul 2009 20:12:04 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by gxk17 with SMTP id 17so695833gxk.19 for ; Wed, 22 Jul 2009 13:12:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=hp/foJsv9gSnoGbdHGHdh+RrUT5lCw6eZmfRMdQZgyw=; b=B7tTjD6y224YfmPIRHQ7NBipgEEbbUrJpsr57gLtuC0Ss0LprDoC/DgghCewc/O7N/ 0FAmQgxePnDWWitNOLaTPOnULtVhOnxbp6jimaDiEY3ijJ+tUTnHWiGV2nXkDZvja2O3 tygUrnBqtUHSwU60o6QzNt4kCDLPQPadqBlWQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=QxAMM9kNblVU97STfOh/nrd9XWp6Bt0ffl+PYWJMJFhjnfBJDDuL9xpGHjfTwFoh2f LGNvHWMkEIM2/XPA8vfxMFXB7QASpg4yZs+2jfJ6N1dHYy6Svi4PDBNLzYYfBHO5f5c5 hwIyFVR0c50Tt6yXwFJA/3iiekKHXnVgBJvBk= Received: by 10.90.34.10 with SMTP id h10mr1091191agh.31.1248291734405; Wed, 22 Jul 2009 12:42:14 -0700 (PDT) Received: from ?10.0.3.231? (pool-70-111-14-92.nwrk.east.verizon.net [70.111.14.92]) by mx.google.com with ESMTPS id 26sm2928748aga.64.2009.07.22.12.42.13 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 12:42:14 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: current@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Wed, 22 Jul 2009 15:41:17 -0400 Message-Id: <1248291677.1479.5.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: Subject: Unloading if_em causes panic on 8.0-BETA2 #0 r195818 (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 20:12:05 -0000 System: FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-BETA2 FreeBSD 8.0-BETA2 #0 r195818: Wed Jul 22 13:50:22 EDT 2009 root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 To reproduce: kldload if_em; kldunload if_em Hardware: em0@pci0:2:0:0: class=0x020000 card=0x207e17aa chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel PRO/1000 PL Network Adaptor (82573L)' class = network subclass = ethernet Crash summary: http://members.verizon.net/~akovalenko/Misc/core.txt.0 Backtrace: (kgdb) bt #0 doadump () at pcpu.h:246 #1 0xa0586614 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xa058692b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xa0712fe1 in vm_fault (map=0xa1090000, vaddr=2701840384, fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:283 #4 0xa076e046 in trap_pfault (frame=0xfa528adc, usermode=0, eva=2701844432) at /usr/src/sys/i386/i386/trap.c:835 #5 0xa076ebab in trap (frame=0xfa528adc) at /usr/src/sys/i386/i386/trap.c:528 #6 0xa075281b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xa057204d in free (addr=0xaefcb000, mtp=0xa07fbcd0) at vm_page.h:255 #8 0xa05b1978 in buf_ring_free (br=0xaefcb000, type=0xa07fbcd0) at /usr/src/sys/kern/subr_bufring.c:67 #9 0xaeff86aa in em_free_transmit_structures (adapter=0xaefc6000) at /usr/src/sys/modules/em/../../dev/e1000/if_em.c:3647 #10 0xaeffb10f in em_detach (dev=0xa6250400) at /usr/src/sys/modules/em/../../dev/e1000/if_em.c:925 #11 0xa05af62d in device_detach (dev=0xa6250400) at device_if.h:212 #12 0xa05afaba in driver_module_handler (mod=0xa7908e00, what=1, arg=0xaf01b81c) at /usr/src/sys/kern/subr_bus.c:1098 #13 0xa05742fd in module_unload (mod=0xa7908e00) at /usr/src/sys/kern/kern_module.c:266 #14 0xa056b65d in linker_file_unload (file=0xaefaf400, flags=0) at /usr/src/sys/kern/kern_linker.c:632 #15 0xa056c0e4 in kern_kldunload (td=0xab050900, fileid=27, flags=0) at /usr/src/sys/kern/kern_linker.c:1091 #16 0xa056c161 in kldunloadf (td=0xab050900, uap=0xfa528cf8) at /usr/src/sys/kern/kern_linker.c:1121 #17 0xa076e474 in syscall (frame=0xfa528d38) at /usr/src/sys/i386/i386/trap.c:1073 #18 0xa07528b0 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #19 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Please, let me know if there is anything else I can provide. -- Alexandre Kovalenko (ОлекÑандр Коваленко) From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 21:17:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B65A1065673 for ; Wed, 22 Jul 2009 21:17:34 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id DB64F8FC1D for ; Wed, 22 Jul 2009 21:17:33 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by yxe11 with SMTP id 11so798340yxe.3 for ; Wed, 22 Jul 2009 14:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=Jn97BWZ/kZ7PLLh0IJHE31TFXM4zP8I6mFPMzPNgfQ0=; b=uH/Iqg4ZQoTqKnz76ehpylu88fPBlVImgM1G2Jt6HA55a82a0PGnKyU6Ej8FnnWPx7 wBDlJduW1oRh0gTR5QJsi07YlcoIYttvK6STpSY7KoNFA1fWQhswdjUo0ZD0L3pVAu17 BZXJAnPzyZcrnzCyAbladviGvMUVBPNHzahO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=rPN2d+n/bgyyr/8vBas6/HHvsCJHR9VHhpkdpViARwIAJWeBQn+AwzVKWjp8W3VuOo Fl9wMLdWsZFNUu3t9btSOp0X5k6fPNkTRyszebFWMXXU3rJ7l2vOd99a6SuVUGpTSBtP 7KS7QyXS58lU4iYIxN8mmQ1nYS67M/9Vdxek0= Received: by 10.100.11.13 with SMTP id 13mr1828872ank.148.1248297453134; Wed, 22 Jul 2009 14:17:33 -0700 (PDT) Received: from ?192.168.1.100? ([190.177.196.93]) by mx.google.com with ESMTPS id b7sm817496ana.17.2009.07.22.14.17.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 14:17:32 -0700 (PDT) From: Gonzalo Nemmi To: freebsd-current@freebsd.org Date: Wed, 22 Jul 2009 18:17:30 -0300 User-Agent: KMail/1.9.10 References: <1248292053.1479.12.camel@RabbitsDen> In-Reply-To: <1248292053.1479.12.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907221817.31095.gnemmi@gmail.com> Cc: "Alexandre \"Sunny\" Kovalenko" , current@freebsd.org Subject: Re: Loading atapicam causes panic on 8.0-BETA2 #0 r195818 (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 21:17:36 -0000 On Wednesday 22 July 2009 4:47:33 pm Alexandre "Sunny" Kovalenko wrote: > System: > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-BETA2 FreeBSD > 8.0-BETA2 #0 r195818: Wed Jul 22 13:50:22 EDT 2009 > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 > i386 > > Hardware: > Master: acd0 ATA/ATAPI revision 6 > *NOTE*: Curiously enough, I can trigger this without drive being > present (it is in the media slice of ThinkPad x60) > > To reproduce: > kldload atapicd; kldload atapicam > > Crash summary: > http://members.verizon.net/~akovalenko/Misc/core.txt.1 > > Backtrace: > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xa0586614 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:419 > #2 0xa058692b in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xa076ddd5 in trap_fatal (frame=0xfa388678, eva=1180) > at /usr/src/sys/i386/i386/trap.c:933 > #4 0xa076e0a3 in trap_pfault (frame=0xfa388678, usermode=0, > eva=1180) at /usr/src/sys/i386/i386/trap.c:846 > #5 0xa076ebab in trap (frame=0xfa388678) > at /usr/src/sys/i386/i386/trap.c:528 > #6 0xa075281b in calltrap () at > /usr/src/sys/i386/i386/exception.s:165 #7 0xaf5ad125 in atapi_action > (sim=0xaf4b3300, ccb=0xfa3887a0) at > /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:390 #8 > 0xa0453e58 in xpt_action_default (start_ccb=0xfa3887a0) > at /usr/src/sys/cam/cam_xpt.c:2580 > #9 0xa044eb24 in xpt_action (start_ccb=0xfa3887a0) > at /usr/src/sys/cam/cam_xpt.c:2403 > #10 0xa0450f77 in xpt_bus_register (sim=0xaf4b3300, > parent=0xaf4b4780, bus=0) at /usr/src/sys/cam/cam_xpt.c:3794 > #11 0xaf5acce6 in atapi_cam_attach (dev=0xaf4b4780) > at /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:221 > #12 0xa05aff94 in device_attach (dev=0xaf4b4780) at device_if.h:178 > #13 0xa05b0f5a in device_probe_and_attach (dev=0xaf4b4780) > at /usr/src/sys/kern/subr_bus.c:2552 > #14 0xa05b1265 in bus_generic_driver_added (dev=0xa633d980, > driver=0xaf5aed7c) at /usr/src/sys/kern/subr_bus.c:3303 > #15 0xa05ae5d4 in devclass_driver_added (dc=0xa61ccd40, > driver=0xaf5aed7c) at bus_if.h:183 > #16 0xa05af9d7 in driver_module_handler (mod=0xa70bcc80, what=0, > arg=0xaf5aed64) at /usr/src/sys/kern/subr_bus.c:1036 > #17 0xa057471e in module_register_init (arg=0xaf5aed4c) > at /usr/src/sys/kern/kern_module.c:124 > #18 0xa056ccdf in linker_load_module (kldname=Variable "kldname" is > not available. > ) at /usr/src/sys/kern/kern_linker.c:233 > #19 0xa056d1ed in kern_kldload (td=0xa65aab40, file=0xa61ff000 > "atapicam", fileid=0xfa388c6c) at > /usr/src/sys/kern/kern_linker.c:1015 #20 0xa056d2bf in kldload > (td=0xa65aab40, uap=0xfa388cf8) > at /usr/src/sys/kern/kern_linker.c:1043 > #21 0xa076e474 in syscall (frame=0xfa388d38) > at /usr/src/sys/i386/i386/trap.c:1073 > #22 0xa07528b0 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:261 > #23 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > Please, let me know if I can provide any additional information. I'm getting a fatal trap 12 every time I try to kldload atapicam on BETA2 as well, but I'm not getting a vmcore or anything ... acd0: DVDR at ata0-master UDMA33 So, basically, I can confirm kldload atapicam crashes my system but I can't provide any cores or anything .. Im probably missing something and that's why Im getting nothing under /var/crash .. should anyone want to enlighten me with a link to read how to get the vmcore, I'll read it and try to get it so I can provide more info. Best regards Gonzalo -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 21:18:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 513AE106566C for ; Wed, 22 Jul 2009 21:18:10 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id E03738FC17 for ; Wed, 22 Jul 2009 21:18:09 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by qyk29 with SMTP id 29so675752qyk.3 for ; Wed, 22 Jul 2009 14:18:09 -0700 (PDT) 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 :content-transfer-encoding; bh=G2G9BJQM7rSIQsIpBEmQG6emGDQij7J2uSVQCAkcbcQ=; b=CHGsyprsyO8+q7PWrpZRAEqaLafm3S+Ub+Dp3PbSnSL7rHFVKHgwdaLxnJ666CzpIG OKDplBLfCFvL1p4CELIWaFmzyj+V5bgFi98gPAK4D6KmIJZ+iae/e/8CGrFUJew7x5ho KD1syXAzaG6hnJQxUrcLFhAkQ113JJxeNzBzs= 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:content-transfer-encoding; b=NXBmK9AKP4kOVjD45RnLA3cWzqCwKVy61p4kGqWx4TVe9S2pzv6DyMaYFphn8u96Re taKeYdg1fyc17Ir79ctNAvtIKPMKs77aKnk6pyCEvdZjoc4UGLYa6Y0UPw5ktV/JrAfM aGtEdeO8kGok6H2OsVb1aJyq6l2WkLipFCkwc= MIME-Version: 1.0 Received: by 10.229.82.81 with SMTP id a17mr290822qcl.107.1248297488775; Wed, 22 Jul 2009 14:18:08 -0700 (PDT) In-Reply-To: <20090722211600.GC1184@weongyo.local> References: <4A66CFFC.30601@doghouserepair.com> <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> <20090722211600.GC1184@weongyo.local> Date: Wed, 22 Jul 2009 16:18:08 -0500 Message-ID: <11167f520907221418r593be0eeu519a3914d2cbaae7@mail.gmail.com> From: "Sam Fourman Jr." To: Weongyo Jeong , "Sam Fourman Jr." , "b. f." , Ryan Rogers , FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 21:18:10 -0000 On Wed, Jul 22, 2009 at 4:16 PM, Weongyo Jeong wrote: > On Wed, Jul 22, 2009 at 05:26:07AM -0500, Sam Fourman Jr. wrote: >> > svn co svn://svn.freebsd.org/base/head >> > svn merge -c -193289 >> > >> > Thereafter, in the root of the repo: >> > svn up >> > svn merge >> >> Confirmed, running the above set of commands fixed my 88E1116 nfe problem >> everything works as it should now. thanks guys for the help. >> >> Sam Fourman Jr. >> >> ps. svn was WAY faster than csup, I think I am going to use svn all >> the time now. > > I know that yongari@ knows what the problem is and the solution but he > could not access the internet right now due to relocation to USA. > > It looks he is busy with looking for house and etc... > > regards, > Weongyo Jeong No worries here. Just wanted to make sure a Patch get in before 8.0 RELEASE Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 21:40:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03583106566B for ; Wed, 22 Jul 2009 21:40:08 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id DAECC8FC0C for ; Wed, 22 Jul 2009 21:40:07 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n6MLaRPe024576; Wed, 22 Jul 2009 14:36:27 -0700 (PDT) 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, 22 Jul 2009 14:34:59 -0700 Message-ID: In-Reply-To: <4A6692F7.4080905@incunabulum.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CARP broken on -CURRENT? Thread-Index: AcoKg5msfoYYtap5Sgeut84dtGf2KQAkKCPw References: <4A5F8010.7050504@delphij.net> <4A5F7540.7070201@delphij.net> <4A5EF889.6040604@delphij.net> <4A61544E.2050208@delphij.net> <4A6692F7.4080905@incunabulum.net> From: "Li, Qing" To: "Bruce Simpson" , Cc: Ian FREISLICH , FreeBSD Current Subject: RE: CARP broken on -CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 21:40:08 -0000 This is still under investigation. --Qing > -----Original Message----- > From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- > current@freebsd.org] On Behalf Of Bruce Simpson > Sent: Tuesday, July 21, 2009 9:18 PM > To: d@delphij.net > Cc: Ian FREISLICH; FreeBSD Current > Subject: Re: CARP broken on -CURRENT? >=20 > Hi Xin, >=20 > Xin LI wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > I got it. It was the cached llentry that preventing ether_output() > to > > choose the right broadcast/multicast address and use the default > > gateway's L2 address. Here is a proposed patch. > > >=20 > This patch has been reported to fix a regression with multicast > transmission, please can you commit? >=20 > thanks, > BMS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 21:43:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77019106566C for ; Wed, 22 Jul 2009 21:43:09 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-pz0-f193.google.com (mail-pz0-f193.google.com [209.85.222.193]) by mx1.freebsd.org (Postfix) with ESMTP id 396C88FC12 for ; Wed, 22 Jul 2009 21:43:09 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by pzk31 with SMTP id 31so464771pzk.3 for ; Wed, 22 Jul 2009 14:43:09 -0700 (PDT) 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:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=1qC9H4G1WI0zb8dr3XKkcFeEH+oBdT376bAdOgJdcgE=; b=my33xyMYrx8amz48Sx/+oCsAo3B4J18gVQktxj8+dWMOnki0EPkMO+0Gdgj6Blc/gJ qiZpbVwdWmxh1PCWiO7RFQT/x9eRgU/mP9pEg4/DDGextwbb5L539pfWYnYBWTMifkDb NuMImha0NTfoYMXAX1GLId7qCuhUS7gPmR8S4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=TJnoyi8oltXcxJSg2FXtiKGTwWLo+ZG9dpI2ElvhI/7ilr4Ul1zo1Csf7x/7TWq+DG 9pKzyL/Nil8Y/+3BIeRJK74dCEep803uA4Nza10aRtEsYkACDg+MoFR0FBGqXEs+xf3Y J4a5OJgQ+jOZIWZTTzfm+R9lr+psRjQ+HxGL4= Received: by 10.141.13.13 with SMTP id q13mr905700rvi.72.1248297356954; Wed, 22 Jul 2009 14:15:56 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id g14sm1639354rvb.0.2009.07.22.14.15.55 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 14:15:56 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Wed, 22 Jul 2009 14:16:00 -0700 From: Weongyo Jeong Date: Wed, 22 Jul 2009 14:16:00 -0700 To: "Sam Fourman Jr." Message-ID: <20090722211600.GC1184@weongyo.local> Mail-Followup-To: "Sam Fourman Jr." , "b. f." , Ryan Rogers , FreeBSD Current References: <4A66CFFC.30601@doghouserepair.com> <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: Ryan Rogers , FreeBSD Current , "b. f." Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 21:43:09 -0000 On Wed, Jul 22, 2009 at 05:26:07AM -0500, Sam Fourman Jr. wrote: > > svn co svn://svn.freebsd.org/base/head > > svn merge -c -193289 > > > > Thereafter, in the root of the repo: > > svn up > > svn merge > > Confirmed, running the above set of commands fixed my 88E1116 nfe problem > everything works as it should now. thanks guys for the help. > > Sam Fourman Jr. > > ps. svn was WAY faster than csup, I think I am going to use svn all > the time now. I know that yongari@ knows what the problem is and the solution but he could not access the internet right now due to relocation to USA. It looks he is busy with looking for house and etc... regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 21:46:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECBD7106566B for ; Wed, 22 Jul 2009 21:46:18 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB5C8FC12 for ; Wed, 22 Jul 2009 21:46:18 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so233772and.13 for ; Wed, 22 Jul 2009 14:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=Jn97BWZ/kZ7PLLh0IJHE31TFXM4zP8I6mFPMzPNgfQ0=; b=uH/Iqg4ZQoTqKnz76ehpylu88fPBlVImgM1G2Jt6HA55a82a0PGnKyU6Ej8FnnWPx7 wBDlJduW1oRh0gTR5QJsi07YlcoIYttvK6STpSY7KoNFA1fWQhswdjUo0ZD0L3pVAu17 BZXJAnPzyZcrnzCyAbladviGvMUVBPNHzahO8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=rPN2d+n/bgyyr/8vBas6/HHvsCJHR9VHhpkdpViARwIAJWeBQn+AwzVKWjp8W3VuOo Fl9wMLdWsZFNUu3t9btSOp0X5k6fPNkTRyszebFWMXXU3rJ7l2vOd99a6SuVUGpTSBtP 7KS7QyXS58lU4iYIxN8mmQ1nYS67M/9Vdxek0= Received: by 10.100.11.13 with SMTP id 13mr1828872ank.148.1248297453134; Wed, 22 Jul 2009 14:17:33 -0700 (PDT) Received: from ?192.168.1.100? ([190.177.196.93]) by mx.google.com with ESMTPS id b7sm817496ana.17.2009.07.22.14.17.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 14:17:32 -0700 (PDT) From: Gonzalo Nemmi To: freebsd-current@freebsd.org Date: Wed, 22 Jul 2009 18:17:30 -0300 User-Agent: KMail/1.9.10 References: <1248292053.1479.12.camel@RabbitsDen> In-Reply-To: <1248292053.1479.12.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907221817.31095.gnemmi@gmail.com> Cc: "Alexandre \"Sunny\" Kovalenko" , current@freebsd.org Subject: Re: Loading atapicam causes panic on 8.0-BETA2 #0 r195818 (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 21:46:19 -0000 On Wednesday 22 July 2009 4:47:33 pm Alexandre "Sunny" Kovalenko wrote: > System: > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-BETA2 FreeBSD > 8.0-BETA2 #0 r195818: Wed Jul 22 13:50:22 EDT 2009 > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 > i386 > > Hardware: > Master: acd0 ATA/ATAPI revision 6 > *NOTE*: Curiously enough, I can trigger this without drive being > present (it is in the media slice of ThinkPad x60) > > To reproduce: > kldload atapicd; kldload atapicam > > Crash summary: > http://members.verizon.net/~akovalenko/Misc/core.txt.1 > > Backtrace: > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xa0586614 in boot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:419 > #2 0xa058692b in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xa076ddd5 in trap_fatal (frame=0xfa388678, eva=1180) > at /usr/src/sys/i386/i386/trap.c:933 > #4 0xa076e0a3 in trap_pfault (frame=0xfa388678, usermode=0, > eva=1180) at /usr/src/sys/i386/i386/trap.c:846 > #5 0xa076ebab in trap (frame=0xfa388678) > at /usr/src/sys/i386/i386/trap.c:528 > #6 0xa075281b in calltrap () at > /usr/src/sys/i386/i386/exception.s:165 #7 0xaf5ad125 in atapi_action > (sim=0xaf4b3300, ccb=0xfa3887a0) at > /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:390 #8 > 0xa0453e58 in xpt_action_default (start_ccb=0xfa3887a0) > at /usr/src/sys/cam/cam_xpt.c:2580 > #9 0xa044eb24 in xpt_action (start_ccb=0xfa3887a0) > at /usr/src/sys/cam/cam_xpt.c:2403 > #10 0xa0450f77 in xpt_bus_register (sim=0xaf4b3300, > parent=0xaf4b4780, bus=0) at /usr/src/sys/cam/cam_xpt.c:3794 > #11 0xaf5acce6 in atapi_cam_attach (dev=0xaf4b4780) > at /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:221 > #12 0xa05aff94 in device_attach (dev=0xaf4b4780) at device_if.h:178 > #13 0xa05b0f5a in device_probe_and_attach (dev=0xaf4b4780) > at /usr/src/sys/kern/subr_bus.c:2552 > #14 0xa05b1265 in bus_generic_driver_added (dev=0xa633d980, > driver=0xaf5aed7c) at /usr/src/sys/kern/subr_bus.c:3303 > #15 0xa05ae5d4 in devclass_driver_added (dc=0xa61ccd40, > driver=0xaf5aed7c) at bus_if.h:183 > #16 0xa05af9d7 in driver_module_handler (mod=0xa70bcc80, what=0, > arg=0xaf5aed64) at /usr/src/sys/kern/subr_bus.c:1036 > #17 0xa057471e in module_register_init (arg=0xaf5aed4c) > at /usr/src/sys/kern/kern_module.c:124 > #18 0xa056ccdf in linker_load_module (kldname=Variable "kldname" is > not available. > ) at /usr/src/sys/kern/kern_linker.c:233 > #19 0xa056d1ed in kern_kldload (td=0xa65aab40, file=0xa61ff000 > "atapicam", fileid=0xfa388c6c) at > /usr/src/sys/kern/kern_linker.c:1015 #20 0xa056d2bf in kldload > (td=0xa65aab40, uap=0xfa388cf8) > at /usr/src/sys/kern/kern_linker.c:1043 > #21 0xa076e474 in syscall (frame=0xfa388d38) > at /usr/src/sys/i386/i386/trap.c:1073 > #22 0xa07528b0 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:261 > #23 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > Please, let me know if I can provide any additional information. I'm getting a fatal trap 12 every time I try to kldload atapicam on BETA2 as well, but I'm not getting a vmcore or anything ... acd0: DVDR at ata0-master UDMA33 So, basically, I can confirm kldload atapicam crashes my system but I can't provide any cores or anything .. Im probably missing something and that's why Im getting nothing under /var/crash .. should anyone want to enlighten me with a link to read how to get the vmcore, I'll read it and try to get it so I can provide more info. Best regards Gonzalo -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 21:54:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 954A7106566C; Wed, 22 Jul 2009 21:54:59 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from mail-px0-f200.google.com (mail-px0-f200.google.com [209.85.216.200]) by mx1.freebsd.org (Postfix) with ESMTP id 52FE58FC0C; Wed, 22 Jul 2009 21:54:59 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by pxi38 with SMTP id 38so559498pxi.3 for ; Wed, 22 Jul 2009 14:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=U/Dc6D3mKMXCZWlGaBN0INS6PaeBXW62PAXjsQC29Ug=; b=xEBtZ2AvE+A0ym8ZE9qM3BHkzXZ+EbrVruxCTVw6PcsD5JICCtS8qp4E/bjXul8ssG BxBH9GeydHTBGGTkKszW67TYSX66RE08iTiGjqnssLi+jFM0kOYbPh1KAox1/fH1Xeqg Q6/BuR+P11t7PXI/oaIIuYtk3cxYAZPdOPAC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=PXIw/VVbz63+72l3uuVyW9MgAZaPbnuuGNvwP/9ZpGeoRICTFFRfuy/DULLHNJ0xY2 rUCc4b0dzrQQuQWLasRV/HMPo5YCJ28WO9VsNB5Y/Gulg3mdPCcGvIkNFJE+wJoJGT9/ tludMUBEV2iDmdJHoY20m87jLTrCAp/vqXOfQ= Received: by 10.141.4.3 with SMTP id g3mr1016189rvi.8.1248299699104; Wed, 22 Jul 2009 14:54:59 -0700 (PDT) Received: from ?10.0.3.231? (pool-70-111-14-92.nwrk.east.verizon.net [70.111.14.92]) by mx.google.com with ESMTPS id l31sm4288741rvb.24.2009.07.22.14.54.56 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 14:54:58 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Gonzalo Nemmi In-Reply-To: <200907221817.31095.gnemmi@gmail.com> References: <1248292053.1479.12.camel@RabbitsDen> <200907221817.31095.gnemmi@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 22 Jul 2009 17:53:59 -0400 Message-Id: <1248299639.1479.17.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: Loading atapicam causes panic on 8.0-BETA2 #0 r195818 (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 21:55:00 -0000 On Wed, 2009-07-22 at 18:17 -0300, Gonzalo Nemmi wrote: > On Wednesday 22 July 2009 4:47:33 pm Alexandre "Sunny" Kovalenko wrote: > > System: > > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-BETA2 FreeBSD > > 8.0-BETA2 #0 r195818: Wed Jul 22 13:50:22 EDT 2009 > > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 > > i386 > > > > Hardware: > > Master: acd0 ATA/ATAPI revision 6 > > *NOTE*: Curiously enough, I can trigger this without drive being > > present (it is in the media slice of ThinkPad x60) > > > > To reproduce: > > kldload atapicd; kldload atapicam > > > > Crash summary: > > http://members.verizon.net/~akovalenko/Misc/core.txt.1 > > > > Backtrace: > > (kgdb) bt > > #0 doadump () at pcpu.h:246 > > #1 0xa0586614 in boot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:419 > > #2 0xa058692b in panic (fmt=Variable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:575 > > #3 0xa076ddd5 in trap_fatal (frame=0xfa388678, eva=1180) > > at /usr/src/sys/i386/i386/trap.c:933 > > #4 0xa076e0a3 in trap_pfault (frame=0xfa388678, usermode=0, > > eva=1180) at /usr/src/sys/i386/i386/trap.c:846 > > #5 0xa076ebab in trap (frame=0xfa388678) > > at /usr/src/sys/i386/i386/trap.c:528 > > #6 0xa075281b in calltrap () at > > /usr/src/sys/i386/i386/exception.s:165 #7 0xaf5ad125 in atapi_action > > (sim=0xaf4b3300, ccb=0xfa3887a0) at > > /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:390 #8 > > 0xa0453e58 in xpt_action_default (start_ccb=0xfa3887a0) > > at /usr/src/sys/cam/cam_xpt.c:2580 > > #9 0xa044eb24 in xpt_action (start_ccb=0xfa3887a0) > > at /usr/src/sys/cam/cam_xpt.c:2403 > > #10 0xa0450f77 in xpt_bus_register (sim=0xaf4b3300, > > parent=0xaf4b4780, bus=0) at /usr/src/sys/cam/cam_xpt.c:3794 > > #11 0xaf5acce6 in atapi_cam_attach (dev=0xaf4b4780) > > at /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:221 > > #12 0xa05aff94 in device_attach (dev=0xaf4b4780) at device_if.h:178 > > #13 0xa05b0f5a in device_probe_and_attach (dev=0xaf4b4780) > > at /usr/src/sys/kern/subr_bus.c:2552 > > #14 0xa05b1265 in bus_generic_driver_added (dev=0xa633d980, > > driver=0xaf5aed7c) at /usr/src/sys/kern/subr_bus.c:3303 > > #15 0xa05ae5d4 in devclass_driver_added (dc=0xa61ccd40, > > driver=0xaf5aed7c) at bus_if.h:183 > > #16 0xa05af9d7 in driver_module_handler (mod=0xa70bcc80, what=0, > > arg=0xaf5aed64) at /usr/src/sys/kern/subr_bus.c:1036 > > #17 0xa057471e in module_register_init (arg=0xaf5aed4c) > > at /usr/src/sys/kern/kern_module.c:124 > > #18 0xa056ccdf in linker_load_module (kldname=Variable "kldname" is > > not available. > > ) at /usr/src/sys/kern/kern_linker.c:233 > > #19 0xa056d1ed in kern_kldload (td=0xa65aab40, file=0xa61ff000 > > "atapicam", fileid=0xfa388c6c) at > > /usr/src/sys/kern/kern_linker.c:1015 #20 0xa056d2bf in kldload > > (td=0xa65aab40, uap=0xfa388cf8) > > at /usr/src/sys/kern/kern_linker.c:1043 > > #21 0xa076e474 in syscall (frame=0xfa388d38) > > at /usr/src/sys/i386/i386/trap.c:1073 > > #22 0xa07528b0 in Xint0x80_syscall () > > at /usr/src/sys/i386/i386/exception.s:261 > > #23 0x00000033 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) > > > > Please, let me know if I can provide any additional information. > > I'm getting a fatal trap 12 every time I try to kldload atapicam on > BETA2 as well, but I'm not getting a vmcore or anything ... > > acd0: DVDR at ata0-master UDMA33 > > So, basically, I can confirm kldload atapicam crashes my system but I > can't provide any cores or anything .. Im probably missing something > and that's why Im getting nothing under /var/crash .. should anyone > want to enlighten me with a link to read how to get the vmcore, I'll > read it and try to get it so I can provide more info. > > Best regards > Gonzalo > Would this help? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN -- Alexandre Kovalenko (ОлекÑандр Коваленко) From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 21:54:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 954A7106566C; Wed, 22 Jul 2009 21:54:59 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from mail-px0-f200.google.com (mail-px0-f200.google.com [209.85.216.200]) by mx1.freebsd.org (Postfix) with ESMTP id 52FE58FC0C; Wed, 22 Jul 2009 21:54:59 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by pxi38 with SMTP id 38so559498pxi.3 for ; Wed, 22 Jul 2009 14:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=U/Dc6D3mKMXCZWlGaBN0INS6PaeBXW62PAXjsQC29Ug=; b=xEBtZ2AvE+A0ym8ZE9qM3BHkzXZ+EbrVruxCTVw6PcsD5JICCtS8qp4E/bjXul8ssG BxBH9GeydHTBGGTkKszW67TYSX66RE08iTiGjqnssLi+jFM0kOYbPh1KAox1/fH1Xeqg Q6/BuR+P11t7PXI/oaIIuYtk3cxYAZPdOPAC0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=PXIw/VVbz63+72l3uuVyW9MgAZaPbnuuGNvwP/9ZpGeoRICTFFRfuy/DULLHNJ0xY2 rUCc4b0dzrQQuQWLasRV/HMPo5YCJ28WO9VsNB5Y/Gulg3mdPCcGvIkNFJE+wJoJGT9/ tludMUBEV2iDmdJHoY20m87jLTrCAp/vqXOfQ= Received: by 10.141.4.3 with SMTP id g3mr1016189rvi.8.1248299699104; Wed, 22 Jul 2009 14:54:59 -0700 (PDT) Received: from ?10.0.3.231? (pool-70-111-14-92.nwrk.east.verizon.net [70.111.14.92]) by mx.google.com with ESMTPS id l31sm4288741rvb.24.2009.07.22.14.54.56 (version=SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 14:54:58 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Gonzalo Nemmi In-Reply-To: <200907221817.31095.gnemmi@gmail.com> References: <1248292053.1479.12.camel@RabbitsDen> <200907221817.31095.gnemmi@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 22 Jul 2009 17:53:59 -0400 Message-Id: <1248299639.1479.17.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: Loading atapicam causes panic on 8.0-BETA2 #0 r195818 (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 21:55:00 -0000 On Wed, 2009-07-22 at 18:17 -0300, Gonzalo Nemmi wrote: > On Wednesday 22 July 2009 4:47:33 pm Alexandre "Sunny" Kovalenko wrote: > > System: > > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-BETA2 FreeBSD > > 8.0-BETA2 #0 r195818: Wed Jul 22 13:50:22 EDT 2009 > > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 > > i386 > > > > Hardware: > > Master: acd0 ATA/ATAPI revision 6 > > *NOTE*: Curiously enough, I can trigger this without drive being > > present (it is in the media slice of ThinkPad x60) > > > > To reproduce: > > kldload atapicd; kldload atapicam > > > > Crash summary: > > http://members.verizon.net/~akovalenko/Misc/core.txt.1 > > > > Backtrace: > > (kgdb) bt > > #0 doadump () at pcpu.h:246 > > #1 0xa0586614 in boot (howto=260) > > at /usr/src/sys/kern/kern_shutdown.c:419 > > #2 0xa058692b in panic (fmt=Variable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:575 > > #3 0xa076ddd5 in trap_fatal (frame=0xfa388678, eva=1180) > > at /usr/src/sys/i386/i386/trap.c:933 > > #4 0xa076e0a3 in trap_pfault (frame=0xfa388678, usermode=0, > > eva=1180) at /usr/src/sys/i386/i386/trap.c:846 > > #5 0xa076ebab in trap (frame=0xfa388678) > > at /usr/src/sys/i386/i386/trap.c:528 > > #6 0xa075281b in calltrap () at > > /usr/src/sys/i386/i386/exception.s:165 #7 0xaf5ad125 in atapi_action > > (sim=0xaf4b3300, ccb=0xfa3887a0) at > > /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:390 #8 > > 0xa0453e58 in xpt_action_default (start_ccb=0xfa3887a0) > > at /usr/src/sys/cam/cam_xpt.c:2580 > > #9 0xa044eb24 in xpt_action (start_ccb=0xfa3887a0) > > at /usr/src/sys/cam/cam_xpt.c:2403 > > #10 0xa0450f77 in xpt_bus_register (sim=0xaf4b3300, > > parent=0xaf4b4780, bus=0) at /usr/src/sys/cam/cam_xpt.c:3794 > > #11 0xaf5acce6 in atapi_cam_attach (dev=0xaf4b4780) > > at /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:221 > > #12 0xa05aff94 in device_attach (dev=0xaf4b4780) at device_if.h:178 > > #13 0xa05b0f5a in device_probe_and_attach (dev=0xaf4b4780) > > at /usr/src/sys/kern/subr_bus.c:2552 > > #14 0xa05b1265 in bus_generic_driver_added (dev=0xa633d980, > > driver=0xaf5aed7c) at /usr/src/sys/kern/subr_bus.c:3303 > > #15 0xa05ae5d4 in devclass_driver_added (dc=0xa61ccd40, > > driver=0xaf5aed7c) at bus_if.h:183 > > #16 0xa05af9d7 in driver_module_handler (mod=0xa70bcc80, what=0, > > arg=0xaf5aed64) at /usr/src/sys/kern/subr_bus.c:1036 > > #17 0xa057471e in module_register_init (arg=0xaf5aed4c) > > at /usr/src/sys/kern/kern_module.c:124 > > #18 0xa056ccdf in linker_load_module (kldname=Variable "kldname" is > > not available. > > ) at /usr/src/sys/kern/kern_linker.c:233 > > #19 0xa056d1ed in kern_kldload (td=0xa65aab40, file=0xa61ff000 > > "atapicam", fileid=0xfa388c6c) at > > /usr/src/sys/kern/kern_linker.c:1015 #20 0xa056d2bf in kldload > > (td=0xa65aab40, uap=0xfa388cf8) > > at /usr/src/sys/kern/kern_linker.c:1043 > > #21 0xa076e474 in syscall (frame=0xfa388d38) > > at /usr/src/sys/i386/i386/trap.c:1073 > > #22 0xa07528b0 in Xint0x80_syscall () > > at /usr/src/sys/i386/i386/exception.s:261 > > #23 0x00000033 in ?? () > > Previous frame inner to this frame (corrupt stack?) > > (kgdb) > > > > Please, let me know if I can provide any additional information. > > I'm getting a fatal trap 12 every time I try to kldload atapicam on > BETA2 as well, but I'm not getting a vmcore or anything ... > > acd0: DVDR at ata0-master UDMA33 > > So, basically, I can confirm kldload atapicam crashes my system but I > can't provide any cores or anything .. Im probably missing something > and that's why Im getting nothing under /var/crash .. should anyone > want to enlighten me with a link to read how to get the vmcore, I'll > read it and try to get it so I can provide more info. > > Best regards > Gonzalo > Would this help? http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN -- Alexandre Kovalenko (ОлекÑандр Коваленко) From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 22:09:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64B87106566B for ; Wed, 22 Jul 2009 22:09:19 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from mail.chrishedley.com (77-44-98-139.xdsl.murphx.net [77.44.98.139]) by mx1.freebsd.org (Postfix) with ESMTP id AFE288FC1E for ; Wed, 22 Jul 2009 22:09:18 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from localhost (localhost [127.0.0.1]) by mail.chrishedley.com (Postfix) with ESMTP id 82AEC6D2D0 for ; Wed, 22 Jul 2009 22:53:12 +0100 (BST) X-Virus-Scanned: amavisd-new at chrishedley.com Received: from mail.chrishedley.com ([127.0.0.1]) by localhost (mail.chrishedley.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VLl8YBHdH6rN for ; Wed, 22 Jul 2009 22:53:09 +0100 (BST) Received: from teapot.cbhnet (teapot.cbhnet [192.168.1.1]) by mail.chrishedley.com (Postfix) with ESMTP id 2A4E86D2B5 for ; Wed, 22 Jul 2009 22:53:09 +0100 (BST) Date: Wed, 22 Jul 2009 22:53:09 +0100 (BST) From: Chris Hedley X-X-Sender: cbh@teapot.cbhnet To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Linux NFS ate my bge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:09:19 -0000 My bge network interface dies when faced with a barrage of Linux NFS requests. I've (re)discovered this now that I've recently got my assorted config problems largely ironed out and have my FreeBSD box up to date again, I'm reminded of an unresolved problem from way back, which is that my bge card collapses after being subjected to a large amount of NFS traffic coming from my Linux box, e.g. recompiling KDE on a discless workstation, which has been responsible for three embuggerances so far today. Now I'm not sure if it's specifically Linux NFS it doesn't like, or just NFS, or even just a lot of traffic (though Samba doesn't do this - I'd like to say it's probably because Windows' CIFS or whatever it's called this week is too inefficient to generate that amount of traffic, but actually its performance is much better than FreeBSD - Linux NFS), but it frequently puts my FreeBSD system into a state where my bge is unusable unless I reboot; and by "reboot" I mean "reset" as it seems to render the rest of the system prone to locking up solid, presumably putting anything wanting network access into a no-wake state, or whatever the 21st century name is for an unkillable process. Scanning back through the archives I see I'm not alone with both this problem and assorted other bge-related annoyances, which I gather are likely due to insufficient documentation being provided to the kernel devs to get a robust driver together. I guess my question is "have any breakthroughs been made?" and given that I'm using -current, I guess the answer is "no". In which case I guess my next question is "what cheap but good PCI/PCI-X (but not PCIe) based card would you recommend?" since I'd rather just get this one sorted out once and for all. My only real requirement is that it does 1 Gbit. And works. I did wonder for a while if it might be something to do with having four aliases on the same subnet on my bge (32 bit netmask, of course) but it seems to make no difference whether they're configured or not (it was interesting seeing the ifconfig after one bge failure place the primary interface /after/ all its aliases; don't know if that's symptomatic of what's going on, but do bear in mind that as I mentioned it seems to make no difference to its stability whether those aliases are present or not). Another (totally unrelated) thing that should probably go in its own thread, I've found an oddity with the ohci and/or ukbd drivers which is that if I compile them into my kernel it won't boot, but if I leave them as separate modules and get loader to deal with them it boots fine. That's "won't boot" as in "gets to the orm0 bit of its boot messages and then hangs"; normally sc0 comes next, though I don't know if the USB bits change that. I'm not that bothered as I prefer modular kernels anyway, but I thought I'd bring it up in case anyone's interested. Cheers, Chris. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 22:12:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BB311065720; Wed, 22 Jul 2009 22:12:31 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by mx1.freebsd.org (Postfix) with ESMTP id C85B08FC19; Wed, 22 Jul 2009 22:12:30 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by gxk17 with SMTP id 17so816878gxk.19 for ; Wed, 22 Jul 2009 15:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=J7/k3UAS+L/7pg7mobAUE7k0MzPERSc59uMEOPCn/MU=; b=xbnLDVHfZG+NWjIYir0Y7l0bK7sHNX9zw7aS92IKP6JT9xJgCnBPtmtUzBvQqKDS5w aplZXIoGLByFVlfEmaoIx7lxE3wb4DoYi2b5dXeyq30I8uXmWhgiCfwzJn3AFNPbWHu0 RaHrQic1D652GZbIJOXI54v+9I3KML1PRkClg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=HIdEiGFSuDm5C2dVWMzyVHIQY4zJd3h3amoJTj1sjWS3z4/jpLPyfCP7qjvmL5ROiE 6l7noDTStoCMymjwWHWRUtYSlT2mmz48MYZ69jLaUKwSm8n3NCMNbW8UcNKGaM2co6bU VWR7Xxkoy+b20Cpp6O7N+RZZhi5BG1N3aLvu8= Received: by 10.90.49.8 with SMTP id w8mr1184589agw.52.1248300749574; Wed, 22 Jul 2009 15:12:29 -0700 (PDT) Received: from ?192.168.1.100? ([190.177.196.93]) by mx.google.com with ESMTPS id 4sm3369383aga.16.2009.07.22.15.12.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 15:12:29 -0700 (PDT) From: Gonzalo Nemmi To: "Alexandre \"Sunny\" Kovalenko" Date: Wed, 22 Jul 2009 19:12:27 -0300 User-Agent: KMail/1.9.10 References: <1248292053.1479.12.camel@RabbitsDen> <200907221817.31095.gnemmi@gmail.com> <1248299639.1479.17.camel@RabbitsDen> In-Reply-To: <1248299639.1479.17.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907221912.27776.gnemmi@gmail.com> Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: Loading atapicam causes panic on 8.0-BETA2 #0 r195818 (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:12:32 -0000 On Wednesday 22 July 2009 6:53:59 pm Alexandre "Sunny" Kovalenko wrote: > On Wed, 2009-07-22 at 18:17 -0300, Gonzalo Nemmi wrote: > > On Wednesday 22 July 2009 4:47:33 pm Alexandre "Sunny" Kovalenko wrote: > > > System: > > > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-BETA2 FreeBSD > > > 8.0-BETA2 #0 r195818: Wed Jul 22 13:50:22 EDT 2009 > > > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX6 > > >0 i386 > > > > > > Hardware: > > > Master: acd0 ATA/ATAPI revision 6 > > > *NOTE*: Curiously enough, I can trigger this without drive being > > > present (it is in the media slice of ThinkPad x60) > > > > > > To reproduce: > > > kldload atapicd; kldload atapicam > > > > > > Crash summary: > > > http://members.verizon.net/~akovalenko/Misc/core.txt.1 > > > > > > Backtrace: > > > (kgdb) bt > > > #0 doadump () at pcpu.h:246 > > > #1 0xa0586614 in boot (howto=260) > > > at /usr/src/sys/kern/kern_shutdown.c:419 > > > #2 0xa058692b in panic (fmt=Variable "fmt" is not available. > > > ) at /usr/src/sys/kern/kern_shutdown.c:575 > > > #3 0xa076ddd5 in trap_fatal (frame=0xfa388678, eva=1180) > > > at /usr/src/sys/i386/i386/trap.c:933 > > > #4 0xa076e0a3 in trap_pfault (frame=0xfa388678, usermode=0, > > > eva=1180) at /usr/src/sys/i386/i386/trap.c:846 > > > #5 0xa076ebab in trap (frame=0xfa388678) > > > at /usr/src/sys/i386/i386/trap.c:528 > > > #6 0xa075281b in calltrap () at > > > /usr/src/sys/i386/i386/exception.s:165 #7 0xaf5ad125 in > > > atapi_action (sim=0xaf4b3300, ccb=0xfa3887a0) at > > > /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:39 > > >0 #8 0xa0453e58 in xpt_action_default (start_ccb=0xfa3887a0) at > > > /usr/src/sys/cam/cam_xpt.c:2580 > > > #9 0xa044eb24 in xpt_action (start_ccb=0xfa3887a0) > > > at /usr/src/sys/cam/cam_xpt.c:2403 > > > #10 0xa0450f77 in xpt_bus_register (sim=0xaf4b3300, > > > parent=0xaf4b4780, bus=0) at /usr/src/sys/cam/cam_xpt.c:3794 > > > #11 0xaf5acce6 in atapi_cam_attach (dev=0xaf4b4780) > > > at > > > /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:22 > > >1 #12 0xa05aff94 in device_attach (dev=0xaf4b4780) at > > > device_if.h:178 #13 0xa05b0f5a in device_probe_and_attach > > > (dev=0xaf4b4780) at /usr/src/sys/kern/subr_bus.c:2552 > > > #14 0xa05b1265 in bus_generic_driver_added (dev=0xa633d980, > > > driver=0xaf5aed7c) at /usr/src/sys/kern/subr_bus.c:3303 > > > #15 0xa05ae5d4 in devclass_driver_added (dc=0xa61ccd40, > > > driver=0xaf5aed7c) at bus_if.h:183 > > > #16 0xa05af9d7 in driver_module_handler (mod=0xa70bcc80, what=0, > > > arg=0xaf5aed64) at /usr/src/sys/kern/subr_bus.c:1036 > > > #17 0xa057471e in module_register_init (arg=0xaf5aed4c) > > > at /usr/src/sys/kern/kern_module.c:124 > > > #18 0xa056ccdf in linker_load_module (kldname=Variable "kldname" > > > is not available. > > > ) at /usr/src/sys/kern/kern_linker.c:233 > > > #19 0xa056d1ed in kern_kldload (td=0xa65aab40, file=0xa61ff000 > > > "atapicam", fileid=0xfa388c6c) at > > > /usr/src/sys/kern/kern_linker.c:1015 #20 0xa056d2bf in kldload > > > (td=0xa65aab40, uap=0xfa388cf8) > > > at /usr/src/sys/kern/kern_linker.c:1043 > > > #21 0xa076e474 in syscall (frame=0xfa388d38) > > > at /usr/src/sys/i386/i386/trap.c:1073 > > > #22 0xa07528b0 in Xint0x80_syscall () > > > at /usr/src/sys/i386/i386/exception.s:261 > > > #23 0x00000033 in ?? () > > > Previous frame inner to this frame (corrupt stack?) > > > (kgdb) > > > > > > Please, let me know if I can provide any additional information. > > > > I'm getting a fatal trap 12 every time I try to kldload atapicam on > > BETA2 as well, but I'm not getting a vmcore or anything ... > > > > acd0: DVDR at ata0-master UDMA33 > > > > So, basically, I can confirm kldload atapicam crashes my system but > > I can't provide any cores or anything .. Im probably missing > > something and that's why Im getting nothing under /var/crash .. > > should anyone want to enlighten me with a link to read how to get > > the vmcore, I'll read it and try to get it so I can provide more > > info. > > > > Best regards > > Gonzalo > > Would this help? > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ >kerneldebug.html#KERNELDEBUG-OBTAIN Not really .. I was there before and even if dumpdev="AUTO" and dumpdir="/var/crash" (which I did chmod 700) are set by default in /etc/defaults/rc.conf, I did add those two to /etc/rc.conf .. yet still, I get nothing under /var/crash except for "minfree" :s Am I missing something else? Regards -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 22:12:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3BB311065720; Wed, 22 Jul 2009 22:12:31 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: from mail-gx0-f217.google.com (mail-gx0-f217.google.com [209.85.217.217]) by mx1.freebsd.org (Postfix) with ESMTP id C85B08FC19; Wed, 22 Jul 2009 22:12:30 +0000 (UTC) (envelope-from gnemmi@gmail.com) Received: by gxk17 with SMTP id 17so816878gxk.19 for ; Wed, 22 Jul 2009 15:12:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=J7/k3UAS+L/7pg7mobAUE7k0MzPERSc59uMEOPCn/MU=; b=xbnLDVHfZG+NWjIYir0Y7l0bK7sHNX9zw7aS92IKP6JT9xJgCnBPtmtUzBvQqKDS5w aplZXIoGLByFVlfEmaoIx7lxE3wb4DoYi2b5dXeyq30I8uXmWhgiCfwzJn3AFNPbWHu0 RaHrQic1D652GZbIJOXI54v+9I3KML1PRkClg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=HIdEiGFSuDm5C2dVWMzyVHIQY4zJd3h3amoJTj1sjWS3z4/jpLPyfCP7qjvmL5ROiE 6l7noDTStoCMymjwWHWRUtYSlT2mmz48MYZ69jLaUKwSm8n3NCMNbW8UcNKGaM2co6bU VWR7Xxkoy+b20Cpp6O7N+RZZhi5BG1N3aLvu8= Received: by 10.90.49.8 with SMTP id w8mr1184589agw.52.1248300749574; Wed, 22 Jul 2009 15:12:29 -0700 (PDT) Received: from ?192.168.1.100? ([190.177.196.93]) by mx.google.com with ESMTPS id 4sm3369383aga.16.2009.07.22.15.12.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 15:12:29 -0700 (PDT) From: Gonzalo Nemmi To: "Alexandre \"Sunny\" Kovalenko" Date: Wed, 22 Jul 2009 19:12:27 -0300 User-Agent: KMail/1.9.10 References: <1248292053.1479.12.camel@RabbitsDen> <200907221817.31095.gnemmi@gmail.com> <1248299639.1479.17.camel@RabbitsDen> In-Reply-To: <1248299639.1479.17.camel@RabbitsDen> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907221912.27776.gnemmi@gmail.com> Cc: freebsd-current@freebsd.org, current@freebsd.org Subject: Re: Loading atapicam causes panic on 8.0-BETA2 #0 r195818 (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:12:32 -0000 On Wednesday 22 July 2009 6:53:59 pm Alexandre "Sunny" Kovalenko wrote: > On Wed, 2009-07-22 at 18:17 -0300, Gonzalo Nemmi wrote: > > On Wednesday 22 July 2009 4:47:33 pm Alexandre "Sunny" Kovalenko wrote: > > > System: > > > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-BETA2 FreeBSD > > > 8.0-BETA2 #0 r195818: Wed Jul 22 13:50:22 EDT 2009 > > > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX6 > > >0 i386 > > > > > > Hardware: > > > Master: acd0 ATA/ATAPI revision 6 > > > *NOTE*: Curiously enough, I can trigger this without drive being > > > present (it is in the media slice of ThinkPad x60) > > > > > > To reproduce: > > > kldload atapicd; kldload atapicam > > > > > > Crash summary: > > > http://members.verizon.net/~akovalenko/Misc/core.txt.1 > > > > > > Backtrace: > > > (kgdb) bt > > > #0 doadump () at pcpu.h:246 > > > #1 0xa0586614 in boot (howto=260) > > > at /usr/src/sys/kern/kern_shutdown.c:419 > > > #2 0xa058692b in panic (fmt=Variable "fmt" is not available. > > > ) at /usr/src/sys/kern/kern_shutdown.c:575 > > > #3 0xa076ddd5 in trap_fatal (frame=0xfa388678, eva=1180) > > > at /usr/src/sys/i386/i386/trap.c:933 > > > #4 0xa076e0a3 in trap_pfault (frame=0xfa388678, usermode=0, > > > eva=1180) at /usr/src/sys/i386/i386/trap.c:846 > > > #5 0xa076ebab in trap (frame=0xfa388678) > > > at /usr/src/sys/i386/i386/trap.c:528 > > > #6 0xa075281b in calltrap () at > > > /usr/src/sys/i386/i386/exception.s:165 #7 0xaf5ad125 in > > > atapi_action (sim=0xaf4b3300, ccb=0xfa3887a0) at > > > /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:39 > > >0 #8 0xa0453e58 in xpt_action_default (start_ccb=0xfa3887a0) at > > > /usr/src/sys/cam/cam_xpt.c:2580 > > > #9 0xa044eb24 in xpt_action (start_ccb=0xfa3887a0) > > > at /usr/src/sys/cam/cam_xpt.c:2403 > > > #10 0xa0450f77 in xpt_bus_register (sim=0xaf4b3300, > > > parent=0xaf4b4780, bus=0) at /usr/src/sys/cam/cam_xpt.c:3794 > > > #11 0xaf5acce6 in atapi_cam_attach (dev=0xaf4b4780) > > > at > > > /usr/src/sys/modules/ata/atapicam/../../../dev/ata/atapi-cam.c:22 > > >1 #12 0xa05aff94 in device_attach (dev=0xaf4b4780) at > > > device_if.h:178 #13 0xa05b0f5a in device_probe_and_attach > > > (dev=0xaf4b4780) at /usr/src/sys/kern/subr_bus.c:2552 > > > #14 0xa05b1265 in bus_generic_driver_added (dev=0xa633d980, > > > driver=0xaf5aed7c) at /usr/src/sys/kern/subr_bus.c:3303 > > > #15 0xa05ae5d4 in devclass_driver_added (dc=0xa61ccd40, > > > driver=0xaf5aed7c) at bus_if.h:183 > > > #16 0xa05af9d7 in driver_module_handler (mod=0xa70bcc80, what=0, > > > arg=0xaf5aed64) at /usr/src/sys/kern/subr_bus.c:1036 > > > #17 0xa057471e in module_register_init (arg=0xaf5aed4c) > > > at /usr/src/sys/kern/kern_module.c:124 > > > #18 0xa056ccdf in linker_load_module (kldname=Variable "kldname" > > > is not available. > > > ) at /usr/src/sys/kern/kern_linker.c:233 > > > #19 0xa056d1ed in kern_kldload (td=0xa65aab40, file=0xa61ff000 > > > "atapicam", fileid=0xfa388c6c) at > > > /usr/src/sys/kern/kern_linker.c:1015 #20 0xa056d2bf in kldload > > > (td=0xa65aab40, uap=0xfa388cf8) > > > at /usr/src/sys/kern/kern_linker.c:1043 > > > #21 0xa076e474 in syscall (frame=0xfa388d38) > > > at /usr/src/sys/i386/i386/trap.c:1073 > > > #22 0xa07528b0 in Xint0x80_syscall () > > > at /usr/src/sys/i386/i386/exception.s:261 > > > #23 0x00000033 in ?? () > > > Previous frame inner to this frame (corrupt stack?) > > > (kgdb) > > > > > > Please, let me know if I can provide any additional information. > > > > I'm getting a fatal trap 12 every time I try to kldload atapicam on > > BETA2 as well, but I'm not getting a vmcore or anything ... > > > > acd0: DVDR at ata0-master UDMA33 > > > > So, basically, I can confirm kldload atapicam crashes my system but > > I can't provide any cores or anything .. Im probably missing > > something and that's why Im getting nothing under /var/crash .. > > should anyone want to enlighten me with a link to read how to get > > the vmcore, I'll read it and try to get it so I can provide more > > info. > > > > Best regards > > Gonzalo > > Would this help? > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ >kerneldebug.html#KERNELDEBUG-OBTAIN Not really .. I was there before and even if dumpdev="AUTO" and dumpdir="/var/crash" (which I did chmod 700) are set by default in /etc/defaults/rc.conf, I did add those two to /etc/rc.conf .. yet still, I get nothing under /var/crash except for "minfree" :s Am I missing something else? Regards -- Blessings Gonzalo Nemmi From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 22:13:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DC7810656B7 for ; Wed, 22 Jul 2009 22:13:22 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out4.libero.it (cp-out4.libero.it [212.52.84.104]) by mx1.freebsd.org (Postfix) with ESMTP id C6EBB8FC12 for ; Wed, 22 Jul 2009 22:13:21 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from libero.it (192.168.17.5) by cp-out4.libero.it (8.5.107) id 4A6742FD00033ED3; Thu, 23 Jul 2009 00:13:18 +0200 Date: Thu, 23 Jul 2009 00:13:18 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "barbara" To: "peter\.schuller" X-XaM3-API-Version: 4.3 (R1) (B3pl25) X-SenderIP: 87.17.226.96 Cc: freebsd-current Subject: Re:vm_page_remove() crash on sys_exit() (possibly ZFS related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:13:22 -0000 > Hello, > > so I finally got my crash dump. I'll include some more history further > down. First off: > > http://distfiles.scode.org/mlref/crashdump_20090722/core.txt.0 > http://distfiles.scode.org/mlref/crashdump_20090722/backtrace.txt Does this look similar to what I've just had? http://lists.freebsd.org/pipermail/freebsd-bugs/2009-July/036054.html i386 and no zfs here. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 22:16:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF6AE10656E3 for ; Wed, 22 Jul 2009 22:16:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5038FC1F for ; Wed, 22 Jul 2009 22:16:32 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 55D525C024 for ; Thu, 23 Jul 2009 06:16:31 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 29B2255CD8B9; Thu, 23 Jul 2009 06:16:31 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id 002r-Kq+Wiir; Thu, 23 Jul 2009 06:15:37 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 1337755CD8BA; Thu, 23 Jul 2009 06:15:30 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=CSDFlkmAveixbD7e1EJVDI9K/4fEf+AK7tuaVnw7iHCLlHANU1IIEVifAW1LKyO6K PSVenPRscTby1ZpaEQy4w== Message-ID: <4A678F71.6030006@delphij.net> Date: Wed, 22 Jul 2009 15:15:13 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: "Li, Qing" References: <4A5F8010.7050504@delphij.net> <4A5F7540.7070201@delphij.net> <4A5EF889.6040604@delphij.net> <4A61544E.2050208@delphij.net> <4A6692F7.4080905@incunabulum.net> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ian FREISLICH , Bruce Simpson , d@delphij.net, FreeBSD Current Subject: Re: CARP broken on -CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:16:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Li, Qing wrote: > This is still under investigation. Yes, consider my previously proposed change a "known-to-work workaround" but not a real solution, as we have similar problems for other protocols. >> -----Original Message----- >> From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd- >> current@freebsd.org] On Behalf Of Bruce Simpson >> Sent: Tuesday, July 21, 2009 9:18 PM >> To: d@delphij.net >> Cc: Ian FREISLICH; FreeBSD Current >> Subject: Re: CARP broken on -CURRENT? >> >> Hi Xin, >> >> Xin LI wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> I got it. It was the cached llentry that preventing ether_output() >> to >>> choose the right broadcast/multicast address and use the default >>> gateway's L2 address. Here is a proposed patch. >>> >> This patch has been reported to fix a regression with multicast >> transmission, please can you commit? >> >> thanks, >> BMS >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current- >> unsubscribe@freebsd.org" - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpnj3EACgkQi+vbBBjt66AyyACgjpdupI+Eq70gfVNe8jf8p8PL eCMAn24pHS8wu7p9q0lZq5OmKXC8F0cN =gVrO -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 22:28:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 72D1C106566B for ; Wed, 22 Jul 2009 22:28:48 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by mx1.freebsd.org (Postfix) with SMTP id 317C58FC08 for ; Wed, 22 Jul 2009 22:28:48 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: (qmail 88250 invoked from network); 22 Jul 2009 22:28:47 -0000 Received: from unknown (HELO ?10.10.10.3?) (webmaster@69.108.138.13 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 22 Jul 2009 22:28:47 -0000 X-YMail-OSG: D8aX_PgVM1mQ2DowcNEgRL_cJlSPTdQF_mcLY3lVnAtDmOGhpEJzCnjQPIojmlxvJVhyeFiff1tG.XPY9bI82skPZyKD0L.bDNatZ7RvU6YjgfMTLlr4tp9G4O1xQejjoTJJzTomKWEsGxU4lr82kmtgpF5nkUfY2FEgrhvyF3DYcu9c.pGz3PkUPWuYj4qfakFR37kGHWVU41awrstb2Ub3FvybKB9uMZupnYPnzRlkqjl7eny5ne4BONtAkPjIFP0Wlit5DkJBV2376j4iIh6rEXUa3Y5DrMK0Kt2d21Du2tVLLATkZjkN6VX7O3.eKv5q7t.Up_TJMUlKTcgTcvI- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A679223.10604@doghouserepair.com> Date: Wed, 22 Jul 2009 15:26:43 -0700 From: Ryan Rogers User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: Weongyo Jeong References: <4A66CFFC.30601@doghouserepair.com> <11167f520907220200m5dd456dfs2ad53d4b579b851b@mail.gmail.com> <4A66D587.9060001@haruhiism.net> <11167f520907220326m430709efv7aa6c779f9511b78@mail.gmail.com> <20090722211600.GC1184@weongyo.local> In-Reply-To: <20090722211600.GC1184@weongyo.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nfe problem on 8.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:28:48 -0000 Weongyo Jeong wrote: > On Wed, Jul 22, 2009 at 05:26:07AM -0500, Sam Fourman Jr. wrote: >>> svn co svn://svn.freebsd.org/base/head >>> svn merge -c -193289 >>> >>> Thereafter, in the root of the repo: >>> svn up >>> svn merge >> Confirmed, running the above set of commands fixed my 88E1116 nfe problem >> everything works as it should now. thanks guys for the help. >> >> Sam Fourman Jr. >> >> ps. svn was WAY faster than csup, I think I am going to use svn all >> the time now. > > I know that yongari@ knows what the problem is and the solution but he > could not access the internet right now due to relocation to USA. > > It looks he is busy with looking for house and etc... > > regards, > Weongyo Jeong > > > Well, the good news is that r193289 was the only thing keeping my nics from working. I was able to update to current as of today and revert that patch, and everything is working nicely now. So I'll just keep my eye on the commit logs and patch that up by hand whenever I need to update until yongari is able to get situated. Thanks for the help everyone. Ryan From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 22:46:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22335106564A for ; Wed, 22 Jul 2009 22:46:42 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id A42D28FC1F for ; Wed, 22 Jul 2009 22:46:41 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: by fxm18 with SMTP id 18so478951fxm.43 for ; Wed, 22 Jul 2009 15:46:40 -0700 (PDT) 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 :content-transfer-encoding; bh=52T0X22W9qZQ9XzoylvBa7wC4Jr07Jsyd+pwhZsetUM=; b=Ig+x2p8LnyWgj1iBgUY/HekgewWD6YT9gaCuvUzLtavYiyqe+n0IuqzzYU1MSpQULd H/6RmXKmJx4Z1r7ASdCzcsviJFRJeKp6n2V9hbUWTjwmDLXcr+pCMJOf5Zmce0cmQGEZ 830kbpMECQTgFOEl/rWo7r62noe/qyfWX/Cas= 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:content-transfer-encoding; b=rRuwHOhXAJXgjmx1XI4QtbhuxuZMpBY8F+YgoMmZ7NIpkvR9ntz5/3Y3UKO056e46X a2TIDPV7w2g2TobA45avNIfT23CDvCLd7yTLziiZ/zktzCShdRW21rsPREaOrdbgYt3t B35fJM8TdN85vE+2OXZ8+Uc/vbVVcgsUuohjc= MIME-Version: 1.0 Received: by 10.223.109.19 with SMTP id h19mr813792fap.20.1248301029403; Wed, 22 Jul 2009 15:17:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 23 Jul 2009 00:17:09 +0200 Message-ID: From: Daniel Nebdal To: Chris Hedley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Linux NFS ate my bge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 22:46:42 -0000 On Wed, Jul 22, 2009 at 11:53 PM, Chris Hedley wrote: > In which case I guess my next question is "what cheap but good PCI/PCI-X > (but not PCIe) based card would you recommend?" since I'd rather just get > this one sorted out once and for all. =A0My only real requirement is that= it > does 1 Gbit. =A0And works. > Cheers, > > Chris. Looking at my local webshop, an intel pro1000/GT is about $65. Not the very cheapest, but the other intel gbit cards I've used have been very good, and em(4) is a well-supported driver. --=20 Daniel Nebdal From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 23:07:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 403E2106566B for ; Wed, 22 Jul 2009 23:07:38 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1560E8FC1C for ; Wed, 22 Jul 2009 23:07:37 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n6MN7YCt012789; Wed, 22 Jul 2009 16:07:34 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n6MN7YhU012788; Wed, 22 Jul 2009 16:07:34 -0700 (PDT) Date: Wed, 22 Jul 2009 16:07:34 -0700 (PDT) From: Matthew Dillon Message-Id: <200907222307.n6MN7YhU012788@apollo.backplane.com> To: Chris Hedley References: Cc: freebsd-current@freebsd.org Subject: Re: Linux NFS ate my bge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 23:07:38 -0000 :requests. : :I've (re)discovered this now that I've recently got my assorted config :problems largely ironed out and have my FreeBSD box up to date again, I'm :reminded of an unresolved problem from way back, which is that my bge card :collapses after being subjected to a large amount of NFS traffic coming :from my Linux box, e.g. recompiling KDE on a discless workstation, which :has been responsible for three embuggerances so far today. If you are using a NFS UDP mount, try using a NFS TCP mount instead. This could very well instantly fix your issues even if it does not solve the underlying bugs. With a UDP mount the server can get a barrage of IP fragmented UDP packets, particularly from linux clients. While I don't know any specific with regards to bugs in the bge driver itself, I do know that for a UDP mount to operate adequately over a GigE network the NFS server needs about a 2 Megabyte socket buffer to receive the bursts. This is not something that would typically be seen between two FreeBSD boxes as FreeBSD's asynchronous NFS client traffic (mainly read-ahead) is limited by available synchronous nfsiod threads, and further limited by default mount options, internal #defined concurrency limits, and by the out-of-order transmission of the read ahead rpcs caused by the way the nfsiod threads operate (which results in out-of-order processing on the server side and stalls the linear reads done by the client). Linux clients, on the other-hand can generate an enormous number of concurrent RPCs. Use of a TCP mount instead of a UDP mount solves the sockbuf and IP fragmentation issues. The TCP connection will not use fragmented IP packets, will not blow away the server's receive-side sockbuf, and does a much better job dealing with any packet loss, to boot. -Matt From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 23:15:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 739F51065674 for ; Wed, 22 Jul 2009 23:15:26 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from mail.chrishedley.com (77-44-98-139.xdsl.murphx.net [77.44.98.139]) by mx1.freebsd.org (Postfix) with ESMTP id 1D21B8FC08 for ; Wed, 22 Jul 2009 23:15:25 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from localhost (localhost [127.0.0.1]) by mail.chrishedley.com (Postfix) with ESMTP id C276B6D960; Thu, 23 Jul 2009 00:15:23 +0100 (BST) X-Virus-Scanned: amavisd-new at chrishedley.com Received: from mail.chrishedley.com ([127.0.0.1]) by localhost (mail.chrishedley.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5UgrgQgYogl1; Thu, 23 Jul 2009 00:15:20 +0100 (BST) Received: from teapot.cbhnet (teapot.cbhnet [192.168.1.1]) by mail.chrishedley.com (Postfix) with ESMTP id 4A52C6D945; Thu, 23 Jul 2009 00:15:20 +0100 (BST) Date: Thu, 23 Jul 2009 00:15:20 +0100 (BST) From: Chris Hedley X-X-Sender: cbh@teapot.cbhnet To: Matthew Dillon In-Reply-To: <200907222307.n6MN7YhU012788@apollo.backplane.com> Message-ID: References: <200907222307.n6MN7YhU012788@apollo.backplane.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: Linux NFS ate my bge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 23:15:26 -0000 On Wed, 22 Jul 2009, Matthew Dillon wrote: > If you are using a NFS UDP mount, try using a NFS TCP mount instead. > This could very well instantly fix your issues even if it does not > solve the underlying bugs. > ... > Use of a TCP mount instead of a UDP mount solves the sockbuf and > IP fragmentation issues. The TCP connection will not use fragmented IP > packets, will not blow away the server's receive-side sockbuf, and > does a much better job dealing with any packet loss, to boot. "But I'm already using TCP!" I was about to say - actually turns out I'm not, and I have to wonder if my bright idea to change to UDP (probably for performance reasons, though I don't think it made any difference) coincides with the problems I was seeing. I'll give it a try and see how I get on. I think I'll still follow Daniel's kind suggestion for a replacement interface card, but this may well make things a bit less painful in the meantime. I'll resume my network-intensive KDE build tomorrow and post my findings (or, hopefully, lack thereof as far as outages are concerned!) Chris. From owner-freebsd-current@FreeBSD.ORG Wed Jul 22 23:40:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22CDE106566B for ; Wed, 22 Jul 2009 23:40:07 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id EC0BA8FC0C for ; Wed, 22 Jul 2009 23:40:06 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n6MNe4HE013224; Wed, 22 Jul 2009 16:40:04 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n6MNe3K5013221; Wed, 22 Jul 2009 16:40:03 -0700 (PDT) Date: Wed, 22 Jul 2009 16:40:03 -0700 (PDT) From: Matthew Dillon Message-Id: <200907222340.n6MNe3K5013221@apollo.backplane.com> To: Chris Hedley References: <200907222307.n6MN7YhU012788@apollo.backplane.com> Cc: freebsd-current@freebsd.org Subject: Re: Linux NFS ate my bge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 23:40:07 -0000 TCP will likely work better, for several reasons, not the least of which being that the NFS client does not have to estimate a retransmit timeout on a rpc-by-rpc basis. Such estimations fail utterly in the face of a large number of concurrent RPCs because latency winds up being governed by the disk backlog on the server. A UDP mount will wind up retransmitting even under completely lossless conditions. Another reason TCP tends to work better is that UDP uses IP fragmentation and IP fragmentation reassembly is not typically in the critical path. The desired NFS filesystem block size is 16K (smaller will typically reduce performance), so even a 9000 MTU won't help. Also use netstat ... not sure what option, I think -x, to determine the actual size of the socket buffer being employed for the connection (TCP or UDP). There are multiple internal caps in the kernel and it is often not as big as you might have thought it should be. You want a 256KB socket buffer at a minimum for a GigE network. Smaller works (at least for linear transfers), but you lose a lot of RPC concurrency from the client. Again, something that matters more for a linux client vs a FreeBSD client. -Matt From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 00:08:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E9D01065677 for ; Thu, 23 Jul 2009 00:08:04 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 06F4F8FC1F for ; Thu, 23 Jul 2009 00:08:03 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so307548qwe.7 for ; Wed, 22 Jul 2009 17:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=7QeGClP0tBBn4kmlTulZXWY5eq0+cC0AduRWh1Vaf08=; b=bMIsLRxZcTy9sDRBnM4bRjNBYXdoPkRu5cZcnOy0h/hmq9VRB5QUU3MhUENLZY2k/4 QQW+N1xBrrTnWrVMLH7G4Qzeo1tTBepqCW23OSF0mCz1XTOdBcEDbCL4rKTtaQyTq4F0 4/TX7j6YCIUhF6Xz0JZO23zO/aXGO/EBO0w3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=IeOAn/cb/xyNsC3PonUJzIatY6GdLHjI6t7AWd2zbeKUX+TLCjyEeDDXY5VfMQO7Hi tqUzhv6IN1lauJ1MgZa2eahsNQXrYx1vuwc52TmAVworpoz1FzSFVHtwh5BFfDaeBSRs 7u8gOVtoU+3oO4N9t+lmSt/K/19PQryx87d8E= Received: by 10.224.2.65 with SMTP id 1mr1367982qai.344.1248307683405; Wed, 22 Jul 2009 17:08:03 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.108.65]) by mx.google.com with ESMTPS id 7sm1361323qwb.0.2009.07.22.17.08.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 22 Jul 2009 17:08:02 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 01A55B80C2; Wed, 22 Jul 2009 21:07:57 -0300 (BRT) Received: from 189.59.75.37 (proxying for 10.12.1.221, 10.12.1.7) (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Wed, 22 Jul 2009 21:07:57 -0300 (BRT) Message-ID: <88c9d55ce088bdbd079185bb6abac971.squirrel@cygnus.homeunix.com> In-Reply-To: References: Date: Wed, 22 Jul 2009 21:07:57 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: ZFS pool corrupted on upgrade of -current (probably sata renaming) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 00:08:04 -0000 On Wed, July 22, 2009 15:41, Freddie Cash wrote: > On Wed, Jul 22, 2009 at 6:12 AM, Nenhum_de_Nos > wrote: > >> >> On Wed, July 15, 2009 13:22, Freddie Cash wrote: >> > On Tue, Jul 14, 2009 at 8:44 PM, Randy Bush wrote: >> > >> >> > # glabel label disk01 /dev/ad4 >> >> > # glabel label disk02 /dev/ad6 >> >> > # glabel label disk03 /dev/ad8 >> >> > # zpool create pool raidz1 label/disk01 label/disk02 label/disk03 >> >> > >> >> > After that, you can shuffle the drives around in the system, and >> the >> >> pool >> >> > will continue to work correctly. >> >> >> >> ooooooo! i wish i had understood that when i built a large set of >> >> mirrored raid. >> >> >> >> any way to hack it ex post facto? >> >> >> > >> > Yep. It's as simple as: >> > >> > * label all the drives using glabel, while they're still attached to >> the >> > pool >> > * use "zpool replace pool ad4 label/disk01" to replace 1 drive >> > * wait for it to resilver >> > * use "zpool replace pool ad6 label/disk02" to replace the next >> drive >> > * repeat the resilver and replace until all the devices are replaced >> > >> > This is what I did to one of our servers. Works quite nicely. >> > >> > There's no need to detach anything. >> >> was all this supposed to work with raidz ? >> >> here it doesn't. >> >> harry# zpool status >> pool: zdados >> state: ONLINE >> scrub: none requested >> config: >> >> NAME STATE READ WRITE CKSUM >> zdados ONLINE 0 0 0 >> raidz1 ONLINE 0 0 0 >> ad8 ONLINE 0 0 0 >> ad10 ONLINE 0 0 0 >> ad12 ONLINE 0 0 0 >> >> errors: No known data errors >> harry# zpool detach zdados ad8 >> cannot detach ad8: only applicable to mirror and replacing vdevs >> > > Reread what you quoted. :) Note how there's no "detach" step. :) Just > label and replace. ok, my bad :) I used the wrong mail to quote and get into the thread. bellow this message, I think I saw someone saying not to do this. use the detach. I'll try anyway. not much sensitive data here... thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 00:29:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93CC11065672; Thu, 23 Jul 2009 00:29:58 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 45E928FC08; Thu, 23 Jul 2009 00:29:58 +0000 (UTC) (envelope-from sam@errno.com) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n6N0Tv8J026845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2009 17:29:57 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A67AF05.7060504@errno.com> Date: Wed, 22 Jul 2009 17:29:57 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Giorgos Keramidas References: <87eis8g3b9.fsf@kobe.laptop> In-Reply-To: <87eis8g3b9.fsf@kobe.laptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: lagg0 and tcpdump problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 00:29:58 -0000 Giorgos Keramidas wrote: > When I run tcpdump on lagg0 (with em0 and iwn0 as laggports), tcpdump > seems to work fine, but typing ^C kills the wireless interface too. > > My /var/log/messages shows at the time: > > Jul 22 17:59:29 kobe kernel: --- syscall (6, FreeBSD ELF32, close), eip = 0x28393313, esp = 0xbfbfe78c, ebp = 0xbfbfe7a8 --- > Jul 22 17:59:29 kobe kernel: taskqueue_drain with the following non-sleepable locks held: > Jul 22 17:59:29 kobe kernel: exclusive rw if_lagg rwlock (if_lagg rwlock) r = 0 (0xcb651704) locked @ /usr/src/sys/modules/if_lagg/../../net/if_lagg.c:953 > Jul 22 17:59:29 kobe kernel: exclusive sleep mutex bpf global lock (bpf global lock) r = 0 (0xc0bc1e90) locked @ /usr/src/sys/net/bpf.c:605 > Jul 22 17:59:29 kobe kernel: KDB: stack backtrace: > Jul 22 17:59:29 kobe kernel: db_trace_self_wrapper(c09a567c,fba428ec,c06be155,c09b0bcd,25d,...) at db_trace_self_wrapper+0x26 > Jul 22 17:59:29 kobe kernel: kdb_backtrace(c09b0bcd,25d,ffffffff,c0b90604,fba42924,...) at kdb_backtrace+0x29 > Jul 22 17:59:29 kobe kernel: _witness_debugger(c09a7af7,fba42938,4,1,0,...) at _witness_debugger+0x25 > Jul 22 17:59:29 kobe kernel: witness_warn(5,0,c0961ec8,137,c673c85c,...) at witness_warn+0x1fd > Jul 22 17:59:29 kobe kernel: taskqueue_drain(c673c840,c678c0b8,d5821000,fba42994,c075a5fc,...) at taskqueue_drain+0xa9 > Jul 22 17:59:29 kobe kernel: ieee80211_waitfor_parent(c678c000,0,c09b6c55,caf,c678c000,...) at ieee80211_waitfor_parent+0x7b > Jul 22 17:59:29 kobe kernel: ieee80211_ioctl(d2633400,80206910,fba429b4,c6515748,8903,...) at ieee80211_ioctl+0x1ac > Jul 22 17:59:29 kobe kernel: if_setflag(d2633438,0,fba42a18,c06bdf9c,100,...) at if_setflag+0x10a > Jul 22 17:59:29 kobe kernel: ifpromisc(d2633400,0,c7e96a43,431,1,...) at ifpromisc+0x33 > Jul 22 17:59:29 kobe kernel: lagg_setflags(cb651704,c7e96a43,3b9,c09b09ad,c650e380,...) at lagg_setflags+0x84 > Jul 22 17:59:29 kobe kernel: lagg_ioctl(c7057800,80206910,fba42aec,fba42b1c,8903,...) at lagg_ioctl+0x50c > Jul 22 17:59:29 kobe kernel: if_setflag(c7057838,0,c09a0c3d,df,0,...) at if_setflag+0x10a > Jul 22 17:59:29 kobe kernel: ifpromisc(c7057800,0,c09b0bcd,236,c6551a4c,...) at ifpromisc+0x33 > Jul 22 17:59:29 kobe kernel: bpf_detachd(c0bc1e90,0,c09b0bcd,25d,d93e57a0,...) at bpf_detachd+0x249 > Jul 22 17:59:29 kobe kernel: bpf_dtor(ca46a100,0,c099768a,9e,c7789460,...) at bpf_dtor+0xb0 > Jul 22 17:59:29 kobe kernel: devfs_destroy_cdevpriv(d93e57a0,0,c099768a,a8,fba42be4,...) at devfs_destroy_cdevpriv+0xac > Jul 22 17:59:29 kobe kernel: devfs_fpdrop(c7789460,cd581b40,3,0,c7789460,...) at devfs_fpdrop+0x68 > Jul 22 17:59:29 kobe kernel: _fdrop(c7789460,cd581b40,fba42c18,c06bdf9c,0,cd581be4,c0b90600,c0a0afa0,c099cf22,cc5efa2c,45b,c099cf22,fba42c40,c0684440,cc5efa2c,8,c099cf22,45b) at _fdrop+0x53 > Jul 22 17:59:29 kobe kernel: closef(c7789460,cd581b40,45b,440,cc5efa2c,...) at closef+0x290 > Jul 22 17:59:29 kobe kernel: kern_close(cd581b40,3,fba42d2c,c0932863,cd581b40,...) at kern_close+0x117 > Jul 22 17:59:29 kobe kernel: close(cd581b40,fba42cf8,4,c099ed18,c0a01b68,...) at close+0x1a > Jul 22 17:59:29 kobe kernel: syscall(fba42d38) at syscall+0x2a3 > Jul 22 17:59:29 kobe kernel: Xint0x80_syscall() at Xint0x80_syscall+0x20 > Jul 22 17:59:29 kobe kernel: --- syscall (6, FreeBSD ELF32, close), eip = 0x28393313, esp = 0xbfbfe78c, ebp = 0xbfbfe7a8 --- > This is a known issue; bpf is holding a mutex over calls to the driver that may block (in this case the taskqueue_drain calls in net80211). It's unlikely to be resolved for 8.0 (too risky). > Then typing ^C stops tcpdump but the log shows: > > Jul 22 17:59:29 kobe kernel: wlan0: promiscuous mode disabled > Jul 22 17:59:29 kobe kernel: em0: promiscuous mode disabled > Jul 22 17:59:29 kobe kernel: iwn0: error, INTR=82000000 STATUS=0x40010000 > Jul 22 17:59:29 kobe kernel: lagg0: promiscuous mode disabled > Jul 22 17:59:30 kobe kernel: iwn0: iwn_transfer_firmware: timeout waiting for first alive notice, error 35 > Jul 22 17:59:30 kobe kernel: iwn0: iwn_init_locked: could not load firmware, error 35 > Jul 22 17:59:30 kobe kernel: wlan0: link state changed to DOWN > Jul 22 17:59:30 kobe kernel: lagg0: link state changed to DOWN > > At this point wlan0 is without carrier, and stays that way until I > unplumb wlan0 and lagg0 and re-create them. > > It seems that at this part of if_lagg.c we are locking the lagg softc, > but then we call lagg_setflags() -> lagg_setflag(): > > 953 LAGG_WLOCK(sc); > 954 SLIST_FOREACH(lp, &sc->sc_ports, lp_entries) { > 955 lagg_setflags(lp, 1); > 956 } > 957 LAGG_WUNLOCK(sc); > > but this vectors into the wlan code near if_lagg.c:line 1088. Does it > make sense to drop the exclusive lagg lock around the code to the port > flag changing code or would this introduce a silly race? > > %%% > --- a/sys/net/if_lagg.c Wed Jul 15 15:29:17 2009 +0300 > +++ b/sys/net/if_lagg.c Wed Jul 22 18:10:29 2009 +0300 > @@ -1085,7 +1085,9 @@ > * in accord with actual ports flags. > */ > if (status != (lp->lp_ifflags & flag)) { > + LAGG_WUNLOCK(sc); > error = (*func)(ifp, status); > + LAGG_WLOCK(sc); > if (error) > return (error); > lp->lp_ifflags &= ~flag; > %%% Sounds like iwn isn't reacting well to the calls coming in from lagg. wlandebug state should provide some insight. I've used lagg+iwn+em on a t61p with no obvious issues but never tried to run tcpdump on the lagg port. Sam From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 01:03:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 072C41065672; Thu, 23 Jul 2009 01:03:18 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id D9A5E8FC13; Thu, 23 Jul 2009 01:03:17 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n6N13HK1016131; Wed, 22 Jul 2009 18:03:17 -0700 (PDT) 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, 22 Jul 2009 18:02:20 -0700 Message-ID: In-Reply-To: <4A6469CE.4060907@restart.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections Thread-Index: AcoJObSWT5TAEZHBQUSzJcSfFLGE8QB9xV6w References: <4A5734C3.3000806@restart.be> <4A5864DC.1070106@restart.be> <4A6469CE.4060907@restart.be> From: "Li, Qing" To: "Henri Hennebert" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: RE: 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 01:03:18 -0000 > > > Just another case where the route must be created: >=20 That's probably because I explicitly disabled such route installation for PPP link type. Please apply patch http://people.freebsd.org/~qingli/patch and let me know if that solves your problem. Thanks, -- Qing > [root@avoriaz ~]# ifconfig gif0 > gif0: flags=3D8051 metric 0 mtu 1280 > tunnel inet 212.239.166.57 --> 94.23.44.41 > inet6 fe80::21d:60ff:fead:2ace%gif0 prefixlen 64 scopeid 0x4 > inet6 2001:41d0:2:2d29:1:ffff:: --> 2001:41d0:2:2d29:0:ffff:: > prefixlen > 128 > options=3D1 >=20 > [root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff:: > PING6(56=3D40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: --> > 2001:41d0:2:2d29:1:ffff:: > ^C > --- 2001:41d0:2:2d29:1:ffff:: ping6 statistics --- > 4 packets transmitted, 0 packets received, 100.0% packet loss >=20 > [root@avoriaz ~]# route add -inet6 2001:41d0:2:2d29:1:ffff:: -interface > lo0 > add host 2001:41d0:2:2d29:1:ffff::: gateway lo0 >=20 > [root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff:: > PING6(56=3D40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: --> > 2001:41d0:2:2d29:1:ffff:: > 16 bytes from ::1, icmp_seq=3D0 hlim=3D64 time=3D0.531 ms > 16 bytes from ::1, icmp_seq=3D1 hlim=3D64 time=3D0.884 ms > 16 bytes from ::1, icmp_seq=3D2 hlim=3D64 time=3D0.748 ms > ^C > --- 2001:41d0:2:2d29:1:ffff:: ping6 statistics --- > 3 packets transmitted, 3 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev =3D 0.531/0.721/0.884/0.145 ms >=20 > Thanks >=20 > Henri > > > > -----Original Message----- > > From: Henri Hennebert [mailto:hlh@restart.be] > > Sent: Sat 7/11/2009 3:09 AM > > To: Li, Qing > > Cc: freebsd-stable@freebsd.org; freebsd-net@freebsd.org > > Subject: Re: 8.0-BETA1 - for the record - different paths followed by > IPv4 and IPv6 for 'local' connections > > > > Li, Qing wrote: > >> Hi, > >> > >> Please try patch-7-10 in my home directory > http://people.freebsd.org/~qingli/ > >> and let me know how it works out for you. I thought I had committed > the patch > >> but turned out I didn't. > > > > I apply the patch, reset my pf.conf to its previous content and all > is > > running smoothly. By the way, I discover after my post that my > > "solution" was not working for long (many bytes) connections and this > is > > solved too. > > > > Many thank for your time > > > > Henri > > > > PS please commit as soon as possible > > > >>> On 8.0-BETA1 there is an assymetry: > >>> > >>> netstat -rn display > >>> > >>> 192.168.24.1 link#3 > >>> .... > >>> no entry for 2001:41d0:2:2d29:1:1:: > >>> > >> This is by design as part of the new architecture in 8.0, which > maintains > >> the L2 ARP/ND6 and L3 routing tables separately. > >> > >> -- Qing > >> > >> > >> > >> -----Original Message----- > >> From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert > >> Sent: Fri 7/10/2009 5:32 AM > >> To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org > >> Subject: 8.0-BETA1 - for the record - different paths followed by > IPv4 and IPv6 for 'local' connections > >> > >> Hello, > >> > >> After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem > when > >> connecting with firefox to a local apache server using the global > >> unicast IPv6 address of the local machine. pf.conf must be updated! > >> > >> My configuration: > >> > >> [root@avoriaz ~]# ifconfig em0 > >> > >> em0: flags=3D8843 metric 0 mtu > 1500 > >> > options=3D19b 4> > >> ether 00:1d:60:ad:2a:ce > >> inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255 > >> inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 > >> inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 > >> media: Ethernet 100baseTX (100baseTX ) > >> status: active > >> > >> [root@avoriaz ~]# host www.restart.bel > >> www.restart.bel is an alias for avoriaz.restart.bel. > >> avoriaz.restart.bel has address 192.168.24.1 > >> avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: > >> > >> pf.conf: > >> > >> int_if=3D"em0" > >> block in log all > >> block out log all > >> set skip on lo0 > >> antispoof quick for $int_if inet > >> # Allow trafic with physical internal network > >> pass in quick on $int_if from ($int_if:network) to ($int_if) keep > state > >> pass out quick on $int_if from ($int_if) to ($int_if:network) keep > state > >> > >> The problem: > >> > >> [root@avoriaz ~]# telnet -4 www.restart.bel 80 > >> Trying 192.168.24.1... > >> Connected to avoriaz.restart.bel. > >> Escape character is '^]'. > >> ^] > >> telnet> quit > >> Connection closed. > >> [root@avoriaz ~]# telnet -6 www.restart.bel 80 > >> Trying 2001:41d0:2:2d29:1:1::... > >> --->Never connect and get a timeout! > >> > >> tcpdump and logging in pf show me that > >> > >> For a IPv4 connection: > >> the packet from telnet to apache pass 2 times on lo0 (out and in) > >> the answer packet from apache to telnet pass 2 times on lo0 (out and > in) > >> > >> So no problem, there is `set skip on lo0' > >> > >> For a IPv6 connection: > >> The first packet from telnet to apache pass 2 times on lo0 (out and > in) > >> The answer packet from apache to telnet path on em0 and is rejected > >> due to the default flags S/SA. > >> > >> So I have to change pf.conf and replace the last line: > >> pass out quick on $int_if from ($int_if) to ($int_if:network) \ > >> keep state flags any > >> > >> Then all is OK > >> > >> By the way, on 7.2 > >> > >> netstat -rn display > >> > >> 192.168.24.1 00:1d:60:ad:2a:ce > >> .... > >> 2001:41d0:2:2d29:1:1:: 00:1d:60:ad:2a:ce > >> > >> > >> On 8.0-BETA1 there is an assymetry: > >> > >> netstat -rn display > >> > >> 192.168.24.1 link#3 > >> .... > >> no entry for 2001:41d0:2:2d29:1:1:: > >> > >> Hope it may help someone > >> > >> Henri > >> > >> _______________________________________________ > >> freebsd-stable@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable > >> To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" > >> > > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 01:57:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AC241065670 for ; Thu, 23 Jul 2009 01:57:09 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwqsrv01p.mx.bigpond.com (nschwqsrv01p.mx.bigpond.com [61.9.189.231]) by mx1.freebsd.org (Postfix) with ESMTP id 12D4E8FC08 for ; Thu, 23 Jul 2009 01:57:08 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx02p.mx.bigpond.com ([124.188.162.219]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20090723003136.XRJM1829.nschwmtas03p.mx.bigpond.com@nschwotgx02p.mx.bigpond.com> for ; Thu, 23 Jul 2009 00:31:36 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx02p.mx.bigpond.com with ESMTP id <20090723003136.WJJQ13014.nschwotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Thu, 23 Jul 2009 00:31:36 +0000 Received: (qmail 12556 invoked by uid 501); 23 Jul 2009 00:31:23 -0000 Date: Thu, 23 Jul 2009 10:31:23 +1000 From: Andrew Reilly To: Marc UBM Bocklet Message-ID: <20090723003123.GB11945@duncan.reilly.home> References: <4A66C7BB.6030307@samsco.org> <20090722193148.dfc8f7aa.ubm@u-boot-man.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090722193148.dfc8f7aa.ubm@u-boot-man.de> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.4A67AF68.00F3,ss=1,fgs=0 X-SIH-MSG-ID: ohgxFtz2TAD0zmQv0WC2OwcnyAzlq3Mv8Z4QX81loRIGTUDBp8PfStrHK+ZRu8u6xDxPJhqFNGIhaa/iTY3RstCK Cc: freebsd-current@freebsd.org Subject: Re: run_interrupt_driven_hooks - waiting for xpt_config - booting on DL380 G6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 01:57:09 -0000 On Wed, Jul 22, 2009 at 07:31:48PM +0200, Marc UBM Bocklet wrote: > On Wed, 22 Jul 2009 02:03:07 -0600 > Scott Long wrote: > > > This is probably a CISS P410 controller, right? It'll say exactly > > what it is further up in the boot messages. I know of the problem > > here, and I'm working on a fix. However, it might be a few more days > > before I have anything that can be tested. > > Is it likely that your patch will also apply for my RocketRaid 2322 > controller? (I seem to have the same problem as the original poster) > > Thanks a lot for tackling this! I get this probelem every time I boot (I've sent a PR on the subject). Yesterday I discovered that I could kick the system past the xpt_config log-jam by unplugging my external USB disk drive (and later re-plugging it.) Presumably this means that the interrupt that was being waited-for was a USB one in my case, and the removal generated an interrupt that got the driver to sort things out. [This is on 7-STABLE rather than -CURRENT, so perhaps a different problem altogether?] -- Andrew From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 02:38:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 929AF106566C for ; Thu, 23 Jul 2009 02:38:40 +0000 (UTC) (envelope-from drew@mykitchentable.net) Received: from smtp1.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id 53CBE8FC19 for ; Thu, 23 Jul 2009 02:38:40 +0000 (UTC) (envelope-from drew@mykitchentable.net) Received: (qmail 8182 invoked from network); 22 Jul 2009 20:01:54 -0700 Received: by simscan 1.1.0 ppid: 8159, pid: 8162, t: 2.2517s scanners: regex: 1.1.0 attach: 1.1.0 spam: 3.1.7-deb X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on smtp1.surewest.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=10.0 tests=none autolearn=disabled version=3.1.7-deb X-Spam-CMAE-Analysis: v=1.0 c=1 a=0fHVTxLUsUkA:10 a=jDt-9pEAAAAA:8 a=1NGZCLlUl76i1h-bwFQA:9 a=wamyKHXLWoqfyGuobw0PJ4k8ToUA:4 Received: from unknown (HELO blacklamb.mykitchentable.net) (69.62.230.77) by smtp1 with SMTP; 22 Jul 2009 20:01:52 -0700 Received: from [192.168.2.3] (unknown [192.168.2.3]) by blacklamb.mykitchentable.net (Postfix) with ESMTPA id AC80316550C for ; Wed, 22 Jul 2009 19:38:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mykitchentable.net; s=default; t=1248316716; bh=0TklqlReeCm6wb6zT3NaRdjwggHL3j7MlVgZV0U57Vc=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=GP5Q1DV70shx/FWNV78N0/mXQEZPa4E0GgfW/fiPkpVxbwqAVczBULeoqGWiDWcjC 1bXOVHJgG+EL41Q5E/QPHGazb74XcopXPlRi7prZTxjHsBxb2flpM0mDaWVIm+ppVl NRuKzhr0lyugTJVVpbZmJlDLtrA20CjzdPLhPWWc= Message-ID: <4A67CD2B.9040200@mykitchentable.net> Date: Wed, 22 Jul 2009 19:38:35 -0700 From: Drew Tomlinson User-Agent: Thunderbird 2.0.0.22 (X11/20090717) MIME-Version: 1.0 To: FreeBSD current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: USB 2.0 External Drive - What Is A Reasonable Transfer Rate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 02:38:40 -0000 I have a USB 2.0 external drive that's formatted as NTFS under Windows XP. I've plugged it into my 8.0 BETA2 install and am copying files to a local raid1z zpool with one vdev consisting of 4 drives. I'm trying to move about 100 GB of assorted files and have been at it all day. The USB drive contains assorted files such as mp3, CD/DVD images, zip, documents, etc. I'm guessing most files range between 1 - 4 MB with some as large as 4 GB. Anyway, iostat shows the transfer rate at around 2 - 3 MB per second. Is this all I should expect from a USB 2.0 drive? Is there anything I can do to speed this up? Thanks, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 02:52:23 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58EE1106564A for ; Thu, 23 Jul 2009 02:52:23 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntqsrv02p.mx.bigpond.com (nskntqsrv02p.mx.bigpond.com [61.9.168.234]) by mx1.freebsd.org (Postfix) with ESMTP id D18368FC16 for ; Thu, 23 Jul 2009 02:52:22 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntotgx02p.mx.bigpond.com ([124.188.162.219]) by nskntmtas04p.mx.bigpond.com with ESMTP id <20090723002729.TAXO1821.nskntmtas04p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com> for ; Thu, 23 Jul 2009 00:27:29 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20090723002728.HVCZ4023.nskntotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Thu, 23 Jul 2009 00:27:28 +0000 Received: (qmail 12259 invoked by uid 501); 23 Jul 2009 00:26:51 -0000 Date: Thu, 23 Jul 2009 10:26:51 +1000 From: Andrew Reilly To: Vladimir Grebenschikov , Steve Kargl , freebsd-stable , "O. Hartmann" , Thomas Backman , Olivier SMEDTS , FreeBSD current , Ken Smith Message-ID: <20090723002651.GA11945@duncan.reilly.home> References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <58F0204B-ECE6-479A-AAC2-7868E71ABB43@exscape.org> <367b2c980907200729s57eafbbfw83c8ae5a94f41ffc@mail.gmail.com> <4A6628F0.6080802@mail.zedat.fu-berlin.de> <20090721215201.GA61999@troutmask.apl.washington.edu> <1248277420.8644.70.camel@localhost> <20090722193033.GA83848@zim.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090722193033.GA83848@zim.MIT.EDU> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.4A67AE70.0093,ss=1,fgs=0 Cc: Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 02:52:23 -0000 On Wed, Jul 22, 2009 at 03:30:33PM -0400, David Schultz wrote: > I do the same thing. I wish the ports system kept track of which > ports were installed explicitly by me, and which were only > dependencies. Then it would be possible to garbage collect ports > that are no longer needed. Portmaster -s will cull ports that are "no longer depended on". Seems to work fairly well. You can (probably) find the list of ports that you installed deliberately by trawling through /var/db/pkg for those that don't have a +REQUIRED_BY file. (The portmaster -s trick works by finding ports that have a +REQUIRED_BY file that is empty, I believe.) Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 03:01:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86CCC1065680 for ; Thu, 23 Jul 2009 03:01:01 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id 6F16E8FC19 for ; Thu, 23 Jul 2009 03:01:01 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id B378F33C6C for ; Wed, 22 Jul 2009 19:37:15 -0700 (PDT) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 62A3933C64 for ; Wed, 22 Jul 2009 19:37:15 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19047.52443.164412.363239@already.local> Date: Wed, 22 Jul 2009 19:37:15 -0700 To: freebsd-current@freebsd.org X-Mailer: VM 8.0.12 under 22.3.1 (i386-apple-darwin9.6.0) X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 23 Jul 2009 03:19:48 +0000 Subject: gptzfsboot doesn't like change (failure after swapping drives) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 03:01:01 -0000 I've been playing around with building an 8.0BETA2 system with everything on a single zfs filesystem (I'll get fancier later) on a zpool that is a 4 disk raidz. I'm using GPT partitions and glabels so that I can move the drives around w/out drama. Things work well, but if I swap a pair of drives then try to boot I get the message that other folks have reported: ZFS: i/o error - all block copies unavailable. ZFS: can't read MOS ZFS: unexpected object set type lld ZFS: unexpected object set type lld Then a couple of boot: prompts. If I boot off of the 8.0BETA2 media I can import the pool, even with the drives in different slots. When I put the drives back into their original slots (verified by booting the USB stick and checking with glabel status) I still can't boot off of them, which surprised me a bit. Can anyone suggest something that I might be able to do to get a system in this state to boot? I've tried importing and exporting and importing the pool several times. g. From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 03:33:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38C7A106568C for ; Thu, 23 Jul 2009 03:33:16 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id E4E4B8FC0C for ; Thu, 23 Jul 2009 03:33:15 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so351687qwe.7 for ; Wed, 22 Jul 2009 20:33:15 -0700 (PDT) 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 :content-transfer-encoding; bh=nrwk819ZqYxWFKpV6yic9uiEEPueMiUqaXSG2XQRypQ=; b=NasmoQUPy8ccR02cjJ6PZncB/Vh10xKjuUAV1USUsFo9d7N7LZ+y32/NVnVlc19CVu wf6+C+wMuj3VuaBlL9+0df8Ma2Omhiso+N2aliKP5ASeSYOHrAGKJPpqN7SpujVzHUJI X6Jhok2/0EGm9BFM+KZBB9S10+j2R0hkuMxtQ= 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:content-transfer-encoding; b=kfHSxmhtPKl1fGmrujZ2JpWphULfPAI/vx0JDtUdHLZ7VLnJ8J3m2UduUq08RDrciJ nPygGpWX5bOrJB0XSgYEaoDObP+raSHD8+7IlcZt/bE2yOpodPpgAQhx1Zmt7rkGFnVy GsOCg0wfnNW5IeNZM0ycjsLmsuQcLMS9POC9k= MIME-Version: 1.0 Received: by 10.220.83.146 with SMTP id f18mr1450539vcl.20.1248319994961; Wed, 22 Jul 2009 20:33:14 -0700 (PDT) In-Reply-To: <19047.52443.164412.363239@already.local> References: <19047.52443.164412.363239@already.local> Date: Wed, 22 Jul 2009 22:33:14 -0500 Message-ID: <790a9fff0907222033t6393b725n59a9f7d8a38f32c9@mail.gmail.com> From: Scot Hetzel To: hartzell@alerce.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: gptzfsboot doesn't like change (failure after swapping drives) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 03:33:16 -0000 On Wed, Jul 22, 2009 at 9:37 PM, George Hartzell wrote= : > > I've been playing around with building an 8.0BETA2 system with > everything on a single zfs filesystem (I'll get fancier later) on a > zpool that is a 4 disk raidz. =A0I'm using GPT partitions and glabels so > that I can move the drives around w/out drama. > > Things work well, but if I swap a pair of drives then try to boot I > get the message that other folks have reported: > > =A0ZFS: i/o error - all block copies unavailable. > =A0ZFS: can't read MOS > =A0ZFS: unexpected object set type lld > =A0ZFS: unexpected object set type lld > > Then a couple of boot: prompts. > > If I boot off of the 8.0BETA2 media I can import the pool, even with > the drives in different slots. > > When I put the drives back into their original slots (verified by > booting the USB stick and checking with glabel status) I still can't > boot off of them, which surprised me a bit. > > Can anyone suggest something that I might be able to do to get a > system in this state to boot? =A0I've tried importing and exporting and > importing the pool several times. > I haven't tested this, but try the following: 1. boot the 8.0BETA install/fixit media 2. goto the fixit environment 3. Create /boot/zfs directory 4. load the kernel modules opensolaris.ko and zfs.ko 5. import the pool, and mount the root filesystem on /mnt 6. Copy /boot/zfs/zpool.cache to /mnt/boot/zfs 7. Reboot the system Scot From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 07:31:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A7721065670 for ; Thu, 23 Jul 2009 07:31:30 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 91C2F8FC14 for ; Thu, 23 Jul 2009 07:31:29 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:60362 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MTslv-0005dG-6I; Thu, 23 Jul 2009 09:31:25 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 9CB7F16969C; Thu, 23 Jul 2009 09:31:21 +0200 (CEST) Message-Id: From: Thomas Backman To: McLone In-Reply-To: <451cb3010907181027q13d5c345w8962a648c7682ed8@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 23 Jul 2009 09:31:19 +0200 References: <451cb3010907181027q13d5c345w8962a648c7682ed8@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MTslv-0005dG-6I. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MTslv-0005dG-6I 4ba3011694c4f5e1528303ec2874e19f Cc: FreeBSD current Subject: Re: [bug] ZFS zvol dev entry disappearing upon reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 07:31:30 -0000 On Jul 18, 2009, at 19:27, McLone wrote: > Hell Low. > > As downloading torrent files from many peers to ZFS > imposes fragmentation (and there's no way to defragment > ZFS volume - what a pity! How come now-a-days FS can > go like this?), i created zvol with UFS2 on it last time > i wanted to watch some old sci-fi. I had plans to > move sci-fi from UFS2/zvol to ZFS when it'll be complete, > but forgot it, and rebooted machine. After reboot > rtorrent said sci-fi is marked as complete, but it > can not find files. I wasn't surprised, as i haven't modified > my /etc/fstab, so i entered "mount /dev/zvol" and pressed > Tab in hope of tcsh (eek) autocomplete. > It just beeped on me. > I've done "ls /dev" and there was no directory there named zvol. > Then i've done "zfs list" and my zvol was there. > Puzzled, i've done "zfs snapshot" and then a little dance of > "zfs send | zfs recv" to a new volume. Now dev entries appeared > (both for newly created snapshot of an old zvol and for new zvol). > I rebooted, and there was no /dev/zvol again. > > I looked at my uname -v output (it was HEAD/amd64 from Jul 1) > and decided to update. Updating didn't solved this problem. > > Strangely, simple "zfs rename zpool/zvol zpool/newzvol" > cures this woe, but i think this is a bug. > > Steps to reproduce: > zfs create -V 1g zpool/zvol > [newfs /dev/zvol/zpool/zvol] > reboot > ls /dev > > Workaround: > zfs rename zpool/zvol zpool/newzvol > mount /dev/zvol/zpool/zvol /mnt OK, I've found the problem we have here... Or, rather, I've found the *reason* (and this shows why I previously said I couldn't reproduce). I haven't found it in source, though. UFS filesystems in fstab are mounted *before* the /dev/zvol directory is populated, at least on my system! If I remove the entry from fstab, everything boots fine, and the directory exists when the boot is complete. If its IN fstab, init gives me a root prompt because it couldn't find /dev/zvol/x/y. Remove it, and again it works on the next boot. And, as you said, renaming it while in single user creates /dev/zvol and thus resolves the issue for that boot and allows me to boot into multiuser with the ZVOL working. Anyone with a clue in these areas know if there's an easy fix to this (i.e. easy enough that we could have it in 8.0)? I'm guessing /etc/ rc.d/zfs simply starts too late in the boot process? Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 08:04:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71B00106566C for ; Thu, 23 Jul 2009 08:04:50 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 093748FC0C for ; Thu, 23 Jul 2009 08:04:49 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=UB_yN8qgYpcA:10 a=gg2W7PyvkLb8p4ie143lBA==:17 a=xXnuTjoHLCyQ-YV6x5kA:9 a=hAbdpAEGA_MrFVXn9w9PmRtqZsoA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1112282405; Thu, 23 Jul 2009 10:04:48 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 23 Jul 2009 10:04:36 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <4A67CD2B.9040200@mykitchentable.net> In-Reply-To: <4A67CD2B.9040200@mykitchentable.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907231004.37704.hselasky@c2i.net> Cc: Drew Tomlinson Subject: Re: USB 2.0 External Drive - What Is A Reasonable Transfer Rate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 08:04:50 -0000 On Thursday 23 July 2009 04:38:35 Drew Tomlinson wrote: > I have a USB 2.0 external drive that's formatted as NTFS under Windows > XP. I've plugged it into my 8.0 BETA2 install and am copying files to a > local raid1z zpool with one vdev consisting of 4 drives. I'm trying to > move about 100 GB of assorted files and have been at it all day. The > USB drive contains assorted files such as mp3, CD/DVD images, zip, > documents, etc. I'm guessing most files range between 1 - 4 MB with > some as large as 4 GB. > > Anyway, iostat shows the transfer rate at around 2 - 3 MB per second. > Is this all I should expect from a USB 2.0 drive? Is there anything I > can do to speed this up? Hi, Benchmark your device like this: dd if=/dev/daX of=/dev/null bs=65536 It will give you the correct transferrate number. Maybe there are some utilities in /usr/ports that can read NTFS faster than the kernel NTFS driver. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 08:12:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDC50106567B for ; Thu, 23 Jul 2009 08:12:09 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 5CD168FC12 for ; Thu, 23 Jul 2009 08:12:09 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:41233 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MTtPI-0007u4-5o; Thu, 23 Jul 2009 10:12:06 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 70D7316969D; Thu, 23 Jul 2009 10:12:05 +0200 (CEST) Message-Id: From: Thomas Backman To: McLone 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 v935.3) Date: Thu, 23 Jul 2009 10:12:03 +0200 References: <451cb3010907181027q13d5c345w8962a648c7682ed8@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MTtPI-0007u4-5o. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MTtPI-0007u4-5o 48dd18b6a233840a3f9b0aee6d8ae9d5 Cc: FreeBSD current Subject: Re: [bug] ZFS zvol dev entry disappearing upon reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 08:12:10 -0000 On Jul 23, 2009, at 09:31, Thomas Backman wrote: > On Jul 18, 2009, at 19:27, McLone wrote: > >> Hell Low. >> >> As downloading torrent files from many peers to ZFS >> imposes fragmentation (and there's no way to defragment >> ZFS volume - what a pity! How come now-a-days FS can >> go like this?), i created zvol with UFS2 on it last time >> i wanted to watch some old sci-fi. I had plans to >> move sci-fi from UFS2/zvol to ZFS when it'll be complete, >> but forgot it, and rebooted machine. After reboot >> rtorrent said sci-fi is marked as complete, but it >> can not find files. I wasn't surprised, as i haven't modified >> my /etc/fstab, so i entered "mount /dev/zvol" and pressed >> Tab in hope of tcsh (eek) autocomplete. >> It just beeped on me. >> I've done "ls /dev" and there was no directory there named zvol. >> Then i've done "zfs list" and my zvol was there. >> Puzzled, i've done "zfs snapshot" and then a little dance of >> "zfs send | zfs recv" to a new volume. Now dev entries appeared >> (both for newly created snapshot of an old zvol and for new zvol). >> I rebooted, and there was no /dev/zvol again. >> >> I looked at my uname -v output (it was HEAD/amd64 from Jul 1) >> and decided to update. Updating didn't solved this problem. >> >> Strangely, simple "zfs rename zpool/zvol zpool/newzvol" >> cures this woe, but i think this is a bug. >> >> Steps to reproduce: >> zfs create -V 1g zpool/zvol >> [newfs /dev/zvol/zpool/zvol] >> reboot >> ls /dev >> >> Workaround: >> zfs rename zpool/zvol zpool/newzvol >> mount /dev/zvol/zpool/zvol /mnt > OK, I've found the problem we have here... Or, rather, I've found > the *reason* (and this shows why I previously said I couldn't > reproduce). I haven't found it in source, though. > > UFS filesystems in fstab are mounted *before* the /dev/zvol > directory is populated, at least on my system! > If I remove the entry from fstab, everything boots fine, and the > directory exists when the boot is complete. If its IN fstab, init > gives me a root prompt because it couldn't find /dev/zvol/x/y. > Remove it, and again it works on the next boot. > And, as you said, renaming it while in single user creates /dev/zvol > and thus resolves the issue for that boot and allows me to boot into > multiuser with the ZVOL working. > > Anyone with a clue in these areas know if there's an easy fix to > this (i.e. easy enough that we could have it in 8.0)? I'm guessing / > etc/rc.d/zfs simply starts too late in the boot process? > > Regards, > Thomas So, my solution: Edit /etc/rc.d/zfs, and replace "#REQUIRE: mountcritlocal" with "#BEFORE: mountcritlocal". / is mounted before any of these runs anyway, right? And / contains / sbin/zfs and everything it needs: # ldd /sbin/zfs /sbin/zfs: libzfs.so.2 => /lib/libzfs.so.2 (0x800656000) libgeom.so.5 => /lib/libgeom.so.5 (0x80078a000) libbsdxml.so.4 => /lib/libbsdxml.so.4 (0x80088f000) libsbuf.so.5 => /lib/libsbuf.so.5 (0x8009b2000) libm.so.5 => /lib/libm.so.5 (0x800ab4000) libnvpair.so.2 => /lib/libnvpair.so.2 (0x800bd3000) libuutil.so.2 => /lib/libuutil.so.2 (0x800cdc000) libutil.so.8 => /lib/libutil.so.8 (0x800de5000) libc.so.7 => /lib/libc.so.7 (0x800ef5000) Works for me(tm) (with MBR, ZFS root and UFS /boot), the ZVOL mounts just fine and I get no errors during boot. Another way would probably (haven't tested) to run "zfs volinit" in mountcritlocal, but then I suppose there'd have to be a check for zfs_enable="YES" in there too. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 08:22:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 092B3106564A; Thu, 23 Jul 2009 08:22:41 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id B7A998FC1B; Thu, 23 Jul 2009 08:22:40 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:47556 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MTtZD-0002fx-63; Thu, 23 Jul 2009 10:22:21 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 838401696A2; Thu, 23 Jul 2009 10:22:15 +0200 (CEST) Message-Id: From: Thomas Backman To: bug-followup@FreeBSD.org, freebsd@r.zeeb.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 23 Jul 2009 10:22:13 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MTtZD-0002fx-63. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MTtZD-0002fx-63 a27d59751262fe8beaa58b7e258a33e4 Cc: freebsd-fs@freebsd.org, FreeBSD current Subject: Re: kern/132337: [zfs] [panic] kernel panic in zfs_fuid_create_cred X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 08:22:41 -0000 Hey all, Unfortunately, this PR appears to still be unfixed. Is anyone looking at this? I tried to set up a diskless client over NFS yesterday, running ZFS on /, and ran in to this panic (exact same backtrace as the PR (see bottom the this mail)) a lot of times. In the end, I created a ZVOL with UFS on it, and the panics disappeared as expected - since it no longer has to work directly with files on a ZFS *filesystem*. It seems to be pretty easy to trigger, as I couldn't finish the boot process on the diskless client more than once until I went with UFS. Since then I've gotten 0 panics. FWIW, my /etc/exports (I know now R/W NFS root isn't a good idea, but it might be relevant): /diskless -maproot=0 -alldirs 192.168.1.6 Regards, Thomas Backtrace: panic: zfs_fuid_create_cred cpuid = x KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a panic() at panic+0x182 zfs_fuid_create_cred() at zfs_fuid_create_cred+0x56 zfs_perm_init() at zfs_perm_init+0x84 zfs_mknode() at zfs_mknode+0x24e zfs_freebsd_create() at zfs_freebsd_create+0x617 VOP_CREATE_APV() at VOP_CREATE_APV+0xb3 nfsrv_create() at nfsrv_create+0x909 nfssvc_program() at nfssvc_program+0x1a1 svc_run_internal() at svc_run_internal+0x62b svc_thread_start() at svc_thread_start+0xb fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 09:01:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0261E106566B for ; Thu, 23 Jul 2009 09:01:01 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id 919008FC21 for ; Thu, 23 Jul 2009 09:01:00 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.10] (helo=0.mx.freenet.de) by mout1.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MTuAc-0001FV-SK; Thu, 23 Jul 2009 11:00:58 +0200 Received: from tbad0.t.pppool.de ([89.55.186.208]:61404 helo=ernst.jennejohn.org) by 0.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #93) id 1MTuAc-0007pX-H3; Thu, 23 Jul 2009 11:00:58 +0200 Date: Thu, 23 Jul 2009 11:00:57 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20090723110057.00f4cbcd@ernst.jennejohn.org> In-Reply-To: <200907231004.37704.hselasky@c2i.net> References: <4A67CD2B.9040200@mykitchentable.net> <200907231004.37704.hselasky@c2i.net> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-purgate-ID: 149285::1248339658-00006070-371E4C55/0-0/0-0 Cc: Drew Tomlinson Subject: Re: USB 2.0 External Drive - What Is A Reasonable Transfer Rate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 09:01:01 -0000 On Thu, 23 Jul 2009 10:04:36 +0200 Hans Petter Selasky wrote: > On Thursday 23 July 2009 04:38:35 Drew Tomlinson wrote: > > I have a USB 2.0 external drive that's formatted as NTFS under Windows > > XP. I've plugged it into my 8.0 BETA2 install and am copying files to a > > local raid1z zpool with one vdev consisting of 4 drives. I'm trying to > > move about 100 GB of assorted files and have been at it all day. The > > USB drive contains assorted files such as mp3, CD/DVD images, zip, > > documents, etc. I'm guessing most files range between 1 - 4 MB with > > some as large as 4 GB. > > > > Anyway, iostat shows the transfer rate at around 2 - 3 MB per second. > > Is this all I should expect from a USB 2.0 drive? Is there anything I > > can do to speed this up? > > Hi, > > Benchmark your device like this: > > dd if=/dev/daX of=/dev/null bs=65536 > > It will give you the correct transferrate number. > > Maybe there are some utilities in /usr/ports that can read NTFS faster than > the kernel NTFS driver. > You could try /usr/ports/sysutils/fusefs-ntfs. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 09:13:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96A081065676 for ; Thu, 23 Jul 2009 09:13:04 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id 1D89F8FC17 for ; Thu, 23 Jul 2009 09:13:03 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by bwz19 with SMTP id 19so657564bwz.43 for ; Thu, 23 Jul 2009 02:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; bh=IXGNsMovyYe2eE/hfeJZqaBusbWPLqRTPJpjo6D8X2I=; b=T0mSk7LFgtFd27yTjOh7EFDVKohQmlZdu4c1B//GXhSc5A91MuR7r64rLa0d1/FBtv ldkDNz49LJLNdQs+GFYN/Lio43CNDjKEw7yzVnM7pAGDt1NA/i4Qi+g103r0igZpMg8b 0WjxT9qtfDS+a/0LR9Y/uaZUBUy6ubbA8CKm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=PUJkB1td09tjV7lMi9jrY0eUUmiHfWCxnixeGn8zLBv5bdzhRG0qcaqilJpCRJRlDQ JuEfmkvqxTx7cg6mjB1NUeuANnwrvpI+gR3u/8ip+iLxSVrEEKzHZEB4bdmOVXzlWwcr F8tM48jAPvCoZc+EbQhICx0wbrVXrNUCxeeoY= Received: by 10.204.98.141 with SMTP id q13mr1828553bkn.188.1248340001929; Thu, 23 Jul 2009 02:06:41 -0700 (PDT) Received: from gizmo.nevosoft.local ([195.182.128.54]) by mx.google.com with ESMTPS id 31sm2301418fkt.13.2009.07.23.02.06.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Jul 2009 02:06:41 -0700 (PDT) From: subbsd To: freebsd-current@freebsd.org Date: Thu, 23 Jul 2009 13:02:33 +0400 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907231302.34000.subbsd@gmail.com> Subject: library compat for FreeBSD7x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 09:13:05 -0000 Hello, after the bump version on FreeBSD8-Beta2, some application needs for old library. But misc/compat7x ports not found for this. It still not ready? thanks! From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 09:24:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91317106564A; Thu, 23 Jul 2009 09:24:42 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.freebsd.org (Postfix) with ESMTP id 50DE58FC15; Thu, 23 Jul 2009 09:24:42 +0000 (UTC) (envelope-from jh@saunalahti.fi) Received: from a91-153-125-115.elisa-laajakaista.fi (a91-153-125-115.elisa-laajakaista.fi [91.153.125.115]) by gw01.mail.saunalahti.fi (Postfix) with SMTP id 9D86F15153C; Thu, 23 Jul 2009 12:24:36 +0300 (EEST) Date: Thu, 23 Jul 2009 12:24:36 +0300 From: Jaakko Heinonen To: Thomas Backman Message-ID: <20090723092435.GA799@a91-153-125-115.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD current , bug-followup@FreeBSD.org, freebsd@r.zeeb.org Subject: Re: kern/132337: [zfs] [panic] kernel panic in zfs_fuid_create_cred X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 09:24:42 -0000 Hi, On 2009-07-23, Thomas Backman wrote: > Unfortunately, this PR appears to still be unfixed. Is anyone looking > at this? > panic: zfs_fuid_create_cred This PR is a duplicate of kern/133020. There is a workaround fix in pjd's perforce branch but apparently it was never committed to svn. See: http://p4db.freebsd.org/changeView.cgi?CH=159874 http://people.freebsd.org/~pjd/patches/zfs_znode.h.patch -- Jaakko From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 09:25:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54BF41065679 for ; Thu, 23 Jul 2009 09:25:41 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by mx1.freebsd.org (Postfix) with ESMTP id CCDD48FC1D for ; Thu, 23 Jul 2009 09:25:40 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: by bwz19 with SMTP id 19so663820bwz.43 for ; Thu, 23 Jul 2009 02:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:mime-version:content-type:content-transfer-encoding :content-disposition:message-id; bh=ItNPy+/YnjqQMMG0TQtQJXqf5s4xYzc31Oak/wle0rk=; b=Ck4avww7MBoz4OapdSbQrizuhP9DF3WJ+rfL/n07xNBTkslpULy/QWgDUmlnc6gNaI fA+WCeQqSszd24WCOvbd5OQOlHO2XLE5O3fpi4l3gyvNsvb/kcxkaEG2vl/+axi+ayLC L4e++Qv1AWV4r7fYGBY0eBsoNcMOIuQUAIv9Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; b=netIvDz6hYKrAhgNdotWDPr1wLB9pvzeOksGUQSKdl2qawyM80XwvoCNzHdcq9BXag +qsjwbKGYxaSs5hk3YnMpdQ1EbPWBJg5T5YFWq3fGD8JnPU8lwkyZW47s8IHIGdT2iqX OS/EzDdvuPv7spYvsencREaZzYfDKUsXAa6hs= Received: by 10.204.51.200 with SMTP id e8mr1804429bkg.175.1248339757335; Thu, 23 Jul 2009 02:02:37 -0700 (PDT) Received: from gizmo.nevosoft.local ([195.182.128.54]) by mx.google.com with ESMTPS id y15sm2325947fkd.17.2009.07.23.02.02.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Jul 2009 02:02:36 -0700 (PDT) From: subbsd To: freebsd-current@freebsd.org Date: Thu, 23 Jul 2009 12:58:29 +0400 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907231258.29702.subbsd@gmail.com> Subject: ports: java/jdk16 broken for FreeBSD 8 BETA2? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 09:25:41 -0000 Hello Ive try to builds java/jdk16. diablo-jdk-1.6.0.07.02_5 Has been successfull builds (as i know this is bootstrap for jdk16 install?) After make -C /usr/ports/java/jdk16 install i get messages: -- /usr/local/diablo-jdk1.6.0/bin/javap javax.xml.transform.TransformerFactory > /dev/null 2>&1; \ if [ $? -ne 0 ]; then \ /usr/local/diablo-jdk1.6.0/bin/java -version; \ echo "*** An XSLT processor (J2SE 1.4.x or newer) is required" \ "to bootstrap this build" 1>&2; \ exit 1; \ fi Error occurred during initialization of VM Unable to load ZIP library: /usr/local/diablo-jdk1.6.0/jre/lib/amd64/libzip.so *** An XSLT processor (J2SE 1.4.x or newer) is required to bootstrap this build gmake[4]: *** [check_j2se_version] Error 1 gmake[4]: Leaving directory `/usr/ports/java/jdk16/work/control/build/bsd- amd64/hotspot/outputdir' gmake[3]: *** [bsd_amd64_compiler2/debug] Error 2 gmake[3]: Leaving directory `/usr/ports/java/jdk16/work/control/build/bsd- amd64/hotspot/outputdir' gmake[2]: *** [generic_build2] Error 2 gmake[2]: Leaving directory `/usr/ports/java/jdk16/work/hotspot/make' gmake[1]: *** [product] Error 2 gmake[1]: Leaving directory `/usr/ports/java/jdk16/work/hotspot/make' gmake: *** [hotspot-build] Error 2 *** Error code 2 File libzip.so is ok : file /usr/local/diablo-jdk1.6.0/jre/lib/amd64/libzip.so /usr/local/diablo-jdk1.6.0/jre/lib/amd64/libzip.so: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically linked, not stripped This ports normal builds before -- 20090719: Bump the shared library version numbers for all libraries that do not use symbol versioning as part of the 8.0-RELEASE cycle. Bump __FreeBSD_version to 800105. -- From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 09:32:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15428106564A for ; Thu, 23 Jul 2009 09:32:20 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id C1A528FC16 for ; Thu, 23 Jul 2009 09:32:19 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 98B3D130C54; Thu, 23 Jul 2009 11:32:17 +0200 (CEST) Date: Thu, 23 Jul 2009 11:32:17 +0200 From: Guido Falsi To: subbsd Message-ID: <20090723093217.GA26926@megatron.madpilot.net> References: <200907231302.34000.subbsd@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907231302.34000.subbsd@gmail.com> X-Operating-System: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: library compat for FreeBSD7x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 09:32:20 -0000 On Thu, Jul 23, 2009 at 01:02:33PM +0400, subbsd wrote: > Hello, > > after the bump version on FreeBSD8-Beta2, some application needs for old > library. But misc/compat7x ports not found for this. It still not ready? > thanks! You'll have to rempile all ports anyway. For the few ports which still require an old library(diablo-jdk, for one) you can use libmap.conf: # Temporary libmap.cnf to solve problems caused by the 8.0 lib version bump. # diablo still looks for libz.so.4 libz.so.4 libz.so.5 I made this to solve the problem i found with the diablo jdk binaries. (not restricted because sometimes I call java binaries without path...Should not interefere with other programs) -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 09:38:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F1B9106566C for ; Thu, 23 Jul 2009 09:38:39 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 979838FC12 for ; Thu, 23 Jul 2009 09:38:38 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n6N9cU2K081443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 Jul 2009 11:38:32 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <1E3C4A20-1B89-4C8C-912E-3CA99A427452@lassitu.de> From: Stefan Bethke To: hartzell@alerce.com In-Reply-To: <19047.52443.164412.363239@already.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 23 Jul 2009 11:38:30 +0200 References: <19047.52443.164412.363239@already.local> X-Mailer: Apple Mail (2.935.3) Cc: freebsd-current@freebsd.org Subject: Re: gptzfsboot doesn't like change (failure after swapping drives) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 09:38:39 -0000 Am 23.07.2009 um 04:37 schrieb George Hartzell: > I've been playing around with building an 8.0BETA2 system with > everything on a single zfs filesystem (I'll get fancier later) on a > zpool that is a 4 disk raidz. Quite a few people had no luck with booting from RAIDZ volumes at all. (Single disks and mirrors seem to work fine.) See this thread: http://lists.freebsd.org/pipermail/freebsd-fs/2009-July/006466.html Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 10:01:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDF41106566B; Thu, 23 Jul 2009 10:01:16 +0000 (UTC) (envelope-from hlh@restart.be) Received: from tignes.restart.be (tignes.restart.be [IPv6:2001:41d0:2:2d29:0:1::]) by mx1.freebsd.org (Postfix) with ESMTP id 74D2E8FC13; Thu, 23 Jul 2009 10:01:16 +0000 (UTC) (envelope-from hlh@restart.be) Received: from restart.be (avoriaz.tunnel.bel [IPv6:2001:41d0:2:2d29:1:ffff::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "avoriaz.restart.be", Issuer "CA master" (verified OK)) by tignes.restart.be (Postfix) with ESMTPS id A12E965A6; Thu, 23 Jul 2009 12:01:15 +0200 (CEST) Received: from morzine.restart.bel (morzine.restart.be [IPv6:2001:41d0:2:2d29:1:2::]) (authenticated bits=0) by restart.be (8.14.3/8.14.3) with ESMTP id n6NA1BgY031894; Thu, 23 Jul 2009 12:01:12 +0200 (CEST) (envelope-from hlh@restart.be) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=restart.be; s=avoriaz; t=1248343275; bh=Gg/FZaDVotr6VdFb+7Y22mkZx8XtuyNR5dTHyHRSmU4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=P/1G/u97WmGC71km9borv1mZ7WDySws9m3vm6NwYKXhev3RpDId/FBg1NyaaSSPun 4kHrjF/lpz98Ay1DObAuA== DomainKey-Signature: a=rsa-sha1; s=avoriaz; d=restart.be; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-scanned-by; b=oZ/oIs2aXaMOQMW2VwYYak9hanjVAie+quJSmXOMis802/cBV2rJ4rWwLy3Mejzbd 9XvYnHHvMlJg7tjjXXCDQ== Message-ID: <4A6834E7.60704@restart.be> Date: Thu, 23 Jul 2009 12:01:11 +0200 From: Henri Hennebert Organization: RestartSoft User-Agent: Thunderbird 2.0.0.22 (X11/20090717) MIME-Version: 1.0 To: "Li, Qing" References: <4A5734C3.3000806@restart.be> <4A5864DC.1070106@restart.be> <4A6469CE.4060907@restart.be> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on IPv6:2001:41d0:2:2d29:1:1:: Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: [SOLVED] 8.0-BETA1 - for the record - different paths followed by IPv4 and IPv6 for 'local' connections X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 10:01:17 -0000 Li, Qing wrote: >> Just another case where the route must be created: >> > > That's probably because I explicitly disabled such > route installation for PPP link type. > > Please apply patch http://people.freebsd.org/~qingli/patch and > let me know if that solves your problem. The problem is solved. Thanks a lot. Henri PS. the ipv4 ping was working fine before (and after) your patch, so I don't see why you have to patch in.c > > Thanks, > > -- Qing > > > >> [root@avoriaz ~]# ifconfig gif0 >> gif0: flags=8051 metric 0 mtu 1280 >> tunnel inet 212.239.166.57 --> 94.23.44.41 >> inet6 fe80::21d:60ff:fead:2ace%gif0 prefixlen 64 scopeid 0x4 >> inet6 2001:41d0:2:2d29:1:ffff:: --> 2001:41d0:2:2d29:0:ffff:: >> prefixlen >> 128 >> options=1 >> >> [root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff:: >> PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: --> >> 2001:41d0:2:2d29:1:ffff:: >> ^C >> --- 2001:41d0:2:2d29:1:ffff:: ping6 statistics --- >> 4 packets transmitted, 0 packets received, 100.0% packet loss >> >> [root@avoriaz ~]# route add -inet6 2001:41d0:2:2d29:1:ffff:: > -interface >> lo0 >> add host 2001:41d0:2:2d29:1:ffff::: gateway lo0 >> >> [root@avoriaz ~]# ping6 2001:41d0:2:2d29:1:ffff:: >> PING6(56=40+8+8 bytes) 2001:41d0:2:2d29:1:ffff:: --> >> 2001:41d0:2:2d29:1:ffff:: >> 16 bytes from ::1, icmp_seq=0 hlim=64 time=0.531 ms >> 16 bytes from ::1, icmp_seq=1 hlim=64 time=0.884 ms >> 16 bytes from ::1, icmp_seq=2 hlim=64 time=0.748 ms >> ^C >> --- 2001:41d0:2:2d29:1:ffff:: ping6 statistics --- >> 3 packets transmitted, 3 packets received, 0.0% packet loss >> round-trip min/avg/max/std-dev = 0.531/0.721/0.884/0.145 ms >> >> Thanks >> >> Henri >>> -----Original Message----- >>> From: Henri Hennebert [mailto:hlh@restart.be] >>> Sent: Sat 7/11/2009 3:09 AM >>> To: Li, Qing >>> Cc: freebsd-stable@freebsd.org; freebsd-net@freebsd.org >>> Subject: Re: 8.0-BETA1 - for the record - different paths followed > by >> IPv4 and IPv6 for 'local' connections >>> Li, Qing wrote: >>>> Hi, >>>> >>>> Please try patch-7-10 in my home directory >> http://people.freebsd.org/~qingli/ >>>> and let me know how it works out for you. I thought I had committed >> the patch >>>> but turned out I didn't. >>> I apply the patch, reset my pf.conf to its previous content and all >> is >>> running smoothly. By the way, I discover after my post that my >>> "solution" was not working for long (many bytes) connections and > this >> is >>> solved too. >>> >>> Many thank for your time >>> >>> Henri >>> >>> PS please commit as soon as possible >>> >>>>> On 8.0-BETA1 there is an assymetry: >>>>> >>>>> netstat -rn display >>>>> >>>>> 192.168.24.1 link#3 >>>>> .... >>>>> no entry for 2001:41d0:2:2d29:1:1:: >>>>> >>>> This is by design as part of the new architecture in 8.0, which >> maintains >>>> the L2 ARP/ND6 and L3 routing tables separately. >>>> >>>> -- Qing >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: owner-freebsd-stable@freebsd.org on behalf of Henri Hennebert >>>> Sent: Fri 7/10/2009 5:32 AM >>>> To: freebsd-stable@freebsd.org; freebsd-st@freebsd.org >>>> Subject: 8.0-BETA1 - for the record - different paths followed by >> IPv4 and IPv6 for 'local' connections >>>> Hello, >>>> >>>> After upgrading from 7.2-STABLE to 8.0-BETA1 I encounter a problem >> when >>>> connecting with firefox to a local apache server using the global >>>> unicast IPv6 address of the local machine. pf.conf must be updated! >>>> >>>> My configuration: >>>> >>>> [root@avoriaz ~]# ifconfig em0 >>>> >>>> em0: flags=8843 metric 0 > mtu >> 1500 > options=19b> 4> >>>> ether 00:1d:60:ad:2a:ce >>>> inet 192.168.24.1 netmask 0xffffff00 broadcast 192.168.24.255 >>>> inet6 fe80::21d:60ff:fead:2ace%em0 prefixlen 64 scopeid 0x1 >>>> inet6 2001:41d0:2:2d29:1:1:: prefixlen 80 >>>> media: Ethernet 100baseTX (100baseTX ) >>>> status: active >>>> >>>> [root@avoriaz ~]# host www.restart.bel >>>> www.restart.bel is an alias for avoriaz.restart.bel. >>>> avoriaz.restart.bel has address 192.168.24.1 >>>> avoriaz.restart.bel has IPv6 address 2001:41d0:2:2d29:1:1:: >>>> >>>> pf.conf: >>>> >>>> int_if="em0" >>>> block in log all >>>> block out log all >>>> set skip on lo0 >>>> antispoof quick for $int_if inet >>>> # Allow trafic with physical internal network >>>> pass in quick on $int_if from ($int_if:network) to ($int_if) keep >> state >>>> pass out quick on $int_if from ($int_if) to ($int_if:network) keep >> state >>>> The problem: >>>> >>>> [root@avoriaz ~]# telnet -4 www.restart.bel 80 >>>> Trying 192.168.24.1... >>>> Connected to avoriaz.restart.bel. >>>> Escape character is '^]'. >>>> ^] >>>> telnet> quit >>>> Connection closed. >>>> [root@avoriaz ~]# telnet -6 www.restart.bel 80 >>>> Trying 2001:41d0:2:2d29:1:1::... >>>> --->Never connect and get a timeout! >>>> >>>> tcpdump and logging in pf show me that >>>> >>>> For a IPv4 connection: >>>> the packet from telnet to apache pass 2 times on lo0 (out and in) >>>> the answer packet from apache to telnet pass 2 times on lo0 (out > and >> in) >>>> So no problem, there is `set skip on lo0' >>>> >>>> For a IPv6 connection: >>>> The first packet from telnet to apache pass 2 times on lo0 (out and >> in) >>>> The answer packet from apache to telnet path on em0 and is > rejected >>>> due to the default flags S/SA. >>>> >>>> So I have to change pf.conf and replace the last line: >>>> pass out quick on $int_if from ($int_if) to ($int_if:network) \ >>>> keep state flags any >>>> >>>> Then all is OK >>>> >>>> By the way, on 7.2 >>>> >>>> netstat -rn display >>>> >>>> 192.168.24.1 00:1d:60:ad:2a:ce >>>> .... >>>> 2001:41d0:2:2d29:1:1:: 00:1d:60:ad:2a:ce >>>> >>>> >>>> On 8.0-BETA1 there is an assymetry: >>>> >>>> netstat -rn display >>>> >>>> 192.168.24.1 link#3 >>>> .... >>>> no entry for 2001:41d0:2:2d29:1:1:: >>>> >>>> Hope it may help someone >>>> >>>> Henri >>>> >>>> _______________________________________________ >>>> freebsd-stable@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>>> To unsubscribe, send any mail to "freebsd-stable- >> unsubscribe@freebsd.org" >>> >>> _______________________________________________ >>> freebsd-stable@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>> To unsubscribe, send any mail to "freebsd-stable- >> unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 10:05:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F7C61065673 for ; Thu, 23 Jul 2009 10:05:54 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id B496C8FC19 for ; Thu, 23 Jul 2009 10:05:53 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id n6NA5n5k023552; Thu, 23 Jul 2009 12:05:49 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id n6NA5ntg023551; Thu, 23 Jul 2009 12:05:49 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Thu, 23 Jul 2009 12:05:48 +0200 From: Ruben de Groot To: Guido Falsi Message-ID: <20090723100548.GA23481@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Guido Falsi , subbsd , freebsd-current@freebsd.org References: <200907231302.34000.subbsd@gmail.com> <20090723093217.GA26926@megatron.madpilot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090723093217.GA26926@megatron.madpilot.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, J_CHICKENPOX_71 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Thu, 23 Jul 2009 12:05:52 +0200 (CEST) Cc: freebsd-current@freebsd.org, subbsd Subject: Re: library compat for FreeBSD7x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 10:05:54 -0000 On Thu, Jul 23, 2009 at 11:32:17AM +0200, Guido Falsi typed: > On Thu, Jul 23, 2009 at 01:02:33PM +0400, subbsd wrote: > > Hello, > > > > after the bump version on FreeBSD8-Beta2, some application needs for old > > library. But misc/compat7x ports not found for this. It still not ready? > > thanks! > > You'll have to rempile all ports anyway. Erm, doesn't that defeat the whole point of having compat* libraries? Ruben From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 10:29:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6BF70106568E for ; Thu, 23 Jul 2009 10:29:31 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id F198B8FC1A for ; Thu, 23 Jul 2009 10:29:30 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.43,253,1246831200"; d="txt'?scan'208";a="278074269" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay1.uni-muenster.de with ESMTP; 23 Jul 2009 12:29:29 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 4351B1B07E4; Thu, 23 Jul 2009 12:29:29 +0200 (CEST) Date: Thu, 23 Jul 2009 12:29:23 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-20090723102923f7e55a9d000042a4-a_best01+ Cc: Subject: possible bug in sbin/fsck_msdosfs/boot.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 10:29:31 -0000 This is a MIME encoded multipart message. --+permail-20090723102923f7e55a9d000042a4-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit i just tried to do fsck_msdosfs on my mobile phone's memory card using a usb connection cable. this is what `file -s` has to say about /dev/da0: /dev/da0: x86 boot sector, code offset 0x0, OEM-ID " ", sectors/cluster 64, reserved sectors 6304, Media descriptor 0xf8, heads 128, hidden sectors 8192, sectors 7736320 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 944, reserved3 0x800000, serial number 0x34613466, label: "mem " however after issuing the command `fsck_msdosfs /dev/da0` i got the following error: fsck_msdosfs /dev/da0 ** /dev/da0 backup doesn't compare to primary bootblock i did a bit of research and it seems this bug was supposed to be fixed by r128463. the problem was that the entire bootblock was compared to the backupblock. but since only the first 52 bytes of the bootblock are important many device use the rest of the bootblock for some other purpose. the following change was made to sbin/fsck_msdosfs/boot.c: -- if (memcmp(block, backup, DOSBOOTBLOCKSIZE)) { ++ if (memcmp(block + 11, backup + 11, 79)) { it seems however that the last memcmp argument is still too high. could somebody with good fat12/16/32 knowledge please look into this? i attached the original openbsd problem report which described the problem in detail in 2006 (actually the problem was first discovered in 2001 but nobody seemed to care about it back then). cheers. alex oh...and i'm running r195774 (8.0-BETA2). --+permail-20090723102923f7e55a9d000042a4-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="pr.txt" PlN1Ym1pdHRlci1JZDoga291c3UKPk9yaWdpbmF0b3I6IE5pY2sgR3VlbnRoZXIKPk9yZ2FuaXph dGlvbjoKPlN5bm9wc2lzOiBmc2NrX21zZG9zIGRldGVjdHMgYSBiYWQgcGFydGl0aW9uIHdoZW4g aXQncyBhY3R1YWxseSBva2F5Cj5TZXZlcml0eTogbm9uLWNyaXRpY2FsCj5Qcmlvcml0eTogbWVk aXVtCj5DYXRlcmdvcnk6IHN5c3RlbQo+Q2xhc3M6IHN3LWJ1Zwo+UmVsZWFzZTogMy44LVJlbGVh c2UKPkVudmlyb25tZW50OgoJU3lzdGVtCTogT3BlbkJTRCAzLjgKCUFyY2hpdGVjdHVyZQk6IE9w ZW5CU0QuaTM4NgoJTWFjaGluZToJOiBpMzg2Cj5EZXNjcmlwdGlvbjoKCVJ1bm5nIGZzY2tfbXNk b3Mgb24gRkFUMzIgcGFydGl0aW9ucyB0aGF0IGhhdmUgYmVlbiBjb3JydXB0ZWQgaW4gYQpjZXJ0 YWluIHdheSBjYXVzZXMgImJhY2t1cCBkb2Vzbid0IGNvbXBhcmUgdG8gcHJpbWFyeSBib290Ymxv Y2siIGV2ZW4Kd2hlbiB0aGUgY29ycmVzcG9uZGluZyBtaWNyb3NvZnQgdG9vbHMgc2F5IHRoZSBk aXNrIGlzIGNsZWFuLiBUaGlzIGlzCmJlY2F1c2UgaXQgY29tcGFyZXMgdG9vIG11Y2ggb2YgdGhl IHByaW1hcnkgYW5kIGJhY2t1cCBib290YmxvY2tzIG9uIGEKRkFUMzIgcGFydGl0aW9uLiBJdCBz aG91bGQgb25seSBjb21wYXJlIHRoZSBmaXJzdCA1MiBieXRlcyBidXQgaXQKY29tcGFyZXMgdGhl IGVudGlyZXR5IG9mIHRoZSBET1MgYm9vdCBibG9jay4KPkhvdy1Uby1SZXBlYXQ6CglGb3JtYXQg YSBuZXcgRkFUMzIgcGFydGl0aW9uIChpZGVhbGx5IHVzaW5nIG1pY3Jvc29mdCB0b29scykuIElm IHlvdQpydW4gZnNja19tc2RvcyBvbiB0aGlzIGl0IGlzIGZpbmUgYmVjYXVzZSB0aGUgcHJpbWFy eSBhbmQgYmFja3VwCmJvb3RibG9ja3Mgd2VyZSBib3RoIGluaXRpYWxpemVkIHRoZSBzYW1lIHdh eSAocHJlc3VtYWJsZSB0byBudWxscykuCkhvd2V2ZXIsIGlmIHlvdSBjb3JydXB0IG9uZSBvZiB0 aGVtIChwdWxsaW5nIHRoZSBwb3dlciB3aGlsZSBpdCdzCnJ1bm5pbmcgd2lsbCBkbyB0aGlzKSBh bmQgdGhlbiB0cnkgZnNja19tc2RvcyB5b3Ugc2VlICJiYWNrdXAgZG9lc24ndApjb21wYXJlIHRv IHByaW1hcnkgYm9vdGJsb2NrIjsgdGhpcyBvY2N1cnMgZXZlbiBpZiB5b3UgcnVuIHNjYW5kaXNr Cihmcm9tIHdpbmRvd3MpIG9uIHRoZSBwYXJ0aXRpb24gYmVmb3JlIHRyeWluZyBmc2NrX21zZG9z IGJlY2F1c2UKc2NhbmRpc2sgd2lsbCBvbmx5IGZpeCB0aGUgZmlyc3QgNTIgYnl0ZXMgYW5kIGln bm9yZXMgdGhlIHJlc3Qgb2YgdGhlCmJvb3QgYmxvY2suCj5GaXg6CglUaGUgZml4IGZvciB0aGlz IHdhcyBhY3R1YWxseSBwcm92aWRlZCB5ZWFycyBhZ28sIGJ1dCBhcHBlYXJhbnRseSB3YXMKZm9y Z290dGVuLCBzbyBJJ20gcmVtaW5kaW5nIHlvdS4gU2VlCmh0dHA6Ly93d3cubW9ua2V5Lm9yZy9v cGVuYnNkL2FyY2hpdmUvYnVncy8wMTA1L21zZzAwMDg1Lmh0bWwgZm9yIHRoZQpmaXguIEJhc2lj YWxseSwganVzdCBnbyBpbnRvIC91c3Ivc3JjL3NiaW4vZnNja19tc2Rvcy9ib290LmMgYW5kCmNo YW5nZQppZihtZW1jbXAoYmxvY2ssIGJhY2t1cCwgRE9TQk9PVEJMT0NLU0laRSApKQp0bwppZiht ZW1jbXAoYmxvY2ssIGJhY2t1cCwgNTIpKQpUaGVyZSdzIHNvbWV0aGluZyBlbHNlIGluIHRoYXQg bWVzc2FnZSB0b28gdGhhdCBJIGRvbid0IHVuZGVyc3RhbmQgYnV0CmlzIHByb2JhYmx5IHdvcnRo IGxvb2tpbmcgYXQuCgo= --+permail-20090723102923f7e55a9d000042a4-a_best01+-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 10:41:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE465106564A for ; Thu, 23 Jul 2009 10:41:16 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 72FC98FC08 for ; Thu, 23 Jul 2009 10:41:16 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 8561A130C54; Thu, 23 Jul 2009 12:41:15 +0200 (CEST) Date: Thu, 23 Jul 2009 12:41:15 +0200 From: Guido Falsi To: Ruben de Groot , subbsd , freebsd-current@freebsd.org Message-ID: <20090723104115.GB26926@megatron.madpilot.net> References: <200907231302.34000.subbsd@gmail.com> <20090723093217.GA26926@megatron.madpilot.net> <20090723100548.GA23481@ei.bzerk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090723100548.GA23481@ei.bzerk.org> X-Operating-System: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: library compat for FreeBSD7x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 10:41:17 -0000 On Thu, Jul 23, 2009 at 12:05:48PM +0200, Ruben de Groot wrote: > On Thu, Jul 23, 2009 at 11:32:17AM +0200, Guido Falsi typed: > > On Thu, Jul 23, 2009 at 01:02:33PM +0400, subbsd wrote: > > > Hello, > > > > > > after the bump version on FreeBSD8-Beta2, some application needs for old > > > library. But misc/compat7x ports not found for this. It still not ready? > > > thanks! > > > > You'll have to rempile all ports anyway. > > Erm, doesn't that defeat the whole point of having compat* libraries? The problem is that while a single port directly depending on a compat library may work indefinitely this way, you'll have many problems when you mix and match ports depending on libraries from other ports, mixing ld and new libraries dependancies. I never used the compat bits, but I really think they are there for software you have just in binary form, and no way to recompile. If recompiling all ports is problematic just wait a few days and uupdate using packages... -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 11:41:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9361C106564A for ; Thu, 23 Jul 2009 11:41:02 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id 05C678FC15 for ; Thu, 23 Jul 2009 11:41:01 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id n6NBevlI024052; Thu, 23 Jul 2009 13:40:57 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id n6NBevY2024051; Thu, 23 Jul 2009 13:40:57 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Thu, 23 Jul 2009 13:40:57 +0200 From: Ruben de Groot To: Guido Falsi Message-ID: <20090723114057.GA23923@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Guido Falsi , subbsd , freebsd-current@freebsd.org References: <200907231302.34000.subbsd@gmail.com> <20090723093217.GA26926@megatron.madpilot.net> <20090723100548.GA23481@ei.bzerk.org> <20090723104115.GB26926@megatron.madpilot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090723104115.GB26926@megatron.madpilot.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, J_CHICKENPOX_71 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Thu, 23 Jul 2009 13:41:01 +0200 (CEST) Cc: freebsd-current@freebsd.org, subbsd Subject: Re: library compat for FreeBSD7x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 11:41:02 -0000 On Thu, Jul 23, 2009 at 12:41:15PM +0200, Guido Falsi typed: > On Thu, Jul 23, 2009 at 12:05:48PM +0200, Ruben de Groot wrote: > > On Thu, Jul 23, 2009 at 11:32:17AM +0200, Guido Falsi typed: > > > On Thu, Jul 23, 2009 at 01:02:33PM +0400, subbsd wrote: > > > > Hello, > > > > > > > > after the bump version on FreeBSD8-Beta2, some application needs for old > > > > library. But misc/compat7x ports not found for this. It still not ready? > > > > thanks! > > > > > > You'll have to rempile all ports anyway. > > > > Erm, doesn't that defeat the whole point of having compat* libraries? > > The problem is that while a single port directly depending on a compat > library may work indefinitely this way, you'll have many problems when > you mix and match ports depending on libraries from other ports, mixing > ld and new libraries dependancies. Can you give a concrete example of this? I've never had any such problems. > I never used the compat bits, but I really think they are there for > software you have just in binary form, and no way to recompile. That may be the main reason, but there can be many others. For example, I'm still using the subversion 1.5 client compiled on 6.x because the newer version from ports (1.6) doesn't play nice with eclipse (subclipse). > If recompiling all ports is problematic just wait a few days and uupdate > using packages... Updating using packages might not be an option at all. Example: mod_php5 Ruben From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 12:15:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC4F5106566B for ; Thu, 23 Jul 2009 12:15:23 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 90E1B8FC0C for ; Thu, 23 Jul 2009 12:15:23 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 53F32130C54; Thu, 23 Jul 2009 14:15:22 +0200 (CEST) Date: Thu, 23 Jul 2009 14:15:22 +0200 From: Guido Falsi To: Ruben de Groot , subbsd , freebsd-current@freebsd.org Message-ID: <20090723121522.GC26926@megatron.madpilot.net> References: <200907231302.34000.subbsd@gmail.com> <20090723093217.GA26926@megatron.madpilot.net> <20090723100548.GA23481@ei.bzerk.org> <20090723104115.GB26926@megatron.madpilot.net> <20090723114057.GA23923@ei.bzerk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090723114057.GA23923@ei.bzerk.org> X-Operating-System: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: library compat for FreeBSD7x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 12:15:24 -0000 On Thu, Jul 23, 2009 at 01:40:57PM +0200, Ruben de Groot wrote: > > > > > > Erm, doesn't that defeat the whole point of having compat* libraries? > > BTW, why don't you just let the old libraries lie in your system, or use libmap.conf just to map them to the newer ones? As long as there is no ABI breakage this will work. > > The problem is that while a single port directly depending on a compat > > library may work indefinitely this way, you'll have many problems when > > you mix and match ports depending on libraries from other ports, mixing > > ld and new libraries dependancies. > > Can you give a concrete example of this? I've never had any such problems. If port A depends on library from port B which itself depends on library in base system foo.so.1, but program A was recompiled and itself depends on library foo.so.2 ld could have an hard time linking them at runtime I think. Anyway, I think someone with better uderstanding of the internals of ld can give better explanations. Anyway this is academic, for yhow I understand it, symbol versioning will solve this in a not too far future... > > > I never used the compat bits, but I really think they are there for > > software you have just in binary form, and no way to recompile. > > That may be the main reason, but there can be many others. > For example, I'm still using the subversion 1.5 client compiled on 6.x > because the newer version from ports (1.6) doesn't play nice with eclipse > (subclipse). You have the sources, you could anyway recompile an old version. > > > If recompiling all ports is problematic just wait a few days and uupdate > > using packages... > > Updating using packages might not be an option at all. Example: mod_php5 If you manage many servers you should anyway have a machine to make your own packages too and roll those ones out to production machines, I think. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 04:27:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 466771065674 for ; Thu, 23 Jul 2009 04:27:34 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9A18FC1B for ; Thu, 23 Jul 2009 04:27:34 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 923B333C6C; Wed, 22 Jul 2009 21:27:33 -0700 (PDT) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 336F233C64; Wed, 22 Jul 2009 21:27:33 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <19047.59060.727642.306526@already.local> Date: Wed, 22 Jul 2009 21:27:32 -0700 To: Scot Hetzel In-Reply-To: <790a9fff0907222033t6393b725n59a9f7d8a38f32c9@mail.gmail.com> References: <19047.52443.164412.363239@already.local> <790a9fff0907222033t6393b725n59a9f7d8a38f32c9@mail.gmail.com> X-Mailer: VM 8.0.12 under 22.3.1 (i386-apple-darwin9.6.0) X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 23 Jul 2009 12:34:59 +0000 Cc: freebsd-current@freebsd.org, hartzell@alerce.com Subject: Re: gptzfsboot doesn't like change (failure after swapping drives) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 04:27:34 -0000 Scot Hetzel writes: > On Wed, Jul 22, 2009 at 9:37 PM, George Hartzell wrote: > > > > I've been playing around with building an 8.0BETA2 system with > > everything on a single zfs filesystem (I'll get fancier later) on = a > > zpool that is a 4 disk raidz. =A0I'm using GPT partitions and glab= els so > > that I can move the drives around w/out drama. > > > > Things work well, but if I swap a pair of drives then try to boot = I > > get the message that other folks have reported: > > > > =A0ZFS: i/o error - all block copies unavailable. > > =A0ZFS: can't read MOS > > =A0ZFS: unexpected object set type lld > > =A0ZFS: unexpected object set type lld > > > > Then a couple of boot: prompts. > > > > If I boot off of the 8.0BETA2 media I can import the pool, even wi= th > > the drives in different slots. > > > > When I put the drives back into their original slots (verified by > > booting the USB stick and checking with glabel status) I still can= 't > > boot off of them, which surprised me a bit. > > > > Can anyone suggest something that I might be able to do to get a > > system in this state to boot? =A0I've tried importing and exportin= g and > > importing the pool several times. > > > I haven't tested this, but try the following: >=20 > 1. boot the 8.0BETA install/fixit media > 2. goto the fixit environment > 3. Create /boot/zfs directory > 4. load the kernel modules opensolaris.ko and zfs.ko > 5. import the pool, and mount the root filesystem on /mnt > 6. Copy /boot/zfs/zpool.cache to /mnt/boot/zfs > 7. Reboot the system I'd tried that, just did it again to be sure. Didn't help. I don't think that the {gpt,}zfsboot code uses that file, I think that's a kernel thing. g. From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 12:42:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C16CD106566C for ; Thu, 23 Jul 2009 12:42:16 +0000 (UTC) (envelope-from michiel@boland.org) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1B08FC1F for ; Thu, 23 Jul 2009 12:42:16 +0000 (UTC) (envelope-from michiel@boland.org) Received: from aja.boland.org (91-43-215.ftth.xms.internl.net [82.215.43.91]) (authenticated bits=0) by smtp-vbr10.xs4all.nl (8.13.8/8.13.8) with ESMTP id n6NCg7Su086875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2009 14:42:14 +0200 (CEST) (envelope-from michiel@boland.org) Message-ID: <4A685A9F.30004@boland.org> Date: Thu, 23 Jul 2009 14:42:07 +0200 From: Michiel Boland User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: subbsd References: <200907231258.29702.subbsd@gmail.com> In-Reply-To: <200907231258.29702.subbsd@gmail.com> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org Subject: Re: ports: java/jdk16 broken for FreeBSD 8 BETA2? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 12:42:17 -0000 subbsd wrote: > Hello > > Ive try to builds java/jdk16. > > diablo-jdk-1.6.0.07.02_5 Has been successfull builds (as i know this is > bootstrap for jdk16 install?) > > After make -C /usr/ports/java/jdk16 install i get messages: > -- > > /usr/local/diablo-jdk1.6.0/bin/javap javax.xml.transform.TransformerFactory > > /dev/null 2>&1; \ > if [ $? -ne 0 ]; then \ > /usr/local/diablo-jdk1.6.0/bin/java -version; \ > echo "*** An XSLT processor (J2SE 1.4.x or newer) is required" \ > "to bootstrap this build" 1>&2; \ > exit 1; \ > fi > Error occurred during initialization of VM > Unable to load ZIP library: /usr/local/diablo-jdk1.6.0/jre/lib/amd64/libzip.so > *** An XSLT processor (J2SE 1.4.x or newer) is required to bootstrap this > build Map libz.so.4 to libz.so.5 in /etc/libmap.conf Or wait until someone updates the diablo-jdk port. Cheers Michiel From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 04:56:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EA12106564A for ; Thu, 23 Jul 2009 04:56:22 +0000 (UTC) (envelope-from erich@apsara.com.sg) Received: from babylon.webvis.net (babylon.webvis.net [202.157.163.226]) by mx1.freebsd.org (Postfix) with ESMTP id BAD998FC0C for ; Thu, 23 Jul 2009 04:56:21 +0000 (UTC) (envelope-from erich@apsara.com.sg) Received: from [10.0.1.240] ([119.73.191.194]) by apsara.com.sg ; Thu, 23 Jul 2009 12:56:17 +0800 SGT From: Erich Dollansky Organization: apsara green technology pte ltd To: freebsd-current@freebsd.org Date: Thu, 23 Jul 2009 12:56:12 +0800 User-Agent: KMail/1.9.10 References: <4A67CD2B.9040200@mykitchentable.net> In-Reply-To: <4A67CD2B.9040200@mykitchentable.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907231256.14754.erich@apsara.com.sg> X-Mailman-Approved-At: Thu, 23 Jul 2009 12:44:43 +0000 Cc: Drew Tomlinson Subject: Re: USB 2.0 External Drive - What Is A Reasonable Transfer Rate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 04:56:22 -0000 Hi, On 23 July 2009 am 10:38:35 Drew Tomlinson wrote: > I have a USB 2.0 external drive that's formatted as NTFS under > Windows XP. I've plugged it into my 8.0 BETA2 install and am i did this before on 6.x and did not have this problem? So, you are reading from the USB NTFS drive? Can you copy some files from there to /dev/null to check that it is really the reading? Erich From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 13:06:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 58AC2106566C for ; Thu, 23 Jul 2009 13:06:49 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id BB2588FC08 for ; Thu, 23 Jul 2009 13:06:48 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.2/8.14.2) with ESMTP id n6ND6hLf024480; Thu, 23 Jul 2009 15:06:44 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.2/8.14.2/Submit) id n6ND6hfA024479; Thu, 23 Jul 2009 15:06:43 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Thu, 23 Jul 2009 15:06:43 +0200 From: Ruben de Groot To: Guido Falsi Message-ID: <20090723130643.GA24141@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Guido Falsi , subbsd , freebsd-current@freebsd.org References: <200907231302.34000.subbsd@gmail.com> <20090723093217.GA26926@megatron.madpilot.net> <20090723100548.GA23481@ei.bzerk.org> <20090723104115.GB26926@megatron.madpilot.net> <20090723114057.GA23923@ei.bzerk.org> <20090723121522.GC26926@megatron.madpilot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090723121522.GC26926@megatron.madpilot.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, J_CHICKENPOX_61,J_CHICKENPOX_71 autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Thu, 23 Jul 2009 15:06:47 +0200 (CEST) Cc: freebsd-current@freebsd.org, subbsd Subject: Re: library compat for FreeBSD7x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:06:49 -0000 On Thu, Jul 23, 2009 at 02:15:22PM +0200, Guido Falsi typed: > On Thu, Jul 23, 2009 at 01:40:57PM +0200, Ruben de Groot wrote: > > > > > > > > Erm, doesn't that defeat the whole point of having compat* libraries? > > > > > BTW, why don't you just let the old libraries lie in your system, or use > libmap.conf just to map them to the newer ones? As long as there is no > ABI breakage this will work. A new library version usually means ABI changes. So libmap.conf is not a failsafe solution. As for leaving the old libraries in an upgraded system, that's essentially the same as installing compat?x in a newly installed system. > > > The problem is that while a single port directly depending on a compat > > > library may work indefinitely this way, you'll have many problems when > > > you mix and match ports depending on libraries from other ports, mixing > > > ld and new libraries dependancies. > > > > Can you give a concrete example of this? I've never had any such problems. > > If port A depends on library from port B which itself depends on library > in base system foo.so.1, but program A was recompiled and itself depends > on library foo.so.2 ld could have an hard time linking them at runtime I > think. Yes, that would be hard. The obvious solution to this is to not recompile program A on a system with the newer library version. > > That may be the main reason, but there can be many others. > > For example, I'm still using the subversion 1.5 client compiled on 6.x > > because the newer version from ports (1.6) doesn't play nice with eclipse > > (subclipse). > > You have the sources, you could anyway recompile an old version. Sure, but I prefer using ports/packages. Keeps my systems manageable. > > Updating using packages might not be an option at all. Example: mod_php5 > > If you manage many servers you should anyway have a machine to make your > own packages too and roll those ones out to production machines, I > think. Yes, and there's another reason for having compat7x libraries. If you build on 7.X-RELEASE and want to test your packages on 8.X, you're going to need them. Ruben From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 13:14:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E32D106564A; Thu, 23 Jul 2009 13:14:14 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 046E08FC0C; Thu, 23 Jul 2009 13:14:13 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:48976 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1MTy7P-0004wX-6A; Thu, 23 Jul 2009 15:13:57 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 257A74CC44; Thu, 23 Jul 2009 15:13:53 +0200 (CEST) Message-Id: From: Thomas Backman To: Michael Reifenberger 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 v935.3) Date: Thu, 23 Jul 2009 15:13:51 +0200 References: <20090723092435.GA799@a91-153-125-115.elisa-laajakaista.fi> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MTy7P-0004wX-6A. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MTy7P-0004wX-6A d9243ddd0e66c7769844331c82dea539 Cc: Jaakko Heinonen , freebsd@r.zeeb.org, bug-followup@FreeBSD.org, FreeBSD current Subject: Re: kern/132337: [zfs] [panic] kernel panic in zfs_fuid_create_cred X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:14:14 -0000 On Jul 23, 2009, at 15:06, Michael Reifenberger wrote: > On Thu, 23 Jul 2009, Jaakko Heinonen wrote: > ... >> This PR is a duplicate of kern/133020. There is a workaround fix in >> pjd's perforce branch but apparently it was never committed to svn. >> >> See: >> >> http://p4db.freebsd.org/changeView.cgi?CH=159874 >> http://people.freebsd.org/~pjd/patches/zfs_znode.h.patch >> > I'm using this patch since march without problems. I've only used it for hours but it seems to work here too, no longer using ZVOLs. Would be nice to have in -RELEASE :) Jaakko: It's the other way around. 132337 < 133020. This bug was filed Mar 05 2009, while 133020 was filed Mar 24 2009. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 13:15:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99447106566B for ; Thu, 23 Jul 2009 13:15:44 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 425E08FC0A for ; Thu, 23 Jul 2009 13:15:44 +0000 (UTC) (envelope-from mad@madpilot.net) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 3A41E130C5E; Thu, 23 Jul 2009 15:15:43 +0200 (CEST) Date: Thu, 23 Jul 2009 15:15:43 +0200 From: Guido Falsi To: Ruben de Groot , subbsd , freebsd-current@freebsd.org Message-ID: <20090723131543.GD26926@megatron.madpilot.net> References: <200907231302.34000.subbsd@gmail.com> <20090723093217.GA26926@megatron.madpilot.net> <20090723100548.GA23481@ei.bzerk.org> <20090723104115.GB26926@megatron.madpilot.net> <20090723114057.GA23923@ei.bzerk.org> <20090723121522.GC26926@megatron.madpilot.net> <20090723130643.GA24141@ei.bzerk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090723130643.GA24141@ei.bzerk.org> X-Operating-System: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: library compat for FreeBSD7x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:15:44 -0000 On Thu, Jul 23, 2009 at 03:06:43PM +0200, Ruben de Groot wrote: > > A new library version usually means ABI changes. So libmap.conf is not a > failsafe solution. As for leaving the old libraries in an upgraded system, > that's essentially the same as installing compat?x in a newly installed > system. > > Yes, that would be hard. > The obvious solution to this is to not recompile program A on a system with > the newer library version. > Sure, but I prefer using ports/packages. Keeps my systems manageable. > > Yes, and there's another reason for having compat7x libraries. If you build on > 7.X-RELEASE and want to test your packages on 8.X, you're going to need them. I see your point, but I'd rather spend some time and effort when the bump ha[ppens recompiling everything than fiddle with hacks and compat libs for months...Maybe we just like doing things dirfferently. Anyway, as things stand right now it's better to advise people to recompile everything than risk giving them an advice difficult to follow. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 13:22:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44C81106566B; Thu, 23 Jul 2009 13:22:39 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) by mx1.freebsd.org (Postfix) with ESMTP id EA00F8FC15; Thu, 23 Jul 2009 13:22:38 +0000 (UTC) (envelope-from mike@reifenberger.com) Received: from mail01.m-online.net (mail.m-online.net [192.168.3.149]) by mail-out.m-online.net (Postfix) with ESMTP id 277531C158D9; Thu, 23 Jul 2009 15:06:54 +0200 (CEST) Received: from localhost (dynscan2.mnet-online.de [192.168.1.215]) by mail.m-online.net (Postfix) with ESMTP id 8360F903D3; Thu, 23 Jul 2009 15:06:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.3.149]) by localhost (dynscan2.mnet-online.de [192.168.1.215]) (amavisd-new, port 10024) with ESMTP id Gh+icpG1qkN7; Thu, 23 Jul 2009 15:06:52 +0200 (CEST) Received: from mail.reifenberger.com (ppp-93-104-40-254.dynamic.mnet-online.de [93.104.40.254]) by mail.mnet-online.de (Postfix) with ESMTP; Thu, 23 Jul 2009 15:06:52 +0200 (CEST) Received: by mail.reifenberger.com (Postfix, from userid 1001) id 649093CE81; Thu, 23 Jul 2009 15:06:52 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.reifenberger.com (Postfix) with ESMTP id 5CFB33CE80; Thu, 23 Jul 2009 15:06:52 +0200 (CEST) Date: Thu, 23 Jul 2009 15:06:52 +0200 (CEST) From: Michael Reifenberger To: Jaakko Heinonen In-Reply-To: <20090723092435.GA799@a91-153-125-115.elisa-laajakaista.fi> Message-ID: References: <20090723092435.GA799@a91-153-125-115.elisa-laajakaista.fi> 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 current , bug-followup@FreeBSD.org, Thomas Backman , freebsd@r.zeeb.org Subject: Re: kern/132337: [zfs] [panic] kernel panic in zfs_fuid_create_cred X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:22:39 -0000 On Thu, 23 Jul 2009, Jaakko Heinonen wrote: ... > This PR is a duplicate of kern/133020. There is a workaround fix in > pjd's perforce branch but apparently it was never committed to svn. > > See: > > http://p4db.freebsd.org/changeView.cgi?CH=159874 > http://people.freebsd.org/~pjd/patches/zfs_znode.h.patch > I'm using this patch since march without problems. Bye/2 --- Michael Reifenberger Michael@Reifenberger.com http://www.Reifenberger.com From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 13:34:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA498106566B for ; Thu, 23 Jul 2009 13:34:34 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id EBC618FC1E for ; Thu, 23 Jul 2009 13:34:33 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 204E39CB0EC for ; Thu, 23 Jul 2009 15:32:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRF4864PW+d2 for ; Thu, 23 Jul 2009 15:32:30 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id B92C39CB29B for ; Thu, 23 Jul 2009 15:32:30 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n6NDWUQ1070495 for current@freebsd.org; Thu, 23 Jul 2009 15:32:30 +0200 (CEST) (envelope-from rdivacky) Date: Thu, 23 Jul 2009 15:32:30 +0200 From: Roman Divacky To: current@freebsd.org Message-ID: <20090723133230.GA69577@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gatW/ieO32f1wygP" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [PATCH]: MPSAFE isa_dma* functions for i386/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:34:35 -0000 --gatW/ieO32f1wygP Content-Type: multipart/mixed; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi I have a patch that makes isa_dma* routines MPSAFE on i386/amd64. These routines are also present in ia64/sparc64. Sparc64 provides just empty stubs and ia64 should be removed (according to Marcel Moolenaar). there are some old drivers that use this - most prominently ppc(4) and fdc(4) if you have this hardware please test the attached patch or you can download it here: http://www.vlakno.cz/~rdivacky/isa_dma-locking.patch the patch was reviewed by jhb@ but never tested on a real hw (as I have none). most of the users of the isa_dma* routines are still covered by Giant because they are used in drivers attach routines (which are Giant locked) but ppc/fdc use those in the normal code as well thank you very much for testing roman --LZvS9be/3tNcYl/X Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="isa_dma-locking.patch" Content-Transfer-Encoding: quoted-printable Index: amd64/isa/isa_dma.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- amd64/isa/isa_dma.c (revision 195829) +++ amd64/isa/isa_dma.c (working copy) @@ -71,6 +71,8 @@ static u_int8_t dma_busy =3D 0; /* Used in isa_dmastart() */ static u_int8_t dma_inuse =3D 0; /* User for acquire/release */ static u_int8_t dma_auto_mode =3D 0; +static struct mtx isa_dma_lock; +MTX_SYSINIT(isa_dma_lock, &isa_dma_lock, "isa DMA lock", MTX_DEF); =20 #define VALID_DMA_MASK (7) =20 @@ -84,39 +86,56 @@ isa_dma_init(int chan, u_int bouncebufsize, int flag) { void *buf; + int contig; =20 - /* - * If a DMA channel is shared, both drivers have to call isa_dma_init - * since they don't know that the other driver will do it. - * Just return if we're already set up good. - * XXX: this only works if they agree on the bouncebuf size. This - * XXX: is typically the case since they are multiple instances of - * XXX: the same driver. - */ - if (dma_bouncebuf[chan] !=3D NULL) - return (0); - #ifdef DIAGNOSTIC if (chan & ~VALID_DMA_MASK) panic("isa_dma_init: channel out of range"); #endif =20 - dma_bouncebufsize[chan] =3D bouncebufsize; =20 /* Try malloc() first. It works better if it works. */ buf =3D malloc(bouncebufsize, M_DEVBUF, flag); if (buf !=3D NULL) { - if (isa_dmarangecheck(buf, bouncebufsize, chan) =3D=3D 0) { - dma_bouncebuf[chan] =3D buf; - return (0); + if (isa_dmarangecheck(buf, bouncebufsize, chan) !=3D 0) { + free(buf, M_DEVBUF); + buf =3D NULL; } - free(buf, M_DEVBUF); + contig =3D 0; } - buf =3D contigmalloc(bouncebufsize, M_DEVBUF, flag, 0ul, 0xfffffful, + + if (buf =3D=3D NULL) { + buf =3D contigmalloc(bouncebufsize, M_DEVBUF, flag, 0ul, 0xfffffful, 1ul, chan & 4 ? 0x20000ul : 0x10000ul); + contig =3D 1; + } + if (buf =3D=3D NULL) return (ENOMEM); + + mtx_lock(&isa_dma_lock); + /* + * If a DMA channel is shared, both drivers have to call isa_dma_init + * since they don't know that the other driver will do it. + * Just return if we're already set up good. + * XXX: this only works if they agree on the bouncebuf size. This + * XXX: is typically the case since they are multiple instances of + * XXX: the same driver. + */ + if (dma_bouncebuf[chan] !=3D NULL) { + if (contig) + contigfree(buf, bouncebufsize, M_DEVBUF); + else + free(buf, M_DEVBUF); + mtx_unlock(&isa_dma_lock); + return (0); + } + + dma_bouncebufsize[chan] =3D bouncebufsize; dma_bouncebuf[chan] =3D buf; + + mtx_unlock(&isa_dma_lock); + return (0); } =20 @@ -133,12 +152,15 @@ panic("isa_dma_acquire: channel out of range"); #endif =20 + mtx_lock(&isa_dma_lock); if (dma_inuse & (1 << chan)) { printf("isa_dma_acquire: channel %d already in use\n", chan); + mtx_unlock(&isa_dma_lock); return (EBUSY); } dma_inuse |=3D (1 << chan); dma_auto_mode &=3D ~(1 << chan); + mtx_unlock(&isa_dma_lock); =20 return (0); } @@ -155,8 +177,11 @@ if (chan & ~VALID_DMA_MASK) panic("isa_dma_release: channel out of range"); =20 + mtx_lock(&isa_dma_lock); if ((dma_inuse & (1 << chan)) =3D=3D 0) printf("isa_dma_release: channel %d not in use\n", chan); +#else + mtx_lock(&isa_dma_lock); #endif =20 if (dma_busy & (1 << chan)) { @@ -171,6 +196,8 @@ =20 dma_inuse &=3D ~(1 << chan); dma_auto_mode &=3D ~(1 << chan); + + mtx_unlock(&isa_dma_lock); } =20 /* @@ -186,6 +213,7 @@ panic("isa_dmacascade: channel out of range"); #endif =20 + mtx_lock(&isa_dma_lock); /* set dma channel mode, and set dma channel mode */ if ((chan & 4) =3D=3D 0) { outb(DMA1_MODE, DMA37MD_CASCADE | chan); @@ -194,6 +222,7 @@ outb(DMA2_MODE, DMA37MD_CASCADE | (chan & 3)); outb(DMA2_SMSK, chan & 3); } + mtx_unlock(&isa_dma_lock); } =20 /* @@ -206,8 +235,11 @@ vm_paddr_t phys; int waport; caddr_t newaddr; + int dma_range_checked; =20 - GIANT_REQUIRED; + /* translate to physical */ + phys =3D pmap_extract(kernel_pmap, (vm_offset_t)addr); + dma_range_checked =3D isa_dmarangecheck(addr, nbytes, chan); =20 #ifdef DIAGNOSTIC if (chan & ~VALID_DMA_MASK) @@ -217,8 +249,11 @@ || (chan >=3D 4 && (nbytes > (1<<17) || (uintptr_t)addr & 1))) panic("isa_dmastart: impossible request"); =20 + mtx_lock(&isa_dma_lock); if ((dma_inuse & (1 << chan)) =3D=3D 0) printf("isa_dmastart: channel %d not acquired\n", chan); +#else + mtx_lock(&isa_dma_lock); #endif =20 #if 0 @@ -233,7 +268,7 @@ =20 dma_busy |=3D (1 << chan); =20 - if (isa_dmarangecheck(addr, nbytes, chan)) { + if (dma_range_checked) { if (dma_bouncebuf[chan] =3D=3D NULL || dma_bouncebufsize[chan] < nbytes) panic("isa_dmastart: bad bounce buffer");=20 @@ -246,9 +281,6 @@ addr =3D newaddr; } =20 - /* translate to physical */ - phys =3D pmap_extract(kernel_pmap, (vm_offset_t)addr); - if (flags & ISADMA_RAW) { dma_auto_mode |=3D (1 << chan); } else {=20 @@ -323,6 +355,7 @@ /* unmask channel */ outb(DMA2_SMSK, chan & 3); } + mtx_unlock(&isa_dma_lock); } =20 void @@ -336,6 +369,7 @@ printf("isa_dmadone: channel %d not acquired\n", chan); #endif =20 + mtx_lock(&isa_dma_lock); if (((dma_busy & (1 << chan)) =3D=3D 0) &&=20 (dma_auto_mode & (1 << chan)) =3D=3D 0 ) printf("isa_dmadone: channel %d not busy\n", chan); @@ -351,6 +385,7 @@ dma_bounced &=3D ~(1 << chan); } dma_busy &=3D ~(1 << chan); + mtx_unlock(&isa_dma_lock); } =20 /* @@ -367,8 +402,6 @@ vm_offset_t endva; u_int dma_pgmsk =3D (chan & 4) ? ~(128*1024-1) : ~(64*1024-1); =20 - GIANT_REQUIRED; - endva =3D (vm_offset_t)round_page((vm_offset_t)va + length); for (; va < (caddr_t) endva ; va +=3D PAGE_SIZE) { phys =3D trunc_page(pmap_extract(kernel_pmap, (vm_offset_t)va)); @@ -420,13 +453,15 @@ * or -1 if the channel requested is not active. * */ -int -isa_dmastatus(int chan) +static int +isa_dmastatus_locked(int chan) { u_long cnt =3D 0; int ffport, waport; u_long low1, high1, low2, high2; =20 + mtx_assert(&isa_dma_lock, MA_OWNED); + /* channel active? */ if ((dma_inuse & (1 << chan)) =3D=3D 0) { printf("isa_dmastatus: channel %d not active\n", chan); @@ -472,6 +507,18 @@ return(cnt); } =20 +int +isa_dmastatus(int chan) +{ + int status; + + mtx_lock(&isa_dma_lock); + status =3D isa_dmastatus_locked(chan); + mtx_unlock(&isa_dma_lock); + + return (status); +} + /* * Reached terminal count yet ? */ @@ -491,12 +538,16 @@ int isa_dmastop(int chan)=20 { + int status; + + mtx_lock(&isa_dma_lock); if ((dma_inuse & (1 << chan)) =3D=3D 0) printf("isa_dmastop: channel %d not acquired\n", chan); =20 =20 if (((dma_busy & (1 << chan)) =3D=3D 0) && ((dma_auto_mode & (1 << chan)) =3D=3D 0)) { printf("chan %d not busy\n", chan); + mtx_unlock(&isa_dma_lock); return -2 ; } =20 @@ -505,7 +556,12 @@ } else { outb(DMA2_SMSK, (chan & 3) | 4 /* disable mask */); } - return(isa_dmastatus(chan)); + + status =3D isa_dmastatus_locked(chan); + + mtx_unlock(&isa_dma_lock); + + return (status); } =20 /* Index: i386/isa/isa_dma.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- i386/isa/isa_dma.c (revision 195829) +++ i386/isa/isa_dma.c (working copy) @@ -69,6 +69,8 @@ static u_int8_t dma_busy =3D 0; /* Used in isa_dmastart() */ static u_int8_t dma_inuse =3D 0; /* User for acquire/release */ static u_int8_t dma_auto_mode =3D 0; +static struct mtx isa_dma_lock; +MTX_SYSINIT(isa_dma_lock, &isa_dma_lock, "isa DMA lock", MTX_DEF); =20 #define VALID_DMA_MASK (7) =20 @@ -82,39 +84,56 @@ isa_dma_init(int chan, u_int bouncebufsize, int flag) { void *buf; + int contig; =20 - /* - * If a DMA channel is shared, both drivers have to call isa_dma_init - * since they don't know that the other driver will do it. - * Just return if we're already set up good. - * XXX: this only works if they agree on the bouncebuf size. This - * XXX: is typically the case since they are multiple instances of - * XXX: the same driver. - */ - if (dma_bouncebuf[chan] !=3D NULL) - return (0); - #ifdef DIAGNOSTIC if (chan & ~VALID_DMA_MASK) panic("isa_dma_init: channel out of range"); #endif =20 - dma_bouncebufsize[chan] =3D bouncebufsize; =20 /* Try malloc() first. It works better if it works. */ buf =3D malloc(bouncebufsize, M_DEVBUF, flag); if (buf !=3D NULL) { - if (isa_dmarangecheck(buf, bouncebufsize, chan) =3D=3D 0) { - dma_bouncebuf[chan] =3D buf; - return (0); + if (isa_dmarangecheck(buf, bouncebufsize, chan) !=3D 0) { + free(buf, M_DEVBUF); + buf =3D NULL; } - free(buf, M_DEVBUF); + contig =3D 0; } - buf =3D contigmalloc(bouncebufsize, M_DEVBUF, flag, 0ul, 0xfffffful, + + if (buf =3D=3D NULL) { + buf =3D contigmalloc(bouncebufsize, M_DEVBUF, flag, 0ul, 0xfffffful, 1ul, chan & 4 ? 0x20000ul : 0x10000ul); + contig =3D 1; + } + if (buf =3D=3D NULL) return (ENOMEM); + + mtx_lock(&isa_dma_lock); + /* + * If a DMA channel is shared, both drivers have to call isa_dma_init + * since they don't know that the other driver will do it. + * Just return if we're already set up good. + * XXX: this only works if they agree on the bouncebuf size. This + * XXX: is typically the case since they are multiple instances of + * XXX: the same driver. + */ + if (dma_bouncebuf[chan] !=3D NULL) { + if (contig) + contigfree(buf, bouncebufsize, M_DEVBUF); + else + free(buf, M_DEVBUF); + mtx_unlock(&isa_dma_lock); + return (0); + } + + dma_bouncebufsize[chan] =3D bouncebufsize; dma_bouncebuf[chan] =3D buf; + + mtx_unlock(&isa_dma_lock); + return (0); } =20 @@ -131,12 +150,15 @@ panic("isa_dma_acquire: channel out of range"); #endif =20 + mtx_lock(&isa_dma_lock); if (dma_inuse & (1 << chan)) { printf("isa_dma_acquire: channel %d already in use\n", chan); + mtx_unlock(&isa_dma_lock); return (EBUSY); } dma_inuse |=3D (1 << chan); dma_auto_mode &=3D ~(1 << chan); + mtx_unlock(&isa_dma_lock); =20 return (0); } @@ -153,8 +175,11 @@ if (chan & ~VALID_DMA_MASK) panic("isa_dma_release: channel out of range"); =20 + mtx_lock(&isa_dma_lock); if ((dma_inuse & (1 << chan)) =3D=3D 0) printf("isa_dma_release: channel %d not in use\n", chan); +#else + mtx_lock(&isa_dma_lock); #endif =20 if (dma_busy & (1 << chan)) { @@ -169,6 +194,8 @@ =20 dma_inuse &=3D ~(1 << chan); dma_auto_mode &=3D ~(1 << chan); + + mtx_unlock(&isa_dma_lock); } =20 /* @@ -184,6 +211,7 @@ panic("isa_dmacascade: channel out of range"); #endif =20 + mtx_lock(&isa_dma_lock); /* set dma channel mode, and set dma channel mode */ if ((chan & 4) =3D=3D 0) { outb(DMA1_MODE, DMA37MD_CASCADE | chan); @@ -192,6 +220,7 @@ outb(DMA2_MODE, DMA37MD_CASCADE | (chan & 3)); outb(DMA2_SMSK, chan & 3); } + mtx_unlock(&isa_dma_lock); } =20 /* @@ -204,8 +233,11 @@ vm_paddr_t phys; int waport; caddr_t newaddr; + int dma_range_checked; =20 - GIANT_REQUIRED; + /* translate to physical */ + phys =3D pmap_extract(kernel_pmap, (vm_offset_t)addr); + dma_range_checked =3D isa_dmarangecheck(addr, nbytes, chan); =20 #ifdef DIAGNOSTIC if (chan & ~VALID_DMA_MASK) @@ -215,8 +247,11 @@ || (chan >=3D 4 && (nbytes > (1<<17) || (u_int)addr & 1))) panic("isa_dmastart: impossible request"); =20 + mtx_lock(&isa_dma_lock); if ((dma_inuse & (1 << chan)) =3D=3D 0) printf("isa_dmastart: channel %d not acquired\n", chan); +#else + mtx_lock(&isa_dma_lock); #endif =20 #if 0 @@ -231,7 +266,7 @@ =20 dma_busy |=3D (1 << chan); =20 - if (isa_dmarangecheck(addr, nbytes, chan)) { + if (dma_range_checked) { if (dma_bouncebuf[chan] =3D=3D NULL || dma_bouncebufsize[chan] < nbytes) panic("isa_dmastart: bad bounce buffer");=20 @@ -244,9 +279,6 @@ addr =3D newaddr; } =20 - /* translate to physical */ - phys =3D pmap_extract(kernel_pmap, (vm_offset_t)addr); - if (flags & ISADMA_RAW) { dma_auto_mode |=3D (1 << chan); } else {=20 @@ -321,6 +353,7 @@ /* unmask channel */ outb(DMA2_SMSK, chan & 3); } + mtx_unlock(&isa_dma_lock); } =20 void @@ -334,6 +367,7 @@ printf("isa_dmadone: channel %d not acquired\n", chan); #endif =20 + mtx_lock(&isa_dma_lock); if (((dma_busy & (1 << chan)) =3D=3D 0) &&=20 (dma_auto_mode & (1 << chan)) =3D=3D 0 ) printf("isa_dmadone: channel %d not busy\n", chan); @@ -349,6 +383,7 @@ dma_bounced &=3D ~(1 << chan); } dma_busy &=3D ~(1 << chan); + mtx_unlock(&isa_dma_lock); } =20 /* @@ -365,8 +400,6 @@ vm_offset_t endva; u_int dma_pgmsk =3D (chan & 4) ? ~(128*1024-1) : ~(64*1024-1); =20 - GIANT_REQUIRED; - endva =3D (vm_offset_t)round_page((vm_offset_t)va + length); for (; va < (caddr_t) endva ; va +=3D PAGE_SIZE) { phys =3D trunc_page(pmap_extract(kernel_pmap, (vm_offset_t)va)); @@ -419,13 +452,15 @@ * or -1 if the channel requested is not active. * */ -int -isa_dmastatus(int chan) +static int +isa_dmastatus_locked(int chan) { u_long cnt =3D 0; int ffport, waport; u_long low1, high1, low2, high2; =20 + mtx_assert(&isa_dma_lock, MA_OWNED); + /* channel active? */ if ((dma_inuse & (1 << chan)) =3D=3D 0) { printf("isa_dmastatus: channel %d not active\n", chan); @@ -471,6 +506,18 @@ return(cnt); } =20 +int +isa_dmastatus(int chan) +{ + int status; + + mtx_lock(&isa_dma_lock); + status =3D isa_dmastatus_locked(chan); + mtx_unlock(&isa_dma_lock); + + return (status); +} + /* * Reached terminal count yet ? */ @@ -490,12 +537,16 @@ int isa_dmastop(int chan)=20 { + int status; + + mtx_lock(&isa_dma_lock); if ((dma_inuse & (1 << chan)) =3D=3D 0) printf("isa_dmastop: channel %d not acquired\n", chan); =20 =20 if (((dma_busy & (1 << chan)) =3D=3D 0) && ((dma_auto_mode & (1 << chan)) =3D=3D 0)) { printf("chan %d not busy\n", chan); + mtx_unlock(&isa_dma_lock); return -2 ; } =20 @@ -504,7 +555,12 @@ } else { outb(DMA2_SMSK, (chan & 3) | 4 /* disable mask */); } - return(isa_dmastatus(chan)); + + status =3D isa_dmastatus_locked(chan); + + mtx_unlock(&isa_dma_lock); + + return (status); } =20 /* Index: dev/ieee488/ibfoo.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- dev/ieee488/ibfoo.c (revision 195829) +++ dev/ieee488/ibfoo.c (working copy) @@ -397,18 +397,14 @@ KASSERT(u->dmachan >=3D 0, ("Bogus dmachan %d", u->dmachan)); ib =3D u->ibfoo; ib->mode =3D DMA_IDATA; - mtx_lock(&Giant); isa_dmastart(ISADMA_READ, data, len, u->dmachan); - mtx_unlock(&Giant); mtx_lock(&u->mutex); upd7210_wr(u, IMR1, IXR1_ENDRX); upd7210_wr(u, IMR2, IMR2_DMAI); gpib_ib_wait_xfer(u, ib); mtx_unlock(&u->mutex); - mtx_lock(&Giant); j =3D isa_dmastatus(u->dmachan); isa_dmadone(ISADMA_READ, data, len, u->dmachan); - mtx_unlock(&Giant); return (len - j); } =20 @@ -790,14 +786,12 @@ mtx_unlock(&u->mutex); =20 if (u->dmachan >=3D 0) { - mtx_lock(&Giant); error =3D isa_dma_acquire(u->dmachan); if (!error) { error =3D isa_dma_init(u->dmachan, PAGE_SIZE, M_WAITOK); if (error) isa_dma_release(u->dmachan); } - mtx_unlock(&Giant); } =20 if (error) { @@ -855,9 +849,7 @@ free(ib, M_IBFOO); =20 if (u->dmachan >=3D 0) { - mtx_lock(&Giant); isa_dma_release(u->dmachan); - mtx_unlock(&Giant); } mtx_lock(&u->mutex); u->busy =3D 0; Index: dev/fdc/fdc.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- dev/fdc/fdc.c (revision 195829) +++ dev/fdc/fdc.c (working copy) @@ -781,11 +781,9 @@ =20 /* Disable ISADMA if we bailed while it was active */ if (fd !=3D NULL && (fd->flags & FD_ISADMA)) { - mtx_lock(&Giant); isa_dmadone( bp->bio_cmd & BIO_READ ? ISADMA_READ : ISADMA_WRITE, fd->fd_ioptr, fd->fd_iosize, fdc->dmachan); - mtx_unlock(&Giant); mtx_lock(&fdc->fdc_mtx); fd->flags &=3D ~FD_ISADMA; mtx_unlock(&fdc->fdc_mtx); @@ -958,11 +956,9 @@ /* Setup ISADMA if we need it and have it */ if ((bp->bio_cmd & (BIO_READ|BIO_WRITE|BIO_FMT)) && !(fdc->flags & FDC_NODMA)) { - mtx_lock(&Giant); isa_dmastart( bp->bio_cmd & BIO_READ ? ISADMA_READ : ISADMA_WRITE, fd->fd_ioptr, fd->fd_iosize, fdc->dmachan); - mtx_unlock(&Giant); mtx_lock(&fdc->fdc_mtx); fd->flags |=3D FD_ISADMA; mtx_unlock(&fdc->fdc_mtx); @@ -1040,11 +1036,9 @@ =20 /* Finish DMA */ if (fd->flags & FD_ISADMA) { - mtx_lock(&Giant); isa_dmadone( bp->bio_cmd & BIO_READ ? ISADMA_READ : ISADMA_WRITE, fd->fd_ioptr, fd->fd_iosize, fdc->dmachan); - mtx_unlock(&Giant); mtx_lock(&fdc->fdc_mtx); fd->flags &=3D ~FD_ISADMA; mtx_unlock(&fdc->fdc_mtx); --LZvS9be/3tNcYl/X-- --gatW/ieO32f1wygP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpoZm4ACgkQLVEj6D3CBExhmgCffL74DHfSYRKmwzY254c1+wSY hmcAni9yjfOzPfu7fc+eNhMecrBnVTcL =SI4E -----END PGP SIGNATURE----- --gatW/ieO32f1wygP-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 13:56:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5B7D1065674 for ; Thu, 23 Jul 2009 13:56:05 +0000 (UTC) (envelope-from wtf.jlaine@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 5FE168FC18 for ; Thu, 23 Jul 2009 13:56:05 +0000 (UTC) (envelope-from wtf.jlaine@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1164863fgb.12 for ; Thu, 23 Jul 2009 06:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:subject :message-id:mime-version:content-type:content-disposition:user-agent :x-operating-system; bh=7jD2HZdB0SZgogge9fjGTds66zR4RCB9R4x1HIHEDww=; b=t0IQiBUhzWgNSuD4v34jee+AidJTCuBf11ohs1diwpLo/f43CXPog4szQv0tZkaQ7a izZWO76r1Ko8aQpUhGdepC1ZrIU68eMBBPAGrewdDiz4n3sO1j2vB0qxuntbFQIChpfq I6/OqT57YhOvmPMEwRVOWgZzFri+vSwhzCjGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent:x-operating-system; b=vNGXGrTIo/lEL2X7/lB3TyKCX5ILHM5AaIP7xCop12ZS51l3riUXHOGgZAVCVNprlw pbequ6Bj6B9rmbqncNLdTjBSba2pLw8uq/wFy2m9pBv33u2RHOV3WmeA/pbnBaafw8G6 TtPpy3U8BG/n38vaVtNZc1DMfLnyDnAqlKxFc= Received: by 10.86.59.2 with SMTP id h2mr1890132fga.60.1248355714644; Thu, 23 Jul 2009 06:28:34 -0700 (PDT) Received: from blackmesa ([77.66.145.99]) by mx.google.com with ESMTPS id 4sm4433684fgg.22.2009.07.23.06.28.33 (version=SSLv3 cipher=RC4-MD5); Thu, 23 Jul 2009 06:28:34 -0700 (PDT) Received: by blackmesa (sSMTP sendmail emulation); Thu, 23 Jul 2009 17:28:30 +0400 Date: Thu, 23 Jul 2009 17:28:30 +0400 From: Jeff Laine To: freebsd-current@freebsd.org Message-ID: <20090723132830.GA33539@free.bsd.loc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-BETA2 i386 Subject: ng_ipacct build error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:56:06 -0000 Hello list! I have upgraded to BETA2 recently and decided to recompile net-mgmt/ng_ipacct port (it was compiled in 7.2 so it's kernel module refused to load). But I stuck with this permanent stop error: 4:49pm [/ports/net-mgmt/ng_ipacct]# make ===> Vulnerability check disabled, database not found ===> Found saved configuration for ng_ipacct-20061223 ===> Extracting for ng_ipacct-20061223 => MD5 Checksum OK for ng_ipacct-20061223.tar.gz. => SHA256 Checksum OK for ng_ipacct-20061223.tar.gz. ===> Patching for ng_ipacct-20061223 ===> Applying FreeBSD patches for ng_ipacct-20061223 ===> Configuring for ng_ipacct-20061223 ===> Building for ng_ipacct-20061223 ===> ng_ipacct (all) Warning: Object directory not changed from original /tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct @ -> /usr/src/sys machine -> /usr/src/sys/i386/include :> opt_netgraph.h cc -O2 -pipe -DMEM_USE_ZONE -fno-strict-aliasing -g -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -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 ng_ipacct.c ld -d -warn-common -r -d -o ng_ipacct.kld ng_ipacct.o :> export_syms awk -f /sys/conf/kmod_syms.awk ng_ipacct.kld export_syms | xargs -J% objcopy % ng_ipacct.kld ld -Bshareable -d -warn-common -o ng_ipacct.ko ng_ipacct.kld objcopy --strip-debug ng_ipacct.ko ===> ipacctctl (all) Warning: Object directory not changed from original /tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ipacctctl cc -O2 -pipe -DMEM_USE_ZONE -fno-strict-aliasing -g -Wall -Wformat -std=gnu99 -fstack-protector -c ipacctctl.c ipacctctl.c:146: error: 'NG_PATHLEN' undeclared here (not in a function) ipacctctl.c: In function 'ip_account_get_info': ipacctctl.c:505: warning: unused variable 'path' ipacctctl.c: In function 'ip_account_show': ipacctctl.c:602: warning: unused variable 'path' *** Error code 1 Stop in /tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ipacctctl. *** Error code 1 Stop in /tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct. *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct. *** Error code 1 Stop in /usr/ports/net-mgmt/ng_ipacct. Should I contact the maintainer or am I 'doing it wrong'? :) TIA -- Best regards, Jeff | "Nobody wants to say how this works. | | Maybe nobody knows ..." | | Xorg.conf(5) | From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 14:36:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05CCA106564A for ; Thu, 23 Jul 2009 14:36:06 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from poseidon.ceid.upatras.gr (poseidon.ceid.upatras.gr [150.140.141.169]) by mx1.freebsd.org (Postfix) with ESMTP id 71BDE8FC20 for ; Thu, 23 Jul 2009 14:36:05 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mail.ceid.upatras.gr (unknown [10.1.0.143]) by poseidon.ceid.upatras.gr (Postfix) with ESMTP id 4FBE1EB4DD5; Thu, 23 Jul 2009 17:36:04 +0300 (EEST) Received: from localhost (europa.ceid.upatras.gr [127.0.0.1]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 427A94C800E; Thu, 23 Jul 2009 17:36:04 +0300 (EEST) X-Virus-Scanned: amavisd-new at ceid.upatras.gr Received: from mail.ceid.upatras.gr ([127.0.0.1]) by localhost (europa.ceid.upatras.gr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6VqLBkQPeBJ; Thu, 23 Jul 2009 17:36:04 +0300 (EEST) Received: from kobe.laptop (adsl129-11.kln.forthnet.gr [77.49.248.11]) by mail.ceid.upatras.gr (Postfix) with ESMTP id 0E1D94C800D; Thu, 23 Jul 2009 17:36:04 +0300 (EEST) Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n6NEa2I1044714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2009 17:36:03 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n6NEa1Ia044713; Thu, 23 Jul 2009 17:36:01 +0300 (EEST) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Sam Leffler References: <87eis8g3b9.fsf@kobe.laptop> <4A67AF05.7060504@errno.com> Date: Thu, 23 Jul 2009 17:36:01 +0300 In-Reply-To: <4A67AF05.7060504@errno.com> (Sam Leffler's message of "Wed, 22 Jul 2009 17:29:57 -0700") Message-ID: <87hbx3zctq.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: lagg0 and tcpdump problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 14:36:06 -0000 On Wed, 22 Jul 2009 17:29:57 -0700, Sam Leffler wrote: > Giorgos Keramidas wrote: >> When I run tcpdump on lagg0 (with em0 and iwn0 as laggports), tcpdump >> seems to work fine, but typing ^C kills the wireless interface too. > > This is a known issue; bpf is holding a mutex over calls to the driver > that may block (in this case the taskqueue_drain calls in > net80211). It's unlikely to be resolved for 8.0 (too risky). Ok, it's good to know it is a known issue :) >> Then typing ^C stops tcpdump but the log shows: >> >> Jul 22 17:59:29 kobe kernel: wlan0: promiscuous mode disabled >> Jul 22 17:59:29 kobe kernel: em0: promiscuous mode disabled >> Jul 22 17:59:29 kobe kernel: iwn0: error, INTR=82000000 STATUS=0x40010000 >> Jul 22 17:59:29 kobe kernel: lagg0: promiscuous mode disabled >> Jul 22 17:59:30 kobe kernel: iwn0: iwn_transfer_firmware: timeout waiting for first alive notice, error 35 >> Jul 22 17:59:30 kobe kernel: iwn0: iwn_init_locked: could not load firmware, error 35 >> Jul 22 17:59:30 kobe kernel: wlan0: link state changed to DOWN >> Jul 22 17:59:30 kobe kernel: lagg0: link state changed to DOWN >> >> At this point wlan0 is without carrier, and stays that way until I >> unplumb wlan0 and lagg0 and re-create them. > Sounds like iwn isn't reacting well to the calls coming in from > lagg. wlandebug state should provide some insight. I've used > lagg+iwn+em on a t61p with no obvious issues but never tried to run > tcpdump on the lagg port. It's a Lenovo Thinkpad X61s I'm using for this, so I'll gather some wlandebug output and post more details. I think it's probably a problem with iwn because the other interface (em0) seems to be handling tcpdump runs better. From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 15:11:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2BF6E1065670 for ; Thu, 23 Jul 2009 15:11:57 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outa.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id 10BA08FC14 for ; Thu, 23 Jul 2009 15:11:56 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 980FBB9857; Thu, 23 Jul 2009 08:12:13 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 49C1A2D6014; Thu, 23 Jul 2009 08:11:56 -0700 (PDT) Message-ID: <4A687DBE.5060200@elischer.org> Date: Thu, 23 Jul 2009 08:11:58 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Jeff Laine , "M. Warner Losh" , FreeBSD Current References: <20090723132830.GA33539@free.bsd.loc> In-Reply-To: <20090723132830.GA33539@free.bsd.loc> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: ng_ipacct build error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 15:11:57 -0000 Jeff Laine wrote: > Hello list! > > I have upgraded to BETA2 recently and decided to recompile net-mgmt/ng_ipacct port > (it was compiled in 7.2 so it's kernel module refused to load). > > But I stuck with this permanent stop error: > > > 4:49pm [/ports/net-mgmt/ng_ipacct]# make > ===> Vulnerability check disabled, database not found > ===> Found saved configuration for ng_ipacct-20061223 > ===> Extracting for ng_ipacct-20061223 > => MD5 Checksum OK for ng_ipacct-20061223.tar.gz. > => SHA256 Checksum OK for ng_ipacct-20061223.tar.gz. > ===> Patching for ng_ipacct-20061223 > ===> Applying FreeBSD patches for ng_ipacct-20061223 > ===> Configuring for ng_ipacct-20061223 > ===> Building for ng_ipacct-20061223 > ===> ng_ipacct (all) > Warning: Object directory not changed from original /tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct > @ -> /usr/src/sys > machine -> /usr/src/sys/i386/include > :> opt_netgraph.h > cc -O2 -pipe -DMEM_USE_ZONE -fno-strict-aliasing -g -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I/tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -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 ng_ipacct.c > ld -d -warn-common -r -d -o ng_ipacct.kld ng_ipacct.o > :> export_syms > awk -f /sys/conf/kmod_syms.awk ng_ipacct.kld export_syms | xargs -J% objcopy % ng_ipacct.kld > ld -Bshareable -d -warn-common -o ng_ipacct.ko ng_ipacct.kld > objcopy --strip-debug ng_ipacct.ko > ===> ipacctctl (all) > Warning: Object directory not changed from original /tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ipacctctl > cc -O2 -pipe -DMEM_USE_ZONE -fno-strict-aliasing -g -Wall -Wformat -std=gnu99 -fstack-protector -c ipacctctl.c > ipacctctl.c:146: error: 'NG_PATHLEN' undeclared here (not in a function) > ipacctctl.c: In function 'ip_account_get_info': > ipacctctl.c:505: warning: unused variable 'path' > ipacctctl.c: In function 'ip_account_show': > ipacctctl.c:602: warning: unused variable 'path' > *** Error code 1 > > Stop in /tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ipacctctl. > *** Error code 1 > > Stop in /tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct. > *** Error code 1 > > Stop in /usr/ports/net-mgmt/ng_ipacct. > *** Error code 1 > > Stop in /usr/ports/net-mgmt/ng_ipacct. > > > > > Should I contact the maintainer or am I 'doing it wrong'? :) > > > TIA > > #ifndef BURN_BRIDGES /* don't use these - they will go away */ #define NG_TYPELEN (NG_TYPESIZ - 1) #define NG_HOOKLEN (NG_HOOKSIZ - 1) #define NG_NODELEN (NG_NODESIZ - 1) #define NG_PATHLEN (NG_PATHSIZ - 1) #define NG_CMDSTRLEN (NG_CMDSTRSIZ - 1) #endif they went away use NG_PATHSIZ (or NG_PATHSIZ-1 depending on what you ar edoing wih it). From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 15:22:28 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F086106566B for ; Thu, 23 Jul 2009 15:22:28 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id B10BA8FC13 for ; Thu, 23 Jul 2009 15:22:27 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:Reply-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=DQo7q0D0Hhfi0+4kQVbCyawPvGIw6mYjZiKUocD4lhDoQJErL4WhNlWL4amXNnpR7VrCwpcODnLfzlkgeG+uez5oFRkPYbWr8+dLLlexUHPFSlsYfhscoAuGu7JDoKCGaV4DWNjJUjGiJm+VP2qXt8gOkILsgf+4Nb6QBeebUyU=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1MU07m-000PxV-K1; Thu, 23 Jul 2009 19:22:26 +0400 Date: Thu, 23 Jul 2009 19:22:24 +0400 From: Eygene Ryabinkin To: Alexander Best Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: freebsd-current@FreeBSD.org Subject: Re: possible bug in sbin/fsck_msdosfs/boot.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rea-fbsd@codelabs.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 15:22:28 -0000 Alexander, good day. Thu, Jul 23, 2009 at 12:29:23PM +0200, Alexander Best wrote: > i just tried to do fsck_msdosfs on my mobile phone's memory card using a usb > connection cable. this is what `file -s` has to say about /dev/da0: > > /dev/da0: x86 boot sector, code offset 0x0, OEM-ID " ", sectors/cluster > 64, reserved sectors 6304, Media descriptor 0xf8, heads 128, hidden sectors > 8192, sectors 7736320 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 944, > reserved3 0x800000, serial number 0x34613466, label: "mem " > > however after issuing the command `fsck_msdosfs /dev/da0` i got the following > error: > > fsck_msdosfs /dev/da0 > ** /dev/da0 > backup doesn't compare to primary bootblock > > i did a bit of research and it seems this bug was supposed to be fixed by > r128463. the problem was that the entire bootblock was compared to the > backupblock. but since only the first 52 bytes of the bootblock are important > many device use the rest of the bootblock for some other purpose. the > following change was made to sbin/fsck_msdosfs/boot.c: > > -- if (memcmp(block, backup, DOSBOOTBLOCKSIZE)) { > ++ if (memcmp(block + 11, backup + 11, 79)) { > > it seems however that the last memcmp argument is still too high. could > somebody with good fat12/16/32 knowledge please look into this? 79 looks sane for the FAT32, see http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html For FAT16/FAT12 the size should be 51. Actually, what is now compared is the BIOS parameter block. I'll take a look at the FS forensics book: my memory blocks with FAT remniscents are a bit rusty ;)) -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 16:02:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B2BE1065678 for ; Thu, 23 Jul 2009 16:02:31 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id B7FB48FC14 for ; Thu, 23 Jul 2009 16:02:30 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from [192.168.0.154] (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.3/8.14.3) with ESMTP id n6NG2KIt086068; Thu, 23 Jul 2009 17:02:20 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4A68898C.8070701@fletchermoorland.co.uk> Date: Thu, 23 Jul 2009 17:02:20 +0100 From: Paul Wootton User-Agent: Thunderbird 2.0.0.21 (X11/20090504) MIME-Version: 1.0 To: hartzell@alerce.com References: <19047.52443.164412.363239@already.local> <1E3C4A20-1B89-4C8C-912E-3CA99A427452@lassitu.de> In-Reply-To: <1E3C4A20-1B89-4C8C-912E-3CA99A427452@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.64 on 192.168.0.1 X-Spam-Status: No, score=-4.4 required=10.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hydra.fletchermoorland.co.uk Cc: freebsd-current@freebsd.org, Stefan Bethke Subject: Re: gptzfsboot doesn't like change (failure after swapping drives) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 16:02:31 -0000 Stefan Bethke wrote: > Am 23.07.2009 um 04:37 schrieb George Hartzell: > >> I've been playing around with building an 8.0BETA2 system with >> everything on a single zfs filesystem (I'll get fancier later) on a >> zpool that is a 4 disk raidz. > > Quite a few people had no luck with booting from RAIDZ volumes at > all. (Single disks and mirrors seem to work fine.) See this thread: > http://lists.freebsd.org/pipermail/freebsd-fs/2009-July/006466.html > > > Stefan > I've been trying on and off for a few months now to get a raidz pack to boot and a few days ago finally got a working setup. I have a 3 disk raidz pack. I've only set zfs_load="YES" in /boot/loader.conf. All the mountpoints are set to none and I am using /etc/fstab instead. I have the root of the working filing system as a zfs volume, and not in the base of the pool zboot 7.31G 201G 18K none (this never gets mounted) zboot/root 65.4M 201G 65.4M none (this gets mounted as /) zboot/tmp 27K 201G 27K none (this gets mounted as /tmp) zboot/usr 7.21G 201G 7.21G none (this gets mounted as /usr) zboot/var 35.4M 201G 35.4M none (this gets mounted as /var) Paul ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 17:35:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6150B106568B for ; Thu, 23 Jul 2009 17:35:20 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from mail.chrishedley.com (77-44-98-139.xdsl.murphx.net [77.44.98.139]) by mx1.freebsd.org (Postfix) with ESMTP id 0414D8FC1C for ; Thu, 23 Jul 2009 17:35:19 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from localhost (localhost [127.0.0.1]) by mail.chrishedley.com (Postfix) with ESMTP id B95186D166; Thu, 23 Jul 2009 18:35:12 +0100 (BST) X-Virus-Scanned: amavisd-new at chrishedley.com Received: from mail.chrishedley.com ([127.0.0.1]) by localhost (mail.chrishedley.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pYJ6cZrXfEi1; Thu, 23 Jul 2009 18:35:07 +0100 (BST) Received: from teapot.cbhnet (teapot.cbhnet [192.168.1.1]) by mail.chrishedley.com (Postfix) with ESMTP id 623DC6D14A; Thu, 23 Jul 2009 18:35:07 +0100 (BST) Date: Thu, 23 Jul 2009 18:35:07 +0100 (BST) From: Chris Hedley X-X-Sender: cbh@teapot.cbhnet To: Daniel Nebdal In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2180312168-1628859323-1248370221=:3132" Content-ID: Cc: freebsd-current@freebsd.org Subject: Re: Linux NFS ate my bge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:35:21 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2180312168-1628859323-1248370221=:3132 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-15; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Thu, 23 Jul 2009, Daniel Nebdal wrote: > Looking at my local webshop, an intel pro1000/GT is about $65. Not the > very cheapest, but the other intel gbit cards I've used have been very > good, and em(4) is a well-supported driver. Thanks for the suggestion; it'll be nice to know I'm using a good, stable driver (no disrespect to the bge folks, of course, as I understand that the documentation provided was a bit lacking). I've managed to find one for £20, which is hopefully the correct one: it's a "BLK" designation but its hardware specs look identical. Of course I should be looking at a new motherboard at some point to replace this rather elderly thing, especially as my SATA controllers are equally flaky, but that's a subject for a new thread! And now to follow Matthew's recommendation to use TCP connections for my NFS... Cheers! --2180312168-1628859323-1248370221=:3132-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 16:40:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBA9B106566B for ; Thu, 23 Jul 2009 16:40:36 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id B2B4D8FC17 for ; Thu, 23 Jul 2009 16:40:36 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 7179733C6C; Thu, 23 Jul 2009 09:40:36 -0700 (PDT) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 2F75C33C64; Thu, 23 Jul 2009 09:40:36 -0700 (PDT) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19048.37509.297550.851269@already.local> Date: Thu, 23 Jul 2009 09:40:37 -0700 To: Paul Wootton In-Reply-To: <4A68898C.8070701@fletchermoorland.co.uk> References: <19047.52443.164412.363239@already.local> <1E3C4A20-1B89-4C8C-912E-3CA99A427452@lassitu.de> <4A68898C.8070701@fletchermoorland.co.uk> X-Mailer: VM 8.0.12 under 22.3.1 (i386-apple-darwin9.6.0) X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 23 Jul 2009 17:37:11 +0000 Cc: freebsd-current@freebsd.org, hartzell@alerce.com, Stefan Bethke Subject: Re: gptzfsboot doesn't like change (failure after swapping drives) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 16:40:37 -0000 Paul Wootton writes: > Stefan Bethke wrote: > > Am 23.07.2009 um 04:37 schrieb George Hartzell: > > > >> I've been playing around with building an 8.0BETA2 system with > >> everything on a single zfs filesystem (I'll get fancier later) on a > >> zpool that is a 4 disk raidz. > > > > Quite a few people had no luck with booting from RAIDZ volumes at > > all. (Single disks and mirrors seem to work fine.) See this thread: > > http://lists.freebsd.org/pipermail/freebsd-fs/2009-July/006466.html > > > > > > Stefan > > > I've been trying on and off for a few months now to get a raidz pack to > boot and a few days ago finally got a working setup. > > I have a 3 disk raidz pack. I've only set zfs_load="YES" in > /boot/loader.conf. All the mountpoints are set to none and I am using > /etc/fstab instead. I have the root of the working filing system as a > zfs volume, and not in the base of the pool > > zboot 7.31G 201G 18K none (this never gets mounted) > zboot/root 65.4M 201G 65.4M none (this gets mounted as /) > zboot/tmp 27K 201G 27K none (this gets mounted as /tmp) > zboot/usr 7.21G 201G 7.21G none (this gets mounted as /usr) > zboot/var 35.4M 201G 35.4M none (this gets mounted as /var) If you don't have any important data on it, and don't mind having to recreate it, it'd be interesting to try to boot it with one drive pulled. I'll bet that you can't, even though you'll be able to see the pool if you boot from some fixit media. I'll also bet that you still won't be able to boot once you reinsert the drive. g. From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 17:39:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A415B10656CA for ; Thu, 23 Jul 2009 17:39:16 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from mail.chrishedley.com (77-44-98-139.xdsl.murphx.net [77.44.98.139]) by mx1.freebsd.org (Postfix) with ESMTP id 4CFBE8FC20 for ; Thu, 23 Jul 2009 17:39:16 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from localhost (localhost [127.0.0.1]) by mail.chrishedley.com (Postfix) with ESMTP id 4ACB36D1F5 for ; Thu, 23 Jul 2009 18:39:10 +0100 (BST) X-Virus-Scanned: amavisd-new at chrishedley.com Received: from mail.chrishedley.com ([127.0.0.1]) by localhost (mail.chrishedley.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FOXLKy+pKKLy for ; Thu, 23 Jul 2009 18:39:01 +0100 (BST) Received: from teapot.cbhnet (teapot.cbhnet [192.168.1.1]) by mail.chrishedley.com (Postfix) with ESMTP id 916F66D1CA for ; Thu, 23 Jul 2009 18:39:01 +0100 (BST) Date: Thu, 23 Jul 2009 18:39:01 +0100 (BST) From: Chris Hedley X-X-Sender: cbh@teapot.cbhnet To: freebsd-current@freebsd.org In-Reply-To: <1E3C4A20-1B89-4C8C-912E-3CA99A427452@lassitu.de> Message-ID: References: <19047.52443.164412.363239@already.local> <1E3C4A20-1B89-4C8C-912E-3CA99A427452@lassitu.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: gptzfsboot doesn't like change (failure after swapping drives) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:39:17 -0000 On Thu, 23 Jul 2009, Stefan Bethke wrote: > Am 23.07.2009 um 04:37 schrieb George Hartzell: > >> I've been playing around with building an 8.0BETA2 system with >> everything on a single zfs filesystem (I'll get fancier later) on a >> zpool that is a 4 disk raidz. > > Quite a few people had no luck with booting from RAIDZ volumes at all. > (Single disks and mirrors seem to work fine.) See this thread: > http://lists.freebsd.org/pipermail/freebsd-fs/2009-July/006466.html I'm tempted to set up a second ZFS pool for booting since my main one is RAIDZ2, which it currently unsupported; this is with some trepidation as I read ages back that there may be "issues" with multiple pools (though that may be in the past, whatever it was) but it'll be interesting to find out. Then again, "if it ain't broke, don't fix it": maybe I should just stick with the regular boot system using my gmirrored UFS partition... Chris. From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 17:52:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 70679106564A for ; Thu, 23 Jul 2009 17:52:26 +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 430AE8FC12 for ; Thu, 23 Jul 2009 17:52:26 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id F1AF246B91; Thu, 23 Jul 2009 13:52:25 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2A0C78A0A3; Thu, 23 Jul 2009 13:52:25 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Thu, 23 Jul 2009 13:21:10 -0400 User-Agent: KMail/1.9.7 References: <20090722171741.GB17684@hyperion.scode.org> In-Reply-To: <20090722171741.GB17684@hyperion.scode.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907231321.10866.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 23 Jul 2009 13:52:25 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Peter Schuller Subject: Re: vm_page_remove() crash on sys_exit() (possibly ZFS related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:52:26 -0000 On Wednesday 22 July 2009 1:17:41 pm Peter Schuller wrote: > Hello, > > so I finally got my crash dump. I'll include some more history further > down. First off: > > http://distfiles.scode.org/mlref/crashdump_20090722/core.txt.0 > http://distfiles.scode.org/mlref/crashdump_20090722/backtrace.txt > > Inline version of backtrace appears below[1] (after background). I would check your RAM. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 17:56:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79DC2106584F; Thu, 23 Jul 2009 17:56:23 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id F046F8FC18; Thu, 23 Jul 2009 17:56:22 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (hyperion.scode.org [85.17.42.115]) by hyperion.scode.org (Postfix) with ESMTPS id 3D1EA23C472; Thu, 23 Jul 2009 19:56:22 +0200 (CEST) Date: Thu, 23 Jul 2009 19:56:21 +0200 From: Peter Schuller To: John Baldwin Message-ID: <20090723175620.GA63961@hyperion.scode.org> References: <20090722171741.GB17684@hyperion.scode.org> <200907231321.10866.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline In-Reply-To: <200907231321.10866.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: vm_page_remove() crash on sys_exit() (possibly ZFS related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 17:56:24 -0000 --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > http://distfiles.scode.org/mlref/crashdump_20090722/core.txt.0 > > http://distfiles.scode.org/mlref/crashdump_20090722/backtrace.txt > >=20 > > Inline version of backtrace appears below[1] (after background). >=20 > I would check your RAM. Broken RAM would be good news :) I'll run some memtests and see if I can trigger anything, though it would be somewhat of a co-incidence. Thanks, --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpopEQACgkQDNor2+l1i329ggCgzD/1TKxtqsZhfmD6AMOlDYxk UFoAn3P5UtcKJ82FuyLRtlZXJSCAkFcl =afdy -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 18:40:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1602A106564A for ; Thu, 23 Jul 2009 18:40:44 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id D69248FC26 for ; Thu, 23 Jul 2009 18:40:43 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so357372rvb.43 for ; Thu, 23 Jul 2009 11:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:date:from:to :subject:message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=XdZR4xvIqRRp2ubgOfxGCxpc0rs0Z/+lWXaFRb3AMhQ=; b=JAaDDivg0S9kSD19grtgG3518udZHginyS0W7L6zNqMl5PYhMLsIAAv7ar5MWXiRrt DRaSd1gIg8KtdCyZwkM14sUlbNLcHxABtsQCJ4umO7e5Ni7FJxr4JyLwUpf5PCZIaCGe qdmyhTiAF8Eq9lUumGh9O9Hyi7tvTGisgEeK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:subject:message-id:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; b=rtVglo4dNnjS+DBxMEgw3o10EzB3twR8bY6vRG/+KiRbsz7Idi7rYssXF/EoKDtSjZ /Zp1Hf//1LeK8+Cll7HNmJ61ckaoojqB3tHDTsST54XMy6MZbJnA8WZ6XyrbUUh09DNs YIWtgEvfE3OR9tJt7BRj6MIcx/KT5+sjIAd2o= Received: by 10.140.208.16 with SMTP id f16mr1754187rvg.151.1248374443441; Thu, 23 Jul 2009 11:40:43 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.108.65]) by mx.google.com with ESMTPS id g22sm680811rvb.23.2009.07.23.11.40.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 23 Jul 2009 11:40:42 -0700 (PDT) Sender: Nenhum_de_Nos Received: from arroway (arroway.apartnet [10.1.1.80]) by cygnus.homeunix.com (Postfix) with SMTP id 73CFDB8084 for ; Thu, 23 Jul 2009 15:40:38 -0300 (BRT) Date: Thu, 23 Jul 2009 15:41:05 -0300 From: Nenhum_de_Nos To: freebsd-current@freebsd.org Message-Id: <20090723154105.1e6da1d7.matheus@eternamente.info> In-Reply-To: <1248270943.9978.6.camel@polaris> References: <1248270943.9978.6.camel@polaris> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.9; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: thanks for usb install image X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:40:44 -0000 On Wed, 22 Jul 2009 15:55:43 +0200 Marten Vijn wrote: > > ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/8.0/8.0-BETA2-i386-memstick.img > > work great, > > thanks Marten I love this feature !! quick and simple ! :) matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 18:50:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B702A106566B; Thu, 23 Jul 2009 18:50:24 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 45AD98FC12; Thu, 23 Jul 2009 18:50:24 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yxe11 with SMTP id 11so1927210yxe.3 for ; Thu, 23 Jul 2009 11:50:23 -0700 (PDT) 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 :content-transfer-encoding; bh=512FG/SiaW+ajoe+CMHToMbXkLMaCgXMIUz8Wra03vs=; b=E8oa2z+k42lMLm9eLNi99LksH02CBD1X9nRbEgWjiWpLJB4EnBDgrW29LJ6qvVcEcm K6c/r9sjMHCnPg08jg92wV6UUeRyEfQrwwAkC/+y6urnTp/Q1gaE2S7RHVUWxZ8/HDaQ oXFoUoDj9VPZT45NOPlgEHwUag3juPss0KMzE= 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:content-transfer-encoding; b=AB946FiIOrTTkUZOitJjojKI5OaxRRlcF8WXrXQiNsjx/Kaa1nN5VUVP/x+nt6TDRj eC/iafdujwKtzGCHsC3gz63bsJM6uo2AcuvrPjL1gpUuX1xFZTHmzQqGg3jbxKjf/vf1 J1LW/XNxamckmGrprKE3IgA1YHtQres4gB1eA= MIME-Version: 1.0 Received: by 10.150.189.20 with SMTP id m20mr3623384ybf.255.1248373388472; Thu, 23 Jul 2009 11:23:08 -0700 (PDT) In-Reply-To: <200907211420.33571.hselasky@c2i.net> References: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> <200907152236.58049.hselasky@c2i.net> <20090720215141.GL49724@elvis.mu.org> <200907211420.33571.hselasky@c2i.net> Date: Thu, 23 Jul 2009 11:23:08 -0700 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@freebsd.org, Alfred Perlstein , Andrew Thompson , freebsd-current@freebsd.org Subject: Re: USB polling (75% done) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 18:50:25 -0000 On Tue, Jul 21, 2009 at 5:20 AM, Hans Petter Selasky wrote: > On Monday 20 July 2009 23:51:41 Alfred Perlstein wrote: >> * Hans Petter Selasky [090715 13:37] wrote: >> > Hi, >> > >> > I've added minimal polling support to the USB P4 repository now. Patch >> > can be found here: >> > >> > http://perforce.freebsd.org/chv.cgi?CH=166148 >> > >> > Dumping core to USB disk: Tested and works. >> > >> > Using USB keyboard in KDB: Does not work because Giant is not locked when >> > calling into the UKBD's get char routine. UKBD is Giant locked. Someone >> > familiar with the keyboard system on FreeBSD please step forward and fix >> > this so that UKBD gets independent of the Giant mutex. >> >> the ukbd driver needs giant? > > I think the keyboard mux is under Giant, and does not have any concept about > mutexes. Most simple solution would be that DDB locks Giant before entering > into the keyboard code. as i understand it, keyboard drivers (and kbdmux(4) is a keyboard driver), can/should not use any locks. period. so whatever calls into keyboard driver should take care of locking. thanks, max From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 19:32:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 473DA1065674 for ; Thu, 23 Jul 2009 19:32:53 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id D22438FC1B for ; Thu, 23 Jul 2009 19:32:52 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=ygtw2-J_-OoA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=-F-tvJxw6Z9NwhR1-oEA:9 a=_OM2YagmvldsFSE7pIMA:7 a=EVVE9EFEDUf0EDzvVl24YcTFatEA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 229378713 for current@freebsd.org; Thu, 23 Jul 2009 21:32:51 +0200 From: Hans Petter Selasky To: current@freebsd.org Date: Thu, 23 Jul 2009 21:32:39 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <200907232109.04094.hselasky@c2i.net> In-Reply-To: <200907232109.04094.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907232132.41400.hselasky@c2i.net> Cc: Subject: Re: 8-current + USB CD-ROM drive + CAM layer audio extraction from CD (regression) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 19:32:53 -0000 On Thursday 23 July 2009 21:09:02 Hans Petter Selasky wrote: > Hi, > > I have a CD I want to extract audio from, giving me trouble this time. > Plugging the USB CD-ROM into a MAC allows for instant audio playback. I'm > pretty sure that digital audio extraction works. The USB CD-ROM drive is > made by Samsung. The CD is made by forefront/EMI. > > At first I thought that this is another example of record labels making > deals with hardware manufacturers, but I'm leaving a chance it might be a > bug in the CAM layer. > This is an regression issue introduced during the last month. I tested more CD's and none can be played back via digital audio extraction :-( With an older 8-current kernel it works. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 19:45:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6147F1065673 for ; Thu, 23 Jul 2009 19:45:57 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 1FBEB8FC18 for ; Thu, 23 Jul 2009 19:45:56 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 249582825; Thu, 23 Jul 2009 22:45:53 +0300 Message-ID: <4A68BDD7.60408@FreeBSD.org> Date: Thu, 23 Jul 2009 22:45:27 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Yoshihiro Ota References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> <49A04510.5030405@FreeBSD.org> <7d6fde3d0902211356h66b05cfcxf2ebbe9b2a6fd0f0@mail.gmail.com> <20090224004110.e4ad76f4.ota@j.email.ne.jp> <49A45127.3000108@FreeBSD.org> <20090225211656.75c546c3.ota@j.email.ne.jp> <49A6F609.20901@FreeBSD.org> <20090226223106.b56ad289.ota@j.email.ne.jp> <49A7D1C2.6070608@FreeBSD.org> <20090228015207.d7432c0a.ota@j.email.ne.jp> <20090723153734.e1a8bff1.ota@j.email.ne.jp> In-Reply-To: <20090723153734.e1a8bff1.ota@j.email.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 19:45:58 -0000 Yoshihiro Ota wrote: > This problem was gone once back in Febrary. > > I was away from 8-current and came back to 8-BETA1/2. > Then, now I hear this noise again. > > Alexander, do you have any ideas for this time, too? Can you remind me what are you talking about? You are talking about some noise, but following messages about detection problems. > On Sat, 28 Feb 2009 01:52:07 -0500 > Yoshihiro Ota wrote: > >> On Fri, 27 Feb 2009 13:42:58 +0200 >> Alexander Motin wrote: >> >>> Yoshihiro Ota wrote: >>>> On Thu, 26 Feb 2009 22:05:29 +0200 >>>> Alexander Motin wrote: >>>> >>>>> Yoshihiro Ota wrote: >>>>>> On Tue, 24 Feb 2009 21:57:27 +0200 >>>>>> Alexander Motin wrote: >>>>>>> Yoshihiro Ota wrote: >>>>>>>> In my case, with hdac or pcm device, 8-CURRENT fails to boot very requentry. >>>>>>>> It fails to prove a device and doesn't proceed farthar than that point. >>>>>>>> Now it only boots once in 5 or 10 reboots. >>>>>>>> >>>>>>>> When it boots, it prints lots of following messages. >>>>>>>> >>>>>>>> hdac0: HDA Codec #0: Conexant CX20549 (Venice) >>>>>>>> hdac0: unable to allocate widgets! >>>>>>>> hdac0: unable to allocate widgets! >>>>>>>> hdac0: unable to allocate widgets! >>>>>>>> hdac0: unable to allocate widgets! >>>>>>>> hdac0: unable to allocate widgets! >>>>>>>> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 >>>>>>>> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 >>>>>>>> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 >>>>>>>> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 >>>>>>>> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 >>>>>>>> >>>>>>>> I think this started happening about a week ago or so, sometime between >>>>>>>> 13 and 16th. >>>>>>> The only significant change last time was enabling MSI by default. But I >>>>>>> don't think it should lead to such errors. I have tried even operation >>>>>>> completely without interrupts working and there is not such errors. Can >>>>>>> you send me complete verbose dmesg with the problem and `pciconf -lvc` >>>>>>> output? >>>>>>> >>>>>>> Also you may try to disable MSI by setting 'hint.hdac.0.msi=0' hint. >>>>>> Once I disabled snd_hda_load="YES" in /boot/loader.conf, it comes up >>>>>> all times. However, when I run "kldload snd_hda", the system stops responding, >>>>>> i.e. crashes. >>>>>> >>>>>> So, now I added 'hint.hdac.0.msi="0"' in the hint; then, system comes up fine. >>>>>> I tried "kldload snd_hda" and got the following output. >>>>>> System didn't crash after adding the hint so that I added snd_hda_load="YES" >>>>>> back to /boot/loader.conf. >>>>> I have committed a patch to the CURRENT that should disable MSI for your >>>>> HDA controller by default. Test it please. >>>> That's r189086, isn't it? >>>> >>>> So, for testing, I will remove hint.hdac.0.msi and add 'snd_hda_load="YES"' back. >>>> Does that sound valid test? >>> Yes. 'snd_hda_load="YES"' is on your wish. >> System comes up without problems now. >> >> Thanks, >> Hiro -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 19:58:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F3B7106566C for ; Thu, 23 Jul 2009 19:58:16 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 40A9D8FC0C for ; Thu, 23 Jul 2009 19:58:16 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from pavillion-dv6425us.advok.com (pool-70-110-182-250.phil.east.verizon.net [70.110.182.250]) by mail1.asahi-net.or.jp (Postfix) with ESMTP id CDA8E7651F; Fri, 24 Jul 2009 04:37:29 +0900 (JST) Date: Thu, 23 Jul 2009 15:37:34 -0400 From: Yoshihiro Ota To: FreeBSD Current Message-Id: <20090723153734.e1a8bff1.ota@j.email.ne.jp> In-Reply-To: <20090228015207.d7432c0a.ota@j.email.ne.jp> References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> <49A04510.5030405@FreeBSD.org> <7d6fde3d0902211356h66b05cfcxf2ebbe9b2a6fd0f0@mail.gmail.com> <20090224004110.e4ad76f4.ota@j.email.ne.jp> <49A45127.3000108@FreeBSD.org> <20090225211656.75c546c3.ota@j.email.ne.jp> <49A6F609.20901@FreeBSD.org> <20090226223106.b56ad289.ota@j.email.ne.jp> <49A7D1C2.6070608@FreeBSD.org> <20090228015207.d7432c0a.ota@j.email.ne.jp> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Alexander Motin Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 19:58:16 -0000 Hi. This problem was gone once back in Febrary. I was away from 8-current and came back to 8-BETA1/2. Then, now I hear this noise again. Alexander, do you have any ideas for this time, too? Thanks, Hiro On Sat, 28 Feb 2009 01:52:07 -0500 Yoshihiro Ota wrote: > On Fri, 27 Feb 2009 13:42:58 +0200 > Alexander Motin wrote: > > > Yoshihiro Ota wrote: > > > On Thu, 26 Feb 2009 22:05:29 +0200 > > > Alexander Motin wrote: > > > > > >> Yoshihiro Ota wrote: > > >>> On Tue, 24 Feb 2009 21:57:27 +0200 > > >>> Alexander Motin wrote: > > >>>> Yoshihiro Ota wrote: > > >>>>> In my case, with hdac or pcm device, 8-CURRENT fails to boot very requentry. > > >>>>> It fails to prove a device and doesn't proceed farthar than that point. > > >>>>> Now it only boots once in 5 or 10 reboots. > > >>>>> > > >>>>> When it boots, it prints lots of following messages. > > >>>>> > > >>>>> hdac0: HDA Codec #0: Conexant CX20549 (Venice) > > >>>>> hdac0: unable to allocate widgets! > > >>>>> hdac0: unable to allocate widgets! > > >>>>> hdac0: unable to allocate widgets! > > >>>>> hdac0: unable to allocate widgets! > > >>>>> hdac0: unable to allocate widgets! > > >>>>> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 > > >>>>> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 > > >>>>> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 > > >>>>> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 > > >>>>> hdac0: hdac_command_send_internal: TIMEOUT numcmd=1, sent=1, received=0 > > >>>>> > > >>>>> I think this started happening about a week ago or so, sometime between > > >>>>> 13 and 16th. > > >>>> The only significant change last time was enabling MSI by default. But I > > >>>> don't think it should lead to such errors. I have tried even operation > > >>>> completely without interrupts working and there is not such errors. Can > > >>>> you send me complete verbose dmesg with the problem and `pciconf -lvc` > > >>>> output? > > >>>> > > >>>> Also you may try to disable MSI by setting 'hint.hdac.0.msi=0' hint. > > >>> Once I disabled snd_hda_load="YES" in /boot/loader.conf, it comes up > > >>> all times. However, when I run "kldload snd_hda", the system stops responding, > > >>> i.e. crashes. > > >>> > > >>> So, now I added 'hint.hdac.0.msi="0"' in the hint; then, system comes up fine. > > >>> I tried "kldload snd_hda" and got the following output. > > >>> System didn't crash after adding the hint so that I added snd_hda_load="YES" > > >>> back to /boot/loader.conf. > > >> I have committed a patch to the CURRENT that should disable MSI for your > > >> HDA controller by default. Test it please. > > > > > > That's r189086, isn't it? > > > > > > So, for testing, I will remove hint.hdac.0.msi and add 'snd_hda_load="YES"' back. > > > Does that sound valid test? > > > > Yes. 'snd_hda_load="YES"' is on your wish. > > System comes up without problems now. > > Thanks, > Hiro From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 20:00:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF67D1065670 for ; Thu, 23 Jul 2009 20:00:34 +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 80A918FC22 for ; Thu, 23 Jul 2009 20:00:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2CAE846B94; Thu, 23 Jul 2009 16:00:34 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id EAF4C8A0A2; Thu, 23 Jul 2009 16:00:32 -0400 (EDT) From: John Baldwin To: Peter Schuller Date: Thu, 23 Jul 2009 15:34:03 -0400 User-Agent: KMail/1.9.7 References: <20090722171741.GB17684@hyperion.scode.org> <200907231321.10866.jhb@freebsd.org> <20090723175620.GA63961@hyperion.scode.org> In-Reply-To: <20090723175620.GA63961@hyperion.scode.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907231534.03971.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 23 Jul 2009 16:00:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: vm_page_remove() crash on sys_exit() (possibly ZFS related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 20:00:34 -0000 On Thursday 23 July 2009 1:56:21 pm Peter Schuller wrote: > > > http://distfiles.scode.org/mlref/crashdump_20090722/core.txt.0 > > > http://distfiles.scode.org/mlref/crashdump_20090722/backtrace.txt > > > > > > Inline version of backtrace appears below[1] (after background). > > > > I would check your RAM. > > Broken RAM would be good news :) I'll run some memtests and see if I > can trigger anything, though it would be somewhat of a co-incidence. I have seen many similar (although not quite identical) panics caused by bad RAM in the past which is why I suggested it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 21:24:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A316106566B; Thu, 23 Jul 2009 21:24:21 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 5F37C8FC19; Thu, 23 Jul 2009 21:24:21 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-70-110-182-250.phil.east.verizon.net [70.110.182.250]) by mail2.asahi-net.or.jp (Postfix) with ESMTP id 768CF77F51; Fri, 24 Jul 2009 06:24:19 +0900 (JST) Date: Thu, 23 Jul 2009 17:24:23 -0400 From: Yoshihiro Ota To: Alexander Motin , FreeBSD Current Message-Id: <20090723172423.0337cf35.ota@j.email.ne.jp> In-Reply-To: <4A68BDD7.60408@FreeBSD.org> References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> <49A04510.5030405@FreeBSD.org> <7d6fde3d0902211356h66b05cfcxf2ebbe9b2a6fd0f0@mail.gmail.com> <20090224004110.e4ad76f4.ota@j.email.ne.jp> <49A45127.3000108@FreeBSD.org> <20090225211656.75c546c3.ota@j.email.ne.jp> <49A6F609.20901@FreeBSD.org> <20090226223106.b56ad289.ota@j.email.ne.jp> <49A7D1C2.6070608@FreeBSD.org> <20090228015207.d7432c0a.ota@j.email.ne.jp> <20090723153734.e1a8bff1.ota@j.email.ne.jp> <4A68BDD7.60408@FreeBSD.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: ota@j.email.ne.jp Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 21:24:21 -0000 On Thu, 23 Jul 2009 22:45:27 +0300 Alexander Motin wrote: > Yoshihiro Ota wrote: > > This problem was gone once back in Febrary. > > > > I was away from 8-current and came back to 8-BETA1/2. > > Then, now I hear this noise again. > > > > Alexander, do you have any ideas for this time, too? > > Can you remind me what are you talking about? You are talking about some > noise, but following messages about detection problems. I currently have a problem. The problem is some mysterious sound like szzzz..... in very low tone and low volume. However, it is noticeable and somewhat destructing. I usually use 7.1-RELEASE, but as 8.0 being in BETA, I installed 8-BETA1 and BETA2. Both of these versions has this noise. The noise is very much like the same noise I experienced back in February. At that time, you, Alexander, fixed the problem. I had had used 8-CURRENT until end of April but I was away until this time. Because the symptom was smiler, I decided to reply to the old e-mail chain. Thanks, Hiro From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 21:32:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9D2106566B for ; Thu, 23 Jul 2009 21:32:02 +0000 (UTC) (envelope-from kingedgar@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id 412878FC15 for ; Thu, 23 Jul 2009 21:32:02 +0000 (UTC) (envelope-from kingedgar@gmail.com) Received: by yxe11 with SMTP id 11so2099948yxe.3 for ; Thu, 23 Jul 2009 14:32:01 -0700 (PDT) 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=4VinAS5qm0Wc6ewZ3cOldqiaAlawUC3qS1YuKAden4k=; b=Oya5SQ/ktyKmN0ThIdt92yOEjBuUbuPwFwEVfPY5lbj5VxVY9xWJIhTaB9aBppMXIb ofl93On86Z+1OI3bUns/SK3DRXYfliVn7ExEd+wyQbqnxdulPeR7QR2kG39HePjpjaUf d9jujG5w/0axuies8v0YmIlB0xE2G3usOuHwM= 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=pcHBbtLgggS+Ak6U9g1Oel1IWr57sarsYNlPLVZp+kilU0lYI2Z9XlPSpxDFnw5wr4 g4xluXoNlqjzSbbNHHixExPh66twzJT0zQTRM8hkeVQU4FDvaIyhEAgQGMByCwoiR/Sf FWJQ0R2+7wmBOQ5gyt1phNrnlE26DOIWIsksg= MIME-Version: 1.0 Received: by 10.100.112.8 with SMTP id k8mr3487546anc.174.1248384721548; Thu, 23 Jul 2009 14:32:01 -0700 (PDT) In-Reply-To: References: <19047.52443.164412.363239@already.local> <1E3C4A20-1B89-4C8C-912E-3CA99A427452@lassitu.de> Date: Thu, 23 Jul 2009 16:32:01 -0500 Message-ID: <970380130907231432k2230d22apdd12fb6afd05da70@mail.gmail.com> From: Jason Garrett To: Chris Hedley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: gptzfsboot doesn't like change (failure after swapping drives) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 21:32:02 -0000 On Thu, Jul 23, 2009 at 12:39, Chris Hedley wrote: > On Thu, 23 Jul 2009, Stefan Bethke wrote: > > Am 23.07.2009 um 04:37 schrieb George Hartzell: >> >> I've been playing around with building an 8.0BETA2 system with >>> everything on a single zfs filesystem (I'll get fancier later) on a >>> zpool that is a 4 disk raidz. >>> >> >> Quite a few people had no luck with booting from RAIDZ volumes at all. >> (Single disks and mirrors seem to work fine.) See this thread: >> http://lists.freebsd.org/pipermail/freebsd-fs/2009-July/006466.html >> > > I'm tempted to set up a second ZFS pool for booting since my main one is > RAIDZ2, which it currently unsupported; this is with some trepidation as I > read ages back that there may be "issues" with multiple pools (though that > may be in the past, whatever it was) but it'll be interesting to find out. I have not had problems with multiple pools on 8-CURRENT > > > Then again, "if it ain't broke, don't fix it": maybe I should just stick > with the regular boot system using my gmirrored UFS partition... > > Chris. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 22:07:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6AC6D106566C for ; Thu, 23 Jul 2009 22:07:40 +0000 (UTC) (envelope-from drew@mykitchentable.net) Received: from smtp2.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id 40CE88FC1E for ; Thu, 23 Jul 2009 22:07:40 +0000 (UTC) (envelope-from drew@mykitchentable.net) Received: (qmail 5495 invoked from network); 23 Jul 2009 14:55:57 -0700 Received: by simscan 1.1.0 ppid: 5464, pid: 5466, t: 2.1668s scanners: regex: 1.1.0 attach: 1.1.0 spam: 3.1.7-deb X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on smtp2.surewest.net. X-Spam-Level: X-Spam-Status: No, score=0.0 required=10.0 tests=none autolearn=disabled version=3.1.7-deb X-Spam-CMAE-Analysis: v=1.0 c=1 a=UB_yN8qgYpcA:10 a=jDt-9pEAAAAA:8 a=mQC8oo_Y_hlZHHuuFWcA:9 a=aOVKpUe37nlt0Eaul5tJDIu9pNIA:4 Received: from unknown (HELO blacklamb.mykitchentable.net) (69.62.230.77) by smtp2 with SMTP; 23 Jul 2009 14:55:55 -0700 Received: from [127.0.0.1] (unknown [192.168.25.5]) by blacklamb.mykitchentable.net (Postfix) with ESMTPA id 6AACB1649F8; Thu, 23 Jul 2009 15:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mykitchentable.net; s=default; t=1248386856; bh=NbImcQ8OvkB8kJfh4n8Qyh2DcqZN7S5AB6fV3R32V/Y=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=AwFVhQ8IacOyg1aGf9ggecSuiA5xOM2Xq0mww6LZI5jNkRX+J0yWleWAPcjiDLOsY KqSZb8z2hgJ7Vdsp5oOrlvAj+vty7YTbMQE6NRp/I/BOWlX1ZtD44NylvuBSUd1+dH 03s1J9inHn2E7RsojSiFXLBh/MA2+OMkUbj+DhfY= Message-ID: <4A68DF27.3050303@mykitchentable.net> Date: Thu, 23 Jul 2009 15:07:35 -0700 From: Drew Tomlinson User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hans Petter Selasky References: <4A67CD2B.9040200@mykitchentable.net> <200907231004.37704.hselasky@c2i.net> In-Reply-To: <200907231004.37704.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 090723-0, 07/23/2009), Outbound message X-Antivirus-Status: Clean Cc: freebsd-current@freebsd.org, erich@apsara.com.sg Subject: Re: USB 2.0 External Drive - What Is A Reasonable Transfer Rate? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 22:07:40 -0000 Hans Petter Selasky wrote: > On Thursday 23 July 2009 04:38:35 Drew Tomlinson wrote: > >> I have a USB 2.0 external drive that's formatted as NTFS under Windows >> XP. I've plugged it into my 8.0 BETA2 install and am copying files to a >> local raid1z zpool with one vdev consisting of 4 drives. I'm trying to >> move about 100 GB of assorted files and have been at it all day. The >> USB drive contains assorted files such as mp3, CD/DVD images, zip, >> documents, etc. I'm guessing most files range between 1 - 4 MB with >> some as large as 4 GB. >> >> Anyway, iostat shows the transfer rate at around 2 - 3 MB per second. >> Is this all I should expect from a USB 2.0 drive? Is there anything I >> can do to speed this up? >> > > Hi, > > Benchmark your device like this: > > dd if=/dev/daX of=/dev/null bs=65536 > > It will give you the correct transferrate number. > Thanks. When using your suggestion, iostat shows rate at almost 34 MB per second which seems reasonable. When copying a large file to /dev/null as suggested by Erich Dollansky, I get right around 10 MB per second. So does that mean that it's the NTFS driver that's causing the slowing? > Maybe there are some utilities in /usr/ports that can read NTFS faster than > the kernel NTFS driver. > Maybe I'll have a look at /usr/ports/sysutils/fusefs-ntfs as suggested by Gary Jennejohn. Thanks, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 22:09:17 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB2351065670 for ; Thu, 23 Jul 2009 22:09:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swip.net [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 451038FC1B for ; Thu, 23 Jul 2009 22:09:16 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=A6RRDJO9IM8A:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=LU7vJaDcdKBgrRIn9IQA:9 a=cfOkfYJK6CnUQFRTGeQA:7 a=LafRPVB69TcRHshZ4sbt67jT01sA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 542402479 for current@freebsd.org; Thu, 23 Jul 2009 21:09:14 +0200 From: Hans Petter Selasky To: current@freebsd.org Date: Thu, 23 Jul 2009 21:09:02 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907232109.04094.hselasky@c2i.net> Cc: Subject: 8-current + USB CD-ROM drive + CAM layer audio extraction from CD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 22:09:17 -0000 Hi, I have a CD I want to extract audio from, giving me trouble this time. Plugging the USB CD-ROM into a MAC allows for instant audio playback. I'm pretty sure that digital audio extraction works. The USB CD-ROM drive is made by Samsung. The CD is made by forefront/EMI. At first I thought that this is another example of record labels making deals with hardware manufacturers, but I'm leaving a chance it might be a bug in the CAM layer. This is the dmesg I get: umass1: on usbus4 umass1: 8070i (ATAPI) over Bulk-Only; quirks = 0x0000 umass1:1:1:-1: Attached to scbus1 cd0 at umass-sim1 bus 1 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 40.000MB/s transfers cd0: cd present [331838 x 2048 byte records] (cd0:umass-sim1:1:0:0): READ(10). CDB: 28 0 0 5 10 3d 0 0 1 0 (cd0:umass-sim1:1:0:0): CAM Status: SCSI Status Error (cd0:umass-sim1:1:0:0): SCSI Status: Check Condition (cd0:umass-sim1:1:0:0): ILLEGAL REQUEST asc:64,0 (cd0:umass-sim1:1:0:0): Illegal mode for this track (cd0:umass-sim1:1:0:0): Unretryable error (cd0:umass-sim1:1:0:0): cddone: got error 0x6 back How should I proceed debugging this? I might be able to sniff the USB cable of the drive to figure out what the MAC is doing as a reference. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 22:23:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A157B106566C for ; Thu, 23 Jul 2009 22:23:02 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id 33E798FC0C for ; Thu, 23 Jul 2009 22:23:01 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.43,258,1246831200"; d="scan'208";a="278147988" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay1.uni-muenster.de with ESMTP; 24 Jul 2009 00:23:00 +0200 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 84B911B008B; Fri, 24 Jul 2009 00:23:00 +0200 (CEST) Date: Fri, 24 Jul 2009 00:23:00 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: possible bug in sbin/fsck_msdosfs/boot.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 22:23:02 -0000 thanks a bunch. Eygene Ryabinkin schrieb am 2009-07-23: > Alexander, good day. > Thu, Jul 23, 2009 at 12:29:23PM +0200, Alexander Best wrote: > > i just tried to do fsck_msdosfs on my mobile phone's memory card > > using a usb > > connection cable. this is what `file -s` has to say about /dev/da0: > > /dev/da0: x86 boot sector, code offset 0x0, OEM-ID " ", > > sectors/cluster > > 64, reserved sectors 6304, Media descriptor 0xf8, heads 128, hidden > > sectors > > 8192, sectors 7736320 (volumes > 32 MB) , FAT (32 bit), sectors/FAT > > 944, > > reserved3 0x800000, serial number 0x34613466, label: "mem " > > however after issuing the command `fsck_msdosfs /dev/da0` i got the > > following > > error: > > fsck_msdosfs /dev/da0 > > ** /dev/da0 > > backup doesn't compare to primary bootblock > > i did a bit of research and it seems this bug was supposed to be > > fixed by > > r128463. the problem was that the entire bootblock was compared to > > the > > backupblock. but since only the first 52 bytes of the bootblock are > > important > > many device use the rest of the bootblock for some other purpose. > > the > > following change was made to sbin/fsck_msdosfs/boot.c: > > -- if (memcmp(block, backup, DOSBOOTBLOCKSIZE)) { > > ++ if (memcmp(block + 11, backup + 11, 79)) { > > it seems however that the last memcmp argument is still too high. > > could > > somebody with good fat12/16/32 knowledge please look into this? > 79 looks sane for the FAT32, see > http://www.win.tue.nl/~aeb/linux/fs/fat/fat-1.html > For FAT16/FAT12 the size should be 51. Actually, what is now > compared > is the BIOS parameter block. I'll take a look at the FS forensics > book: > my memory blocks with FAT remniscents are a bit rusty ;)) From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 23:03:54 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id C3EA91065672; Thu, 23 Jul 2009 23:03:54 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Thu, 23 Jul 2009 19:03:42 -0400 User-Agent: KMail/1.6.2 References: <4A615602.4090000@freebsd.org> In-Reply-To: <4A615602.4090000@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907231903.46474.jkim@FreeBSD.org> Cc: Tim Kientzle Subject: Re: Joliet and release ISOs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 23:03:55 -0000 On Saturday 18 July 2009 12:56 am, Tim Kientzle wrote: > Do we need Joliet extensions on the release ISOs? > > The reason I ask is a little involved: jkim@ recently > pointed out to me that tar in -CURRENT can no longer > extract symlinks from the release ISOs. > > I tracked this down to the fact that the release ISOs > have both Joliet and RockRidge extensions and tar now > supports (and actually prefers) Joliet extensions when > it sees them. Joliet doesn't support symlinks, so tar > doesn't see symlinks on disks with both kinds of extensions. > > There's a workaround that people can use for now: > tar xf image.iso --options=!joliet > disables the Joliet support. > > I'm curious whether removing the -J option from > /usr/src/release/*/mkisoimages.sh is an option. > > In the longer term, I'd like to find a better way for > tar to handle disks that include both kinds of extensions, > but that will take a while to implement. The "--options=!joliet" trick didn't work for me: # uname -mrs FreeBSD 8.0-BETA2 amd64 # tar -x --options=!joliet -p -f ../8.0-BETA2-amd64-livefs.iso # ls -la total 64 drwx------ 18 root wheel 512 7 23 18:47 . drwxr-xr-x 87 jkim staff 9728 7 23 18:50 .. -r--r--r-- 2 root wheel 786 7 15 17:10 .cshrc -r--r--r-- 1 root wheel 1550 7 15 17:58 .profile -r--r--r-- 1 root wheel 6193 7 15 17:10 COPYRIGHT dr-xr-xr-x 2 root wheel 1024 7 15 17:08 bin dr-xr-xr-x 7 root wheel 1024 7 15 17:58 boot -r--r--r-- 1 root wheel 2048 7 15 20:31 boot.catalog -r--r--r-- 1 root wheel 23 7 15 17:58 cdrom.inf dr-xr-xr-x 2 root wheel 512 7 15 17:08 dev dr-xr-xr-x 20 root wheel 2048 7 15 17:49 etc dr-xr-xr-x 3 root wheel 1536 7 15 17:49 lib dr-xr-xr-x 2 root wheel 512 7 15 17:10 libexec dr-xr-xr-x 2 root wheel 512 7 15 17:08 media dr-xr-xr-x 2 root wheel 512 7 15 17:08 mnt dr-xr-xr-x 2 root wheel 512 7 15 17:08 proc dr-xr-xr-x 2 root wheel 2560 7 15 17:09 rescue dr-xr-xr-x 2 root wheel 512 7 15 17:10 root dr-xr-xr-x 25 root wheel 1024 7 15 20:31 rr_moved dr-xr-xr-x 2 root wheel 2560 7 15 17:10 sbin lr-xr-xr-x 1 root wheel 8 7 15 17:58 stand -> //rescue lr-xr-xr-x 1 root wheel 11 7 15 17:08 sys -> usr/src/sys dr-xr-xr-x 2 root wheel 512 7 15 17:08 tmp dr-xr-xr-x 14 root wheel 512 7 15 17:49 usr dr-xr-xr-x 21 root wheel 512 7 15 17:49 var # cd rescue # ls -il total 4204 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 [ 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 atacontrol 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 atmconfig 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 badsect ... 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 whoami 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 zcat 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 zfs 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 zpool # file atacontrol atacontrol: data # hexdump atacontrol 0000000 0000 0000 0000 0000 0000 0000 0000 0000 * 0447160 What did I miss? Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 23:07:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3B80106564A for ; Thu, 23 Jul 2009 23:07:28 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by mx1.freebsd.org (Postfix) with ESMTP id 6A6648FC13 for ; Thu, 23 Jul 2009 23:07:28 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so650848and.13 for ; Thu, 23 Jul 2009 16:07:27 -0700 (PDT) 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=DcspvJfqUKchN6I4Eb/Nhup4Ekd34rJNFF4zCWqp4fM=; b=TLAzhD/CleZx9qacq8ta2tgKqY2Q/XwKpLGlHMXX0rUsn1/jAkwkszlG2UFfT/vFx2 ziIsLUsjwBlJ8D9i5FZnOUoLjcouK5jQShN0rhZ4YWAlfgXOkV8aj16pnoWkr3XlloPe QdDie3ryB5EcnjGvotjvGc7dySEH1+UeuSepA= 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=e90SxPfsqhh41+HXomOEEHQwMOxjf/51xHKJ7ZTbbO15Eu2H4tU0AtwdUIDhEWs/Sm 7vQCph2cFfzWQN4ciDrnMBlqoN3Cs/PgF/ias9eA5JVRYcvOGSP0Wa3jWcq6bH9n/eLi 6aKxVEyQO1GyIgl3IGrBjWETRU95BN+xiYCKo= MIME-Version: 1.0 Received: by 10.100.58.1 with SMTP id g1mr3627160ana.181.1248390447871; Thu, 23 Jul 2009 16:07:27 -0700 (PDT) In-Reply-To: <1248291677.1479.5.camel@RabbitsDen> References: <1248291677.1479.5.camel@RabbitsDen> Date: Thu, 23 Jul 2009 16:07:27 -0700 Message-ID: <2a41acea0907231607y679cb275i42c81054f3642dda@mail.gmail.com> From: Jack Vogel To: Alexandre Sunny Kovalenko Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Unloading if_em causes panic on 8.0-BETA2 #0 r195818 (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 23:07:29 -0000 Have a fix, it will be checked in shortly, as soon as it has re approval. Cheers, Jack On Wed, Jul 22, 2009 at 12:41 PM, Alexandre "Sunny" Kovalenko < gaijin.k@gmail.com> wrote: > System: > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-BETA2 FreeBSD 8.0-BETA2 > #0 r195818: Wed Jul 22 13:50:22 EDT 2009 > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > > To reproduce: > kldload if_em; kldunload if_em > > Hardware: > em0@pci0:2:0:0: class=3D0x020000 card=3D0x207e17aa chip=3D0x109a8086 rev= =3D0x00 > hdr=3D0x00 > vendor =3D 'Intel Corporation' > device =3D 'Intel PRO/1000 PL Network Adaptor (82573L)' > class =3D network > subclass =3D ethernet > > Crash summary: > http://members.verizon.net/~akovalenko/Misc/core.txt.0 > > Backtrace: > (kgdb) bt > #0 doadump () at pcpu.h:246 > #1 0xa0586614 in boot (howto=3D260) > at /usr/src/sys/kern/kern_shutdown.c:419 > #2 0xa058692b in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xa0712fe1 in vm_fault (map=3D0xa1090000, vaddr=3D2701840384, > fault_type=3D1 '\001', fault_flags=3D0) at /usr/src/sys/vm/vm_fault.c:283 > #4 0xa076e046 in trap_pfault (frame=3D0xfa528adc, usermode=3D0, > eva=3D2701844432) at /usr/src/sys/i386/i386/trap.c:835 > #5 0xa076ebab in trap (frame=3D0xfa528adc) > at /usr/src/sys/i386/i386/trap.c:528 > #6 0xa075281b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 > #7 0xa057204d in free (addr=3D0xaefcb000, mtp=3D0xa07fbcd0) at > vm_page.h:255 > #8 0xa05b1978 in buf_ring_free (br=3D0xaefcb000, type=3D0xa07fbcd0) > at /usr/src/sys/kern/subr_bufring.c:67 > #9 0xaeff86aa in em_free_transmit_structures (adapter=3D0xaefc6000) > at /usr/src/sys/modules/em/../../dev/e1000/if_em.c:3647 > #10 0xaeffb10f in em_detach (dev=3D0xa6250400) > at /usr/src/sys/modules/em/../../dev/e1000/if_em.c:925 > #11 0xa05af62d in device_detach (dev=3D0xa6250400) at device_if.h:212 > #12 0xa05afaba in driver_module_handler (mod=3D0xa7908e00, what=3D1, > arg=3D0xaf01b81c) at /usr/src/sys/kern/subr_bus.c:1098 > #13 0xa05742fd in module_unload (mod=3D0xa7908e00) > at /usr/src/sys/kern/kern_module.c:266 > #14 0xa056b65d in linker_file_unload (file=3D0xaefaf400, flags=3D0) > at /usr/src/sys/kern/kern_linker.c:632 > #15 0xa056c0e4 in kern_kldunload (td=3D0xab050900, fileid=3D27, flags=3D0= ) > at /usr/src/sys/kern/kern_linker.c:1091 > #16 0xa056c161 in kldunloadf (td=3D0xab050900, uap=3D0xfa528cf8) > at /usr/src/sys/kern/kern_linker.c:1121 > #17 0xa076e474 in syscall (frame=3D0xfa528d38) > at /usr/src/sys/i386/i386/trap.c:1073 > #18 0xa07528b0 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:261 > #19 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) > > Please, let me know if there is anything else I can provide. > > -- > Alexandre Kovalenko (=EF=CC=C5=CB=D3=C1=CE=C4=D2 =EB=CF=D7=C1=CC=C5=CE=CB= =CF) > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 23:15:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 312891065673 for ; Thu, 23 Jul 2009 23:15:07 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id BD15F8FC1C for ; Thu, 23 Jul 2009 23:15:06 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.43,259,1246831200"; d="scan'208";a="219527205" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 24 Jul 2009 01:15:05 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 2ACEB1B0751; Fri, 24 Jul 2009 01:15:05 +0200 (CEST) Date: Fri, 24 Jul 2009 01:15:04 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: core dumps being overwritten X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 23:15:07 -0000 i was thinking about this issue the other day again. if /var/crash/bounds gets corrupted vital crash/debug information could be lost (like in my case). why don't we check for existing core dumps instead of using bounds? doing something like in this pseudo code: i = 0; while(exist("vmcore."i) || exist("core.txt."i) || exist("info."i)) i++; write("vmcore."i); write(""core.txt."i); write("info."i); or how about using /dev/random to create unique filenames so core dumps never get overwritten? cheers. From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 23:45:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11FCB106566B for ; Thu, 23 Jul 2009 23:45:05 +0000 (UTC) (envelope-from slyngaas@gmail.com) Received: from mail-ew0-f220.google.com (mail-ew0-f220.google.com [209.85.219.220]) by mx1.freebsd.org (Postfix) with ESMTP id 965748FC17 for ; Thu, 23 Jul 2009 23:45:04 +0000 (UTC) (envelope-from slyngaas@gmail.com) Received: by ewy20 with SMTP id 20so452383ewy.43 for ; Thu, 23 Jul 2009 16:45:03 -0700 (PDT) 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:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=ydYIZYMBoq4y28F2mUl5B9qpER5P8pJpWc14Ss6Pr88=; b=dPyPINbGAWhZaFRiWbkcllCgegGuRdGj+xUtz9bE+t/Zsxsfm7ug0qcmOm0DcISyZo bQ1OweoPv55XmmA8jHPhslee8sUc5UtuW6IBHG2gw/7iS9Jr7sRg86TBDMvzVEh9o+10 hv5TyPmNmpdeZibgyVnfm/wYkaus1YNEIfgbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=IK2SG79EhZlfTNmqntXctuLWbs3DByEZMcEciewihKqHrD80YkyoxHh9cR1GudjQsk EtjUU1jAP4nSIkNpIcQIsHYZHPo6Bvk7BP/f7DcGO46nPkWHMroqMMDF6ULkkiHzf9+9 P6HpMvcg3zfJbSIIysrDyYn3HYTU2c5XlyDNc= MIME-Version: 1.0 Sender: slyngaas@gmail.com Received: by 10.216.10.74 with SMTP id 52mr812449weu.226.1248391398069; Thu, 23 Jul 2009 16:23:18 -0700 (PDT) In-Reply-To: <7d6fde3d0902210101yfb42ff6yd0aa31e6f16b5761@mail.gmail.com> References: <7d6fde3d0902210101yfb42ff6yd0aa31e6f16b5761@mail.gmail.com> Date: Fri, 24 Jul 2009 01:23:18 +0200 X-Google-Sender-Auth: 6a66c5e10bf6edf9 Message-ID: <558ffc2b0907231623v2bad80bbref035bd1fd950d39@mail.gmail.com> From: =?UTF-8?Q?St=C3=A5le_Lyngaas?= To: Garrett Cooper Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Current Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 23:45:05 -0000 On Sat, Feb 21, 2009 at 11:01 AM, Garrett Cooper wrote: > =C2=A0 =C2=A0I don't know how else to describe it, but when I turn up my > speakers enough (50%+) and don't have any sound playing, I hear a > whitenoise hiss coming out of them. When I change webpages (nvidia > driver is GIANT locked) or do something else kernel intensive it stops > for a brief second, but apart from that it's an annoying trill sound > almost like a mosquito humming around me waiting to be swatted. I suspect this is due to the CPU executing the HLT instruction. Try running the following command: sysctl machdep.cpu_idle_hlt=3D0 --=20 St=C3=A5le Lyngaas From owner-freebsd-current@FreeBSD.ORG Thu Jul 23 23:54:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF6DE106564A for ; Thu, 23 Jul 2009 23:54:11 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from hamlet.setfilepointer.com (hamlet.SetFilePointer.com [63.224.10.2]) by mx1.freebsd.org (Postfix) with SMTP id 7E8BD8FC14 for ; Thu, 23 Jul 2009 23:54:11 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 60497 invoked from network); 23 Jul 2009 18:27:30 -0500 Received: from keira.kiwi-computer.com (HELO kiwi-computer.com) (63.224.10.3) by hamlet.setfilepointer.com with SMTP; 23 Jul 2009 18:27:30 -0500 Received: (qmail 72777 invoked by uid 2001); 23 Jul 2009 23:27:30 -0000 Date: Thu, 23 Jul 2009 18:27:30 -0500 From: "Rick C. Petty" To: freebsd-current@freebsd.org Message-ID: <20090723232730.GB72486@keira.kiwi-computer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Thu, 23 Jul 2009 23:57:51 +0000 Subject: Re: UFS label limitations X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 23:54:12 -0000 I posted this patch to freebsd-fs back in December, which allows some separator characters to be used in UFS labels. I've attached the patch below. des@ suggested using strspn(3) instead, so I've attached that version also. Is someone willing to commit this into 8.0? It's rather innocuous. -- Rick C. Petty ~~~ ~~~ original patch ~~~ --- src/sbin/newfs/newfs.c.orig 2007-03-02 14:07:59.000000000 -0600 +++ src/sbin/newfs/newfs.c 2008-12-15 17:29:26.000000000 -0600 @@ -168,11 +168,15 @@ case 'L': volumelabel = optarg; i = -1; - while (isalnum(volumelabel[++i])); - if (volumelabel[i] != '\0') { - errx(1, "bad volume label. Valid characters are alphanumerics."); - } - if (strlen(volumelabel) >= MAXVOLLEN) { + while ((ch = volumelabel[++i]) != '\0') + if (ch != '-' && ch != '.' && ch != '_' && + (ch < '0' || ch > '9') && + (ch < 'A' || ch > 'Z') && + (ch < 'a' || ch > 'z')) + errx(1, + "bad volume label. Valid characters are " + "[0-9A-Za-z._-]."); + if (i >= MAXVOLLEN) { errx(1, "bad volume label. Length is longer than %d.", MAXVOLLEN); } --- src/sbin/tunefs/tunefs.c.orig 2008-02-26 14:25:35.000000000 -0600 +++ src/sbin/tunefs/tunefs.c 2008-12-15 17:27:58.000000000 -0600 @@ -153,13 +153,16 @@ name = "volume label"; Lvalue = optarg; i = -1; - while (isalnum(Lvalue[++i])); - if (Lvalue[i] != '\0') { + while ((ch = Lvalue[++i]) != '\0') + if (ch != '-' && ch != '.' && ch != '_' && + (ch < '0' || ch > '9') && + (ch < 'A' || ch > 'Z') && + (ch < 'a' || ch > 'z')) errx(10, - "bad %s. Valid characters are alphanumerics.", + "bad %s. Valid characters are " + "[0-9A-Za-z._-].", name); - } - if (strlen(Lvalue) >= MAXVOLLEN) { + if (i >= MAXVOLLEN) { errx(10, "bad %s. Length is longer than %d.", name, MAXVOLLEN - 1); } ~~~ ~~~ using strspn instead ~~~ --- src/sbin/newfs/newfs.c.orig 2008-05-03 23:51:38.000000000 -0500 +++ src/sbin/newfs/newfs.c 2009-07-22 16:58:48.000000000 -0500 @@ -167,10 +167,10 @@ break; case 'L': volumelabel = optarg; - i = -1; - while (isalnum(volumelabel[++i])); + i = strspn(volumelabel, + "-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz"); if (volumelabel[i] != '\0') { - errx(1, "bad volume label. Valid characters are alphanumerics."); + errx(1, "bad volume label. Valid characters are [0-9A-Za-z._-]."); } if (strlen(volumelabel) >= MAXVOLLEN) { errx(1, "bad volume label. Length is longer than %d.", --- src/sbin/tunefs/tunefs.c.orig 2008-05-03 23:51:52.000000000 -0500 +++ src/sbin/tunefs/tunefs.c 2009-07-22 17:01:23.000000000 -0500 @@ -152,11 +152,11 @@ found_arg = 1; name = "volume label"; Lvalue = optarg; - i = -1; - while (isalnum(Lvalue[++i])); + i = strspn(Lvalue, + "-.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz"); if (Lvalue[i] != '\0') { errx(10, - "bad %s. Valid characters are alphanumerics.", + "bad %s. Valid characters are [0-9A-Za-z._-].", name); } if (strlen(Lvalue) >= MAXVOLLEN) { From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 01:14:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D83011065670 for ; Fri, 24 Jul 2009 01:14:42 +0000 (UTC) (envelope-from emikulic@gmail.com) Received: from ipmail03.adl6.internode.on.net (ipmail03.adl6.internode.on.net [203.16.214.141]) by mx1.freebsd.org (Postfix) with ESMTP id 596B28FC15 for ; Fri, 24 Jul 2009 01:14:42 +0000 (UTC) (envelope-from emikulic@gmail.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKukaEqWZZrw/2dsb2JhbAC+bJIThA0F X-IronPort-AV: E=Sophos;i="4.43,259,1246804200"; d="scan'208";a="9062378" Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail03.adl6.internode.on.net with ESMTP; 24 Jul 2009 10:29:13 +0930 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id D21E15C44; Fri, 24 Jul 2009 10:59:12 +1000 (EST) Date: Fri, 24 Jul 2009 10:59:12 +1000 From: Emil Mikulic To: Thomas Backman Message-ID: <20090724005912.GB89091@dmr.ath.cx> References: <451cb3010907181027q13d5c345w8962a648c7682ed8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: McLone , FreeBSD current Subject: Re: [bug] ZFS zvol dev entry disappearing upon reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 01:14:43 -0000 On Thu, Jul 23, 2009 at 09:31:19AM +0200, Thomas Backman wrote: > OK, I've found the problem we have here... Or, rather, I've found the > *reason* (and this shows why I previously said I couldn't reproduce). I > haven't found it in source, though. > > UFS filesystems in fstab are mounted *before* the /dev/zvol directory is > populated, at least on my system! I remember running into this! I tried to solve it using the "late" mount flag in fstab but couldn't get it working. In the end I just stuck a bunch of manual "mount" commandlines in /etc/rc.local. What a cop-out. :( --Emil From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 05:02:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D5871065673 for ; Fri, 24 Jul 2009 05:02:37 +0000 (UTC) (envelope-from wtf.jlaine@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 081188FC1F for ; Fri, 24 Jul 2009 05:02:34 +0000 (UTC) (envelope-from wtf.jlaine@gmail.com) Received: by fxm18 with SMTP id 18so1204891fxm.43 for ; Thu, 23 Jul 2009 22:02:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:references:mime-version:content-type :content-disposition:in-reply-to:user-agent:x-operating-system; bh=kOjnUJQ1s6z1U+whhUUnJhxGg3mgPAP3CB2mk5YtGH4=; b=BOtZLQayNOg7V8jFeyhiInR6+AZzcAPcE71F3Jl2PQpgXdwEWJF2qEeuXzst/bSHGc MhDtNIIlfbBVU82H1Ulx7gcfpbbYFCe8jo3232X80J7HMPTieOAbc++G/Y4OlLw555iO c14unrCqlWXQZgKySG0SWraO3zD8hsULPBOgU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-operating-system; b=Mnpn65P3rXR9m62A+8FM+0O264rXG0btk3Pv7pqJNvY5o39xgWUUsaDwI2aiU+NWMY GoccBJISZvZweRDn2RRS1AD+EyVcsP6mat8imyPg51vxNWMFF2KJzq6xQqoOHcbf+7T1 v1M0mVzRA0BhtwygOojz8qa6fR8fKUKK3EArU= Received: by 10.86.65.18 with SMTP id n18mr2589405fga.7.1248410251501; Thu, 23 Jul 2009 21:37:31 -0700 (PDT) Received: from blackmesa ([77.66.145.99]) by mx.google.com with ESMTPS id l19sm6452859fgb.6.2009.07.23.21.37.29 (version=SSLv3 cipher=RC4-MD5); Thu, 23 Jul 2009 21:37:31 -0700 (PDT) Received: by blackmesa (sSMTP sendmail emulation); Fri, 24 Jul 2009 08:37:26 +0400 Date: Fri, 24 Jul 2009 08:37:26 +0400 From: Jeff Laine To: Julian Elischer Message-ID: <20090724043726.GA5474@free.bsd.loc> References: <20090723132830.GA33539@free.bsd.loc> <4A687DBE.5060200@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A687DBE.5060200@elischer.org> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-BETA2 i386 Cc: FreeBSD Current Subject: Re: ng_ipacct build error [SOLVED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 05:02:37 -0000 On Thu,07/23/09 [08:11:58], Julian Elischer wrote: > Jeff Laine wrote: > >Hello list! > > > >I have upgraded to BETA2 recently and decided to recompile > >net-mgmt/ng_ipacct port > >(it was compiled in 7.2 so it's kernel module refused to load). > > > >But I stuck with this permanent stop error: > > > > > >4:49pm [/ports/net-mgmt/ng_ipacct]# make > >===> Vulnerability check disabled, database not found > >===> Found saved configuration for ng_ipacct-20061223 > >===> Extracting for ng_ipacct-20061223 > >=> MD5 Checksum OK for ng_ipacct-20061223.tar.gz. > >=> SHA256 Checksum OK for ng_ipacct-20061223.tar.gz. > >===> Patching for ng_ipacct-20061223 > >===> Applying FreeBSD patches for ng_ipacct-20061223 > >===> Configuring for ng_ipacct-20061223 > >===> Building for ng_ipacct-20061223 > >===> ng_ipacct (all) > >Warning: Object directory not changed from original > >/tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct > >@ -> /usr/src/sys > >machine -> /usr/src/sys/i386/include > >:> opt_netgraph.h > >cc -O2 -pipe -DMEM_USE_ZONE -fno-strict-aliasing -g -Werror -D_KERNEL > >-DKLD_MODULE -nostdinc > >-I/tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ng_ipacct -I. -I@ > >-I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 > >--param large-function-growth=1000 -fno-common -mno-align-long-strings > >-mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > >-mno-sse3 -ffreestanding -fstack-protector -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 ng_ipacct.c > >ld -d -warn-common -r -d -o ng_ipacct.kld ng_ipacct.o > >:> export_syms > >awk -f /sys/conf/kmod_syms.awk ng_ipacct.kld export_syms | xargs -J% > >objcopy % ng_ipacct.kld > >ld -Bshareable -d -warn-common -o ng_ipacct.ko ng_ipacct.kld > >objcopy --strip-debug ng_ipacct.ko > >===> ipacctctl (all) > >Warning: Object directory not changed from original > >/tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ipacctctl > >cc -O2 -pipe -DMEM_USE_ZONE -fno-strict-aliasing -g -Wall -Wformat > >-std=gnu99 -fstack-protector -c ipacctctl.c > >ipacctctl.c:146: error: 'NG_PATHLEN' undeclared here (not in a function) > >ipacctctl.c: In function 'ip_account_get_info': > >ipacctctl.c:505: warning: unused variable 'path' > >ipacctctl.c: In function 'ip_account_show': > >ipacctctl.c:602: warning: unused variable 'path' > >*** Error code 1 > > > >Stop in /tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct/ipacctctl. > >*** Error code 1 > > > >Stop in /tmp/usr/ports/net-mgmt/ng_ipacct/work/ng_ipacct. > >*** Error code 1 > > > >Stop in /usr/ports/net-mgmt/ng_ipacct. > >*** Error code 1 > > > >Stop in /usr/ports/net-mgmt/ng_ipacct. > > > > > > > > > >Should I contact the maintainer or am I 'doing it wrong'? :) > > > > > >TIA > > > > > #ifndef BURN_BRIDGES > /* don't use these - they will go away */ > #define NG_TYPELEN (NG_TYPESIZ - 1) > #define NG_HOOKLEN (NG_HOOKSIZ - 1) > #define NG_NODELEN (NG_NODESIZ - 1) > #define NG_PATHLEN (NG_PATHSIZ - 1) > #define NG_CMDSTRLEN (NG_CMDSTRSIZ - 1) > #endif > > they went away > > use NG_PATHSIZ (or NG_PATHSIZ-1 depending on what you ar edoing wih it). Thanks for the hint Julian! All is ok now. -- Best regards, Jeff | "Nobody wants to say how this works. | | Maybe nobody knows ..." | | Xorg.conf(5) | From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 05:40:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5506B106566B for ; Fri, 24 Jul 2009 05:40:11 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 109888FC08 for ; Fri, 24 Jul 2009 05:40:10 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MUDVn-0005DF-3W for freebsd-current@freebsd.org; Fri, 24 Jul 2009 05:40:07 +0000 Received: from 193.33.173.33 ([193.33.173.33]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 Jul 2009 05:40:07 +0000 Received: from c.kworr by 193.33.173.33 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 24 Jul 2009 05:40:07 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Volodymyr Kostyrko Date: Fri, 24 Jul 2009 08:39:54 +0300 Lines: 31 Message-ID: References: <200907231302.34000.subbsd@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 193.33.173.33 User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.8.1.22) Gecko/20090716 SeaMonkey/1.1.17 In-Reply-To: <200907231302.34000.subbsd@gmail.com> Sender: news Subject: Re: library compat for FreeBSD7x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 05:40:11 -0000 subbsd wrote: > after the bump version on FreeBSD8-Beta2, some application needs for old > library. But misc/compat7x ports not found for this. It still not ready? > thanks! Actually compat port messes things a bit if a newly compiled binary is looking for new lib and it's next not-so-fresh dependency looks for the older one you'll get one set of symbols imported twice. libmap.conf is a just a more painless solution, yet you should rebuild all binaries. There's a good port sysutils/libchk which you can use to deal with this. It rummages through your bin/lib directories and reports any discrepancies it finds. It outputs something like: Unresolvable link(s) found in: /usr/local/bin/lp libssl.so.5 libcrypto.so.5 libcrypt.so.4 I use this to create the list of packages I need to rebuild: pkg_which `grep Unresolvable libchk.out | sed 's|.* in: ||'` | sort -u | grep -v '^\?$' This list can be later given to something like portupgrade. The same file can be used to automatically generate libmap.conf. However I havn't look at it. -- Sphinx of black quartz judge my vow. From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 05:59:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0061A106566C; Fri, 24 Jul 2009 05:59:25 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 790088FC0A; Fri, 24 Jul 2009 05:59:25 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n6O5xOnw036972; Thu, 23 Jul 2009 22:59:24 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id 92abxtd98xwsvdzivy4j6j25fi; Thu, 23 Jul 2009 22:59:24 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A694DBB.8080800@freebsd.org> Date: Thu, 23 Jul 2009 22:59:23 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090601 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Jung-uk Kim References: <4A615602.4090000@freebsd.org> <200907231903.46474.jkim@FreeBSD.org> In-Reply-To: <200907231903.46474.jkim@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------040009070606010401060900" Cc: "'freebsd-current@freebsd.org'" Subject: Re: Joliet and release ISOs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 05:59:26 -0000 This is a multi-part message in MIME format. --------------040009070606010401060900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jung-uk Kim wrote: > > The "--options=!joliet" trick didn't work for me: > > # uname -mrs > FreeBSD 8.0-BETA2 amd64 > # tar -x --options=!joliet -p -f ../8.0-BETA2-amd64-livefs.iso > # cd rescue > # ls -il > total 4204 > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 [ > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 atacontrol > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 atmconfig > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 badsect > ... > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 whoami > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 zcat > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 zfs > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 zpool > # file atacontrol > atacontrol: data > # hexdump atacontrol > 0000000 0000 0000 0000 0000 0000 0000 0000 0000 > * > 0447160 Try the attached patch; I believe this corrects the reading of hardlinks from iso9660 images. Tim --------------040009070606010401060900 Content-Type: text/x-patch; name="libarchive_iso9660_hardlink.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="libarchive_iso9660_hardlink.patch" Index: archive_read_support_format_iso9660.c =================================================================== --- archive_read_support_format_iso9660.c (revision 195838) +++ archive_read_support_format_iso9660.c (working copy) @@ -579,6 +579,7 @@ && file->size > 0) { archive_entry_set_hardlink(entry, iso9660->previous_pathname.s); + archive_entry_unset_size(entry); iso9660->entry_bytes_remaining = 0; iso9660->entry_sparse_offset = 0; release_file(iso9660, file); --------------040009070606010401060900-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 06:55:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A64FD106564A for ; Fri, 24 Jul 2009 06:55:35 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id DE3818FC0C for ; Fri, 24 Jul 2009 06:55:34 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n6O6tIRq080382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Jul 2009 16:25:18 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Fri, 24 Jul 2009 16:25:07 +0930 User-Agent: KMail/1.9.10 References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <20090721215201.GA61999@troutmask.apl.washington.edu> <200907220814.38246.jhb@freebsd.org> In-Reply-To: <200907220814.38246.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1862751.5vLI0Mh6JJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200907241625.16312.doconnor@gsoft.com.au> X-Spam-Score: -3.585 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: "O. Hartmann" , Thomas Backman , Olivier SMEDTS , FreeBSD current , Steve Kargl , Ken Smith Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 06:55:35 -0000 --nextPart1862751.5vLI0Mh6JJ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 22 Jul 2009, John Baldwin wrote: > > How many of those 800 ports are actually necessary and used? > > It would be better to get generate a complete list of your > > installed ports, use pkg_deinstall or pkg_delete to remove > > all ports, and then selectively re-install ports that are > > actually used. > > Xorg takes up ~200 ports alone (not including dependencies like perl, > etc.) since the Xorg decided release engineering was too hard. Throw > in things like KDE, OOo, Firefox, etc. for a desktop and you can get > a fairly high package count. :-/ Ooh I only have 1315 on mine, but a 1.4GHz Pentium-M is pretty slow=20 these days :( Perhaps there needs to be a psuedo port for 'base' (or a few) so that=20 you can easily determine if you have already upgraded something against=20 the new base you installed. Certainly I find it difficult to leave my laptop on for long enough to=20 recompile everything when I upgrade -current (since I actually use it=20 for work), and portupgrade -fa has no way to tell if it's already done=20 something. If there were pseudo base ports you could tell it to force=20 upgrade everything that depends on the old base port and it would DTRT. I, of course, have no patches for such a thing :) I've deleted /usr/local & /var/db/pkg in the past, it can be very=20 therapeutic :) However it is not so good when your mp3 collection is=20 mounted on /usr/local/mp3 and you forgot to unmount it first.. :( =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1862751.5vLI0Mh6JJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBKaVrU5ZPcIHs/zowRAjimAKChX1z895CZ6+YwFI2AC8GnRGJmJgCeNVwK EDfsTISjlY20fd3WDrqGrs0= =G5dX -----END PGP SIGNATURE----- --nextPart1862751.5vLI0Mh6JJ-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 06:55:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9269A106564A for ; Fri, 24 Jul 2009 06:55:59 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 4002E8FC17 for ; Fri, 24 Jul 2009 06:55:58 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so728523qwe.7 for ; Thu, 23 Jul 2009 23:55:58 -0700 (PDT) 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:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:organization:x-operation-sytem; bh=2XHNjpHiYKmKjQmFROBBUjw5KtzzD/pbIoWfXT1oikM=; b=Yl/g9l/txklNnnq+22YlFAl9/6wtFpimuldWF63uHD+3cRKylHGZsDL0bwckXVRYwC v34lTRbROSjH57K+vQKWm1NkqDyRls6rZsU/xubGCsljm7dLF6N9lzBdc07zJjzKT8w/ Ih8HLnonpgUwq43Jl8qDA4wD8JcV+AYrY4p7c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :references:mime-version:content-type:content-disposition :in-reply-to:user-agent:organization:x-operation-sytem; b=mXp9tO5zwIWyIta2OfZfqkSL6nQ5Eo6jezc7Hn0mHkOYaJvHgdRDLb+lkttvmQ9Pnb kynMxbEr994kQj+q6gqaQt/rHnpv59Lp6qTQ6T7CxBU6Km9nh5yG3cnCOSfUeTZGywDB 8HNSVh2C8dF/yhawZRZ/sXHWEjSK2Q9IKKF+I= Received: by 10.224.74.8 with SMTP id s8mr3059301qaj.12.1248416592140; Thu, 23 Jul 2009 23:23:12 -0700 (PDT) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id 5sm4010126qwh.51.2009.07.23.23.23.10 (version=SSLv3 cipher=RC4-MD5); Thu, 23 Jul 2009 23:23:11 -0700 (PDT) Received: by weongyo (sSMTP sendmail emulation); Thu, 23 Jul 2009 23:23:07 -0700 From: Weongyo Jeong Date: Thu, 23 Jul 2009 23:23:07 -0700 To: Lucius Windschuh Message-ID: <20090724062307.GB59861@weongyo.local> Mail-Followup-To: Lucius Windschuh , current@freebsd.org References: <90a5caac0907120353k69fb4f23q5e2f0eff35cfa2c5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90a5caac0907120353k69fb4f23q5e2f0eff35cfa2c5@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: current@freebsd.org Subject: Re: uath0 issues: eject-caused panic, won't work after a restart. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 06:55:59 -0000 On Sun, Jul 12, 2009 at 12:53:38PM +0200, Lucius Windschuh wrote: > Hi guys, > I'm using CURRENT r195362MP and have two issues with it. > > 1st: Pulling the device while the kernel was nearly finished shutting > down shutting down resulted in a kernel panic: > > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 1 1 1 0 0 done > All buffers synced. > > [LORs: ufs, syncer, defs; ELI detaches] > > ugen3.2: at usbus3 (disconnected) > uath0: at uhub3, port 1, addr 2 (disconnected) > > lock order reversal: > 1st 0xc6793208 if_afdata (if_afdata) @ /usr/src/sys/net/if.c:876 > 2nd 0xc0bf82c8 mld_mtx (mld_mtx) @ /usr/src/sys/netinet6/mld6.c:577 > KDB: stack backtrace: > db_trace_self_wrapper(c09cafad,e8b72a64,c06f0fe5,c06e1d9b,c09cde42,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c06e1d9b,c09cde42,c6113ca0,c610e9c0,e8b72ac0,...) at > kdb_backtrace+0x29 > _witness_debugger(c09cde42,c0bf82c8,c09cdfbe,c610e9c0,c09e6205,...) at > _witness_debugger+0x25 > witness_checkorder(c0bf82c8,9,c09e6205,241,0,...) at witness_checkorder+0x839 > _mtx_lock_flags(c0bf82c8,0,c09e6205,241,c79b6ac0,...) at _mtx_lock_flags+0xc4 > mld_domifdetach(c6793000,c6793208,c0a50c60,e8b72b64,c0755e1c,...) at > mld_domifdetach+0x2c > in6_domifdetach(c6793000,c79b6ac0,36c,440,c679322c,...) at in6_domifdetach+0x15 > if_detach(c6793000,c79de00c,e8b72b9c,c79be200,c79ed000,...) at if_detach+0x85c > ieee80211_ifdetach(c79ed000,0,c79c1c40,201,c6793000,...) at > ieee80211_ifdetach+0x14 > uath_detach(c6e84c00,c67cd860,c0a336c8,a3c,c06d7d89,...) at uath_detach+0x80 > device_detach(c6e84c00,c09b6190,c6773650,1,2,...) at device_detach+0x8c > usb_detach_device(c688c43c,0,c09b5fa1,199,19c1b4f,...) at > usb_detach_device+0x178 > usb_unconfigure(c789d400,c05ef530,c78801e0,7b4,0,...) at usb_unconfigure+0x5a > usb_free_device(c688c400,3,1,10,e8b72ca8,...) at usb_free_device+0x1be > uhub_explore(c6785400,0,c09b5463,e0,c6504d34,...) at uhub_explore+0x2a7 > usb_bus_explore(c6504d34,c6504dac,c09b768a,67,c0a89000,...) at > usb_bus_explore+0xbb > usb_process(c6504cd4,e8b72d38,c09c3242,342,c6744d48,...) at usb_process+0xde > fork_exit(c05faed0,c6504cd4,e8b72d38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe8b72d70, ebp = 0 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xdeadc0de > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc074c318 > stack pointer = 0x28:0xc5f3f9e8 > frame pointer = 0x28:0xc5f3f9e8 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 11 (swi4: clock) > > Held locks: > exclusive sx 123456789ABCDEF - USB config SX lock (123456789ABCDEF - > USB config SX lock) r = 0 (0xc688c43c) locked @ > /usr/src/sys/dev/usb/usb_device.c:409 > exclusive sleep mutex Giant (Giant) r = 0 (0xc0a84a30) locked @ > /usr/src/sys/kern/kern_intr.c:1164 > shared sx module subsystem sx lock (module subsystem sx lock) r = 0 > (0xc0a83fe0) locked @ /usr/src/sys/kern/kern_module.c:103 > > More information from the textdump: > > db:1:locks> show alllocks > Process 29 (usbus3) thread 0xc6742000 (100057) > Process 11 (intr) thread 0xc643f480 (100021) > Process 1 (init) thread 0xc6178000 (100001) > db:1:alllocks> show lockedvnods > Locked vnodes > db:0:kdb.enter.default> show pcpu > cpuid = 0 > dynamic pcpu = 0x5b99f2 > curthread = 0xc6176480: pid 11 "swi4: clock" > curpcb = 0xc5f3fd90 > fpcurthread = none > idlethread = 0xc6176b40: pid 10 "idle: cpu0" > APIC ID = 0 > currentldt = 0x50 > spin locks held: > db:0:kdb.enter.default> bt > Tracing pid 11 tid 100006 td 0xc6176480 > strlen(deadc0de,c5f3fb38,4,80000000,c5f3fa7c,...) at strlen+0x8 > kvprintf(c09c6735,c06e0520,c5f3fb38,a,c5f3fb78,...) at kvprintf+0x8fe > vsnprintf(c0a84d00,100,c09c6735,c5f3fb78,0,...) at vsnprintf+0x3b > panic(c09c6735,deadc0de,c09ddcd9,645,c0a83210,...) at panic+0x8d > _mtx_lock_flags(c67e0000,0,c09ddcd9,645,c67e0000,...) at _mtx_lock_flags+0x9a > adhoc_age(c67f2800,c5f3fbe8,c06d2e0c,c0a83210,0,...) at adhoc_age+0x32 > sta_age(c67f2800,c5f3fc48,c078dd71,c79ed000,c6176480,...) at sta_age+0x1c > ieee80211_scan_timeout(c79ed000,c6176480,c0a852c0,c6176480,c5f3fc2c,...) > at ieee80211_scan_timeout+0x1c > ieee80211_node_timeout(c79ed000,0,c09c8fe3,176,c0a852f4,...) at > ieee80211_node_timeout+0x21 > softclock(c0a852c0,c5f3fcc8,c06a0834,c0a89680,c61b6b38,...) at softclock+0x24a > intr_event_execute_handlers(c6174aa0,c61b6b00,c09c34c7,4fc,c61b6b70,...) > at intr_event_execute_handlers+0x125 > ithread_loop(c610bbc0,c5f3fd38,c09c3242,342,c6174aa0,...) at ithread_loop+0x9f > fork_exit(c0689950,c610bbc0,c5f3fd38) at fork_exit+0xb8 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xc5f3fd70, ebp = 0 --- > > PID 11 is the "intr" process. > > A textdump (vm6.tar.gz) is available: > http://sites.google.com/site/lwfreebsd/Home/files/vm6.tar.gz?attredirects=0 Looks weird to me because the backtrace points that ieee80211_node_timeout() is enqueued again after detach routine (including draining callouts) had completed that something goes wrong or there are something the driver missed. It should be never happened. I'll try to reproduce this symptom on my environment but please give me time because I'm currently busy with relocation. > 2nd issue: > > With an plugged and firmware-loaded uath device (TRENDnet TEW-504UB in > my case), reboot the system. It is not initialized by uath until you > pull and plug it back in. > The USB descriptors, obtained by usbconfig dump_device_desc, are the > same before pulling and after reinitializing the device. > > Is there anything I can do to help fixing these issues? I think we need a way to reset USB port with the software (e.g in uathload(8)). I'll let you know when the patch is ready. regards, Weongyo Jeong From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 07:35:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1540D106566B for ; Fri, 24 Jul 2009 07:35:58 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 869068FC1D for ; Fri, 24 Jul 2009 07:35:57 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from smoochies.rachie.is-a-geek.net (mailhub.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id EDE637E818; Thu, 23 Jul 2009 23:35:55 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Thu, 23 Jul 2009 23:35:54 -0800 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <1248027417.14210.110.camel@neo.cse.buffalo.edu> <200907220814.38246.jhb@freebsd.org> <200907241625.16312.doconnor@gsoft.com.au> In-Reply-To: <200907241625.16312.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907232335.54973.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Doug Barton , freebsd-stable@freebsd.org, "O. Hartmann" , Thomas Backman , Olivier SMEDTS , Steve Kargl , Ken Smith Subject: Re: HEADS-UP: Shared Library Versions bumped... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 07:35:58 -0000 On Thursday 23 July 2009 22:55:07 Daniel O'Connor wrote: > On Wed, 22 Jul 2009, John Baldwin wrote: > > > How many of those 800 ports are actually necessary and used? > > > It would be better to get generate a complete list of your > > > installed ports, use pkg_deinstall or pkg_delete to remove > > > all ports, and then selectively re-install ports that are > > > actually used. > > > > Xorg takes up ~200 ports alone (not including dependencies like perl, > > etc.) since the Xorg decided release engineering was too hard. Throw > > in things like KDE, OOo, Firefox, etc. for a desktop and you can get > > a fairly high package count. :-/ > > Ooh I only have 1315 on mine, but a 1.4GHz Pentium-M is pretty slow > these days :( > > Perhaps there needs to be a psuedo port for 'base' (or a few) so that > you can easily determine if you have already upgraded something against > the new base you installed. > > Certainly I find it difficult to leave my laptop on for long enough to > recompile everything when I upgrade -current (since I actually use it > for work), and portupgrade -fa has no way to tell if it's already done > something. If there were pseudo base ports you could tell it to force > upgrade everything that depends on the old base port and it would DTRT. I wrapped portmaster, since -af has the same problem when something screws the build (mostly plist problems and $me wanting backup packages, but also classics like using sudo as PM_SU_CMD and trying to reinstall it). Basically, I made a list of all the installed ports and sorted dep order, then called portmaster -u for every port and if successful put an empty file +PM_DONE in /var/db/pkg//. On a restart the ports containing a +PM_DONE file are skipped. If the entire process finishes successfully, all +PM_DONE files are removed. I briefly looked into building it into portmaster, but that looked to take longer then I had time for. The main loop is at the bottom, perhaps Doug likes the idea and has the time to integrate it. > I, of course, have no patches for such a thing :) > > I've deleted /usr/local & /var/db/pkg in the past, it can be very > therapeutic :) However it is not so good when your mp3 collection is > mounted on /usr/local/mp3 and you forgot to unmount it first.. :( Or your websites in /usr/local/www, your database in /usr/local/pgsql or your squid conf and cache in /usr/local/squid. Especially when pkg_delete -af does the right thing and leaves all this in tact, I don't see the value of rm -rf /usr/local, other then a few minutes on a process that's likely going to be several hours or days. -- Mel mark_done() { local _name _name=$1 if test -d ${PKG_DBDIR}/${_name}; then ${SUDO} ${TOUCH} ${PKG_DBDIR}/${_name}/+PM_DONE else return 1; fi return 0; } for origin in ${LIST}; do pkgname=$(make -C ${PORTSDIR}/${origin} -V PKGNAME) if test -f ${PKG_DBDIR}/${pkgname}/+PM_DONE; then echo "Already done: ${pkgname} (${LOOP}/${TOTAL})" else echo "===> Building ${pkgname}" portmaster -u ${PORTSDIR}/${origin} if test $? -eq 0; then mark_done ${pkgname} || safe_abort else FAILED=$((${FAILED} + 1)) echo "Failed, continue? [n]" read CONT case "${CONT}" in [yY]|[yY][eE]|[yY][eE][sS]) echo "===> Marking state as done" mark_done ${pkgname} || safe_abort ;; *) break;; esac fi fi done if test ${FAILED} -eq 0; then echo "===> Removing state files" for FILE in ${PKG_DBDIR}/*/+PM_DONE; do ${SUDO} /bin/rm ${FILE} done echo "===> Removing origin list" /bin/rm ${LISTFILE} fi From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 07:57:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CF40106564A; Fri, 24 Jul 2009 07:57:46 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (cl-1361.ams-04.nl.sixxs.net [IPv6:2001:960:2:550::2]) by mx1.freebsd.org (Postfix) with ESMTP id 600548FC16; Fri, 24 Jul 2009 07:57:46 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from hyperion.scode.org (hyperion.scode.org [85.17.42.115]) by hyperion.scode.org (Postfix) with ESMTPS id 627DE23C492; Fri, 24 Jul 2009 09:57:45 +0200 (CEST) Date: Fri, 24 Jul 2009 09:57:44 +0200 From: Peter Schuller To: John Baldwin Message-ID: <20090724075743.GA98885@hyperion.scode.org> References: <20090722171741.GB17684@hyperion.scode.org> <200907231321.10866.jhb@freebsd.org> <20090723175620.GA63961@hyperion.scode.org> <200907231534.03971.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline In-Reply-To: <200907231534.03971.jhb@freebsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: vm_page_remove() crash on sys_exit() (possibly ZFS related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 07:57:46 -0000 --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > > Broken RAM would be good news :) I'll run some memtests and see if I > > can trigger anything, though it would be somewhat of a co-incidence. >=20 > I have seen many similar (although not quite identical) panics caused by > bad RAM in the past which is why I suggested it. Sure. It passed one memtest86+ pass, but I'll see about running it for longer when possible. --=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkppaXcACgkQDNor2+l1i32nEQCeMZ69ELRe946/ntmQ56ccYkdB dIQAoIW9+gVwrFdpyKraqVBt/Cj0vvfG =33ej -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 12:27:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ACAC1065674; Fri, 24 Jul 2009 12:27:02 +0000 (UTC) (envelope-from wael.nasreddine@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 77F418FC20; Fri, 24 Jul 2009 12:27:01 +0000 (UTC) (envelope-from wael.nasreddine@gmail.com) Received: by fxm18 with SMTP id 18so1375202fxm.43 for ; Fri, 24 Jul 2009 05:27:00 -0700 (PDT) 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 :content-type; bh=T54k/8zKeQQhWYsoDEcYZkiwPWuO/W7GgM7uHQI6iBA=; b=jgaaBObL6L8Kt16ugBKBHE6U9VooqQpZOqhBxWJObwWdnDy1Nb2k7NeJZ+2yrbAYG7 YQ7T0kd+kDE+6wW5NHqDuY2Dhfg5dINIj3oOQMPnxCeJVfmCImKbqxRhqxsT+VbJHxJB qzQZK4Eaxaohygm9uxIxQUDEmsTzT3aeh3TCU= 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:content-type; b=oiKncsGjvJHU/gbNrOft3V+QRDmsNSyp4IV446uJCzIuAgSlQeCo0P7dUEXg9t0q0f oE/QIs0j15W6/rby2kPM7O/yUI+6WeyShSQKyFJxFI3jhUMj3qQ4YzzUk3yHMUWBuCXu pDSaBFU3vB1CbMfSTPoDAQo4Cx7VIA+BFxDbg= MIME-Version: 1.0 Sender: wael.nasreddine@gmail.com Received: by 10.103.220.18 with SMTP id x18mr1711786muq.107.1248438420315; Fri, 24 Jul 2009 05:27:00 -0700 (PDT) In-Reply-To: References: From: "Wael Nasreddine (a.k.a eMxyzptlk)" Date: Fri, 24 Jul 2009 14:26:40 +0200 X-Google-Sender-Auth: d5c67fccccf0e9ce Message-ID: To: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-hardware@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: FreeBSD + HP Pavilion DV7-1299EF, Pre-install questions. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 12:27:03 -0000 >From what I gathered on the net, the problem seems to be coming from Firewire, or more specifically, the sdp module, They suggested disabling Firewire from BIOS setup, install then build a custom kernel with sdp commented, the problem is, There's no option to disable Firewire in my BIOS setup so I'm back to square 1. Anyone knows how can I boot (from DVD !!) with sdp disabled ?? Thanks References: http://lists.freebsd.org/pipermail/freebsd-questions/2009-May/198376.html http://lists.freebsd.org/pipermail/freebsd-questions/2009-May/198410.html http://www.nabble.com/run_interrupt_driven_hooks:-still-waiting-after-300-seconds-for-xpt_config-td23492390.html On Tue, Jul 21, 2009 at 10:52 PM, Wael Nasreddine (a.k.a eMxyzptlk) < mla@nasreddine.com> wrote: > I have a problem booting the DVD on this laptop, with ACPI enabled, it > crashes after the usb part, check the screenshot > http://omploader.org/vMjBqbA > > I tried with ACPI disabled, the whole system stops responding even > before the USB part. > > On Tue, Jul 21, 2009 at 4:58 PM, Wael Nasreddine (a.k.a eMxyzptlk) > wrote: > > > > Hello, > > > > I recently bought an HP Pavilion DV7-1299EF, it's 2.4Ghz Core 2 DUO, 4G > RAM, 2x250 Gb Hard Disk > > > > ------- lspci > > 00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory > Controller Hub (rev 07) > > 00:01.0 PCI bridge: Intel Corporation Mobile 4 Series Chipset PCI Express > Graphics Port (rev 07) > > 00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI > Controller #4 (rev 03) > > 00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI > Controller #5 (rev 03) > > 00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI > Controller #2 (rev 03) > > 00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio > Controller (rev 03) > > 00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express > Port 1 (rev 03) > > 00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express > Port 2 (rev 03) > > 00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express > Port 3 (rev 03) > > 00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express > Port 4 (rev 03) > > 00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express > Port 5 (rev 03) > > 00:1c.5 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express > Port 6 (rev 03) > > 00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI > Controller #1 (rev 03) > > 00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI > Controller #2 (rev 03) > > 00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI > Controller #3 (rev 03) > > 00:1d.3 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI > Controller #6 (rev 03) > > 00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI > Controller #1 (rev 03) > > 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93) > > 00:1f.0 ISA bridge: Intel Corporation ICH9M LPC Interface Controller (rev > 03) > > 00:1f.2 SATA controller: Intel Corporation ICH9M/M-E SATA AHCI Controller > (rev 03) > > 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller > (rev 03) > > 01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9600M > GT] (rev a1) > > 02:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN > [Shiloh] Network Connection > > 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. > RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 02) > > 06:00.0 FireWire (IEEE 1394): JMicron Technology Corp. IEEE 1394 Host > Controller > > 06:00.1 System peripheral: JMicron Technology Corp. SD/MMC Host > Controller > > 06:00.2 SD Host controller: JMicron Technology Corp. Standard SD Host > Controller > > 06:00.3 System peripheral: JMicron Technology Corp. MS Host Controller > > 06:00.4 System peripheral: JMicron Technology Corp. xD Host Controller > > ------- lspci > > > > What is critical for me is: > > > > Wifi: Intel 5100 AGN > > Graphics: Nvidia Geforce 9600M GT Resolution: 1440x900 > > Sound: Intel High definition Audio, Codec: IDT 92HD71B7X > > > > Since I have 2x250Gb, I would like to use ZFS, I heard FreeBSD can boot > from ZFS now, is it stable ? > > > > Thanks in advance for your feedback. > > > > -- > > Wael Nasreddine > > > > Blog : http://wael.nasreddine.com > > E-mail : wael.nasreddine@gmail.com > > gTalk : wael.nasreddine@gmail.com > > Tel : +33.6.32.94.70.13 > > Skype : eMxyzptlk > > Twitter : @eMxyzptlk > > > > Sabayon Linux Chief Development Officer - http://www.sabayonlinux.org > > > > PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 DE12 5565 3945 C8DD 18A2 > > > > .: An infinite number of monkeys typing into GNU emacs, > > would never make a good program. (L. Torvalds 1995) :. > > > > > > -- > Wael Nasreddine > > Blog : http://wael.nasreddine.com > E-mail : wael.nasreddine@gmail.com > gTalk : wael.nasreddine@gmail.com > Tel : +33.6.32.94.70.13 > Skype : eMxyzptlk > Twitter : @eMxyzptlk > > Sabayon Linux Chief Development Officer - http://www.sabayonlinux.org > > PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 DE12 5565 3945 C8DD 18A2 > > .: An infinite number of monkeys typing into GNU emacs, > would never make a good program. (L. Torvalds 1995) :. > -- Wael Nasreddine Blog : http://wael.nasreddine.com E-mail : wael.nasreddine@gmail.com gTalk : wael.nasreddine@gmail.com Tel : +33.6.32.94.70.13 Skype : eMxyzptlk Twitter : @eMxyzptlk Sabayon Linux Chief Development Officer - http://www.sabayonlinux.org PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 DE12 5565 3945 C8DD 18A2 .: An infinite number of monkeys typing into GNU emacs, would never make a good program. (L. Torvalds 1995) :. From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 12:39:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C082106566B; Fri, 24 Jul 2009 12:39:52 +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 392878FC0A; Fri, 24 Jul 2009 12:39:51 +0000 (UTC) (envelope-from avg@icyb.net.ua) 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 PAA20586; Fri, 24 Jul 2009 15:39:46 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A69AB91.2010208@icyb.net.ua> Date: Fri, 24 Jul 2009 15:39:45 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Maksim Yevmenkin , Hans Petter Selasky References: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> <200907152236.58049.hselasky@c2i.net> <20090720215141.GL49724@elvis.mu.org> <200907211420.33571.hselasky@c2i.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@freebsd.org, freebsd-current@freebsd.org, Andrew Thompson Subject: Re: USB polling (75% done) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 12:39:52 -0000 on 23/07/2009 21:23 Maksim Yevmenkin said the following: > On Tue, Jul 21, 2009 at 5:20 AM, Hans Petter Selasky wrote: >> On Monday 20 July 2009 23:51:41 Alfred Perlstein wrote: >>> * Hans Petter Selasky [090715 13:37] wrote: ... >>>> Using USB keyboard in KDB: Does not work because Giant is not locked when >>>> calling into the UKBD's get char routine. UKBD is Giant locked. Someone >>>> familiar with the keyboard system on FreeBSD please step forward and fix >>>> this so that UKBD gets independent of the Giant mutex. >>> the ukbd driver needs giant? >> I think the keyboard mux is under Giant, and does not have any concept about >> mutexes. Most simple solution would be that DDB locks Giant before entering >> into the keyboard code. > > as i understand it, keyboard drivers (and kbdmux(4) is a keyboard > driver), can/should not use any locks. period. so whatever calls into > keyboard driver should take care of locking. Maybe I am missing something but I do not see any explicit locking or lock assertions in kbdmux code. All lock defines are under #if 0. kbdmux does use taskqueue_swi_giant though. Tasks are queued on it in kbdmux_kbd_intr_timo (periodic callout) and in kbdmux_kbd_event (kbd callback). But, these shouldn't get called in polling mode, right? (because there shouldn't be any interrupts) Maybe Giant asserts in ukbd are not needed? Or should be asserted only in "normal" mode? P.S. I am far from knowing this area, just got curious. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 13:36:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 61F841065670 for ; Fri, 24 Jul 2009 13:36:58 +0000 (UTC) (envelope-from raszobbi@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id D56188FC08 for ; Fri, 24 Jul 2009 13:36:57 +0000 (UTC) (envelope-from raszobbi@gmail.com) Received: by fxm18 with SMTP id 18so1411261fxm.43 for ; Fri, 24 Jul 2009 06:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=D3+MWyf4zTq4JpVFUdIFR5l98WxX/D1pEkWYKnDWcWg=; b=wCOrL8WZDwoL23NsxxK1FjTVySbRidTP0yVyzx/NNaEq07njj57NJuF8Az4gkKgbD0 m/Lnc2bI55U6jqC3/Sa0s03pqwVBsUuhrM6YblQv9MO3rsAeKe1Ev7+dXTsdRL/ZJXuA tq29wxp3bq7KOXKdXeBPXMEBN/ZabS19SwSgI= 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=neW4r3wqYDMHaWNGhbAEVZW3lhtjKnIf6fy7Oy1CwPnlLj/7G8edFA/JL1DTd27KLj cT0TzyICI3bOp2IGxcgozSLoy6MXDwCiy6qO1AZZFlX3PoJkXQxYI8ZoWP/GwoK3cmLi PcvmPKK5NZQooP06HFiYFeqysUFe/+nHk7TvA= Received: by 10.204.59.73 with SMTP id k9mr3203384bkh.167.1248441381566; Fri, 24 Jul 2009 06:16:21 -0700 (PDT) Received: from ilras.barsh (c66-139.i05-17.onvol.net [88.203.66.139]) by mx.google.com with ESMTPS id 12sm4988800fks.21.2009.07.24.06.16.19 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Jul 2009 06:16:20 -0700 (PDT) Message-ID: <4A69B422.20309@gmail.com> Date: Fri, 24 Jul 2009 15:16:18 +0200 From: "m.c" User-Agent: Thunderbird 2.0.0.22 (X11/20090723) MIME-Version: 1.0 To: Yoshihiro Ota References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> <49A04510.5030405@FreeBSD.org> <7d6fde3d0902211356h66b05cfcxf2ebbe9b2a6fd0f0@mail.gmail.com> <20090224004110.e4ad76f4.ota@j.email.ne.jp> <49A45127.3000108@FreeBSD.org> <20090225211656.75c546c3.ota@j.email.ne.jp> <49A6F609.20901@FreeBSD.org> <20090226223106.b56ad289.ota@j.email.ne.jp> <49A7D1C2.6070608@FreeBSD.org> <20090228015207.d7432c0a.ota@j.email.ne.jp> <20090723153734.e1a8bff1.ota@j.email.ne.jp> <4A68BDD7.60408@FreeBSD.org> <20090723172423.0337cf35.ota@j.email.ne.jp> In-Reply-To: <20090723172423.0337cf35.ota@j.email.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD Current Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 13:36:58 -0000 Yoshihiro Ota wrote: > On Thu, 23 Jul 2009 22:45:27 +0300 > Alexander Motin wrote: > > >> Yoshihiro Ota wrote: >> >>> This problem was gone once back in Febrary. >>> >>> I was away from 8-current and came back to 8-BETA1/2. >>> Then, now I hear this noise again. >>> >>> Alexander, do you have any ideas for this time, too? >>> >> Can you remind me what are you talking about? You are talking about some >> noise, but following messages about detection problems. >> > > > I currently have a problem. > The problem is some mysterious sound like szzzz..... in very low tone and low volume. > However, it is noticeable and somewhat destructing. > I usually use 7.1-RELEASE, but as 8.0 being in BETA, I installed 8-BETA1 and BETA2. > Both of these versions has this noise. > > The noise is very much like the same noise I experienced back in February. > At that time, you, Alexander, fixed the problem. > I had had used 8-CURRENT until end of April but I was away until this time. > Because the symptom was smiler, I decided to reply to the old e-mail chain > Sorry to butt in, but saw this post recently and have some possibly related problem with sound on amd64 8 beta2 but snd_ich driver. the driver is ok it seems, but the sound produced is distorted; to the point i thought my speakers had died. i dual boot fedora 10 and they sound fine there, even directly hooking up the ipod eliminated the thought. i don't post here cuz i am a noob and just trying to learn something, but noticed the distortion first time i installed beta1, (now updated to beta 2 yesterday), unless i need some settings i didn't need in 7.x. From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 13:42:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DFDE106564A; Fri, 24 Jul 2009 13:42:45 +0000 (UTC) (envelope-from raszobbi@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 5226C8FC17; Fri, 24 Jul 2009 13:42:44 +0000 (UTC) (envelope-from raszobbi@gmail.com) Received: by fxm18 with SMTP id 18so1414368fxm.43 for ; Fri, 24 Jul 2009 06:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=geHwxzD7op5nJUvj1gQL91tFVfFgaq0RVbfjCgNNo94=; b=xc1Tfvr+YA8zFxsU0x6kEvr65hnb9q68sPK2LgLR9xCsdGUgex+hh29S5uy9/x5dQ4 5rKgNiLzqS5cyxej0ohXIOygcw+V4fqJzKeaEpOEsSppZAJuGk1NX/7l8tK7x8AW9aPP R+DUJ8pStMlenWWiEOuwDeV+csn1NibiUQQ6Y= 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=BaVBS9JzghdiIO2oGcSVsLY8sbN3dKL2qwW8UN7oErwzfgQuVQieq6SRcL0awtuVw8 adpqbFtBj1uJq1oi/UwtZrxOSMZ5Jt35iJ05F1lVLiR5CYX1+PF8WWdM69llrkB4ulia MBSEHzAHVHiYd0eBdpe6vKBlqvWpAFVK+t2Mg= Received: by 10.204.102.133 with SMTP id g5mr3256612bko.180.1248442963466; Fri, 24 Jul 2009 06:42:43 -0700 (PDT) Received: from ilras.barsh (c66-139.i05-17.onvol.net [88.203.66.139]) by mx.google.com with ESMTPS id 22sm5009507fkr.30.2009.07.24.06.42.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Jul 2009 06:42:42 -0700 (PDT) Message-ID: <4A69BA51.1020502@gmail.com> Date: Fri, 24 Jul 2009 15:42:41 +0200 From: "m.c" User-Agent: Thunderbird 2.0.0.22 (X11/20090723) MIME-Version: 1.0 To: Yoshihiro Ota References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> <49A04510.5030405@FreeBSD.org> <7d6fde3d0902211356h66b05cfcxf2ebbe9b2a6fd0f0@mail.gmail.com> <20090224004110.e4ad76f4.ota@j.email.ne.jp> <49A45127.3000108@FreeBSD.org> <20090225211656.75c546c3.ota@j.email.ne.jp> <49A6F609.20901@FreeBSD.org> <20090226223106.b56ad289.ota@j.email.ne.jp> <49A7D1C2.6070608@FreeBSD.org> <20090228015207.d7432c0a.ota@j.email.ne.jp> <20090723153734.e1a8bff1.ota@j.email.ne.jp> <4A68BDD7.60408@FreeBSD.org> <20090723172423.0337cf35.ota@j.email.ne.jp> In-Reply-To: <20090723172423.0337cf35.ota@j.email.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD Current Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 13:42:45 -0000 nevermind, it is no problem with base system, sound is ok from concole mpg123 and most formats/ bitrate. From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 13:52:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78A6F106564A; Fri, 24 Jul 2009 13:52:22 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id A94D48FC0A; Fri, 24 Jul 2009 13:52:21 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=gg2W7PyvkLb8p4ie143lBA==:17 a=MlYEcbAALPz4MxP3jM0A:9 a=t3bJZxhF-4o3L-C5tUAA:7 a=xhwv4h41celMEzYuf8v6XQfrCiIA:4 Received: from [194.248.135.20] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 229864229; Fri, 24 Jul 2009 15:52:20 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 24 Jul 2009 15:52:08 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> <4A69AB91.2010208@icyb.net.ua> In-Reply-To: <4A69AB91.2010208@icyb.net.ua> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907241552.10763.hselasky@c2i.net> Cc: usb@freebsd.org, Andriy Gapon , Andrew Thompson , Maksim Yevmenkin Subject: Re: USB polling (75% done) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 13:52:23 -0000 On Friday 24 July 2009 14:39:45 Andriy Gapon wrote: > Maybe Giant asserts in ukbd are not needed? Option 1) They are needed as long as ukbd is not allowed to lock Giant when it needs it. Like when you are at the console and have Scroll-Lock pressed, and then something is printed, then printf() will directly call into the keyboard layer, to disable scroll lock and its associated LED. Locking Giant from a sub-routine of printf() is not smart and leads to LOR's. Having an AT-keyboard you can always peek or poke a port directly, but an USB-keyboard is quite more advanced. And like some other guy pointed out recently: In some cases the keyboard gets enabled without Giant locked, even though that is a requirement. Option 2) Some work is needed to get the non-USB part of the statemachine in ukbd out of Giant. I'm not a kbdmux expert either. I don't have the full overview from where the variables in the ukbd's keyboard state can be read and written, and which fields in the ukbd's keyboard state needs to remain Giant locked due to kbdmux and kbd. That's basically what is stopping me from converting ukbd free of Giant. Option 3) Assume that the kernel never panics :-) --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 18:19:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B3FD1065670 for ; Fri, 24 Jul 2009 18:19:48 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: from smtp127.rog.mail.re2.yahoo.com (smtp127.rog.mail.re2.yahoo.com [206.190.53.32]) by mx1.freebsd.org (Postfix) with SMTP id D36DC8FC17 for ; Fri, 24 Jul 2009 18:19:47 +0000 (UTC) (envelope-from gtodd@bellanet.org) Received: (qmail 71882 invoked from network); 24 Jul 2009 17:53:07 -0000 Received: from unknown (HELO wawanesa.iciti.ca) (gtodd@99.246.61.82 with login) by smtp127.rog.mail.re2.yahoo.com with SMTP; 24 Jul 2009 17:53:07 -0000 X-YMail-OSG: CDzZCqcVM1kH681DJWJ.2enKyPUMRwxBXKlgBC4v.wsVzyR.xKbwWMkXg_RQYJbgBQ-- X-Yahoo-Newman-Property: ymail-3 Received: from wawanesa.iciti.ca (wawanesa.iciti.ca [192.168.2.4]) by wawanesa.iciti.ca (Postfix) with ESMTP id EBB6C36; Fri, 24 Jul 2009 13:53:20 -0400 (EDT) Message-ID: <4A69F510.8070702@bellanet.org> Date: Fri, 24 Jul 2009 13:53:20 -0400 From: Graham Todd User-Agent: Thunderbird 2.0.0.21 (X11/20090511) MIME-Version: 1.0 To: Emil Mikulic References: <451cb3010907181027q13d5c345w8962a648c7682ed8@mail.gmail.com> <20090724005912.GB89091@dmr.ath.cx> In-Reply-To: <20090724005912.GB89091@dmr.ath.cx> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: McLone , Thomas Backman , FreeBSD current Subject: Re: [bug] ZFS zvol dev entry disappearing upon reboot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 18:19:48 -0000 Emil Mikulic wrote: > On Thu, Jul 23, 2009 at 09:31:19AM +0200, Thomas Backman wrote: >> OK, I've found the problem we have here... Or, rather, I've found the >> *reason* (and this shows why I previously said I couldn't reproduce). I >> haven't found it in source, though. >> >> UFS filesystems in fstab are mounted *before* the /dev/zvol directory is >> populated, at least on my system! > > I remember running into this! I tried to solve it using the "late" > mount flag in fstab but couldn't get it working. > > In the end I just stuck a bunch of manual "mount" commandlines in > /etc/rc.local. What a cop-out. :( Ditto. I ended up using the same approach with a script called from rc.local - "late" didn't work for me because /dev/zvol wasn't there yet. This was in the first release of FreeBSD that included zfs. I believe the rc.local workaround is still in use on the system in question (now running CURRENT). From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 18:43:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E29810656CA for ; Fri, 24 Jul 2009 18:43:59 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id DE1248FC20 for ; Fri, 24 Jul 2009 18:43:58 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 249677873; Fri, 24 Jul 2009 21:43:55 +0300 Message-ID: <4A6A00E9.8020106@FreeBSD.org> Date: Fri, 24 Jul 2009 21:43:53 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Yoshihiro Ota References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> <49A04510.5030405@FreeBSD.org> <7d6fde3d0902211356h66b05cfcxf2ebbe9b2a6fd0f0@mail.gmail.com> <20090224004110.e4ad76f4.ota@j.email.ne.jp> <49A45127.3000108@FreeBSD.org> <20090225211656.75c546c3.ota@j.email.ne.jp> <49A6F609.20901@FreeBSD.org> <20090226223106.b56ad289.ota@j.email.ne.jp> <49A7D1C2.6070608@FreeBSD.org> <20090228015207.d7432c0a.ota@j.email.ne.jp> <20090723153734.e1a8bff1.ota@j.email.ne.jp> <4A68BDD7.60408@FreeBSD.org> <20090723172423.0337cf35.ota@j.email.ne.jp> In-Reply-To: <20090723172423.0337cf35.ota@j.email.ne.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 18:43:59 -0000 Yoshihiro Ota wrote: > The problem is some mysterious sound like szzzz..... in very low tone and low volume. > However, it is noticeable and somewhat destructing. > I usually use 7.1-RELEASE, but as 8.0 being in BETA, I installed 8-BETA1 and BETA2. > Both of these versions has this noise. > > The noise is very much like the same noise I experienced back in February. > At that time, you, Alexander, fixed the problem. > I had had used 8-CURRENT until end of April but I was away until this time. > Because the symptom was smiler, I decided to reply to the old e-mail chain. Sorry, I don't remember what have I done that time, if it really was me. I have reread that thread and haven't found anything except assumptions that it can be radio interference due to low quality power filtering or something alike. May be "szzzz..." is just the sound of your disk, CPU, CPU bus, some power converter, or whatever else. It may depend for example on powerd running or system load, or C-state used or whatever else unrelated. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 19:14:28 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 52B1810656D9; Fri, 24 Jul 2009 19:14:27 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Tim Kientzle Date: Fri, 24 Jul 2009 15:14:16 -0400 User-Agent: KMail/1.6.2 References: <4A615602.4090000@freebsd.org> <200907231903.46474.jkim@FreeBSD.org> <4A694DBB.8080800@freebsd.org> In-Reply-To: <4A694DBB.8080800@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907241514.18806.jkim@FreeBSD.org> Cc: freebsd-current@FreeBSD.org Subject: Re: Joliet and release ISOs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 19:14:36 -0000 On Friday 24 July 2009 01:59 am, Tim Kientzle wrote: > Jung-uk Kim wrote: > > The "--options=!joliet" trick didn't work for me: > > > > # uname -mrs > > FreeBSD 8.0-BETA2 amd64 > > # tar -x --options=!joliet -p -f ../8.0-BETA2-amd64-livefs.iso > > # cd rescue > > # ls -il > > total 4204 > > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 [ > > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 > > atacontrol 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 > > 17:09 atmconfig 3326283 -r-xr-xr-x 131 root wheel 4485472 7 > > 15 17:09 badsect ... > > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 whoami > > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 zcat > > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 zfs > > 3326283 -r-xr-xr-x 131 root wheel 4485472 7 15 17:09 zpool > > # file atacontrol > > atacontrol: data > > # hexdump atacontrol > > 0000000 0000 0000 0000 0000 0000 0000 0000 0000 > > * > > 0447160 > > Try the attached patch; I believe this corrects the > reading of hardlinks from iso9660 images. Thanks, that did it! Still, there is one minor annoyance: %ls -l test total 0 lrwxr-xr-x 1 jkim staff 1 7 24 14:54 link1 -> / lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link2 -> // lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link3 -> /. lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link4 -> ./ lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link5 -> .. lrwxr-xr-x 1 jkim staff 4 7 24 14:56 link6 -> /tmp lrwxr-xr-x 1 jkim staff 5 7 24 14:56 link7 -> //tmp lrwxr-xr-x 1 jkim staff 4 7 24 14:56 link8 -> tmp/ lrwxr-xr-x 1 jkim staff 5 7 24 14:56 link9 -> /tmp/ %sh /usr/src/release/amd64/mkisoimages.sh test test.iso test Total translation table size: 0 Total rockridge attributes bytes: 1045 Total directory bytes: 0 Path table size(bytes): 10 Max brk space used 0 181 extents written (0 MB) %tar -t --options=\!joliet -v -f test.iso drwx------ 0 0 0 2048 7 24 14:56 . lr-xr-xr-x 1 0 0 0 7 24 14:56 link9 -> //tmp/ lr-xr-xr-x 1 0 0 0 7 24 14:56 link8 -> tmp/ lr-xr-xr-x 1 0 0 0 7 24 14:56 link7 -> ///tmp lr-xr-xr-x 1 0 0 0 7 24 14:56 link6 -> //tmp lr-xr-xr-x 1 0 0 0 7 24 14:55 link5 -> .. lr-xr-xr-x 1 0 0 0 7 24 14:55 link4 -> ./ lr-xr-xr-x 1 0 0 0 7 24 14:55 link3 -> //. lr-xr-xr-x 1 0 0 0 7 24 14:55 link2 -> /// lr-xr-xr-x 1 0 0 0 7 24 14:54 link1 -> / Note there is an additional `/' when the link has a leading `/' (but not just `/'), i.e., `//' => `///', `/.' => `//.', `/tmp' => `//tmp', `//tmp' => `///tmp'. For FreeBSD CD-ROMs, `stand -> /rescue' becomes `stand -> //rescue', etc. Can you take a look at it, too? Thanks a lot! Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Fri Jul 24 19:34:16 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B2B1106564A for ; Fri, 24 Jul 2009 19:34:16 +0000 (UTC) (envelope-from wtf.jlaine@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 0236F8FC0A for ; Fri, 24 Jul 2009 19:34:15 +0000 (UTC) (envelope-from wtf.jlaine@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so173252fgb.12 for ; Fri, 24 Jul 2009 12:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:mail-followup-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-operating-system; bh=lwv6A04W2eoOhhCajt6btKa/s9BUqViXDTpZ26Gq9H8=; b=wSozDmVMBVmHUv7WFBUOnKgFlapF6vXlfk2UxRgNaJJCNsgXq8kSjSEXpwVtCTyXrL /8AJ9oimvZEJAZs4EeQq9ioSrCCUV6paMkQhShS+Tekdz8/6H0Ed0mObKAJlgdWg8MDa /riwhtYHuX1vyspmiVa1kdtgEtDiXpBwlttjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:x-operating-system; b=aBEqO5FU6ftkRJ9sa8wmYbir7Gp8ckZVJQ9BfZ0LrEOMoI56wJpX9D3Wax8W8BAc6/ 9EyLJ39Ky1crPDhbbkrhr0iSfAAeVLfUzjTe27mQdCqskCIrJ6TblnhtAWZHmBO77wAq NfqcJTcHXHut++YWKGUSZNrM57svKkG3d6Pv8= Received: by 10.86.70.20 with SMTP id s20mr36614fga.64.1248464054989; Fri, 24 Jul 2009 12:34:14 -0700 (PDT) Received: from aperture_lab ([77.66.145.99]) by mx.google.com with ESMTPS id e11sm3292386fga.6.2009.07.24.12.34.12 (version=SSLv3 cipher=RC4-MD5); Fri, 24 Jul 2009 12:34:14 -0700 (PDT) Received: by aperture_lab (sSMTP sendmail emulation); Fri, 24 Jul 2009 23:34:09 +0400 Date: Fri, 24 Jul 2009 23:34:09 +0400 From: Jeff Laine To: Hans Petter Selasky Message-ID: <20090724193409.GA1692@free.bsd.loc> Mail-Followup-To: Jeff Laine , Hans Petter Selasky , current@freebsd.org References: <200907232109.04094.hselasky@c2i.net> <200907232132.41400.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907232132.41400.hselasky@c2i.net> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-BETA2 i386 Cc: current@freebsd.org Subject: Re: 8-current + USB CD-ROM drive + CAM layer audio extraction from CD (regression) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 19:34:16 -0000 On Thu,07/23/09 [21:32:39], Hans Petter Selasky wrote: > On Thursday 23 July 2009 21:09:02 Hans Petter Selasky wrote: > > Hi, > > > > I have a CD I want to extract audio from, giving me trouble this time. > > Plugging the USB CD-ROM into a MAC allows for instant audio playback. I'm > > pretty sure that digital audio extraction works. The USB CD-ROM drive is > > made by Samsung. The CD is made by forefront/EMI. > > > > At first I thought that this is another example of record labels making > > deals with hardware manufacturers, but I'm leaving a chance it might be a > > bug in the CAM layer. > > > > This is an regression issue introduced during the last month. I tested more > CD's and none can be played back via digital audio extraction :-( > > With an older 8-current kernel it works. > > --HPS > The same with my Lite-On USB multi-recorder: ... umass0:3:0:-1: Attached to scbus3 cd1 at umass-sim0 bus 0 target 0 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 40.000MB/s transfers cd1: cd present [2280432 x 2048 byte records] $ camcontrol -f /dev/cd1 play $ dmesg ... cd0: FAILURE - PLAY_12 ILLEGAL REQUEST asc=0x64 ascq=0x00 (cd0:ata1:0:0:0): PLAY AUDIO(12). CDB: a5 0 0 0 0 0 0 6 dd 39 0 0 (cd0:ata1:0:0:0): CAM Status: SCSI Status Error (cd0:ata1:0:0:0): SCSI Status: Check Condition (cd0:ata1:0:0:0): ILLEGAL REQUEST asc:64,0 (cd0:ata1:0:0:0): Illegal mode for this track (cd0:ata1:0:0:0): Unretryable error No sound, though the disk is actually 'playing' inside. -- Best regards, Jeff | "Nobody wants to say how this works. | | Maybe nobody knows ..." | | Xorg.conf(5) | From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 04:19:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B93A6106566B; Sat, 25 Jul 2009 04:19:46 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from kientzle.com (kientzle.com [66.166.149.50]) by mx1.freebsd.org (Postfix) with ESMTP id 74D248FC1B; Sat, 25 Jul 2009 04:19:46 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n6P4JkPD049800; Fri, 24 Jul 2009 21:19:46 -0700 (PDT) (envelope-from kientzle@freebsd.org) Received: from dark.x.kientzle.com (fw2.kientzle.com [10.123.1.2]) by kientzle.com with SMTP id n6hxvta25d67u4e8svipmwkt5w; Fri, 24 Jul 2009 21:19:45 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A6A87E1.8030504@freebsd.org> Date: Fri, 24 Jul 2009 21:19:45 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.21) Gecko/20090601 SeaMonkey/1.1.16 MIME-Version: 1.0 To: Jung-uk Kim References: <4A615602.4090000@freebsd.org> <200907231903.46474.jkim@FreeBSD.org> <4A694DBB.8080800@freebsd.org> <200907241514.18806.jkim@FreeBSD.org> In-Reply-To: <200907241514.18806.jkim@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------060103060203010600040401" Cc: freebsd-current@freebsd.org Subject: Re: Joliet and release ISOs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 04:19:47 -0000 This is a multi-part message in MIME format. --------------060103060203010600040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jung-uk Kim wrote: > > Still, there is one minor annoyance: > > %ls -l test > total 0 > lrwxr-xr-x 1 jkim staff 1 7 24 14:54 link1 -> / > lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link2 -> // > lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link3 -> /. > lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link4 -> ./ > lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link5 -> .. > lrwxr-xr-x 1 jkim staff 4 7 24 14:56 link6 -> /tmp > lrwxr-xr-x 1 jkim staff 5 7 24 14:56 link7 -> //tmp > lrwxr-xr-x 1 jkim staff 4 7 24 14:56 link8 -> tmp/ > lrwxr-xr-x 1 jkim staff 5 7 24 14:56 link9 -> /tmp/ > %tar -t --options=\!joliet -v -f test.iso > drwx------ 0 0 0 2048 7 24 14:56 . > lr-xr-xr-x 1 0 0 0 7 24 14:56 link9 -> //tmp/ > lr-xr-xr-x 1 0 0 0 7 24 14:56 link8 -> tmp/ > lr-xr-xr-x 1 0 0 0 7 24 14:56 link7 -> ///tmp > lr-xr-xr-x 1 0 0 0 7 24 14:56 link6 -> //tmp > lr-xr-xr-x 1 0 0 0 7 24 14:55 link5 -> .. > lr-xr-xr-x 1 0 0 0 7 24 14:55 link4 -> ./ > lr-xr-xr-x 1 0 0 0 7 24 14:55 link3 -> //. > lr-xr-xr-x 1 0 0 0 7 24 14:55 link2 -> /// > lr-xr-xr-x 1 0 0 0 7 24 14:54 link1 -> / > > Note there is an additional `/' when the link has a leading `/' (but > not just `/'), i.e., `//' => `///', `/.' => `//.', `/tmp' => `//tmp', > `//tmp' => `///tmp'. For FreeBSD CD-ROMs, `stand -> /rescue' becomes > `stand -> //rescue', etc. Here's another patch for you to try; this changes how libarchive parses Rockridge "SL" extensions. Cheers, Tim P.S. Could you email me privately the "test.iso" image you created on your machine? I tried creating one here and get slightly different behavior. Also, what version of mkisofs do you have installed on your machine? --------------060103060203010600040401 Content-Type: text/x-patch; name="libarchive_iso9660_symlink.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="libarchive_iso9660_symlink.patch" Index: archive_read_support_format_iso9660.c =================================================================== --- archive_read_support_format_iso9660.c (revision 195838) +++ archive_read_support_format_iso9660.c (working copy) @@ -1174,12 +1175,12 @@ parse_rockridge_SL1(struct file_info *file, const unsigned char *data, int data_length) { - int component_continues = 1; + const char *separator = ""; - if (!file->symlink_continues) + if (!file->symlink_continues || file->symlink.length < 1) archive_string_empty(&file->symlink); - else - archive_strcat(&file->symlink, "/"); + else if (file->symlink.s[file->symlink.length - 1] != '/') + separator = "/"; file->symlink_continues = 0; /* @@ -1216,9 +1217,8 @@ unsigned char nlen = *data++; data_length -= 2; - if (!component_continues) - archive_strcat(&file->symlink, "/"); - component_continues = 0; + archive_strcat(&file->symlink, separator); + separator = "/"; switch(flag) { case 0: /* Usual case, this is text. */ @@ -1232,7 +1232,7 @@ return; archive_strncat(&file->symlink, (const char *)data, nlen); - component_continues = 1; + separator = ""; break; case 0x02: /* Current dir. */ archive_strcat(&file->symlink, "."); @@ -1243,6 +1243,7 @@ case 0x08: /* Root of filesystem. */ archive_string_empty(&file->symlink); archive_strcat(&file->symlink, "/"); + separator = ""; break; case 0x10: /* Undefined (historically "volume root" */ archive_string_empty(&file->symlink); --------------060103060203010600040401-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 05:34:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 464AD106564A; Sat, 25 Jul 2009 05:34:12 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Tim Kientzle Date: Sat, 25 Jul 2009 01:33:51 -0400 User-Agent: KMail/1.6.2 References: <4A615602.4090000@freebsd.org> <200907241514.18806.jkim@FreeBSD.org> <4A6A87E1.8030504@freebsd.org> In-Reply-To: <4A6A87E1.8030504@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907250134.05925.jkim@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: Joliet and release ISOs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 05:34:13 -0000 On Saturday 25 July 2009 12:19 am, Tim Kientzle wrote: > Jung-uk Kim wrote: > > Still, there is one minor annoyance: > > > > %ls -l test > > total 0 > > lrwxr-xr-x 1 jkim staff 1 7 24 14:54 link1 -> / > > lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link2 -> // > > lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link3 -> /. > > lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link4 -> ./ > > lrwxr-xr-x 1 jkim staff 2 7 24 14:55 link5 -> .. > > lrwxr-xr-x 1 jkim staff 4 7 24 14:56 link6 -> /tmp > > lrwxr-xr-x 1 jkim staff 5 7 24 14:56 link7 -> //tmp > > lrwxr-xr-x 1 jkim staff 4 7 24 14:56 link8 -> tmp/ > > lrwxr-xr-x 1 jkim staff 5 7 24 14:56 link9 -> /tmp/ > > %tar -t --options=\!joliet -v -f test.iso > > drwx------ 0 0 0 2048 7 24 14:56 . > > lr-xr-xr-x 1 0 0 0 7 24 14:56 link9 -> //tmp/ > > lr-xr-xr-x 1 0 0 0 7 24 14:56 link8 -> tmp/ > > lr-xr-xr-x 1 0 0 0 7 24 14:56 link7 -> ///tmp > > lr-xr-xr-x 1 0 0 0 7 24 14:56 link6 -> //tmp > > lr-xr-xr-x 1 0 0 0 7 24 14:55 link5 -> .. > > lr-xr-xr-x 1 0 0 0 7 24 14:55 link4 -> ./ > > lr-xr-xr-x 1 0 0 0 7 24 14:55 link3 -> //. > > lr-xr-xr-x 1 0 0 0 7 24 14:55 link2 -> /// > > lr-xr-xr-x 1 0 0 0 7 24 14:54 link1 -> / > > > > Note there is an additional `/' when the link has a leading `/' > > (but not just `/'), i.e., `//' => `///', `/.' => `//.', `/tmp' => > > `//tmp', `//tmp' => `///tmp'. For FreeBSD CD-ROMs, `stand -> > > /rescue' becomes `stand -> //rescue', etc. > > Here's another patch for you to try; this changes how > libarchive parses Rockridge "SL" extensions. Looks fine now. Thanks! > Cheers, > > Tim > > P.S. Could you email me privately the "test.iso" image > you created on your machine? I tried creating one here > and get slightly different behavior. Also, what version > of mkisofs do you have installed on your machine? I am using 2.01.01a61 from sysutils/cdrtools-devel because 2.01 is too old for me, e.g., virtually no NLS support. I'll send you the file in a separate e-mail shortly. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 06:09:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A425106564A for ; Sat, 25 Jul 2009 06:09:40 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3CFB68FC20 for ; Sat, 25 Jul 2009 06:09:40 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 1D2871A3C41; Fri, 24 Jul 2009 22:49:41 -0700 (PDT) Date: Fri, 24 Jul 2009 22:49:41 -0700 From: Alfred Perlstein To: current@freebsd.org Message-ID: <20090725054941.GB21885@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: weird world break in mklocale X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 06:09:40 -0000 Hey guys, Anyone see a build break in mklocale? ===> share/mk (all) ===> share/mklocale (all) mklocale -o am_ET.UTF-8.out /vol/mac/src/share/mklocale/am_ET.UTF-8.src am_ET.UTF-8.out: Inappropriate ioctl for device *** Error code 1 Stop in /vol/mac/src/share/mklocale. *** Error code 1 Running truss shows: munmap(0x800786000,499712) = 0 (0x0) ioctl(0,TIOCGETA,0xffffe7a0) ERR#25 'Inappropriate ioctl for device' fstat(0,{ mode=-rw-r--r-- ,inode=1700562,size=1092,blksize=4096 }) = 0 (0x0) read(0,"/*\n * Amharic Language (Ethiopi"...,4096) = 1092 (0x444) read(0,0x80081b000,4096) = 0 (0x0) ioctl(0,TIOCGETA,0xffffe780) ERR#25 'Inappropriate ioctl for device' fstat(3,{ mode=-rw-r--r-- ,inode=12007044,size=0,blksize=4096 }) = 0 (0x0) stat("/usr/share/nls/C/libc.cat",0x7fffffffdaa0) ERR#2 'No such file or directory' stat("/usr/share/nls/libc/C",0x7fffffffdaa0) ERR#2 'No such file or directory' stat("/usr/local/share/nls/C/libc.cat",0x7fffffffdaa0) ERR#2 'No such file or directory' stat("/usr/local/share/nls/libc/C",0x7fffffffdaa0) ERR#2 'No such file or directory' am_ET.UTF-8.out: Inappropriate ioctl for device writev(0x2,0x7fffffffdfe0,0x4,0x1e,0x0,0x800800458) = 48 (0x30) unlink("am_ET.UTF-8.out") = 0 (0x0) Should the build be calling mklocale from /usr/bin? Or calling it out of the object tree? If I use the mklocale binary from /usr/obj/... it works fine. Am I missing something? -- - Alfred Perlstein VMOA #5191, 03 vmax, 92 gs500, ch250 - FreeBSD From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 07:00:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C6391065670; Sat, 25 Jul 2009 07:00:46 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 82E378FC16; Sat, 25 Jul 2009 07:00:45 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from smoochies.rachie.is-a-geek.net (mailhub.lan.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 170287E818; Fri, 24 Jul 2009 23:00:45 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Fri, 24 Jul 2009 23:00:43 -0800 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <20090725054941.GB21885@elvis.mu.org> In-Reply-To: <20090725054941.GB21885@elvis.mu.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907242300.44148.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Alfred Perlstein Subject: Re: weird world break in mklocale X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 07:00:46 -0000 On Friday 24 July 2009 21:49:41 Alfred Perlstein wrote: > Anyone see a build break in mklocale? > Am I missing something? The archives: http://lists.freebsd.org/pipermail/freebsd-current/2009-July/thread.html#9406 -- Mel From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 09:20:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2756106566B; Sat, 25 Jul 2009 09:20:36 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id ED5958FC12; Sat, 25 Jul 2009 09:20:35 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=kuK7i7cE-7KyHCsz6OkA:9 a=l4FB7idsSIMP2QVI4QCAplT-0wcA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 230295760; Sat, 25 Jul 2009 11:20:34 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Alfred Perlstein Date: Sat, 25 Jul 2009 11:20:24 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> <4A69AB91.2010208@icyb.net.ua> <200907241552.10763.hselasky@c2i.net> In-Reply-To: <200907241552.10763.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907251120.25957.hselasky@c2i.net> Cc: usb@freebsd.org, Andriy Gapon , Andrew Thompson , Maksim Yevmenkin Subject: Re: USB polling (100% done) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 09:20:37 -0000 Hi, Forget this thread. I found a temporary solution around the Giant problem in UKBD at the DDB prompt. The patch below will end up in -current soon. Tested on macbook pro with USB keyboard only! Even key repetition works :-) The only limitiation is that the USB keyboard must be probed by the USB stack before the panic happens. This might suggest that using loadable modules is the best way to debug problems on machines without AT keyboard or UART. http://perforce.freebsd.org/chv.cgi?CH=166535 --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 12:11:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB82E106566B; Sat, 25 Jul 2009 12:11:06 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF818FC0A; Sat, 25 Jul 2009 12:11:06 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:f0d8:4d61:8883:bb3f] (unknown [IPv6:2001:7b8:3a7:0:f0d8:4d61:8883:bb3f]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 7BA6B5C59; Sat, 25 Jul 2009 14:11:05 +0200 (CEST) Message-ID: <4A6AF659.3000709@andric.com> Date: Sat, 25 Jul 2009 14:11:05 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.2pre) Gecko/20090724 Shredder/3.0b4pre MIME-Version: 1.0 To: Mel Flynn References: <20090725054941.GB21885@elvis.mu.org> <200907242300.44148.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200907242300.44148.mel.flynn+fbsd.current@mailing.thruhere.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Alfred Perlstein Subject: Re: weird world break in mklocale X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 12:11:06 -0000 On 2009-07-25 09:00, Mel Flynn wrote: > On Friday 24 July 2009 21:49:41 Alfred Perlstein wrote: >> Anyone see a build break in mklocale? > The archives: > http://lists.freebsd.org/pipermail/freebsd-current/2009-July/thread.html#9406 I guess there is a need to put mklocale into the build bootstrap tools, since IMHO it's a bit of a kludge to have to manually rebuild it before a buildworld can succeed... This will bite everyone who updates from something oldish to -CURRENT now, right? From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 15:32:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 223A41065672; Sat, 25 Jul 2009 15:32:27 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id B86478FC24; Sat, 25 Jul 2009 15:32:26 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 28A5F1CEBC; Sat, 25 Jul 2009 17:32:26 +0200 (CEST) Date: Sat, 25 Jul 2009 17:32:26 +0200 From: Ed Schouten To: Dimitry Andric Message-ID: <20090725153226.GB83812@hoeg.nl> References: <20090725054941.GB21885@elvis.mu.org> <200907242300.44148.mel.flynn+fbsd.current@mailing.thruhere.net> <4A6AF659.3000709@andric.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline In-Reply-To: <4A6AF659.3000709@andric.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Mel Flynn , freebsd-current@freebsd.org, Alfred Perlstein Subject: Re: weird world break in mklocale X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 15:32:27 -0000 --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Dimitry Andric wrote: > This will bite everyone who updates from something oldish to -CURRENT > now, right? No, it just bites people who have a broken mklocale binary, which is only after 8.0-BETA1 and before 8.0-BETA2. --=20 Ed Schouten WWW: http://80386.nl/ --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkprJYoACgkQ52SDGA2eCwX2cgCfZT6d2ZsGQdVRLjoc0LGdo8Ie 5j0An2BXrHHZXU/qYBfghhvMuCP07riy =Vfy4 -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 15:56:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B4935106566B; Sat, 25 Jul 2009 15:56:22 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 514878FC17; Sat, 25 Jul 2009 15:56:22 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:f0d8:4d61:8883:bb3f] (unknown [IPv6:2001:7b8:3a7:0:f0d8:4d61:8883:bb3f]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 52F3B5C59; Sat, 25 Jul 2009 17:56:21 +0200 (CEST) Message-ID: <4A6B2B25.5080209@andric.com> Date: Sat, 25 Jul 2009 17:56:21 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1.2pre) Gecko/20090724 Shredder/3.0b4pre MIME-Version: 1.0 To: Ed Schouten References: <20090725054941.GB21885@elvis.mu.org> <200907242300.44148.mel.flynn+fbsd.current@mailing.thruhere.net> <4A6AF659.3000709@andric.com> <20090725153226.GB83812@hoeg.nl> In-Reply-To: <20090725153226.GB83812@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mel Flynn , freebsd-current@freebsd.org, Alfred Perlstein Subject: Re: weird world break in mklocale X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 15:56:23 -0000 On 2009-07-25 17:32, Ed Schouten wrote: >> This will bite everyone who updates from something oldish to -CURRENT >> now, right? > No, it just bites people who have a broken mklocale binary, which is > only after 8.0-BETA1 and before 8.0-BETA2. Understood, thanks! Sorry for the noise... From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 16:31:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA126106566B for ; Sat, 25 Jul 2009 16:31:10 +0000 (UTC) (envelope-from freebsd@levsha.org.ua) Received: from expo.ukrweb.net (mail.univua.net [91.202.128.78]) by mx1.freebsd.org (Postfix) with ESMTP id D0CE98FC0A for ; Sat, 25 Jul 2009 16:31:09 +0000 (UTC) (envelope-from freebsd@levsha.org.ua) Received: from levsha by expo.ukrweb.net with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MUkAJ-000LuQ-Ry; Sat, 25 Jul 2009 19:32:07 +0300 Date: Sat, 25 Jul 2009 19:32:07 +0300 From: Mykola Dzham To: jamie@freebsd.org Message-ID: <20090725163207.GP39538@expo.ukrweb.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="J2SCkAp4GZ/dPZZf" Content-Disposition: inline X-Operating-System: FreeBSD/7.0-STABLE (i386) User-Agent: Mutt/1.5.18 (2008-05-17) Cc: bz@freebsd.org, freebsd-current@freebsd.org Subject: 8.0 still allow creating ipv6 udp socket in jail without ipv6 ip X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 16:31:11 -0000 --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi! After r188146 creating tcp ipv6 socket in jail without ipv6 ip is not allowed, but udp socket is allowed. I use this code to test: #include #include #include #include #include int main(int argc, char **argv) { int sockfd; struct sockaddr_in servaddr; char sendline[] ="test"; bzero(&servaddr, sizeof(servaddr)); if( (sockfd = socket(AF_INET6, SOCK_DGRAM, 0))<0){ fprintf(stderr, "socket(): %s\n", strerror(errno)); return(1); } servaddr.sin_family = AF_INET; servaddr.sin_port = htons(12345); int r=inet_pton(AF_INET, "10.10.10.10", &servaddr.sin_addr); if(r<0){ fprintf(stderr, "inet_pton(): %s\n", strerror(errno)); return(1); }else if(r==0){ fprintf(stderr, "call inet_pton() with incorrect address\n"); return(1); } if( sendto(sockfd, sendline, strlen(sendline), 0, (struct sockaddr *) &servaddr, sizeof(servaddr)) < 0 ){ fprintf(stderr, "socket(): %s\n", strerror(errno)); return(1); } return(0); } Runing on FreeBSD 8.0-BETA2 #10: Mon Jul 20 13:56:01 EEST 2009 : $ ./send # sendto(): Invalid argument Runing on FreeBSD 7.1-PRERELEASE #0 r183080: Wed Sep 17 17:54:25 UTC 2008: $ ./send # socket(): Protocol not supported ktrace results for 8.0-BETA2 and 7.1-PRERELEASE attached -- Mykola Dzham, LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kdump-7.1-PRERELEASE.txt" 29503 ktrace RET ktrace 0 29503 ktrace CALL execve(0x7fffffffed47,0x7fffffffeb70,0x7fffffffeb80) 29503 ktrace NAMI "./send" 29503 ktrace NAMI "/libexec/ld-elf.so.1" 29503 send RET execve 0 29503 send CALL __sysctl(0x7fffffffe770,0x2,0x7fffffffe78c,0x7fffffffe780,0,0) 29503 send RET __sysctl 0 29503 send CALL mmap(0,0x230,PROT_READ|PROT_WRITE,MAP_ANON,0xffffffff,0) 29503 send RET mmap 6447104/0x800626000 29503 send CALL munmap(0x800626000,0x230) 29503 send RET munmap 0 29503 send CALL __sysctl(0x7fffffffe7e0,0x2,0x80072df68,0x7fffffffe7d8,0,0) 29503 send RET __sysctl 0 29503 send CALL mmap(0,0x8000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0) 29503 send RET mmap 6447104/0x800626000 29503 send CALL issetugid 29503 send RET issetugid 0 29503 send CALL open(0x800622652,O_RDONLY,0x1b6) 29503 send NAMI "/etc/libmap.conf" 29503 send RET open -1 errno 2 No such file or directory 29503 send CALL open(0x800621670,O_RDONLY,0x2f) 29503 send NAMI "/var/run/ld-elf.so.hints" 29503 send RET open 3 29503 send CALL read(0x3,0x7fffffffe520,0x80) 29503 send GIO fd 3 read 128 bytes 0x0000 4568 6e74 0100 0000 8000 0000 8d00 0000 |Ehnt............| 0x0010 0000 0000 8c00 0000 0000 0000 0000 0000 |................| 0x0020 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0030 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0040 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0050 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0060 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0070 0000 0000 0000 0000 0000 0000 0000 0000 |................| 29503 send RET read 128/0x80 29503 send CALL lseek(0x3,0x80,SEEK_SET) 29503 send RET lseek 128/0x80 29503 send CALL read(0x3,0x80062a000,0x8d) 29503 send GIO fd 3 read 141 bytes "/lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/lib/compat/pkg\ :/usr/local/lib/gcc/x86_64-portbld-freebsd7.0/3.4.6:/usr/local/lib/nss\ \0" 29503 send RET read 141/0x8d 29503 send CALL close(0x3) 29503 send RET close 0 29503 send CALL access(0x80062b000,F_OK) 29503 send NAMI "/lib/libc.so.7" 29503 send RET access 0 29503 send CALL open(0x800627040,O_RDONLY,0x72de40) 29503 send NAMI "/lib/libc.so.7" 29503 send RET open 3 29503 send CALL fstat(0x3,0x7fffffffe7a0) 29503 send RET fstat 0 29503 send CALL read(0x3,0x80072ce20,0x1000) 29503 send GIO fd 3 read 4096 bytes 0x0000 7f45 4c46 0201 0109 0000 0000 0000 0000 |.ELF............| 0x0010 0300 3e00 0100 0000 90c1 0200 0000 0000 |..>.............| 0x0020 4000 0000 0000 0000 c0c3 1100 0000 0000 |@...............| 0x0030 0000 0000 4000 3800 0500 4000 2200 2100 |....@.8...@.".!.| 0x0040 0100 0000 0500 0000 0000 0000 0000 0000 |................| 0x0050 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0060 ecd5 0e00 0000 0000 ecd5 0e00 0000 0000 |................| 0x0070 0000 1000 0000 0000 0100 0000 0600 0000 |................| 0x0080 00d6 0e00 0000 0000 00d6 1e00 0000 0000 |................| 0x0090 00d6 1e00 0000 0000 70c4 0100 0000 0000 |........p.......| 0x00a0 e832 0300 0000 0000 0000 1000 0000 0000 |.2..............| 0x00b0 0200 0000 0600 0000 4079 1000 0000 0000 |........@y......| 0x00c0 4079 2000 0000 0000 4079 2000 0000 0000 |@y .....@y .....| 0x00d0 8001 0000 0000 0000 8001 0000 0000 0000 |................| 0x00e0 0800 0000 0000 0000 0700 0000 0400 0000 |................| 0x00f0 704f 0f00 0000 0000 704f 1f00 0000 0000 |pO......pO......| 0x0100 704f 1f00 0000 0000 0000 0000 0000 0000 |pO..............| 0x0110 0c00 0000 0000 0000 0800 0000 0000 0000 |................| 0x0120 50e5 7464 0400 0000 e4d5 0e00 0000 0000 |P.td............| 0x0130 e4d5 0e00 0000 0000 e4d5 0e00 0000 0000 |................| 0x0140 0800 0000 0000 0000 0800 0000 0000 0000 |................| 0x0150 0400 0000 0000 0000 0508 0000 330a 0000 |............3...| 0x0160 1105 0000 0000 0000 0000 0000 0000 0000 |................| 0x0170 e906 0000 ab05 0000 e301 0000 5f09 0000 |............_...| 0x0180 c303 0000 0000 0000 c207 0000 df07 0000 |................| 0x0190 4906 0000 fc04 0000 6d01 0000 b309 0000 |I.......m.......| 0x01a0 6c08 0000 0000 0000 c602 0000 e208 0000 |l...............| 0x01b0 9105 0000 5f05 0000 c400 0000 c008 0000 |...._...........| 0x01c0 2808 0000 1c0a 0000 280a 0000 5706 0000 |(.......(...W...| 0x01d0 0000 0000 0000 0000 3305 0000 0000 0000 |........3.......| 0x01e0 b809 0000 7d08 0000 f609 0000 f509 0000 |....}...........| 0x01f0 4309 0000 da00 0000 4200 0000 5404 0000 |C.......B...T...| 0x0200 2106 0000 0000 0000 a009 0000 7508 0000 |!...........u...| 0x0210 2606 0000 0000 0000 7b08 0000 bb02 0000 |&.......{.......| 0x0220 2509 0000 0f0a 0000 b302 0000 dc08 0000 |%...............| 0x0230 3004 0000 2d07 0000 0000 0000 3a02 0000 |0...-.......:...| 0x0240 5b08 0000 0000 0000 4f03 0000 0000 0000 |[.......O.......| 0x0250 0000 0000 060a 0000 a506 0000 0000 0000 |................| 0x0260 d700 0000 e409 0000 c404 0000 8104 0000 |................| 0x0270 6103 0000 f400 0000 fd09 0000 3e03 0000 |a...........>...| 0x0280 2507 0000 0000 0000 0000 0000 e108 0000 |%...............| 0x0290 0000 0000 6d08 0000 0000 0000 5806 0000 |....m.......X...| 0x02a0 0000 0000 f808 0000 0000 0000 cd07 0000 |................| 0x02b0 0000 0000 0706 0000 4107 0000 0000 0000 |........A.......| 0x02c0 3906 0000 0f08 0000 fc01 0000 0000 0000 |9...............| 0x02d0 c607 0000 0000 0000 c705 0000 3009 0000 |............0...| 0x02e0 f207 0000 0000 0000 6a06 0000 c403 0000 |........j.......| 0x02f0 0000 0000 0000 0000 e307 0000 1802 0000 |................| 0x0300 0000 0000 8206 0000 0000 0000 0000 0000 |................| 0x0310 6b04 0000 7407 0000 a701 0000 5307 0000 |k...t.......S...| 0x0320 7709 0000 d002 0000 b604 0000 5705 0000 |w...........W...| 0x0330 0000 0000 b808 0000 7d09 0000 8809 0000 |........}.......| 0x0340 fd03 0000 5607 0000 0000 0000 4809 0000 |....V.......H...| 0x0350 6109 0000 4301 0000 be07 0000 0000 0000 |a...C...........| 0x0360 d208 0000 c401 0000 bc06 0000 0000 0000 |................| 0x0370 e608 0000 a008 0000 d006 0000 6707 0000 |............g...| 0x0380 0000 0000 c408 0000 9c07 0000 b704 0000 |................| 0x0390 2601 0000 0000 0000 2909 0000 2407 0000 |&.......)...$...| 0x03a0 7a07 0000 a603 0000 1c08 0000 0000 0000 |z...............| 0x03b0 0000 0000 8e08 0000 0807 0000 0000 0000 |................| 0x03c0 0c02 0000 6f00 0000 7c01 0000 1d05 0000 |....o...|.......| 0x03d0 0000 0000 e400 0000 a101 0000 7205 0000 |............r...| 0x03e0 0000 0000 1102 0000 0000 0000 f209 0000 |................| 0x03f0 0000 0000 0000 0000 2209 0000 d609 0000 |........".......| 0x0400 5d08 0000 1f02 0000 0000 0000 5005 0000 |]...........P...| 0x0410 d300 0000 1b0a 0000 1407 0000 1405 0000 |................| 0x0420 e406 0000 0000 0000 dd05 0000 7208 0000 |............r...| 0x0430 0000 0000 0102 0000 bf07 0000 0108 0000 |................| 0x0440 0000 0000 9606 0000 1a08 0000 9301 0000 |................| 0x0450 0000 0000 dd07 0000 5b02 0000 0000 0000 |........[.......| 0x0460 db07 0000 6b03 0000 1e04 0000 5604 0000 |....k.......V...| 0x0470 6d07 0000 0000 0000 0000 0000 3907 0000 |m...........9...| 0x0480 0000 0000 0000 0000 5a03 0000 0000 0000 |........Z.......| 0x0490 2105 0000 ed04 0000 0000 0000 f807 0000 |!...............| 0x04a0 0000 0000 7505 0000 3d00 0000 3805 0000 |....u...=...8...| 0x04b0 f505 0000 f008 0000 3e05 0000 3d06 0000 |........>...=...| 0x04c0 0000 0000 7905 0000 0000 0000 0000 0000 |....y...........| 0x04d0 0e08 0000 3607 0000 9903 0000 3207 0000 |....6.......2...| 0x04e0 0000 0000 b909 0000 9806 0000 0000 0000 |................| 0x04f0 d005 0000 3302 0000 0000 0000 0000 0000 |....3...........| 0x0500 0000 0000 8302 0000 b208 0000 0000 0000 |................| 0x0510 b908 0000 6803 0000 6106 0000 0000 0000 |....h...a.......| 0x0520 cb08 0000 0000 0000 9506 0000 0000 0000 |................| 0x0530 0a0a 0000 0000 0000 2709 0000 ab02 0000 |........'.......| 0x0540 0000 0000 4606 0000 0000 0000 0000 0000 |....F...........| 0x0550 0000 0000 4203 0000 a904 0000 0000 0000 |....B...........| 0x0560 4106 0000 1209 0000 0b06 0000 6209 0000 |A...........b...| 0x0570 0000 0000 9408 0000 b807 0000 4508 0000 |............E...| 0x0580 7608 0000 4b00 0000 1f01 0000 4b03 0000 |v...K.......K...| 0x0590 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x05a0 0b05 0000 3800 0000 0000 0000 8c09 0000 |....8...........| 0x05b0 0000 0000 0d0a 0000 0000 0000 2102 0000 |............!...| 0x05c0 0000 0000 5006 0000 0000 0000 7808 0000 |....P.......x...| 0x05d0 0000 0000 f508 0000 ca06 0000 0000 0000 |................| 0x05e0 9302 0000 170a 0000 4e03 0000 7804 0000 |........N...x...| 0x05f0 0000 0000 8604 0000 b303 0000 0000 0000 |................| 0x0600 4a05 0000 dd08 0000 1307 0000 a206 0000 |J...............| 0x0610 0000 0000 0000 0000 6d05 0000 3c04 0000 |........m...<...| 0x0620 3307 0000 0000 0000 0000 0000 8f09 0000 |3...............| 0x0630 0000 0000 7b07 0000 4800 0000 3d07 0000 |....{...H...=...| 0x0640 0000 0000 0000 0000 4205 0000 1b08 0000 |........B.......| 0x0650 ee07 0000 0000 0000 d109 0000 1303 0000 |................| 0x0660 7705 0000 e904 0000 ad09 0000 8506 0000 |w...............| 0x0670 0006 0000 0000 0000 0000 0000 9b08 0000 |................| 0x0680 0000 0000 2a04 0000 df08 0000 2402 0000 |....*.......$...| 0x0690 7404 0000 8a03 0000 0000 0000 2008 0000 |t........... ...| 0x06a0 0000 0000 0000 0000 0000 0000 0a07 0000 |................| 0x06b0 8b09 0000 4f00 0000 4503 0000 0000 0000 |....O...E.......| 0x06c0 0000 0000 c908 0000 0000 0000 de07 0000 |................| 0x06d0 2908 0000 7908 0000 5204 0000 6008 0000 |)...y...R...`...| 0x06e0 0000 0000 0000 0000 9005 0000 b409 0000 |................| 0x06f0 5a04 0000 8e04 0000 8105 0000 1905 0000 |Z...............| 0x0700 0000 0000 1805 0000 2c03 0000 ae07 0000 |........,.......| 0x0710 fe02 0000 6909 0000 0f06 0000 0000 0000 |....i...........| 0x0720 0000 0000 0000 0000 7807 0000 8c03 0000 |........x.......| 0x0730 6a00 0000 0000 0000 0000 0000 6805 0000 |j...........h...| 0x0740 e508 0000 1809 0000 0000 0000 de02 0000 |................| 0x0750 0000 0000 0000 0000 ca07 0000 5c06 0000 |............\...| 0x0760 3903 0000 7204 0000 c109 0000 0000 0000 |9...r...........| 0x0770 e909 0000 4605 0000 ce08 0000 7406 0000 |....F.......t...| 0x0780 e901 0000 e209 0000 2204 0000 0000 0000 |........".......| 0x0790 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x07a0 0000 0000 3f01 0000 0000 0000 8905 0000 |....?...........| 0x07b0 3c00 0000 f700 0000 bd08 0000 8a02 0000 |<...............| 0x07c0 a806 0000 0000 0000 5b09 0000 2d02 0000 |........[...-...| 0x07d0 8b06 0000 ae01 0000 5709 0000 7e07 0000 |........W...~...| 0x07e0 7a08 0000 c709 0000 6f07 0000 0000 0000 |z.......o.......| 0x07f0 1402 0000 a109 0000 1806 0000 9904 0000 |................| 0x0800 8d03 0000 ac08 0000 b702 0000 1d07 0000 |................| 0x0810 0000 0000 0e02 0000 8909 0000 9800 0000 |................| 0x0820 1006 0000 a809 0000 d303 0000 f507 0000 |................| 0x0830 0000 0000 6606 0000 0000 0000 0000 0000 |....f...........| 0x0840 5003 0000 bb06 0000 ae09 0000 f603 0000 |P...............| 0x0850 0000 0000 3804 0000 0000 0000 5d07 0000 |....8.......]...| 0x0860 2409 0000 c604 0000 ba06 0000 b800 0000 |$...............| 0x0870 5101 0000 a903 0000 1709 0000 6905 0000 |Q...........i...| 0x0880 1909 0000 c209 0000 0000 0000 c007 0000 |................| 0x0890 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x08a0 de05 0000 4f01 0000 e607 0000 3206 0000 |....O.......2...| 0x08b0 fe00 0000 fc07 0000 e807 0000 cd02 0000 |................| 0x08c0 0000 0000 0000 0000 7006 0000 0000 0000 |........p.......| 0x08d0 af09 0000 b503 0000 e801 0000 0407 0000 |................| 0x08e0 0000 0000 da08 0000 6806 0000 4709 0000 |........h...G...| 0x08f0 0000 0000 9208 0000 e309 0000 e506 0000 |................| 0x0900 6506 0000 1708 0000 6503 0000 4b09 0000 |e.......e...K...| 0x0910 cb02 0000 2203 0000 8c06 0000 b203 0000 |...."...........| 0x0920 bd09 0000 4704 0000 4903 0000 b609 0000 |....G...I.......| 0x0930 3609 0000 f605 0000 0000 0000 4904 0000 |6...........I...| 0x0940 d809 0000 a505 0000 0000 0000 df03 0000 |................| 0x0950 0b0a 0000 ac07 0000 0000 0000 4208 0000 |............B...| 0x0960 6108 0000 010a 0000 5b06 0000 3b07 0000 |a.......[...;...| 0x0970 3705 0000 1904 0000 1906 0000 0000 0000 |7...............| 0x0980 3407 0000 5109 0000 6709 0000 c105 0000 |4...Q...g.......| 0x0990 0000 0000 6708 0000 0000 0000 3406 0000 |....g.......4...| 0x09a0 0000 0000 0000 0000 f906 0000 0000 0000 |................| 0x09b0 0000 0000 f806 0000 5907 0000 0000 0000 |........Y.......| 0x09c0 1109 0000 4b08 0000 c507 0000 8a07 0000 |....K...........| 0x09d0 6b09 0000 0000 0000 3d04 0000 b703 0000 |k.......=.......| 0x09e0 6702 0000 b901 0000 4509 0000 4404 0000 |g.......E...D...| 0x09f0 4402 0000 ba07 0000 dd09 0000 ce09 0000 |D...............| 0x0a00 e900 0000 0000 0000 f708 0000 1401 0000 |................| 0x0a10 2c09 0000 4304 0000 0000 0000 4e01 0000 |,...C.......N...| 0x0a20 0d07 0000 0000 0000 ca09 0000 e507 0000 |................| 0x0a30 6704 0000 7d06 0000 0c08 0000 5608 0000 |g...}.......V...| 0x0a40 0000 0000 3208 0000 ff00 0000 b708 0000 |....2...........| 0x0a50 0000 0000 0000 0000 1f08 0000 a909 0000 |................| 0x0a60 8005 0000 4000 0000 0000 0000 320a 0000 |....@.......2...| 0x0a70 0000 0000 da06 0000 9503 0000 0000 0000 |................| 0x0a80 0c0a 0000 ad06 0000 4d01 0000 8f07 0000 |........M.......| 0x0a90 4609 0000 e100 0000 3908 0000 0000 0000 |F.......9.......| 0x0aa0 8403 0000 6508 0000 2500 0000 d602 0000 |....e...%.......| 0x0ab0 0000 0000 1106 0000 a500 0000 a003 0000 |................| 0x0ac0 3901 0000 0000 0000 e407 0000 5105 0000 |9...........Q...| 0x0ad0 e609 0000 0000 0000 6701 0000 0000 0000 |........g.......| 0x0ae0 6609 0000 9f03 0000 0000 0000 e003 0000 |f...............| 0x0af0 0000 0000 3b00 0000 7106 0000 0000 0000 |....;...q.......| 0x0b00 3405 0000 200a 0000 8f05 0000 0000 0000 |4... ...........| 0x0b10 9b04 0000 e106 0000 d600 0000 4907 0000 |............I...| 0x0b20 d806 0000 f409 0000 df09 0000 0000 0000 |................| 0x0b30 3408 0000 8c08 0000 cd09 0000 7907 0000 |4...........y...| 0x0b40 1d04 0000 e408 0000 0000 0000 b700 0000 |................| 0x0b50 d902 0000 6b08 0000 6505 0000 0000 0000 |....k...e.......| 0x0b60 0b09 0000 4009 0000 0000 0000 6507 0000 |....@.......e...| 0x0b70 eb08 0000 0000 0000 0000 0000 e000 0000 |................| 0x0b80 fc08 0000 ad08 0000 7306 0000 050a 0000 |........s.......| 0x0b90 0000 0000 1001 0000 0000 0000 9b07 0000 |................| 0x0ba0 b400 0000 6f05 0000 1504 0000 0000 0000 |....o...........| 0x0bb0 0000 0000 0000 0000 5e06 0000 db04 0000 |........^.......| 0x0bc0 5107 0000 0000 0000 1309 0000 0000 0000 |Q...............| 0x0bd0 4909 0000 d500 0000 0000 0000 0000 0000 |I...............| 0x0be0 dc09 0000 9006 0000 8202 0000 8901 0000 |................| 0x0bf0 0000 0000 7309 0000 110a 0000 0000 0000 |....s...........| 0x0c00 ff04 0000 0000 0000 0000 0000 4905 0000 |............I...| 0x0c10 0000 0000 7200 0000 6a08 0000 0000 0000 |....r...j.......| 0x0c20 e009 0000 c603 0000 1004 0000 0902 0000 |................| 0x0c30 df01 0000 b300 0000 4207 0000 b803 0000 |........B.......| 0x0c40 9c09 0000 0000 0000 d607 0000 4008 0000 |............@...| 0x0c50 0000 0000 8208 0000 b306 0000 7509 0000 |............u...| 0x0c60 0000 0000 7607 0000 0000 0000 0000 0000 |....v...........| 0x0c70 5000 0000 6a09 0000 9f00 0000 ba08 0000 |P...j...........| 0x0c80 a708 0000 0000 0000 0000 0000 d100 0000 |................| 0x0c90 4e02 0000 6e08 0000 ce05 0000 0000 0000 |N...n...........| 0x0ca0 de09 0000 8607 0000 0000 0000 2809 0000 |............(...| 0x0cb0 da04 0000 0000 0000 6e07 0000 a608 0000 |........n.......| 0x0cc0 0000 0000 9d05 0000 bf06 0000 9000 0000 |................| 0x0cd0 0000 0000 3404 0000 0000 0000 0000 0000 |....4...........| 0x0ce0 0000 0000 be01 0000 0000 0000 8b07 0000 |................| 0x0cf0 0000 0000 cd06 0000 0000 0000 cc04 0000 |................| 0x0d00 3608 0000 5908 0000 0000 0000 030a 0000 |6...Y...........| 0x0d10 4808 0000 7501 0000 0000 0000 0000 0000 |H...u...........| 0x0d20 7e09 0000 f908 0000 ec07 0000 0000 0000 |~...............| 0x0d30 d701 0000 cf03 0000 3708 0000 8702 0000 |........7.......| 0x0d40 0000 0000 8309 0000 cd03 0000 2e07 0000 |................| 0x0d50 3f09 0000 0000 0000 7800 0000 fd02 0000 |?.......x.......| 0x0d60 d309 0000 1509 0000 0000 0000 4100 0000 |............A...| 0x0d70 0000 0000 9104 0000 0000 0000 8906 0000 |................| 0x0d80 2607 0000 0000 0000 7b02 0000 0000 0000 |&.......{.......| 0x0d90 6f02 0000 0000 0000 0000 0000 0000 0000 |o...............| 0x0da0 7308 0000 1601 0000 e808 0000 0000 0000 |s...............| 0x0db0 8407 0000 5c00 0000 0000 0000 3807 0000 |....\.......8...| 0x0dc0 f705 0000 0308 0000 0409 0000 f405 0000 |................| 0x0dd0 0000 0000 3401 0000 dd00 0000 ac03 0000 |....4...........| 0x0de0 0000 0000 0000 0000 0705 0000 0000 0000 |................| 0x0df0 2206 0000 1f07 0000 1d08 0000 bc05 0000 |"...............| 0x0e00 0000 0000 f108 0000 a205 0000 d708 0000 |................| 0x0e10 0000 0000 a508 0000 0000 0000 9102 0000 |................| 0x0e20 4006 0000 0000 0000 d106 0000 e708 0000 |@...............| 0x0e30 2609 0000 bd01 0000 d508 0000 310a 0000 |&...........1...| 0x0e40 8609 0000 0000 0000 4e08 0000 aa02 0000 |........N.......| 0x0e50 0000 0000 0000 0000 4807 0000 250a 0000 |........H...%...| 0x0e60 0000 0000 f503 0000 0209 0000 0304 0000 |................| 0x0e70 b709 0000 0000 0000 0000 0000 9c04 0000 |................| 0x0e80 5e05 0000 4f02 0000 ee09 0000 d001 0000 |^...O...........| 0x0e90 2a07 0000 1d06 0000 1b09 0000 1409 0000 |*...............| 0x0ea0 7f06 0000 9c01 0000 dc04 0000 0000 0000 |................| 0x0eb0 0000 0000 f306 0000 0000 0000 ac01 0000 |................| 0x0ec0 7a00 0000 0000 0000 2b00 0000 5700 0000 |z.......+...W...| 0x0ed0 d907 0000 cf01 0000 1b07 0000 db00 0000 |................| 0x0ee0 fb04 0000 e706 0000 f103 0000 c807 0000 |................| 0x0ef0 1c09 0000 5c09 0000 c106 0000 0905 0000 |....\...........| 0x0f00 ec09 0000 0000 0000 6009 0000 bb05 0000 |........`.......| 0x0f10 2308 0000 b406 0000 0000 0000 9a07 0000 |#...............| 0x0f20 0000 0000 c301 0000 0000 0000 0000 0000 |................| 0x0f30 f202 0000 0000 0000 9e06 0000 6d00 0000 |............m...| 0x0f40 0809 0000 a607 0000 9305 0000 e403 0000 |................| 0x0f50 0000 0000 0000 0000 0000 0000 5007 0000 |............P...| 0x0f60 a908 0000 1603 0000 0000 0000 b603 0000 |................| 0x0f70 0000 0000 0000 0000 6502 0000 0d09 0000 |........e.......| 0x0f80 5306 0000 0000 0000 3a08 0000 b509 0000 |S.......:.......| 0x0f90 8508 0000 0000 0000 b508 0000 7f07 0000 |................| 0x0fa0 0000 0000 2a03 0000 0000 0000 b903 0000 |....*...........| 0x0fb0 4405 0000 8908 0000 b304 0000 5909 0000 |D...........Y...| 0x0fc0 5807 0000 040a 0000 4708 0000 ef07 0000 |X.......G.......| 0x0fd0 c205 0000 0000 0000 0000 0000 ad07 0000 |................| 0x0fe0 8800 0000 0000 0000 1007 0000 c102 0000 |................| 0x0ff0 0000 0000 3508 0000 9e09 0000 0000 0000 |....5...........| 29503 send RET read 4096/0x1000 29503 send CALL mmap(0,0x221000,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,0x3,0) 29503 send RET mmap 7544832/0x800732000 29503 send CALL mprotect(0x80081f000,0x1000,PROT_READ|PROT_WRITE|PROT_EXEC) 29503 send RET mprotect 0 29503 send CALL mprotect(0x80081f000,0x1000,PROT_READ|PROT_EXEC) 29503 send RET mprotect 0 29503 send CALL mmap(0x80091f000,0x1d000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,0x3,0xed000) 29503 send RET mmap 9564160/0x80091f000 29503 send CALL mmap(0x80093c000,0x17000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0xffffffff,0) 29503 send RET mmap 9682944/0x80093c000 29503 send CALL close(0x3) 29503 send RET close 0 29503 send CALL sysarch(0x81,0x7fffffffe860) 29503 send RET sysarch 0 29503 send CALL mmap(0,0x100,PROT_READ|PROT_WRITE,MAP_ANON,0xffffffff,0) 29503 send RET mmap 6479872/0x80062e000 29503 send CALL munmap(0x80062e000,0x100) 29503 send RET munmap 0 29503 send CALL mmap(0,0xa330,PROT_READ|PROT_WRITE,MAP_ANON,0xffffffff,0) 29503 send RET mmap 6479872/0x80062e000 29503 send CALL munmap(0x80062e000,0xa330) 29503 send RET munmap 0 29503 send CALL __sysctl(0x7fffffffe810,0x2,0x80093ce00,0x7fffffffe808,0,0) 29503 send RET __sysctl 0 29503 send CALL sigprocmask(SIG_BLOCK,0x80072cd20,0x7fffffffe830) 29503 send RET sigprocmask 0 29503 send CALL sigprocmask(SIG_SETMASK,0x80072cd30,0) 29503 send RET sigprocmask 0 29503 send CALL socket(PF_INET6,SOCK_DGRAM,IPPROTO_IP) 29503 send RET socket -1 errno 43 Protocol not supported 29503 send CALL write(0x2,0x7fffffffe320,0x21) 29503 send GIO fd 2 wrote 33 bytes "socket(): Protocol not supported " 29503 send RET write 33/0x21 29503 send CALL exit(0x1) --J2SCkAp4GZ/dPZZf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kdump-8.0-BETA2.txt" 30357 ktrace RET ktrace 0 30357 ktrace CALL execve(0x7fffffffed57,0x7fffffffeaf8,0x7fffffffeb08) 30357 ktrace NAMI "./send" 30357 ktrace NAMI "/libexec/ld-elf.so.1" 30357 send RET execve 0 30357 send CALL __sysctl(0x7fffffffe680,0x2,0x7fffffffe69c,0x7fffffffe690,0,0) 30357 send RET __sysctl 0 30357 send CALL mmap(0,0x230,PROT_READ|PROT_WRITE,MAP_ANON,0xffffffff,0) 30357 send RET mmap 6447104/0x800626000 30357 send CALL munmap(0x800626000,0x230) 30357 send RET munmap 0 30357 send CALL __sysctl(0x7fffffffe6f0,0x2,0x80072df68,0x7fffffffe6e8,0,0) 30357 send RET __sysctl 0 30357 send CALL mmap(0,0x8000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0) 30357 send RET mmap 6447104/0x800626000 30357 send CALL issetugid 30357 send RET issetugid 0 30357 send CALL open(0x800622652,O_RDONLY,0x1b6) 30357 send NAMI "/etc/libmap.conf" 30357 send RET open 3 30357 send CALL fstat(0x3,0x7fffffffde00) 30357 send RET fstat 0 30357 send CALL read(0x3,0x80062a000,0x1000) 30357 send GIO fd 3 read 56 bytes "libncurses.so.8 libncurses.so.7 libkvm.so.5 libkvm.so.4 " 30357 send RET read 56/0x38 30357 send CALL read(0x3,0x80062a000,0x1000) 30357 send GIO fd 3 read 0 bytes "" 30357 send RET read 0 30357 send CALL close(0x3) 30357 send RET close 0 30357 send CALL open(0x800621670,O_RDONLY,0x6e) 30357 send NAMI "/var/run/ld-elf.so.hints" 30357 send RET open 3 30357 send CALL read(0x3,0x7fffffffe430,0x80) 30357 send GIO fd 3 read 128 bytes 0x0000 4568 6e74 0100 0000 8000 0000 7a00 0000 |Ehnt........z...| 0x0010 0000 0000 7900 0000 0000 0000 0000 0000 |....y...........| 0x0020 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0030 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0040 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0050 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0060 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0070 0000 0000 0000 0000 0000 0000 0000 0000 |................| 30357 send RET read 128/0x80 30357 send CALL lseek(0x3,0x80,SEEK_SET) 30357 send RET lseek 128/0x80 30357 send CALL read(0x3,0x80062d000,0x7a) 30357 send GIO fd 3 read 122 bytes "/lib:/usr/lib:/usr/lib/compat:/usr/local/lib:/usr/local/lib/compat/pkg\ :/usr/local/lib/gcc/x86_64-portbld-freebsd7.0/3.4.6\0" 30357 send RET read 122/0x7a 30357 send CALL close(0x3) 30357 send RET close 0 30357 send CALL mmap(0,0x9000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0) 30357 send RET mmap 6479872/0x80062e000 30357 send CALL access(0x80062f000,F_OK) 30357 send NAMI "/lib/libc.so.7" 30357 send RET access 0 30357 send CALL open(0x8006270e0,O_RDONLY,0x72de40) 30357 send NAMI "/lib/libc.so.7" 30357 send RET open 3 30357 send CALL fstat(0x3,0x7fffffffe6b0) 30357 send RET fstat 0 30357 send CALL read(0x3,0x80072ce20,0x1000) 30357 send GIO fd 3 read 4096 bytes 0x0000 7f45 4c46 0201 0109 0000 0000 0000 0000 |.ELF............| 0x0010 0300 3e00 0100 0000 90c1 0200 0000 0000 |..>.............| 0x0020 4000 0000 0000 0000 c0c3 1100 0000 0000 |@...............| 0x0030 0000 0000 4000 3800 0500 4000 2200 2100 |....@.8...@.".!.| 0x0040 0100 0000 0500 0000 0000 0000 0000 0000 |................| 0x0050 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x0060 ecd5 0e00 0000 0000 ecd5 0e00 0000 0000 |................| 0x0070 0000 1000 0000 0000 0100 0000 0600 0000 |................| 0x0080 00d6 0e00 0000 0000 00d6 1e00 0000 0000 |................| 0x0090 00d6 1e00 0000 0000 70c4 0100 0000 0000 |........p.......| 0x00a0 e832 0300 0000 0000 0000 1000 0000 0000 |.2..............| 0x00b0 0200 0000 0600 0000 4079 1000 0000 0000 |........@y......| 0x00c0 4079 2000 0000 0000 4079 2000 0000 0000 |@y .....@y .....| 0x00d0 8001 0000 0000 0000 8001 0000 0000 0000 |................| 0x00e0 0800 0000 0000 0000 0700 0000 0400 0000 |................| 0x00f0 704f 0f00 0000 0000 704f 1f00 0000 0000 |pO......pO......| 0x0100 704f 1f00 0000 0000 0000 0000 0000 0000 |pO..............| 0x0110 0c00 0000 0000 0000 0800 0000 0000 0000 |................| 0x0120 50e5 7464 0400 0000 e4d5 0e00 0000 0000 |P.td............| 0x0130 e4d5 0e00 0000 0000 e4d5 0e00 0000 0000 |................| 0x0140 0800 0000 0000 0000 0800 0000 0000 0000 |................| 0x0150 0400 0000 0000 0000 0508 0000 330a 0000 |............3...| 0x0160 1105 0000 0000 0000 0000 0000 0000 0000 |................| 0x0170 e906 0000 ab05 0000 e301 0000 5f09 0000 |............_...| 0x0180 c303 0000 0000 0000 c207 0000 df07 0000 |................| 0x0190 4906 0000 fc04 0000 6d01 0000 b309 0000 |I.......m.......| 0x01a0 6c08 0000 0000 0000 c602 0000 e208 0000 |l...............| 0x01b0 9105 0000 5f05 0000 c400 0000 c008 0000 |...._...........| 0x01c0 2808 0000 1c0a 0000 280a 0000 5706 0000 |(.......(...W...| 0x01d0 0000 0000 0000 0000 3305 0000 0000 0000 |........3.......| 0x01e0 b809 0000 7d08 0000 f609 0000 f509 0000 |....}...........| 0x01f0 4309 0000 da00 0000 4200 0000 5404 0000 |C.......B...T...| 0x0200 2106 0000 0000 0000 a009 0000 7508 0000 |!...........u...| 0x0210 2606 0000 0000 0000 7b08 0000 bb02 0000 |&.......{.......| 0x0220 2509 0000 0f0a 0000 b302 0000 dc08 0000 |%...............| 0x0230 3004 0000 2d07 0000 0000 0000 3a02 0000 |0...-.......:...| 0x0240 5b08 0000 0000 0000 4f03 0000 0000 0000 |[.......O.......| 0x0250 0000 0000 060a 0000 a506 0000 0000 0000 |................| 0x0260 d700 0000 e409 0000 c404 0000 8104 0000 |................| 0x0270 6103 0000 f400 0000 fd09 0000 3e03 0000 |a...........>...| 0x0280 2507 0000 0000 0000 0000 0000 e108 0000 |%...............| 0x0290 0000 0000 6d08 0000 0000 0000 5806 0000 |....m.......X...| 0x02a0 0000 0000 f808 0000 0000 0000 cd07 0000 |................| 0x02b0 0000 0000 0706 0000 4107 0000 0000 0000 |........A.......| 0x02c0 3906 0000 0f08 0000 fc01 0000 0000 0000 |9...............| 0x02d0 c607 0000 0000 0000 c705 0000 3009 0000 |............0...| 0x02e0 f207 0000 0000 0000 6a06 0000 c403 0000 |........j.......| 0x02f0 0000 0000 0000 0000 e307 0000 1802 0000 |................| 0x0300 0000 0000 8206 0000 0000 0000 0000 0000 |................| 0x0310 6b04 0000 7407 0000 a701 0000 5307 0000 |k...t.......S...| 0x0320 7709 0000 d002 0000 b604 0000 5705 0000 |w...........W...| 0x0330 0000 0000 b808 0000 7d09 0000 8809 0000 |........}.......| 0x0340 fd03 0000 5607 0000 0000 0000 4809 0000 |....V.......H...| 0x0350 6109 0000 4301 0000 be07 0000 0000 0000 |a...C...........| 0x0360 d208 0000 c401 0000 bc06 0000 0000 0000 |................| 0x0370 e608 0000 a008 0000 d006 0000 6707 0000 |............g...| 0x0380 0000 0000 c408 0000 9c07 0000 b704 0000 |................| 0x0390 2601 0000 0000 0000 2909 0000 2407 0000 |&.......)...$...| 0x03a0 7a07 0000 a603 0000 1c08 0000 0000 0000 |z...............| 0x03b0 0000 0000 8e08 0000 0807 0000 0000 0000 |................| 0x03c0 0c02 0000 6f00 0000 7c01 0000 1d05 0000 |....o...|.......| 0x03d0 0000 0000 e400 0000 a101 0000 7205 0000 |............r...| 0x03e0 0000 0000 1102 0000 0000 0000 f209 0000 |................| 0x03f0 0000 0000 0000 0000 2209 0000 d609 0000 |........".......| 0x0400 5d08 0000 1f02 0000 0000 0000 5005 0000 |]...........P...| 0x0410 d300 0000 1b0a 0000 1407 0000 1405 0000 |................| 0x0420 e406 0000 0000 0000 dd05 0000 7208 0000 |............r...| 0x0430 0000 0000 0102 0000 bf07 0000 0108 0000 |................| 0x0440 0000 0000 9606 0000 1a08 0000 9301 0000 |................| 0x0450 0000 0000 dd07 0000 5b02 0000 0000 0000 |........[.......| 0x0460 db07 0000 6b03 0000 1e04 0000 5604 0000 |....k.......V...| 0x0470 6d07 0000 0000 0000 0000 0000 3907 0000 |m...........9...| 0x0480 0000 0000 0000 0000 5a03 0000 0000 0000 |........Z.......| 0x0490 2105 0000 ed04 0000 0000 0000 f807 0000 |!...............| 0x04a0 0000 0000 7505 0000 3d00 0000 3805 0000 |....u...=...8...| 0x04b0 f505 0000 f008 0000 3e05 0000 3d06 0000 |........>...=...| 0x04c0 0000 0000 7905 0000 0000 0000 0000 0000 |....y...........| 0x04d0 0e08 0000 3607 0000 9903 0000 3207 0000 |....6.......2...| 0x04e0 0000 0000 b909 0000 9806 0000 0000 0000 |................| 0x04f0 d005 0000 3302 0000 0000 0000 0000 0000 |....3...........| 0x0500 0000 0000 8302 0000 b208 0000 0000 0000 |................| 0x0510 b908 0000 6803 0000 6106 0000 0000 0000 |....h...a.......| 0x0520 cb08 0000 0000 0000 9506 0000 0000 0000 |................| 0x0530 0a0a 0000 0000 0000 2709 0000 ab02 0000 |........'.......| 0x0540 0000 0000 4606 0000 0000 0000 0000 0000 |....F...........| 0x0550 0000 0000 4203 0000 a904 0000 0000 0000 |....B...........| 0x0560 4106 0000 1209 0000 0b06 0000 6209 0000 |A...........b...| 0x0570 0000 0000 9408 0000 b807 0000 4508 0000 |............E...| 0x0580 7608 0000 4b00 0000 1f01 0000 4b03 0000 |v...K.......K...| 0x0590 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x05a0 0b05 0000 3800 0000 0000 0000 8c09 0000 |....8...........| 0x05b0 0000 0000 0d0a 0000 0000 0000 2102 0000 |............!...| 0x05c0 0000 0000 5006 0000 0000 0000 7808 0000 |....P.......x...| 0x05d0 0000 0000 f508 0000 ca06 0000 0000 0000 |................| 0x05e0 9302 0000 170a 0000 4e03 0000 7804 0000 |........N...x...| 0x05f0 0000 0000 8604 0000 b303 0000 0000 0000 |................| 0x0600 4a05 0000 dd08 0000 1307 0000 a206 0000 |J...............| 0x0610 0000 0000 0000 0000 6d05 0000 3c04 0000 |........m...<...| 0x0620 3307 0000 0000 0000 0000 0000 8f09 0000 |3...............| 0x0630 0000 0000 7b07 0000 4800 0000 3d07 0000 |....{...H...=...| 0x0640 0000 0000 0000 0000 4205 0000 1b08 0000 |........B.......| 0x0650 ee07 0000 0000 0000 d109 0000 1303 0000 |................| 0x0660 7705 0000 e904 0000 ad09 0000 8506 0000 |w...............| 0x0670 0006 0000 0000 0000 0000 0000 9b08 0000 |................| 0x0680 0000 0000 2a04 0000 df08 0000 2402 0000 |....*.......$...| 0x0690 7404 0000 8a03 0000 0000 0000 2008 0000 |t........... ...| 0x06a0 0000 0000 0000 0000 0000 0000 0a07 0000 |................| 0x06b0 8b09 0000 4f00 0000 4503 0000 0000 0000 |....O...E.......| 0x06c0 0000 0000 c908 0000 0000 0000 de07 0000 |................| 0x06d0 2908 0000 7908 0000 5204 0000 6008 0000 |)...y...R...`...| 0x06e0 0000 0000 0000 0000 9005 0000 b409 0000 |................| 0x06f0 5a04 0000 8e04 0000 8105 0000 1905 0000 |Z...............| 0x0700 0000 0000 1805 0000 2c03 0000 ae07 0000 |........,.......| 0x0710 fe02 0000 6909 0000 0f06 0000 0000 0000 |....i...........| 0x0720 0000 0000 0000 0000 7807 0000 8c03 0000 |........x.......| 0x0730 6a00 0000 0000 0000 0000 0000 6805 0000 |j...........h...| 0x0740 e508 0000 1809 0000 0000 0000 de02 0000 |................| 0x0750 0000 0000 0000 0000 ca07 0000 5c06 0000 |............\...| 0x0760 3903 0000 7204 0000 c109 0000 0000 0000 |9...r...........| 0x0770 e909 0000 4605 0000 ce08 0000 7406 0000 |....F.......t...| 0x0780 e901 0000 e209 0000 2204 0000 0000 0000 |........".......| 0x0790 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x07a0 0000 0000 3f01 0000 0000 0000 8905 0000 |....?...........| 0x07b0 3c00 0000 f700 0000 bd08 0000 8a02 0000 |<...............| 0x07c0 a806 0000 0000 0000 5b09 0000 2d02 0000 |........[...-...| 0x07d0 8b06 0000 ae01 0000 5709 0000 7e07 0000 |........W...~...| 0x07e0 7a08 0000 c709 0000 6f07 0000 0000 0000 |z.......o.......| 0x07f0 1402 0000 a109 0000 1806 0000 9904 0000 |................| 0x0800 8d03 0000 ac08 0000 b702 0000 1d07 0000 |................| 0x0810 0000 0000 0e02 0000 8909 0000 9800 0000 |................| 0x0820 1006 0000 a809 0000 d303 0000 f507 0000 |................| 0x0830 0000 0000 6606 0000 0000 0000 0000 0000 |....f...........| 0x0840 5003 0000 bb06 0000 ae09 0000 f603 0000 |P...............| 0x0850 0000 0000 3804 0000 0000 0000 5d07 0000 |....8.......]...| 0x0860 2409 0000 c604 0000 ba06 0000 b800 0000 |$...............| 0x0870 5101 0000 a903 0000 1709 0000 6905 0000 |Q...........i...| 0x0880 1909 0000 c209 0000 0000 0000 c007 0000 |................| 0x0890 0000 0000 0000 0000 0000 0000 0000 0000 |................| 0x08a0 de05 0000 4f01 0000 e607 0000 3206 0000 |....O.......2...| 0x08b0 fe00 0000 fc07 0000 e807 0000 cd02 0000 |................| 0x08c0 0000 0000 0000 0000 7006 0000 0000 0000 |........p.......| 0x08d0 af09 0000 b503 0000 e801 0000 0407 0000 |................| 0x08e0 0000 0000 da08 0000 6806 0000 4709 0000 |........h...G...| 0x08f0 0000 0000 9208 0000 e309 0000 e506 0000 |................| 0x0900 6506 0000 1708 0000 6503 0000 4b09 0000 |e.......e...K...| 0x0910 cb02 0000 2203 0000 8c06 0000 b203 0000 |...."...........| 0x0920 bd09 0000 4704 0000 4903 0000 b609 0000 |....G...I.......| 0x0930 3609 0000 f605 0000 0000 0000 4904 0000 |6...........I...| 0x0940 d809 0000 a505 0000 0000 0000 df03 0000 |................| 0x0950 0b0a 0000 ac07 0000 0000 0000 4208 0000 |............B...| 0x0960 6108 0000 010a 0000 5b06 0000 3b07 0000 |a.......[...;...| 0x0970 3705 0000 1904 0000 1906 0000 0000 0000 |7...............| 0x0980 3407 0000 5109 0000 6709 0000 c105 0000 |4...Q...g.......| 0x0990 0000 0000 6708 0000 0000 0000 3406 0000 |....g.......4...| 0x09a0 0000 0000 0000 0000 f906 0000 0000 0000 |................| 0x09b0 0000 0000 f806 0000 5907 0000 0000 0000 |........Y.......| 0x09c0 1109 0000 4b08 0000 c507 0000 8a07 0000 |....K...........| 0x09d0 6b09 0000 0000 0000 3d04 0000 b703 0000 |k.......=.......| 0x09e0 6702 0000 b901 0000 4509 0000 4404 0000 |g.......E...D...| 0x09f0 4402 0000 ba07 0000 dd09 0000 ce09 0000 |D...............| 0x0a00 e900 0000 0000 0000 f708 0000 1401 0000 |................| 0x0a10 2c09 0000 4304 0000 0000 0000 4e01 0000 |,...C.......N...| 0x0a20 0d07 0000 0000 0000 ca09 0000 e507 0000 |................| 0x0a30 6704 0000 7d06 0000 0c08 0000 5608 0000 |g...}.......V...| 0x0a40 0000 0000 3208 0000 ff00 0000 b708 0000 |....2...........| 0x0a50 0000 0000 0000 0000 1f08 0000 a909 0000 |................| 0x0a60 8005 0000 4000 0000 0000 0000 320a 0000 |....@.......2...| 0x0a70 0000 0000 da06 0000 9503 0000 0000 0000 |................| 0x0a80 0c0a 0000 ad06 0000 4d01 0000 8f07 0000 |........M.......| 0x0a90 4609 0000 e100 0000 3908 0000 0000 0000 |F.......9.......| 0x0aa0 8403 0000 6508 0000 2500 0000 d602 0000 |....e...%.......| 0x0ab0 0000 0000 1106 0000 a500 0000 a003 0000 |................| 0x0ac0 3901 0000 0000 0000 e407 0000 5105 0000 |9...........Q...| 0x0ad0 e609 0000 0000 0000 6701 0000 0000 0000 |........g.......| 0x0ae0 6609 0000 9f03 0000 0000 0000 e003 0000 |f...............| 0x0af0 0000 0000 3b00 0000 7106 0000 0000 0000 |....;...q.......| 0x0b00 3405 0000 200a 0000 8f05 0000 0000 0000 |4... ...........| 0x0b10 9b04 0000 e106 0000 d600 0000 4907 0000 |............I...| 0x0b20 d806 0000 f409 0000 df09 0000 0000 0000 |................| 0x0b30 3408 0000 8c08 0000 cd09 0000 7907 0000 |4...........y...| 0x0b40 1d04 0000 e408 0000 0000 0000 b700 0000 |................| 0x0b50 d902 0000 6b08 0000 6505 0000 0000 0000 |....k...e.......| 0x0b60 0b09 0000 4009 0000 0000 0000 6507 0000 |....@.......e...| 0x0b70 eb08 0000 0000 0000 0000 0000 e000 0000 |................| 0x0b80 fc08 0000 ad08 0000 7306 0000 050a 0000 |........s.......| 0x0b90 0000 0000 1001 0000 0000 0000 9b07 0000 |................| 0x0ba0 b400 0000 6f05 0000 1504 0000 0000 0000 |....o...........| 0x0bb0 0000 0000 0000 0000 5e06 0000 db04 0000 |........^.......| 0x0bc0 5107 0000 0000 0000 1309 0000 0000 0000 |Q...............| 0x0bd0 4909 0000 d500 0000 0000 0000 0000 0000 |I...............| 0x0be0 dc09 0000 9006 0000 8202 0000 8901 0000 |................| 0x0bf0 0000 0000 7309 0000 110a 0000 0000 0000 |....s...........| 0x0c00 ff04 0000 0000 0000 0000 0000 4905 0000 |............I...| 0x0c10 0000 0000 7200 0000 6a08 0000 0000 0000 |....r...j.......| 0x0c20 e009 0000 c603 0000 1004 0000 0902 0000 |................| 0x0c30 df01 0000 b300 0000 4207 0000 b803 0000 |........B.......| 0x0c40 9c09 0000 0000 0000 d607 0000 4008 0000 |............@...| 0x0c50 0000 0000 8208 0000 b306 0000 7509 0000 |............u...| 0x0c60 0000 0000 7607 0000 0000 0000 0000 0000 |....v...........| 0x0c70 5000 0000 6a09 0000 9f00 0000 ba08 0000 |P...j...........| 0x0c80 a708 0000 0000 0000 0000 0000 d100 0000 |................| 0x0c90 4e02 0000 6e08 0000 ce05 0000 0000 0000 |N...n...........| 0x0ca0 de09 0000 8607 0000 0000 0000 2809 0000 |............(...| 0x0cb0 da04 0000 0000 0000 6e07 0000 a608 0000 |........n.......| 0x0cc0 0000 0000 9d05 0000 bf06 0000 9000 0000 |................| 0x0cd0 0000 0000 3404 0000 0000 0000 0000 0000 |....4...........| 0x0ce0 0000 0000 be01 0000 0000 0000 8b07 0000 |................| 0x0cf0 0000 0000 cd06 0000 0000 0000 cc04 0000 |................| 0x0d00 3608 0000 5908 0000 0000 0000 030a 0000 |6...Y...........| 0x0d10 4808 0000 7501 0000 0000 0000 0000 0000 |H...u...........| 0x0d20 7e09 0000 f908 0000 ec07 0000 0000 0000 |~...............| 0x0d30 d701 0000 cf03 0000 3708 0000 8702 0000 |........7.......| 0x0d40 0000 0000 8309 0000 cd03 0000 2e07 0000 |................| 0x0d50 3f09 0000 0000 0000 7800 0000 fd02 0000 |?.......x.......| 0x0d60 d309 0000 1509 0000 0000 0000 4100 0000 |............A...| 0x0d70 0000 0000 9104 0000 0000 0000 8906 0000 |................| 0x0d80 2607 0000 0000 0000 7b02 0000 0000 0000 |&.......{.......| 0x0d90 6f02 0000 0000 0000 0000 0000 0000 0000 |o...............| 0x0da0 7308 0000 1601 0000 e808 0000 0000 0000 |s...............| 0x0db0 8407 0000 5c00 0000 0000 0000 3807 0000 |....\.......8...| 0x0dc0 f705 0000 0308 0000 0409 0000 f405 0000 |................| 0x0dd0 0000 0000 3401 0000 dd00 0000 ac03 0000 |....4...........| 0x0de0 0000 0000 0000 0000 0705 0000 0000 0000 |................| 0x0df0 2206 0000 1f07 0000 1d08 0000 bc05 0000 |"...............| 0x0e00 0000 0000 f108 0000 a205 0000 d708 0000 |................| 0x0e10 0000 0000 a508 0000 0000 0000 9102 0000 |................| 0x0e20 4006 0000 0000 0000 d106 0000 e708 0000 |@...............| 0x0e30 2609 0000 bd01 0000 d508 0000 310a 0000 |&...........1...| 0x0e40 8609 0000 0000 0000 4e08 0000 aa02 0000 |........N.......| 0x0e50 0000 0000 0000 0000 4807 0000 250a 0000 |........H...%...| 0x0e60 0000 0000 f503 0000 0209 0000 0304 0000 |................| 0x0e70 b709 0000 0000 0000 0000 0000 9c04 0000 |................| 0x0e80 5e05 0000 4f02 0000 ee09 0000 d001 0000 |^...O...........| 0x0e90 2a07 0000 1d06 0000 1b09 0000 1409 0000 |*...............| 0x0ea0 7f06 0000 9c01 0000 dc04 0000 0000 0000 |................| 0x0eb0 0000 0000 f306 0000 0000 0000 ac01 0000 |................| 0x0ec0 7a00 0000 0000 0000 2b00 0000 5700 0000 |z.......+...W...| 0x0ed0 d907 0000 cf01 0000 1b07 0000 db00 0000 |................| 0x0ee0 fb04 0000 e706 0000 f103 0000 c807 0000 |................| 0x0ef0 1c09 0000 5c09 0000 c106 0000 0905 0000 |....\...........| 0x0f00 ec09 0000 0000 0000 6009 0000 bb05 0000 |........`.......| 0x0f10 2308 0000 b406 0000 0000 0000 9a07 0000 |#...............| 0x0f20 0000 0000 c301 0000 0000 0000 0000 0000 |................| 0x0f30 f202 0000 0000 0000 9e06 0000 6d00 0000 |............m...| 0x0f40 0809 0000 a607 0000 9305 0000 e403 0000 |................| 0x0f50 0000 0000 0000 0000 0000 0000 5007 0000 |............P...| 0x0f60 a908 0000 1603 0000 0000 0000 b603 0000 |................| 0x0f70 0000 0000 0000 0000 6502 0000 0d09 0000 |........e.......| 0x0f80 5306 0000 0000 0000 3a08 0000 b509 0000 |S.......:.......| 0x0f90 8508 0000 0000 0000 b508 0000 7f07 0000 |................| 0x0fa0 0000 0000 2a03 0000 0000 0000 b903 0000 |....*...........| 0x0fb0 4405 0000 8908 0000 b304 0000 5909 0000 |D...........Y...| 0x0fc0 5807 0000 040a 0000 4708 0000 ef07 0000 |X.......G.......| 0x0fd0 c205 0000 0000 0000 0000 0000 ad07 0000 |................| 0x0fe0 8800 0000 0000 0000 1007 0000 c102 0000 |................| 0x0ff0 0000 0000 3508 0000 9e09 0000 0000 0000 |....5...........| 30357 send RET read 4096/0x1000 30357 send CALL mmap(0,0x221000,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_NOCORE,0x3,0) 30357 send RET mmap 7544832/0x800732000 30357 send CALL mprotect(0x80081f000,0x1000,PROT_READ|PROT_WRITE|PROT_EXEC) 30357 send RET mprotect 0 30357 send CALL mprotect(0x80081f000,0x1000,PROT_READ|PROT_EXEC) 30357 send RET mprotect 0 30357 send CALL mmap(0x80091f000,0x1d000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,0x3,0xed000) 30357 send RET mmap 9564160/0x80091f000 30357 send CALL mmap(0x80093c000,0x17000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,0xffffffff,0) 30357 send RET mmap 9682944/0x80093c000 30357 send CALL close(0x3) 30357 send RET close 0 30357 send CALL sysarch(0x81,0x7fffffffe770) 30357 send RET sysarch 0 30357 send CALL mmap(0,0x100,PROT_READ|PROT_WRITE,MAP_ANON,0xffffffff,0) 30357 send RET mmap 6516736/0x800637000 30357 send CALL munmap(0x800637000,0x100) 30357 send RET munmap 0 30357 send CALL mmap(0,0xa330,PROT_READ|PROT_WRITE,MAP_ANON,0xffffffff,0) 30357 send RET mmap 6516736/0x800637000 30357 send CALL munmap(0x800637000,0xa330) 30357 send RET munmap 0 30357 send CALL __sysctl(0x7fffffffe720,0x2,0x80093ce00,0x7fffffffe718,0,0) 30357 send RET __sysctl 0 30357 send CALL sigprocmask(SIG_BLOCK,0x80072cd20,0x7fffffffe740) 30357 send RET sigprocmask 0 30357 send CALL sigprocmask(SIG_SETMASK,0x80072cd30,0) 30357 send RET sigprocmask 0 30357 send CALL socket(PF_INET6,SOCK_DGRAM,IPPROTO_IP) 30357 send RET socket 3 30357 send CALL sendto(0x3,0x7fffffffea20,0x4,0,0x7fffffffea10,0x10) 30357 send RET sendto -1 errno 22 Invalid argument 30357 send CALL write(0x2,0x7fffffffe230,0x1b) 30357 send GIO fd 2 wrote 27 bytes "sendto(): Invalid argument " 30357 send RET write 27/0x1b 30357 send CALL exit(0x1) --J2SCkAp4GZ/dPZZf-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 18:39:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B8EC106564A for ; Sat, 25 Jul 2009 18:39:39 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: from mail-qy0-f191.google.com (mail-qy0-f191.google.com [209.85.221.191]) by mx1.freebsd.org (Postfix) with ESMTP id D408F8FC13 for ; Sat, 25 Jul 2009 18:39:38 +0000 (UTC) (envelope-from gaijin.k@gmail.com) Received: by qyk29 with SMTP id 29so2945947qyk.3 for ; Sat, 25 Jul 2009 11:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=bsweQLtusoKnvwbEz8/V5uOtu5wDZ2+Jvhe60KA770o=; b=hjr8SMnAGlON/JvprTCzPctZIHfcfxjB04QC/+CtQfVEu865hr+oSN39aCq9HGYtaw 7JpTHKZvdjuVYg9S97n6BZx9FBJTU8adtKN0jykXtovrenmhMqRrFPF56gt8ArEDwMlZ zz35ZaQgmv78St1QQqe8fMZZKf5bGUNmIlpBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=NxuHFYYYtdG60H4zfAdvTdMvgeAo33ItLCX3MSlnTYdG03MK7rBbgyl1NE7ejPYxXz NF6nYQAWMI9934Oka60D42MSm2vLmDVOVUyOcDnn6CLrBVmbpcwb26xLjC6+VLadzJ9N 62kfZBUOLJZ0iFNdCWM5X6JiTksv2QlTK+aCY= Received: by 10.224.89.16 with SMTP id c16mr4528403qam.280.1248547177643; Sat, 25 Jul 2009 11:39:37 -0700 (PDT) Received: from ?10.0.3.231? (pool-70-111-14-92.nwrk.east.verizon.net [70.111.14.92]) by mx.google.com with ESMTPS id 8sm7240062qwj.6.2009.07.25.11.39.35 (version=SSLv3 cipher=RC4-MD5); Sat, 25 Jul 2009 11:39:36 -0700 (PDT) From: "Alexandre \"Sunny\" Kovalenko" To: Jack Vogel In-Reply-To: <2a41acea0907231607y679cb275i42c81054f3642dda@mail.gmail.com> References: <1248291677.1479.5.camel@RabbitsDen> <2a41acea0907231607y679cb275i42c81054f3642dda@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Sat, 25 Jul 2009 14:38:37 -0400 Message-Id: <1248547117.1535.3.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: Unloading if_em causes panic on 8.0-BETA2 #0 r195818 (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 18:39:39 -0000 On Thu, 2009-07-23 at 16:07 -0700, Jack Vogel wrote: > Have a fix, it will be checked in shortly, as soon as it has re > approval. I am happy to report that r195851 of if_em.c has fixed this problem for me. Thank you very much for your work. -- Alexandre Kovalenko (ОлекÑандр Коваленко) From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 19:01:21 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6113F106564A; Sat, 25 Jul 2009 19:01:21 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 7B0458FC1F; Sat, 25 Jul 2009 19:01:20 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id E15991E002BE; Sat, 25 Jul 2009 21:01:18 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n6PJ02V7057498; Sat, 25 Jul 2009 21:00:02 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n6PJ01kI057497; Sat, 25 Jul 2009 21:00:01 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 25 Jul 2009 21:00:01 +0200 To: Juergen Lock Message-ID: <20090725190001.GA56987@triton.kn-bremen.de> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> <200907062116.n66LGk5t013830@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200907062116.n66LGk5t013830@triton.kn-bremen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mav@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 19:01:21 -0000 On Mon, Jul 06, 2009 at 11:16:46PM +0200, Juergen Lock wrote: > In article <4A50C331.3040505@FreeBSD.org> you write: > >Lucius Windschuh wrote: > >> Hi Alexander. > >> > >> 2009/7/5 Alexander Motin : > >>> It's never late. I have just uploaded fresh patch: > >>> http://people.freebsd.org/~mav/cam-ata.20090704.patch > >> > >> "make buildworld" with this patch stops in my configuration with: > >> > >> /usr/obj/usr/src/tmp/usr/lib/libcam.a(ata_all.o)(.text+0x263): In > >> function `ata_max_mode': > >> : undefined reference to `min' > >> > >> Simply adding > >> #ifndef min > >> #define min(a,b) (((a)<(b))?(a):(b)) > >> #endif > >> in ata_all.c helps, obviously. > > > >Thanks. > > I tried this on the box with that optical drive that head no > longer likes (fails to be probed and generates an irq storm, see > http://docs.freebsd.org/cgi/mid.cgi?20090628101656.GA38983 > ), and with ahci.ko loaded by loader.conf I got timeouts followed by > a panic: > http://people.freebsd.org/~nox/cam-ata.20090704-panic1.jpg > http://people.freebsd.org/~nox/cam-ata.20090704-panic2.jpg > [...] Ok I managed to dig myself out of this mess by connecting the problem drive to a jmicron pcie card that fell into my hands yesterday; I updated the test install to head from today and started reinstalling ports (bc of the shlib bumps) and testing the new hplip port on head (seems to work no worse than on 7), when suddenly ahci got problems: it printed endless retrying messages with the box' disk access led on solid, causing processes to get stuck. I was still able to switch to a console and enter ddb, but dumping (call doadump) failed and I didn't know what to look for otherwise, so I'm afraid I can't give more info about this hang. :( Anyway, could this be caused by ncq? I have disabled ahci.ko for now, we'll see if this `fixes' it... Oh and btw umass works better than on 7-stable too, at least plugging in an usb key doesnt panic the box like on 7, and i can mount it also. Here is the dmesg with ahci and the jmicron: 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 8.0-BETA2 #0: Sat Jul 25 06:50:29 CEST 2009 nox@triton.kn-bremen.de:/usr/obj/usr/home/nox/src8postsil/src/sys/TRITON8 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff81042000. Preloaded elf obj module "/boot/kernel/ahci.ko" at 0xffffffff810421d0. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2812829137 Hz CPU: AMD Phenom(tm) II X4 920 Processor (2812.83-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant L1 2MB data TLB: 48 entries, fully associative L1 2MB instruction TLB: 16 entries, fully associative L1 4KB data TLB: 48 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB data TLB: 128 entries, 2-way associative L2 2MB instruction TLB: 0 entries, 2-way associative L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative real memory = 9395240960 (8960 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x000000000106c000 - 0x00000000cfddffff, 3470213120 bytes (847220 pages) 0x0000000100000000 - 0x000000021f8affff, 4824170496 bytes (1177776 pages) avail memory = 8252354560 (7870 MB) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf6fe0 00014 (v0 GBT ) ACPI: RSDT 0xcfde3000 0003C (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: FACP 0xcfde3040 00074 (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: DSDT 0xcfde30c0 05E2B (v1 GBT GBTUACPI 00001000 MSFT 03000000) ACPI: FACS 0xcfde0000 00040 ACPI: SSDT 0xcfde8fc0 0088C (v1 PTLTD POWERNOW 00000001 LTP 00000001) ACPI: HPET 0xcfde9880 00038 (v1 GBT GBTUACPI 42302E31 GBTU 00000098) ACPI: MCFG 0xcfde98c0 0003C (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: TAMG 0xcfde9900 00302 (v1 GBT GBT B0 5455312E BG\^A\^A 53450101) ACPI: APIC 0xcfde8f00 00084 (v1 GBT GBTUACPI 42302E31 GBTU 01010101) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 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: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 wlan: <802.11 Link Layer> nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: null: io: random: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xffffff800001a000 pa 0x4000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SACS -> bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.BAR1 -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SMB0.HETT -> bus 0 dev 20 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfce0000 (3) failed ACPI timer: 1/1 1/2 1/1 1/1 1/1 1/1 1/1 1/2 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x4353 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1002, dev=0x5957, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[1c]: type Memory, range 64, base 0xe0000000, size 29, enabled found-> vendor=0x1002, dev=0x5978, revid=0x00 domain=0, bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x597b, revid=0x00 domain=0, bus=0, slot=5, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.5.INTA pcib0: slot 5 INTA hardwired to IRQ 17 found-> vendor=0x1002, dev=0x597d, revid=0x00 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.7.INTA pcib0: slot 7 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x597f, revid=0x00 domain=0, bus=0, slot=10, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.10.INTA pcib0: slot 10 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4391, revid=0x00 domain=0, bus=0, slot=17, func=0 class=01-06-01, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 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 0xff00, size 3, enabled map[14]: type I/O Port, range 32, base 0xfe00, size 2, enabled map[18]: type I/O Port, range 32, base 0xfd00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xfc00, size 2, enabled map[20]: type I/O Port, range 32, base 0xfb00, size 4, enabled map[24]: type Memory, range 32, base 0xfe02f000, size 10, enabled pcib0: matched entry for 0.17.INTA pcib0: slot 17 INTA hardwired to IRQ 22 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=18, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type Memory, range 32, base 0xfe02e000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=18, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type Memory, range 32, base 0xfe02d000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=18, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02c000, size 8, enabled pcib0: matched entry for 0.18.INTB pcib0: slot 18 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 map[10]: type Memory, range 32, base 0xfe02b000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 map[10]: type Memory, range 32, base 0xfe02a000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe029000, size 8, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4385, revid=0x3a domain=0, bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0403, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x439c, revid=0x00 domain=0, bus=0, slot=20, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 MSI supports 1 message map[20]: type I/O Port, range 32, base 0xfa00, size 4, enabled found-> vendor=0x1002, dev=0x4383, revid=0x00 domain=0, bus=0, slot=20, func=2 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0410, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xfe024000, size 14, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x439d, revid=0x00 domain=0, bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4384, revid=0x00 domain=0, bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0027, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4399, revid=0x00 domain=0, bus=0, slot=20, func=5 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=7 map[10]: type Memory, range 32, base 0xfe028000, size 12, enabled pcib0: matched entry for 0.20.INTC pcib0: slot 20 INTC hardwired to IRQ 18 found-> vendor=0x1022, dev=0x1200, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1201, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1202, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1203, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1204, revid=0x00 domain=0, bus=0, slot=24, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: irq 18 at device 2.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xfda00000-0xfdafffff pcib1: prefetched decode 0xd0000000-0xdfffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x9498, revid=0x00 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib1: requested memory range 0xd0000000-0xdfffffff: good map[18]: type Memory, range 64, base 0xfdae0000, size 16, enabled pcib1: requested memory range 0xfdae0000-0xfdaeffff: good map[20]: type I/O Port, range 32, base 0xce00, size 8, enabled pcib1: requested I/O range 0xce00-0xceff: in range pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0xaa38, revid=0x00 domain=0, bus=1, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=7 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfdafc000, size 14, enabled pcib1: requested memory range 0xfdafc000-0xfdafffff: good pcib1: matched entry for 1.0.INTB pcib1: slot 0 INTB hardwired to IRQ 19 vgapci0: port 0xce00-0xceff mem 0xd0000000-0xdfffffff,0xfdae0000-0xfdaeffff irq 18 at device 0.0 on pci1 pci1: at device 0.1 (no driver attached) pcib2: irq 17 at device 5.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xb000-0xbfff pcib2: memory decode 0xfd800000-0xfd8fffff pcib2: prefetched decode 0xfdf00000-0xfdffffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x197b, dev=0x2363, revid=0x03 domain=0, bus=2, slot=0, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xbf00, size 3, enabled pcib2: requested I/O range 0xbf00-0xbf07: in range map[14]: type I/O Port, range 32, base 0xbe00, size 2, enabled pcib2: requested I/O range 0xbe00-0xbe03: in range map[18]: type I/O Port, range 32, base 0xbd00, size 3, enabled pcib2: requested I/O range 0xbd00-0xbd07: in range map[1c]: type I/O Port, range 32, base 0xbc00, size 2, enabled pcib2: requested I/O range 0xbc00-0xbc03: in range map[20]: type I/O Port, range 32, base 0xbb00, size 4, enabled pcib2: requested I/O range 0xbb00-0xbb0f: in range map[24]: type Memory, range 32, base 0xfd8fe000, size 13, enabled pcib2: requested memory range 0xfd8fe000-0xfd8fffff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 17 atapci0: port 0xbf00-0xbf07,0xbe00-0xbe03,0xbd00-0xbd07,0xbc00-0xbc03,0xbb00-0xbb0f mem 0xfd8fe000-0xfd8fffff irq 17 at device 0.0 on pci2 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbb00 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 49 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xfd8fe000 atapci0: AHCI called from vendor specific driver atapci0: AHCI v1.00 controller with 2 3Gbps ports, PM supported atapci0: Caps: 64bit NCQ ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd 2ports ata2: on atapci0 ata2: AHCI reset... ata2: hardware reset ... ata2: SATA connect timeout status=00000000 ata2: AHCI reset done: phy reset found no device ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: AHCI reset... ata3: hardware reset ... ata3: SATA connect time=0ms status=00000113 ata3: ready wait time=11ms ata3: software reset port 15... ata3: ready wait time=0ms ata3: SIGNATURE: eb140101 ata3: AHCI reset done: devices=00010000 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xbf00 atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe00 ata4: reset tp1 mask=03 ostat0=60 ostat1=70 ata4: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 ata4: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 ata4: reset tp2 stat0=20 stat1=30 devices=0x0 ata4: [MPSAFE] ata4: [ITHREAD] pcib3: irq 19 at device 7.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xe000-0xefff pcib3: memory decode 0xfde00000-0xfdefffff pcib3: prefetched decode 0xfdd00000-0xfddfffff pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x8086, dev=0x10b9, revid=0x06 domain=0, bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfdee0000, size 17, enabled pcib3: requested memory range 0xfdee0000-0xfdefffff: good map[14]: type Memory, range 32, base 0xfdec0000, size 17, enabled pcib3: requested memory range 0xfdec0000-0xfdedffff: good map[18]: type I/O Port, range 32, base 0xef00, size 5, enabled pcib3: requested I/O range 0xef00-0xef1f: in range pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 19 em0: port 0xef00-0xef1f mem 0xfdee0000-0xfdefffff,0xfdec0000-0xfdedffff irq 19 at device 0.0 on pci3 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfdee0000 em0: attempting to allocate 1 MSI vectors (1 supported) msi: routing MSI IRQ 256 to local APIC 0 vector 50 em0: using IRQ 256 for MSI em0: Using MSI interrupt em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1b:21:34:ef:46 pcib4: irq 18 at device 10.0 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xd000-0xdfff pcib4: memory decode 0xfdc00000-0xfdcfffff pcib4: prefetched decode 0xfdb00000-0xfdbfffff pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=4, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=7 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xde00, size 8, enabled pcib4: requested I/O range 0xde00-0xdeff: in range map[18]: type Prefetchable Memory, range 64, base 0xfdbff000, size 12, enabled pcib4: requested memory range 0xfdbff000-0xfdbfffff: good map[20]: type Prefetchable Memory, range 64, base 0xfdbe0000, size 16, enabled pcib4: requested memory range 0xfdbe0000-0xfdbeffff: good pcib4: matched entry for 4.0.INTA pcib4: slot 0 INTA hardwired to IRQ 18 re0: port 0xde00-0xdeff mem 0xfdbff000-0xfdbfffff,0xfdbe0000-0xfdbeffff irq 18 at device 0.0 on pci4 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfdbff000 re0: MSI count : 2 re0: attempting to allocate 1 MSI vectors (2 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 52 re0: using IRQ 257 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:1f:d0:d7:4c:1b re0: [MPSAFE] re0: [FILTER] ahci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 ahci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe02f000 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 51 ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd CCC 6ports ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [MPSAFE] ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [MPSAFE] ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [MPSAFE] ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [MPSAFE] ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [MPSAFE] ahcich5: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02e000 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 53 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02d000 ohci1: [MPSAFE] ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe02c000 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at device 19.0 on pci0 ohci2: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02b000 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 54 ohci2: [MPSAFE] ohci2: [ITHREAD] usbus3: on ohci2 ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 ohci3: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 ohci3: [MPSAFE] ohci3: [ITHREAD] usbus4: on ohci3 ehci1: mem 0xfe029000-0xfe0290ff irq 19 at device 19.2 on pci0 ehci1: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe029000 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 55 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfa00 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=7f ostat1=7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 56 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 57 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib5: at device 20.4 on pci0 pcib5: domain 0 pcib5: secondary bus 5 pcib5: subordinate bus 5 pcib5: I/O decode 0xa000-0xafff pcib5: memory decode 0xf8000000-0xfcffffff pcib5: prefetched decode 0xfd900000-0xfd9fffff pcib5: Subtractively decoded bridge. pci5: on pcib5 pci5: domain=0, physical bus=5 found-> vendor=0x14f1, dev=0x8800, revid=0x05 domain=0, bus=5, slot=6, func=0 class=04-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x14 (5000 ns), maxlat=0x37 (13750 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf9000000, size 24, enabled pcib5: requested memory range 0xf9000000-0xf9ffffff: good pcib5: matched entry for 5.6.INTA pcib5: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8811, revid=0x05 domain=0, bus=5, slot=6, func=1 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf8000000, size 24, enabled pcib5: requested memory range 0xf8000000-0xf8ffffff: good pcib5: matched entry for 5.6.INTA pcib5: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8802, revid=0x05 domain=0, bus=5, slot=6, func=2 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x06 (1500 ns), maxlat=0x58 (22000 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfb000000, size 24, enabled pcib5: requested memory range 0xfb000000-0xfbffffff: good pcib5: matched entry for 5.6.INTA pcib5: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8804, revid=0x05 domain=0, bus=5, slot=6, func=4 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfa000000, size 24, enabled pcib5: requested memory range 0xfa000000-0xfaffffff: good pcib5: matched entry for 5.6.INTA pcib5: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x104c, dev=0x8024, revid=0x00 domain=0, bus=5, slot=14, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfcfff000, size 11, enabled pcib5: requested memory range 0xfcfff000-0xfcfff7ff: good map[14]: type Memory, range 32, base 0xfcff8000, size 14, enabled pcib5: requested memory range 0xfcff8000-0xfcffbfff: good pcib5: matched entry for 5.14.INTA pcib5: slot 14 INTA hardwired to IRQ 22 pci5: at device 6.0 (no driver attached) pci5: at device 6.1 (no driver attached) pci5: at device 6.2 (no driver attached) pci5: at device 6.4 (no driver attached) fwohci0: mem 0xfcfff000-0xfcfff7ff,0xfcff8000-0xfcffbfff irq 22 at device 14.0 on pci5 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfcfff000 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:ef:de:f8:00:00:1f:d0 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x28b8000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:ef:de:00:1f:d0 fwe0: bpf attached fwe0: Ethernet address: 02:ef:de:00:1f:d0 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:ef:de:f8:00:00:1f:d0 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 ohci4: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe028000 ohci4: [MPSAFE] ohci4: [ITHREAD] usbus6: on ohci4 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 58 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 59 uart0: [FILTER] uart0: fast interrupt psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 60 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 61 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 atrtc0: port 0x70-0x73 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) cpu0: on acpi0 cpu0: switching to generic Cx mode hwpstate0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 ex_isa_identify() ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed isa_probe_children: disabling PnP devices atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff,0xd0000-0xd27ff 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 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 uart2: not probed (disabled) uart3: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 512451 -> 100000 procfs registered lapic: Divisor 2, Frequency 100458188 hz Timecounter "TSC" frequency 2812829137 Hz quality -100 Timecounters tick every 1.000 msec pfsync0: bpf attached lo0: bpf attached pflog0: bpf attached hptrr: no controller detected.firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 ata0: Identifying devices: 00000000 ata0: New devices: 00000000 ata1: Identifying devices: 00000000 ata1: New devices: 00000000 ata2: Identifying devices: 00000000 ata2: New devices: 00000000 ata3: Identifying devices: 00010000 ata3: New devices: 00010000 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire ata3: device_reset timeout=670us acd0: DVDR drive at ata3 as master acd0: read 5512KB/s (5512KB/s) write 5512KB/s (5512KB/s), 16384KB buffer, SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 2 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata4: Identifying devices: 00000000 ata4: New devices: 00000000 Waiting 5 seconds for SCSI devices to settle ahcich0: AHCI reset... ahcich0: hardware reset ... ahcich0: SATA connect time=0ms status=00000123 ahcich0: ready wait time=0ms ahcich0: AHCI reset done: devices=00000001 ahcich1: AHCI reset... ahcich1: hardware reset ... ahcich1: SATA connect time=0ms status=00000113 ahcich1: ready wait time=143ms ahcich1: AHCI reset done: devices=00000001 ahcich2: AHCI reset... ahcich2: hardware reset ... ahcich2: SATA connect time=0ms status=00000123 ahcich2: ready wait time=0ms ahcich2: AHCI reset done: devices=00000001 ahcich3: AHCI reset... ahcich3: hardware reset ... ahcich3: SATA connect timeout status=00000000 ahcich3: AHCI reset done: phy reset found no device ahcich4: AHCI reset... ahcich4: hardware reset ... ahcich4: SATA connect timeout status=00000000 ahcich4: AHCI reset done: phy reset found no device ahcich5: AHCI reset... ahcich5: hardware reset ... ahcich5: SATA connect timeout status=00000000 ahcich5: AHCI reset done: phy reset found no device 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 uhub6: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered ugen2.2: at usbus2 (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ahcich0: Poll timeout on slot 2 (aprobe0:ahcich0:0:15:0): Command timed out (aprobe0:ahcich0:0:15:0): error 5 (aprobe0:ahcich0:0:15:0): Retries Exhausted (aprobe0:ahcich0:0:0:0): SIGNATURE: 0000 ahcich1: Poll timeout on slot 2 (aprobe1:ahcich1:0:15:0): Command timed out (aprobe1:ahcich1:0:15:0): error 5 (aprobe1:ahcich1:0:15:0): Retries Exhausted (aprobe0:ahcich1:0:0:0): SIGNATURE: eb14 ahcich2: Poll timeout on slot 2 (aprobe2:ahcich2:0:15:0): Command timed out (aprobe2:ahcich2:0:15:0): error 5 (aprobe2:ahcich2:0:15:0): Retries Exhausted (aprobe0:ahcich2:0:0:0): SIGNATURE: 0000 ada0 at ahcich0 bus 0 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: Serial Number STF604MH0PU93B ada0: 300.000MB/s transfers ada0: 953868MB (1953523055 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled ada1 at ahcich2 bus 0 target 0 lun 0 ada1: ATA/ATAPI-8 SATA 2.x device ada1: Serial Number STF604MH0PA68B ada1: 300.000MB/s transfers ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing enabled pass0 at ahcich0 bus 0 target 0 lun 0 pass0: ATA/ATAPI-8 SATA 2.x device pass0: Serial Number STF604MH0PU93BGEOM: new disk ada0 GEOM: new disk ada1 pass0: 300.000MB/s transfers pass1 at ahcich1 bus 0 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: Serial Number HJDP396785WL pass1: 150.000MB/s transfers pass2 at ahcich2 bus 0 target 0 lun 0 pass2: ATA/ATAPI-8 SATA 2.x device pass2: Serial Number STF604MH0PA68B pass2: 300.000MB/s transfers ATA PseudoRAID loaded SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff(cd0: timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400ahcich1:0: 0:0): Retrying Command SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 1 vector 48 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 2 vector 48 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 3 vector 48 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 1 vector 49 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 2 vector 49 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 3 vector 49 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 1 vector 50 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 2 vector 50 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 3 vector 50 msi: Assigning MSI IRQ 257 to local APIC 1 vector 51 WARNING: WITNESS option enabled, expect reduced performance. (cd0:ahcich1:0:0:0): error 6 (cd0:ahcich1:0:0:0): Unretryable Error cd0 at ahcich1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number HJDP396785WL cd0: 150.000MB/s transfers cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, or bus device reset occurred GEOM: ada1: partition 1 does not start on a track boundary. GEOM: ada1: partition 1 does not end on a track boundary. GEOM: new disk cd0 GEOM: ada0s2: geometry does not match label (255h,63s != 16h,63s). GEOM: ada1s3: geometry does not match label (255h,63s != 16h,63s). (cd0:ahcich1:0:0:0): Retrying Command (cd0:ahcich1:0:0:0): error 6 (cd0:ahcich1:0:0:0): Unretryable Error (cd0:ahcich1:0:0:0): Retrying Command (cd0:ahcich1:0:0:0): error 6 (cd0:ahcich1:0:0:0): Unretryable Error Trying to mount root from ufs:/dev/ufsid/49bca1defbad5bce ct_to_ts([2009-07-25 07:03:27]) = 1248505407.000000000 start_init: trying /sbin/init Linux ELF exec handler installed linprocfs registered lock order reversal: 1st 0xffffffff80c1cbe0 pf task mtx (pf task mtx) @ /usr/home/nox/src8postsil/src/sys/contrib/pf/net/pf_ioctl.c:1394 2nd 0xffffffff80e15f40 ifnet (ifnet) @ /usr/home/nox/src8postsil/src/sys/net/if.c:1822 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 _rw_rlock() at _rw_rlock+0x5f ifunit() at ifunit+0x22 pfioctl() at pfioctl+0x1f6d devfs_ioctl_f() at devfs_ioctl_f+0x76 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x80098798c, rsp = 0x7fffffffb568, rbp = 0x7fffffffb6c0 --- tun0: bpf attached altq: emulate 256000000Hz cpu clock WARNING: attempt to domain_add(netgraph) after domainfinalize() splash: image decoder found: green_saver em0: Link is up 1000 Mbps Full Duplex re0: link state changed to UP em0: link state changed to UP From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 19:19:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6AB9106566B for ; Sat, 25 Jul 2009 19:19:42 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 213058FC12 for ; Sat, 25 Jul 2009 19:19:41 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 249722345; Sat, 25 Jul 2009 22:19:38 +0300 Message-ID: <4A6B5AAE.9010809@FreeBSD.org> Date: Sat, 25 Jul 2009 22:19:10 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Juergen Lock References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> <200907062116.n66LGk5t013830@triton.kn-bremen.de> <20090725190001.GA56987@triton.kn-bremen.de> In-Reply-To: <20090725190001.GA56987@triton.kn-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 19:19:43 -0000 Juergen Lock wrote: > On Mon, Jul 06, 2009 at 11:16:46PM +0200, Juergen Lock wrote: >> I tried this on the box with that optical drive that head no >> longer likes (fails to be probed and generates an irq storm, see >> http://docs.freebsd.org/cgi/mid.cgi?20090628101656.GA38983 >> ), and with ahci.ko loaded by loader.conf I got timeouts followed by >> a panic: >> http://people.freebsd.org/~nox/cam-ata.20090704-panic1.jpg >> http://people.freebsd.org/~nox/cam-ata.20090704-panic2.jpg >> [...] > > Ok I managed to dig myself out of this mess by connecting the problem > drive to a jmicron pcie card that fell into my hands yesterday; I updated > the test install to head from today and started reinstalling ports (bc of > the shlib bumps) and testing the new hplip port on head (seems to work > no worse than on 7), when suddenly ahci got problems: it printed endless > retrying messages with the box' disk access led on solid, causing processes > to get stuck. I was still able to switch to a console and enter ddb, > but dumping (call doadump) failed and I didn't know what to look for > otherwise, so I'm afraid I can't give more info about this hang. :( > Anyway, could this be caused by ncq? I have disabled ahci.ko for now, > we'll see if this `fixes' it... Difficult to say without seeing those messages. NCQ errors actually may lead to series (up to 32) of retries, as if there were several running commands when error happened, all other commands are aborted and retried after error recovery process completes. I haven't experimented with really broken drives, but artificially generated NCQ errors were handled properly on my tests. > Here is the dmesg with ahci and the jmicron: > > atapci0: port 0xbf00-0xbf07,0xbe00-0xbe03,0xbd00-0xbd07,0xbc00-0xbc03,0xbb00-0xbb0f mem 0xfd8fe000-0xfd8fffff irq 17 at device 0.0 on pci2 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbb00 > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 49 > atapci0: [MPSAFE] > atapci0: [ITHREAD] > atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xfd8fe000 > atapci0: AHCI called from vendor specific driver > atapci0: AHCI v1.00 controller with 2 3Gbps ports, PM supported > atapci0: Caps: 64bit NCQ ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd 2ports > ata2: on atapci0 > ata2: AHCI reset... > ata2: hardware reset ... > ata2: SATA connect timeout status=00000000 > ata2: AHCI reset done: phy reset found no device > ata2: [MPSAFE] > ata2: [ITHREAD] > ata3: on atapci0 > ata3: AHCI reset... > ata3: hardware reset ... > ata3: SATA connect time=0ms status=00000113 > ata3: ready wait time=11ms > ata3: software reset port 15... > ata3: ready wait time=0ms > ata3: SIGNATURE: eb140101 > ata3: AHCI reset done: devices=00010000 > ata3: [MPSAFE] > ata3: [ITHREAD] > ata4: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xbf00 > atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe00 > ata4: reset tp1 mask=03 ostat0=60 ostat1=70 > ata4: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 > ata4: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 > ata4: reset tp2 stat0=20 stat1=30 devices=0x0 > ata4: [MPSAFE] > ata4: [ITHREAD] As I can see here, your JMicron configured for combined mode, not for plain AHCI, so it was handled by ata(4), not by ahci(4). -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 19:39:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4ADB1106566B for ; Sat, 25 Jul 2009 19:39:35 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 00CB38FC1B for ; Sat, 25 Jul 2009 19:39:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so1254081and.13 for ; Sat, 25 Jul 2009 12:39:34 -0700 (PDT) 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=sclBErycIORlZ2hLcflyzgbzl5TnYBsfueNB/7UaPII=; b=bYkVCyehj5xbrVvjkJDQ4KRGxIGFPIOYIKhIR8tGPavRyoPgk7VSq9EVuRO0LOyasE KxQeqgT13/KyjDpkNPMgMPYyl0Nd9vkpwU5w+2TrnhuJ7vUhkgZRzKTydadWVw9j37zV JlpnHcyZaP9UZOUs6C15YkIuEKY0FYgww4j0M= 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=Tg4T+kBJOr6Xa857G5+sPFWYLwVsPDlhenWLsP+VD6wn3KFjLoRUFmFcWabQKhJ15j zttdLacDaUyvLx9jLAjgwAPxsQh9uJIQzRytQeMxih8909QpxTapbXTmSy3gW28Y6+QL TF6/Jew8fN7IFLcf9Y4oc4YwmFQCzdKNK7VdM= MIME-Version: 1.0 Received: by 10.100.250.16 with SMTP id x16mr6249531anh.25.1248550774377; Sat, 25 Jul 2009 12:39:34 -0700 (PDT) In-Reply-To: <1248547117.1535.3.camel@RabbitsDen> References: <1248291677.1479.5.camel@RabbitsDen> <2a41acea0907231607y679cb275i42c81054f3642dda@mail.gmail.com> <1248547117.1535.3.camel@RabbitsDen> Date: Sat, 25 Jul 2009 12:39:34 -0700 Message-ID: <2a41acea0907251239i7b5d495erc583f625d2f1b9b8@mail.gmail.com> From: Jack Vogel To: Alexandre Sunny Kovalenko Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Unloading if_em causes panic on 8.0-BETA2 #0 r195818 (i386) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 19:39:35 -0000 Glad its fixed, and thank you for reporting the bug. Best regards, Jack On Sat, Jul 25, 2009 at 11:38 AM, Alexandre "Sunny" Kovalenko < gaijin.k@gmail.com> wrote: > On Thu, 2009-07-23 at 16:07 -0700, Jack Vogel wrote: > > Have a fix, it will be checked in shortly, as soon as it has re > > approval. > > I am happy to report that r195851 of if_em.c has fixed this problem for > me. > > Thank you very much for your work. > > -- > Alexandre Kovalenko (=EF=CC=C5=CB=D3=C1=CE=C4=D2 =EB=CF=D7=C1=CC=C5=CE=CB= =CF) > > > From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 18:53:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CE991065675 for ; Sat, 25 Jul 2009 18:53:12 +0000 (UTC) (envelope-from greg.kerr@akua.com) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3148FC0A for ; Sat, 25 Jul 2009 18:53:12 +0000 (UTC) (envelope-from greg.kerr@akua.com) Received: from OMTA19.emeryville.ca.mail.comcast.net ([76.96.30.76]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id LJXp1c0091eYJf8A1Jg3fm; Sat, 25 Jul 2009 18:40:03 +0000 Received: from lion.coh.akua.com ([65.96.218.14]) by OMTA19.emeryville.ca.mail.comcast.net with comcast id LJg11c00H0KDg8Z01Jg2mu; Sat, 25 Jul 2009 18:40:03 +0000 Received: by lion.coh.akua.com (Postfix, from userid 32767) id 24FA471654E; Sat, 25 Jul 2009 14:37:06 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lion.coh.akua.com X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from xitrus.coh.akua.com (xitrus.coh.akua.com [10.9.9.9]) by lion.coh.akua.com (Postfix) with ESMTPSA id 2CDA5716540 for ; Sat, 25 Jul 2009 14:37:05 -0400 (EDT) Message-Id: <9402F820-C832-451C-A59F-A856CB5DB884@akua.com> From: Greg Kerr To: freebsd-current@freebsd.org In-Reply-To: <20090720165136.495F21065715@hub.freebsd.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 25 Jul 2009 14:39:59 -0400 References: <20090720165136.495F21065715@hub.freebsd.org> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Sat, 25 Jul 2009 19:47:45 +0000 Subject: Re: SiI3124/3132/3531 CAM driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 18:53:12 -0000 Put it on an 8b2 amd64 Toshiba notebook with a WD Studio II 2TB sata drive attached to a Rosewill ExpressCard, installed $ kldstat Id Refs Address Size Name 1 24 0xffffffff80100000 93cf50 kernel 2 1 0xffffffff80a4d000 190bb0 zfs.ko 3 2 0xffffffff80bde000 3978 opensolaris.ko 4 1 0xffffffff80be2000 755d0 sound.ko 5 1 0xffffffff80c58000 1578 accf_http.ko 6 1 0xffffffff80c5b000 8d78 siis.ko 7 1 0xffffffff80e22000 1fa green_saver.ko 8 1 0xffffffff80e23000 754 rtc.ko $ lspci | grep 3132 02:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01) $ dmesg|grep 3132 atapci0: at device 0.0 on pci2 $ dmesg | grep atapci0 atapci0: at device 0.0 on pci2 atapci0: [ITHREAD] atapci0: 0x80 bytes of rid 0x10 res 3 failed (0, 0xffffffffffffffff). device_attach: atapci0 attach returned 6 Thanks From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 20:13:31 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A258F106566C; Sat, 25 Jul 2009 20:13:31 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 31C628FC0A; Sat, 25 Jul 2009 20:13:31 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 7E4A01E002B9; Sat, 25 Jul 2009 22:13:30 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n6PKBFXm062456; Sat, 25 Jul 2009 22:11:15 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n6PKBFXA062455; Sat, 25 Jul 2009 22:11:15 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 25 Jul 2009 22:11:14 +0200 To: Alexander Motin Message-ID: <20090725201114.GA62249@triton.kn-bremen.de> References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> <200907062116.n66LGk5t013830@triton.kn-bremen.de> <20090725190001.GA56987@triton.kn-bremen.de> <4A6B5AAE.9010809@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A6B5AAE.9010809@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 20:13:32 -0000 On Sat, Jul 25, 2009 at 10:19:10PM +0300, Alexander Motin wrote: > Juergen Lock wrote: > > On Mon, Jul 06, 2009 at 11:16:46PM +0200, Juergen Lock wrote: > >> I tried this on the box with that optical drive that head no > >> longer likes (fails to be probed and generates an irq storm, see > >> http://docs.freebsd.org/cgi/mid.cgi?20090628101656.GA38983 > >> ), and with ahci.ko loaded by loader.conf I got timeouts followed by > >> a panic: > >> http://people.freebsd.org/~nox/cam-ata.20090704-panic1.jpg > >> http://people.freebsd.org/~nox/cam-ata.20090704-panic2.jpg > >> [...] > > > > Ok I managed to dig myself out of this mess by connecting the problem > > drive to a jmicron pcie card that fell into my hands yesterday; I updated > > the test install to head from today and started reinstalling ports (bc of > > the shlib bumps) and testing the new hplip port on head (seems to work > > no worse than on 7), when suddenly ahci got problems: it printed endless > > retrying messages with the box' disk access led on solid, causing processes > > to get stuck. I was still able to switch to a console and enter ddb, > > but dumping (call doadump) failed and I didn't know what to look for > > otherwise, so I'm afraid I can't give more info about this hang. :( > > Anyway, could this be caused by ncq? I have disabled ahci.ko for now, > > we'll see if this `fixes' it... > > Difficult to say without seeing those messages. NCQ errors actually may > lead to series (up to 32) of retries, as if there were several running > commands when error happened, all other commands are aborted and retried > after error recovery process completes. Ah so the recovery could take several minutes? Maybe I didn't wait long enough then... > I haven't experimented with > really broken drives, but artificially generated NCQ errors were handled > properly on my tests. > OK I guess I should take a photo next time it happens... Btw, can the max # of `tags' be lowered with ncq too in case a drive cant handle too many? I think its `camcontrol tags' for scsi... > > Here is the dmesg with ahci and the jmicron: > > > > atapci0: port 0xbf00-0xbf07,0xbe00-0xbe03,0xbd00-0xbd07,0xbc00-0xbc03,0xbb00-0xbb0f mem 0xfd8fe000-0xfd8fffff irq 17 at device 0.0 on pci2 > > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbb00 > > ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 49 > > atapci0: [MPSAFE] > > atapci0: [ITHREAD] > > atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xfd8fe000 > > atapci0: AHCI called from vendor specific driver > > atapci0: AHCI v1.00 controller with 2 3Gbps ports, PM supported > > atapci0: Caps: 64bit NCQ ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd 2ports > > ata2: on atapci0 > > ata2: AHCI reset... > > ata2: hardware reset ... > > ata2: SATA connect timeout status=00000000 > > ata2: AHCI reset done: phy reset found no device > > ata2: [MPSAFE] > > ata2: [ITHREAD] > > ata3: on atapci0 > > ata3: AHCI reset... > > ata3: hardware reset ... > > ata3: SATA connect time=0ms status=00000113 > > ata3: ready wait time=11ms > > ata3: software reset port 15... > > ata3: ready wait time=0ms > > ata3: SIGNATURE: eb140101 > > ata3: AHCI reset done: devices=00010000 > > ata3: [MPSAFE] > > ata3: [ITHREAD] > > ata4: on atapci0 > > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xbf00 > > atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe00 > > ata4: reset tp1 mask=03 ostat0=60 ostat1=70 > > ata4: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 > > ata4: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 > > ata4: reset tp2 stat0=20 stat1=30 devices=0x0 > > ata4: [MPSAFE] > > ata4: [ITHREAD] > > As I can see here, your JMicron configured for combined mode, not for > plain AHCI, so it was handled by ata(4), not by ahci(4). Ah that can be configured? Anyway there's only an optical drive on it atm so its probably not _that_ important. :) Thanx, Juergen From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 20:26:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 081B910656A6 for ; Sat, 25 Jul 2009 20:26:30 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6708FC16 for ; Sat, 25 Jul 2009 20:26:28 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 249723632; Sat, 25 Jul 2009 23:26:24 +0300 Message-ID: <4A6B6A54.1090709@FreeBSD.org> Date: Sat, 25 Jul 2009 23:25:56 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Juergen Lock References: <4A4517BE.9040504@FreeBSD.org> <4A4FEBBC.30203@omnilan.de> <4A5053A8.2060902@FreeBSD.org> <90a5caac0907050729k4b24f2eaj64f7d752bddff1ea@mail.gmail.com> <200907062116.n66LGk5t013830@triton.kn-bremen.de> <20090725190001.GA56987@triton.kn-bremen.de> <4A6B5AAE.9010809@FreeBSD.org> <20090725201114.GA62249@triton.kn-bremen.de> In-Reply-To: <20090725201114.GA62249@triton.kn-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 20:26:30 -0000 Juergen Lock wrote: > On Sat, Jul 25, 2009 at 10:19:10PM +0300, Alexander Motin wrote: >> Juergen Lock wrote: >>> On Mon, Jul 06, 2009 at 11:16:46PM +0200, Juergen Lock wrote: >>>> I tried this on the box with that optical drive that head no >>>> longer likes (fails to be probed and generates an irq storm, see >>>> http://docs.freebsd.org/cgi/mid.cgi?20090628101656.GA38983 >>>> ), and with ahci.ko loaded by loader.conf I got timeouts followed by >>>> a panic: >>>> http://people.freebsd.org/~nox/cam-ata.20090704-panic1.jpg >>>> http://people.freebsd.org/~nox/cam-ata.20090704-panic2.jpg >>>> [...] >>> Ok I managed to dig myself out of this mess by connecting the problem >>> drive to a jmicron pcie card that fell into my hands yesterday; I updated >>> the test install to head from today and started reinstalling ports (bc of >>> the shlib bumps) and testing the new hplip port on head (seems to work >>> no worse than on 7), when suddenly ahci got problems: it printed endless >>> retrying messages with the box' disk access led on solid, causing processes >>> to get stuck. I was still able to switch to a console and enter ddb, >>> but dumping (call doadump) failed and I didn't know what to look for >>> otherwise, so I'm afraid I can't give more info about this hang. :( >>> Anyway, could this be caused by ncq? I have disabled ahci.ko for now, >>> we'll see if this `fixes' it... >> Difficult to say without seeing those messages. NCQ errors actually may >> lead to series (up to 32) of retries, as if there were several running >> commands when error happened, all other commands are aborted and retried >> after error recovery process completes. > > Ah so the recovery could take several minutes? Maybe I didn't wait > long enough then... Depends on number of errors. It should be incredibly bad case I think. >> I haven't experimented with >> really broken drives, but artificially generated NCQ errors were handled >> properly on my tests. >> > OK I guess I should take a photo next time it happens... Btw, can the > max # of `tags' be lowered with ncq too in case a drive cant handle > too many? I think its `camcontrol tags' for scsi... To allow some simplifications, current implementation supports NCQ in all-or-none fashion. If drive reports queue support of less then 32 commands, then NCQ will not be used for it. It is not controllable via `camcontrol tags` now, due to major difference between SATA NCQ and SCSI TCQ operation principles. >>> Here is the dmesg with ahci and the jmicron: >>> >>> atapci0: port 0xbf00-0xbf07,0xbe00-0xbe03,0xbd00-0xbd07,0xbc00-0xbc03,0xbb00-0xbb0f mem 0xfd8fe000-0xfd8fffff irq 17 at device 0.0 on pci2 >>> atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbb00 >>> ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 49 >>> atapci0: [MPSAFE] >>> atapci0: [ITHREAD] >>> atapci0: Reserved 0x2000 bytes for rid 0x24 type 3 at 0xfd8fe000 >>> atapci0: AHCI called from vendor specific driver >>> atapci0: AHCI v1.00 controller with 2 3Gbps ports, PM supported >>> atapci0: Caps: 64bit NCQ ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd 2ports >>> ata2: on atapci0 >>> ata2: AHCI reset... >>> ata2: hardware reset ... >>> ata2: SATA connect timeout status=00000000 >>> ata2: AHCI reset done: phy reset found no device >>> ata2: [MPSAFE] >>> ata2: [ITHREAD] >>> ata3: on atapci0 >>> ata3: AHCI reset... >>> ata3: hardware reset ... >>> ata3: SATA connect time=0ms status=00000113 >>> ata3: ready wait time=11ms >>> ata3: software reset port 15... >>> ata3: ready wait time=0ms >>> ata3: SIGNATURE: eb140101 >>> ata3: AHCI reset done: devices=00010000 >>> ata3: [MPSAFE] >>> ata3: [ITHREAD] >>> ata4: on atapci0 >>> atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0xbf00 >>> atapci0: Reserved 0x4 bytes for rid 0x14 type 4 at 0xbe00 >>> ata4: reset tp1 mask=03 ostat0=60 ostat1=70 >>> ata4: stat0=0x20 err=0x20 lsb=0x20 msb=0x20 >>> ata4: stat1=0x30 err=0x30 lsb=0x30 msb=0x30 >>> ata4: reset tp2 stat0=20 stat1=30 devices=0x0 >>> ata4: [MPSAFE] >>> ata4: [ITHREAD] >> As I can see here, your JMicron configured for combined mode, not for >> plain AHCI, so it was handled by ata(4), not by ahci(4). > > Ah that can be configured? Anyway there's only an optical drive on > it atm so its probably not _that_ important. :) On my system it can be configured via BIOS settings. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 21:02:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48E5E106564A for ; Sat, 25 Jul 2009 21:02:28 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id C6C898FC13 for ; Sat, 25 Jul 2009 21:02:27 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 249724346; Sun, 26 Jul 2009 00:02:24 +0300 Message-ID: <4A6B72C4.6050408@FreeBSD.org> Date: Sun, 26 Jul 2009 00:01:56 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Greg Kerr , FreeBSD-Current References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: SiI3124/3132/3531 CAM driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 21:02:28 -0000 Greg Kerr wrote: > Put it on an 8b2 amd64 Toshiba notebook with a WD Studio II 2TB sata > drive attached to a Rosewill ExpressCard, installed > > $ kldstat > Id Refs Address Size Name > 6 1 0xffffffff80c5b000 8d78 siis.ko Have you loaded siis via loader.conf or later with kldload? You should use loader.conf, or ata(4) will grab first. > $ lspci | grep 3132 > 02:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial > ATA Raid II Controller (rev 01) Show `pciconf -lbcv` for it please. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Jul 25 23:59:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AA06106564A; Sat, 25 Jul 2009 23:59:35 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 074298FC0A; Sat, 25 Jul 2009 23:59:34 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by qw-out-2122.google.com with SMTP id 3so1175116qwe.7 for ; Sat, 25 Jul 2009 16:59:34 -0700 (PDT) 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 :content-transfer-encoding; bh=xTEvr4xQcDdcYtKwkXVBctnR6Sds9By6ScUc95T9tQc=; b=fc3LBTYX07RuAc3qMBOOcoUdA+ZCaMhV+dRLpIZuiZiYuEPOqzTFbYwBg2d+wXe+m6 UlsP9P9GuuUz1Q/vjvSbPBlweRlrM1Z+RPRmV4S+ZuH+Tl/bXqYwxOwMiAqPiddX4iCu HW890R4rsvG6OMAjRhCGR4QvlhWA0nhaOa14Y= 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:content-transfer-encoding; b=HN7ekF8zigibRFs9ynJGe5knLBE8wBzKkjb3bEh5KdLfdAWMhxt98TAqtOF/gm3deM iSZbAlA1Xyts0sLXiJ+FlfH4Gtf3lt5iVWlyEKC/LSjExqWOjFnfDJxAfddQn8lZzMrt LuyhiWsUvSUxOdy0uInDALlx10JkT3bh+WSvQ= MIME-Version: 1.0 Received: by 10.220.46.5 with SMTP id h5mr3042215vcf.28.1248566373903; Sat, 25 Jul 2009 16:59:33 -0700 (PDT) In-Reply-To: <4A69AB91.2010208@icyb.net.ua> References: <1280352d0907101020q69f494cdndb01ff14ecf7ea8c@mail.gmail.com> <200907152236.58049.hselasky@c2i.net> <20090720215141.GL49724@elvis.mu.org> <200907211420.33571.hselasky@c2i.net> <4A69AB91.2010208@icyb.net.ua> Date: Sat, 25 Jul 2009 16:59:33 -0700 Message-ID: From: Maksim Yevmenkin To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@freebsd.org, freebsd-current@freebsd.org, Andrew Thompson , Hans Petter Selasky Subject: Re: USB polling (75% done) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 23:59:36 -0000 On Fri, Jul 24, 2009 at 5:39 AM, Andriy Gapon wrote: > on 23/07/2009 21:23 Maksim Yevmenkin said the following: >> On Tue, Jul 21, 2009 at 5:20 AM, Hans Petter Selasky wrote: >>> On Monday 20 July 2009 23:51:41 Alfred Perlstein wrote: >>>> * Hans Petter Selasky [090715 13:37] wrote: > ... >>>>> Using USB keyboard in KDB: Does not work because Giant is not locked when >>>>> calling into the UKBD's get char routine. UKBD is Giant locked. Someone >>>>> familiar with the keyboard system on FreeBSD please step forward and fix >>>>> this so that UKBD gets independent of the Giant mutex. >>>> the ukbd driver needs giant? >>> I think the keyboard mux is under Giant, and does not have any concept about >>> mutexes. Most simple solution would be that DDB locks Giant before entering >>> into the keyboard code. >> >> as i understand it, keyboard drivers (and kbdmux(4) is a keyboard >> driver), can/should not use any locks. period. so whatever calls into >> keyboard driver should take care of locking. > > Maybe I am missing something but I do not see any explicit locking or lock > assertions in kbdmux code. All lock defines are under #if 0. that is what i said, no? :) keyboard drivers can/should not use any locks. > kbdmux does use taskqueue_swi_giant though. Tasks are queued on it in > kbdmux_kbd_intr_timo (periodic callout) and in kbdmux_kbd_event (kbd callback). so? it only means that callout will be called with giant held. which is exactly what i said, whatever calls into keyboard driver should take care of locking. > But, these shouldn't get called in polling mode, right? (because there shouldn't > be any interrupts) well, there is polling mode and then there is polling mode :) when ddb is active, yes, there should not be any interrupts, however, there are cases when keyboard is running in polled mode with interrupts enabled. for example, mountroot prompt, geli passphrase prompt, etc. > Maybe Giant asserts in ukbd are not needed? > Or should be asserted only in "normal" mode? again, as far as i understand it, keyboard driver should/can not use any locks. imo, it means that keyboard driver generally should/can not assert on any lock as well. if system drops into ddb because it has panic'ed, any lock can be in any state (potentially) . thanks, max