From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 00:12: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 A1824106564A for ; Sun, 30 Aug 2009 00:12:21 +0000 (UTC) (envelope-from dhorn2000@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 36CC78FC08 for ; Sun, 30 Aug 2009 00:12:20 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 16so236055fgg.13 for ; Sat, 29 Aug 2009 17:12:20 -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=wm29ev8E3z0YfCxfHiH/OTmuasYAUp8jr+TQptMxkkA=; b=HzAI3WITEjkf6k1ik/RCiEBsK/+CpLja7DG6Utt6BFIn1id7bdZghDoDpgXi6Am7vv 4atrUrpM1wbjwOjP8XabxH8oBp2oYyEGJP/Kd9BbAXFh696v+wzdUxIJRVCzMoI2ydkN awrxIfCH5Ji5p8Ab+ftUrAtUjFLgxnGiiDG9E= 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=I7h48yfJBRr1mteXgdLAB6yPn6hu8X8y7hnhXG8UH18mB9On6KGivVCs7a5QcTvOie Q8KoEmvspbd246y3tXzVf4hDRsJc24oax/skvVEgt8al0CWQnAf9kuL/Qc3XKYIswE79 knR9bIF3f9wMGFkDeBb15DOd1lsXnIkFl/7hg= MIME-Version: 1.0 Received: by 10.86.214.12 with SMTP id m12mr536162fgg.55.1251589764498; Sat, 29 Aug 2009 16:49:24 -0700 (PDT) In-Reply-To: References: Date: Sat, 29 Aug 2009 19:49:24 -0400 Message-ID: <25ff90d60908291649x41c020f7tae404c245c4204de@mail.gmail.com> From: David Horn To: Michael Ekstrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: 8.0-BETA3: Cannot use iwn on Thinkpad R61 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 00:12:21 -0000 On Sat, Aug 29, 2009 at 1:49 PM, Michael Ekstrand wrot= e: > I was trying today to get 8.0-BETA3 amd64 usable on my laptop (Thinkpad > R61, Intel 4965 wireless chipset) and so far have had no success. =A0iwnf= w > and if_iwn load without errors, but when I do > > # ifconfig iwn0 list caps > You can't use the iwn0 interface directly. Starting with 8.0, there is a new virtual interface (wlanX) that must be created for each 80.11 (wi-fi) interface that you wish to use. (aka vap or multi-bss) `ifconfig wlan create wlandev iwn0` will create the interface (wlan0 or wlan1, etc.), then you can do things like `ifconfig wlan0 scan`, or `ifconfig wlan0 list caps` If you want this done for you automatically at system boot, add the following lines to your /etc/rc.conf file: wlans_iwn0=3D"wlan0" ifconfig_wlan0=3D"DHCP WPA" You then just need to set your SSID and authentication data (ssid/wpa/psk, etc in /etc/wpa_supplicant.conf) man iwn man wlan man rc.conf man wpa_supplicant.conf > it fails with "invalid argument." =A0Similarly, wpa_supplicant cannot > initialize the interface (again reporting invalid argument). =A0`ifconfig > iwn0 up scan` also fails, complaining that it cannot get the scan results > > > Any suggestions? See also /usr/src/UPDATING entry from 20080420 and search the freebsd-current archives for iwn for other discussion points. > > - Michael > > Good Luck. --Dave From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 00:33: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 300C9106566C for ; Sun, 30 Aug 2009 00:33:22 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 160AE8FC14 for ; Sun, 30 Aug 2009 00:33:22 +0000 (UTC) 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 n7U0XIE9009283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 29 Aug 2009 17:33:19 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id D744B1CC09; Sat, 29 Aug 2009 17:33:18 -0700 (PDT) To: Michael Ekstrand In-reply-to: Your message of "Sat, 29 Aug 2009 12:49:44 CDT." Date: Sat, 29 Aug 2009 17:33:18 -0700 From: "Kevin Oberman" Message-Id: <20090830003318.D744B1CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-08-27_08:2009-08-26, 2009-08-27, 2009-08-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0907200000 definitions=main-0908290177 Cc: freebsd-current@freebsd.org Subject: Re: 8.0-BETA3: Cannot use iwn on Thinkpad R61 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 00:33:22 -0000 > From: Michael Ekstrand > Date: Sat, 29 Aug 2009 12:49:44 -0500 > Sender: owner-freebsd-current@freebsd.org > > I was trying today to get 8.0-BETA3 amd64 usable on my laptop (Thinkpad > R61, Intel 4965 wireless chipset) and so far have had no success. iwnfw > and if_iwn load without errors, but when I do > > # ifconfig iwn0 list caps > > it fails with "invalid argument." Similarly, wpa_supplicant cannot > initialize the interface (again reporting invalid argument). `ifconfig > iwn0 up scan` also fails, complaining that it cannot get the scan results Looks like you need to read /usr/src/UPDATING or the iwn(4) man page. In 8.0, wireless requires a rather different setup. You need to create a wlan device and configure that interface. The man page has examples, but the basic command would be: ifconfig wlan0 create wlandev iwn0 -- 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 Sun Aug 30 03:38: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 5E236106566B for ; Sun, 30 Aug 2009 03:38:25 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by mx1.freebsd.org (Postfix) with ESMTP id 195C58FC08 for ; Sun, 30 Aug 2009 03:38:24 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.50) id 1MhbFC-0000DZ-Rh for freebsd-current@freebsd.org; Sun, 30 Aug 2009 05:38:18 +0200 Received: from elehack.net ([216.243.177.100]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Aug 2009 05:38:18 +0200 Received: from michael by elehack.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 30 Aug 2009 05:38:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Michael Ekstrand Date: Sat, 29 Aug 2009 22:38:01 -0500 Lines: 18 Message-ID: References: <25ff90d60908291649x41c020f7tae404c245c4204de@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: elehack.net User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) In-Reply-To: <25ff90d60908291649x41c020f7tae404c245c4204de@mail.gmail.com> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: 8.0-BETA3: Cannot use iwn on Thinkpad R61 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 03:38:25 -0000 David Horn wrote: > On Sat, Aug 29, 2009 at 1:49 PM, Michael Ekstrand wrote: >> I was trying today to get 8.0-BETA3 amd64 usable on my laptop (Thinkpad >> R61, Intel 4965 wireless chipset) and so far have had no success. iwnfw >> and if_iwn load without errors, but when I do >> >> # ifconfig iwn0 list caps >> > > You can't use the iwn0 interface directly. Starting with 8.0, there > is a new virtual interface (wlanX) that must be created for each 80.11 > (wi-fi) interface that you wish to use. (aka vap or multi-bss) Thank you. I was operating out of the web version of the handbook and somehow overlooked the example in iwn(4) that had the wlan device creation commands. It works now. - Michael From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 14:44: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 A4764106566C; Sun, 30 Aug 2009 14:44:58 +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 E38D98FC17; Sun, 30 Aug 2009 14:44:57 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n7UEiqf9009063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Aug 2009 17:44:52 +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 n7UEiqfx087454; Sun, 30 Aug 2009 17:44:52 +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 n7UEiqSU087453; Sun, 30 Aug 2009 17:44:52 +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: Sun, 30 Aug 2009 17:44:52 +0300 From: Kostik Belousov To: freebsd-amd64@freebsd.org Message-ID: <20090830144452.GK1881@deviant.kiev.zoral.com.ua> References: <20090824193344.GA34949@server.vk2pj.dyndns.org> <20090829233454.GA13036@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ef8eQmdvO1j1gFMO" Content-Disposition: inline In-Reply-To: <20090829233454.GA13036@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: sshd failing in jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 14:44:58 -0000 --ef8eQmdvO1j1gFMO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 30, 2009 at 09:34:54AM +1000, Peter Jeremy wrote: > [Redirected to amd64 because this is an amd64 kernel bug] >=20 > On 2009-Aug-25 05:33:44 +1000, Peter Jeremy wrote: > >I am attempting to build an i386 jail on an amd64 box to build > >packages for my netbook. The host is running -current from just over > >two weeks ago and the jail is -current from early June. The jail was > >built by doing a dump|restore of my netbook and then tweaking various > >config files to give it a new identity. The jail's devfs is using > >"devfsrules_jail" from /etc/default/devfs.rules. > > > >The jail starts OK but when I attempt to ssh into it, I just get > >"Connection closed by ". >=20 > Turns out this is a bug in the 32-bit select(2) wrapper on 64-bit > kernels. The userland fd_set arguments are not wrapped but passed > directly to kern_select(). Unfortunately, fd_set is (effectively) an > array of longs which means kern_select() assumes fd_set is a multiple > of 8-bytes whilst userland assumes it is a multiple of 4 bytes. As a > result, the kernel can over-write an extra 4 bytes of user memory. In > the case of sshd, this causes part of the RSA host key to be trashed > when privilege separation mode is enabled. >=20 > This bug also affects linux emulation on amd64 and potentially affects > any other 64-bit kernels with 32-bit emulation modes. I have raised > amd64/138318 to cover it. I do not think that we can go the proposed route, since changing the type of __fd_mask changes the type of fd_set. The later would not affect the kernel ABI, but definitely changes the ABI of any code that passes fd_sets. Also, looking closely at the issue you found, I think that copyin is the same problematic as copyout, since we can end up reading one more word then userspace supplied. This is not a problem only because most user code keeps fd_sets on stack. Could you test that the patch below fixes real sshd issue. At least, it passes your select test from the PR. diff --git a/sys/compat/freebsd32/freebsd32_misc.c b/sys/compat/freebsd32/f= reebsd32_misc.c index 466aab4..71b22aa 100644 --- a/sys/compat/freebsd32/freebsd32_misc.c +++ b/sys/compat/freebsd32/freebsd32_misc.c @@ -589,7 +589,8 @@ freebsd32_select(struct thread *td, struct freebsd32_se= lect_args *uap) * XXX big-endian needs to convert the fd_sets too. * XXX Do pointers need PTRIN()? */ - return (kern_select(td, uap->nd, uap->in, uap->ou, uap->ex, tvp)); + return (kern_select(td, uap->nd, uap->in, uap->ou, uap->ex, tvp, + sizeof(int32_t) * 8)); } =20 /* diff --git a/sys/compat/linux/linux_misc.c b/sys/compat/linux/linux_misc.c index 267da07..1d5eaf8 100644 --- a/sys/compat/linux/linux_misc.c +++ b/sys/compat/linux/linux_misc.c @@ -522,7 +522,7 @@ linux_select(struct thread *td, struct linux_select_arg= s *args) tvp =3D NULL; =20 error =3D kern_select(td, args->nfds, args->readfds, args->writefds, - args->exceptfds, tvp); + args->exceptfds, tvp, sizeof(l_int) * 8); =20 #ifdef DEBUG if (ldebug(select)) diff --git a/sys/kern/sys_generic.c b/sys/kern/sys_generic.c index bd0f279..6831fe8 100644 --- a/sys/kern/sys_generic.c +++ b/sys/kern/sys_generic.c @@ -774,12 +774,13 @@ select(td, uap) } else tvp =3D NULL; =20 - return (kern_select(td, uap->nd, uap->in, uap->ou, uap->ex, tvp)); + return (kern_select(td, uap->nd, uap->in, uap->ou, uap->ex, tvp, + NFDBITS)); } =20 int kern_select(struct thread *td, int nd, fd_set *fd_in, fd_set *fd_ou, - fd_set *fd_ex, struct timeval *tvp) + fd_set *fd_ex, struct timeval *tvp, int abi_nfdbits) { struct filedesc *fdp; /* @@ -792,7 +793,7 @@ kern_select(struct thread *td, int nd, fd_set *fd_in, f= d_set *fd_ou, fd_mask *ibits[3], *obits[3], *selbits, *sbp; struct timeval atv, rtv, ttv; int error, timo; - u_int nbufbytes, ncpbytes, nfdbits; + u_int nbufbytes, ncpbytes, ncpubytes, nfdbits; =20 if (nd < 0) return (EINVAL); @@ -806,6 +807,7 @@ kern_select(struct thread *td, int nd, fd_set *fd_in, f= d_set *fd_ou, */ nfdbits =3D roundup(nd, NFDBITS); ncpbytes =3D nfdbits / NBBY; + ncpubytes =3D roundup(nd, abi_nfdbits) / NBBY; nbufbytes =3D 0; if (fd_in !=3D NULL) nbufbytes +=3D 2 * ncpbytes; @@ -832,9 +834,11 @@ kern_select(struct thread *td, int nd, fd_set *fd_in, = fd_set *fd_ou, ibits[x] =3D sbp + nbufbytes / 2 / sizeof *sbp; \ obits[x] =3D sbp; \ sbp +=3D ncpbytes / sizeof *sbp; \ - error =3D copyin(name, ibits[x], ncpbytes); \ + error =3D copyin(name, ibits[x], ncpubytes); \ if (error !=3D 0) \ goto done; \ + bzero((char *)ibits[x] + ncpubytes, \ + ncpbytes - ncpubytes); \ } \ } while (0) getbits(fd_in, 0); @@ -888,7 +892,7 @@ done: if (error =3D=3D EWOULDBLOCK) error =3D 0; #define putbits(name, x) \ - if (name && (error2 =3D copyout(obits[x], name, ncpbytes))) \ + if (name && (error2 =3D copyout(obits[x], name, ncpubytes))) \ error =3D error2; if (error =3D=3D 0) { int error2; diff --git a/sys/sys/syscallsubr.h b/sys/sys/syscallsubr.h index d0f209c..e1c83cc 100644 --- a/sys/sys/syscallsubr.h +++ b/sys/sys/syscallsubr.h @@ -170,7 +170,7 @@ int kern_sched_rr_get_interval(struct thread *td, pid_t= pid, int kern_semctl(struct thread *td, int semid, int semnum, int cmd, union semun *arg, register_t *rval); int kern_select(struct thread *td, int nd, fd_set *fd_in, fd_set *fd_ou, - fd_set *fd_ex, struct timeval *tvp); + fd_set *fd_ex, struct timeval *tvp, int abi_nfdbits); int kern_sendfile(struct thread *td, struct sendfile_args *uap, struct uio *hdr_uio, struct uio *trl_uio, int compat); int kern_sendit(struct thread *td, int s, struct msghdr *mp, int flags, --ef8eQmdvO1j1gFMO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqakGMACgkQC3+MBN1Mb4hPJgCgzkRRw85CqSG0dRODxYD4h6HE bkcAn1M/oT7H9vmpIJHOTd7++i7VhKt+ =NGrs -----END PGP SIGNATURE----- --ef8eQmdvO1j1gFMO-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 16:25: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 2564D106566B for ; Sun, 30 Aug 2009 16:25:39 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.tele2.se [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id AEB958FC15 for ; Sun, 30 Aug 2009 16:25:38 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=GvZn1osWK1sA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=eRsS2kvmjT0x5yolq-4A:9 a=AbOZimRGJ5lB4e4uCBoA:7 a=p9-djYAyHnG4mK8d5xv2qAaEb9AA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 561213924; Sun, 30 Aug 2009 18:25:36 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sun, 30 Aug 2009 18:25:56 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <1251570251.1238.21.camel@localhost> In-Reply-To: <1251570251.1238.21.camel@localhost> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908301825.57281.hselasky@c2i.net> Cc: Tobias Grosser Subject: Re: USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 16:25:39 -0000 On Saturday 29 August 2009 20:24:11 Tobias Grosser wrote: > Hi, > > I just bought two external USB hard drives and tried to use them on > > http://svn.freebsd.org/base/stable/8@196642 > > The drives are: Western Digital My Passport Essential (500 and 320 GB) > > After connecting them I get these log messages: > ------------------------------------------------------------------------ > ugen0.2: at usbus0 > umass0: > on usbus0 > umass0: SCSI over Bulk-Only; quirks = 0x0000 > umass0:0:0:-1: Attached to scbus0 > ------------------------------------------------------------------------ > > However there is never any 'ad' device created. So I am not able to use > the harddisk. > > > "camcontrol devlist" does not return anything. > > > "camcontrol rescan all" blocks in: > ------------------------------------------------------------------------ > 1279 root 1 45 0 3472K 828K cbwait 0 0:00 0.00% camcontrol > ------------------------------------------------------------------------ > and returns after removing the usb disk. > > > After removing the disk I always get: > ------------------------------------------------------------------------ > % sudo camcontrol rescan all > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > ------------------------------------------------------------------------ > > > /var/log/messages output is attached for > hw.usb.debug=99999 Try only: sysctl hw.usb.umass.debug=-1 And send new log. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 16:45: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 8BB111065693 for ; Sun, 30 Aug 2009 16:45:47 +0000 (UTC) (envelope-from grosser@fim.uni-passau.de) Received: from smtprelay11.ispgateway.de (smtprelay11.ispgateway.de [80.67.31.34]) by mx1.freebsd.org (Postfix) with ESMTP id F220B8FC08 for ; Sun, 30 Aug 2009 16:45:46 +0000 (UTC) Received: from [84.56.5.207] (helo=[192.168.178.32]) by smtprelay11.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MhnXE-0004ae-Ok; Sun, 30 Aug 2009 18:45:45 +0200 From: Tobias Grosser To: Hans Petter Selasky In-Reply-To: <19936_1251649540_4A9AA804_19936_425_1_200908301825.57281.hselasky@c2i.net> References: <1251570251.1238.21.camel@localhost> <19936_1251649540_4A9AA804_19936_425_1_200908301825.57281.hselasky@c2i.net> Content-Type: multipart/mixed; boundary="=-bvEeRZle9igb8xlRO2xh" Date: Sun, 30 Aug 2009 18:45:41 +0200 Message-Id: <1251650741.1187.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port X-Df-Sender: imapboxtobias@web-wahnsinn.de X-Mailman-Approved-At: Sun, 30 Aug 2009 16:56:33 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 16:45:47 -0000 --=-bvEeRZle9igb8xlRO2xh Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2009-08-30 at 18:25 +0200, Hans Petter Selasky wrote: > On Saturday 29 August 2009 20:24:11 Tobias Grosser wrote: > > Hi, > > > > I just bought two external USB hard drives and tried to use them on > > > > http://svn.freebsd.org/base/stable/8@196642 > > > > The drives are: Western Digital My Passport Essential (500 and 320 GB) > > > > After connecting them I get these log messages: > > ------------------------------------------------------------------------ > > ugen0.2: at usbus0 > > umass0: > > on usbus0 > > umass0: SCSI over Bulk-Only; quirks = 0x0000 > > umass0:0:0:-1: Attached to scbus0 > > ------------------------------------------------------------------------ > > > > However there is never any 'ad' device created. So I am not able to use > > the harddisk. > > > > > > "camcontrol devlist" does not return anything. > > > > > > "camcontrol rescan all" blocks in: > > ------------------------------------------------------------------------ > > 1279 root 1 45 0 3472K 828K cbwait 0 0:00 0.00% camcontrol > > ------------------------------------------------------------------------ > > and returns after removing the usb disk. > > > > > > After removing the disk I always get: > > ------------------------------------------------------------------------ > > % sudo camcontrol rescan all > > camcontrol: CAMIOCOMMAND ioctl failed: Invalid argument > > ------------------------------------------------------------------------ > > > > > > /var/log/messages output is attached for > > hw.usb.debug=99999 > > Try only: > > sysctl hw.usb.umass.debug=-1 > > And send new log. Attached. Thanks Tobias --=-bvEeRZle9igb8xlRO2xh-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 17:09: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 C3CF21065694 for ; Sun, 30 Aug 2009 17:09: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 235948FC17 for ; Sun, 30 Aug 2009 17:09:12 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=GvZn1osWK1sA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=d3c1KBIoSv29Aa8hdJIA:9 a=hmubt8kg0JayCAeUkQjx6R6Je2IA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 246790548; Sun, 30 Aug 2009 19:09:11 +0200 From: Hans Petter Selasky To: Tobias Grosser Date: Sun, 30 Aug 2009 19:09:29 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <1251570251.1238.21.camel@localhost> <19936_1251649540_4A9AA804_19936_425_1_200908301825.57281.hselasky@c2i.net> <1251650741.1187.1.camel@localhost> In-Reply-To: <1251650741.1187.1.camel@localhost> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908301909.30692.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 17:09:13 -0000 Hi, I looks like your device is hanging on SCSI command 0x12,00,00,00,4a,00 This is not an USB fault. --HPS From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 17:50: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 A493B1065702 for ; Sun, 30 Aug 2009 17:50:25 +0000 (UTC) (envelope-from jamie@bishopston.net) Received: from pacha.mail.bishopston.net (pacha.mail.bishopston.net [IPv6:2001:5c0:1100:200::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5BA728FC24 for ; Sun, 30 Aug 2009 17:50:25 +0000 (UTC) X-Catflap-Envelope-From: X-Catflap-Envelope-To: Received: from catflap.bishopston.net (jamie@localhost [127.0.0.1]) by catflap.bishopston.net (8.14.3/8.14.3) with ESMTP id n7UHoO4k069012 for ; Sun, 30 Aug 2009 18:50:24 +0100 (BST) (envelope-from jamie@catflap.bishopston.net) Received: (from jamie@localhost) by catflap.bishopston.net (8.14.3/8.12.9/Submit) id n7UHoOwr069011 for freebsd-current@freebsd.org; Sun, 30 Aug 2009 18:50:24 +0100 (BST) From: Jamie Landeg Jones Message-Id: <200908301750.n7UHoOwr069011@catflap.bishopston.net> Date: Sun, 30 Aug 2009 18:50:24 +0100 Organization: http://www.bishopston.com/jamie/ To: freebsd-current@freebsd.org User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (catflap.bishopston.net [127.0.0.1]); Sun, 30 Aug 2009 18:50:24 +0100 (BST) X-Virus-Scanned: clamav-milter 0.95.2 at catflap.bishopston.net X-Virus-Status: Clean Subject: reproducable kernel panic: page fault - 8.0-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 17:50:25 -0000 problem still exists. no response to PR raised over a month ago :-( From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 18:00: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 F0C2D1065693 for ; Sun, 30 Aug 2009 18:00:14 +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 05EE88FC1F for ; Sun, 30 Aug 2009 18:00:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id B888D41C667; Sun, 30 Aug 2009 20:00: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 YxuBDg5EKD2n; Sun, 30 Aug 2009 20:00:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 3B19941C650; Sun, 30 Aug 2009 20:00: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 5FB2F4448E6; Sun, 30 Aug 2009 17:58:39 +0000 (UTC) Date: Sun, 30 Aug 2009 17:58:39 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Jamie Landeg Jones In-Reply-To: <200908301750.n7UHoOwr069011@catflap.bishopston.net> Message-ID: <20090830175755.J93661@maildrop.int.zabbadoz.net> References: <200908301750.n7UHoOwr069011@catflap.bishopston.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: reproducable kernel panic: page fault - 8.0-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 18:00:15 -0000 On Sun, 30 Aug 2009, Jamie Landeg Jones wrote: > problem still exists. no response to PR raised over a month ago :-( Now it would be really good if you had more information here, at least a PR number. There have been lots of them the last month. -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 18:09: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 17643106566C for ; Sun, 30 Aug 2009 18:09:57 +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 C5B2A8FC12 for ; Sun, 30 Aug 2009 18:09:56 +0000 (UTC) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:35749 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Mhoqd-0008VB-3Y; Sun, 30 Aug 2009 20:09:52 +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 05DEF1A216D; Sun, 30 Aug 2009 20:09:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Thomas Backman In-Reply-To: <20090830175755.J93661@maildrop.int.zabbadoz.net> Date: Sun, 30 Aug 2009 20:09:43 +0200 Content-Transfer-Encoding: 7bit Message-Id: References: <200908301750.n7UHoOwr069011@catflap.bishopston.net> <20090830175755.J93661@maildrop.int.zabbadoz.net> To: Bjoern A. Zeeb X-Mailer: Apple Mail (2.1075.2) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1Mhoqd-0008VB-3Y. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1Mhoqd-0008VB-3Y b1c3c09adca65183383c92c9aad22cab Cc: Jamie Landeg Jones , freebsd-current@freebsd.org Subject: Re: reproducable kernel panic: page fault - 8.0-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 18:09:57 -0000 On Aug 30, 2009, at 7:58 PM, Bjoern A. Zeeb wrote: > On Sun, 30 Aug 2009, Jamie Landeg Jones wrote: > >> problem still exists. no response to PR raised over a month ago :-( > > Now it would be really good if you had more information here, at least > a PR number. There have been lots of them the last month. That's what I thought, but the query PR form (by originator) worked great. ;) kern/137310: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/137310 Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 18:31: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 3CE311065679 for ; Sun, 30 Aug 2009 18:31:20 +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 F05978FC08 for ; Sun, 30 Aug 2009 18:31:18 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n7UITpfI020033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 30 Aug 2009 21:29:52 +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 n7UITpIx088886; Sun, 30 Aug 2009 21:29:51 +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 n7UITpSN088885; Sun, 30 Aug 2009 21:29:51 +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: Sun, 30 Aug 2009 21:29:51 +0300 From: Kostik Belousov To: Thomas Backman Message-ID: <20090830182951.GL1881@deviant.kiev.zoral.com.ua> References: <200908301750.n7UHoOwr069011@catflap.bishopston.net> <20090830175755.J93661@maildrop.int.zabbadoz.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Uus2/pBTyv0r7Av1" Content-Disposition: inline In-Reply-To: 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: Jamie Landeg Jones , "Bjoern A. Zeeb" , freebsd-current@freebsd.org Subject: Re: reproducable kernel panic: page fault - 8.0-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 18:31:20 -0000 --Uus2/pBTyv0r7Av1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 30, 2009 at 08:09:43PM +0200, Thomas Backman wrote: >=20 > On Aug 30, 2009, at 7:58 PM, Bjoern A. Zeeb wrote: >=20 > >On Sun, 30 Aug 2009, Jamie Landeg Jones wrote: > > > >>problem still exists. no response to PR raised over a month ago :-( > > > >Now it would be really good if you had more information here, at least > >a PR number. There have been lots of them the last month. > That's what I thought, but the query PR form (by originator) worked =20 > great. ;) > kern/137310: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/137310 I think this would fix the issue. diff --git a/sys/fs/pseudofs/pseudofs_vnops.c b/sys/fs/pseudofs/pseudofs_vn= ops.c index e03749b..34ca500 100644 --- a/sys/fs/pseudofs/pseudofs_vnops.c +++ b/sys/fs/pseudofs/pseudofs_vnops.c @@ -339,7 +339,6 @@ pfs_getextattr(struct vop_getextattr_args *va) if (proc !=3D NULL) PROC_UNLOCK(proc); =20 - pfs_unlock(pn); PFS_RETURN (error); } =20 --Uus2/pBTyv0r7Av1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqaxR4ACgkQC3+MBN1Mb4i8jACdHwhihPfAaV66WlzSEoxQSxTB 3A8AoJ2LcTfuN2rI/MpEUUdIOfcETXu0 =j2gT -----END PGP SIGNATURE----- --Uus2/pBTyv0r7Av1-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 19:09: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 9B566106566C for ; Sun, 30 Aug 2009 19:09:18 +0000 (UTC) (envelope-from grosser@fim.uni-passau.de) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [80.67.31.31]) by mx1.freebsd.org (Postfix) with ESMTP id A6D3D8FC0A for ; Sun, 30 Aug 2009 19:09:17 +0000 (UTC) Received: from [84.56.5.207] (helo=[192.168.178.32]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Mhpm7-0007DA-8W; Sun, 30 Aug 2009 21:09:15 +0200 From: Tobias Grosser To: Hans Petter Selasky In-Reply-To: <200908301909.30692.hselasky@c2i.net> References: <1251570251.1238.21.camel@localhost> <19936_1251649540_4A9AA804_19936_425_1_200908301825.57281.hselasky@c2i.net> <1251650741.1187.1.camel@localhost> <200908301909.30692.hselasky@c2i.net> Content-Type: multipart/mixed; boundary="=-OQM2l0CXW/02Q/ApMp8G" Date: Sun, 30 Aug 2009 21:09:12 +0200 Message-Id: <1251659352.1358.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port X-Df-Sender: imapboxtobias@web-wahnsinn.de X-Mailman-Approved-At: Sun, 30 Aug 2009 19:21:46 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 19:09:18 -0000 --=-OQM2l0CXW/02Q/ApMp8G Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sun, 2009-08-30 at 19:09 +0200, Hans Petter Selasky wrote: > Hi, > > I looks like your device is hanging on SCSI command 0x12,00,00,00,4a,00 > > This is not an USB fault. OK. Thanks. I just realized that I have been to fast. If I wait a little bit longer I get some more messages. I attached umass2.log I also added "options CAMDEBUG" to the kernel. camdebug_attach.log and camdebug_detach.log attached. And I found my drive in the verbose output of "camcontrol". With drive detached: ------------------------------------------------------------------------- % sudo camcontrol devlist -v scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun -1 (xpt0) ------------------------------------------------------------------------- With drive attached: ------------------------------------------------------------------------- % sudo camcontrol devlist -v scbus0 on umass-sim0 bus 0: at scbus0 target 0 lun 0 (probe0) <> at scbus0 target -1 lun -1 () scbus-1 on xpt0 bus 0: <> at scbus-1 target -1 lun -1 (xpt0) ------------------------------------------------------------------------- It seems it is hanging during probe. I will jump into this a little bit deeper. Thanks Tobi --=-OQM2l0CXW/02Q/ApMp8G-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 19:40: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 3D05C106566C for ; Sun, 30 Aug 2009 19:40:40 +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 BF68A8FC0C for ; Sun, 30 Aug 2009 19:40:39 +0000 (UTC) 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 252912204; Sun, 30 Aug 2009 22:40:30 +0300 Message-ID: <4A9AD5A9.2060004@FreeBSD.org> Date: Sun, 30 Aug 2009 22:40:25 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: "Alexander V. Chernikov" References: <200908301520.n7UFKDuY098521@svn.freebsd.org> <4A9AD22B.6060005@ipfw.ru> In-Reply-To: <4A9AD22B.6060005@ipfw.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: svn commit: r196656 - in head: share/man/man4 sys/dev/ahci X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 19:40:40 -0000 Alexander V. Chernikov wrote: > Recent -current does not compile: > > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function > 'ahci_begin_transaction': > > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1075: warning: statement > with no > effect > > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1075: error: expected > ';' before string constant > KASSERT(tag != ch->lastslot, "ahci: ALL SLOTS BUSY!"); should be changed to > KASSERT(tag != ch->lastslot, ("ahci: ALL SLOTS BUSY!")); Thanks. Fixed. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 19:41: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 E169D1065670 for ; Sun, 30 Aug 2009 19:41:20 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru [77.73.233.132]) by mx1.freebsd.org (Postfix) with ESMTP id 9979C8FC0A for ; Sun, 30 Aug 2009 19:41:20 +0000 (UTC) Received: from ws.ipfw.ru (secured.by.ipfw.ru [81.200.11.182]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id EC91237C5E4; Sun, 30 Aug 2009 19:25:41 +0000 (UTC) Message-ID: <4A9AD22B.6060005@ipfw.ru> Date: Sun, 30 Aug 2009 23:25:31 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.22 (X11/20090818) MIME-Version: 1.0 To: Alexander Motin References: <200908301520.n7UFKDuY098521@svn.freebsd.org> In-Reply-To: <200908301520.n7UFKDuY098521@svn.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: svn commit: r196656 - in head: share/man/man4 sys/dev/ahci X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 19:41:21 -0000 Recent -current does not compile: /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function 'ahci_begin_transaction': /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1075: warning: statement with no effect /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1075: error: expected ';' before string constant KASSERT(tag != ch->lastslot, "ahci: ALL SLOTS BUSY!"); should be changed to KASSERT(tag != ch->lastslot, ("ahci: ALL SLOTS BUSY!")); From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 19:51: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 232891065693 for ; Sun, 30 Aug 2009 19:51:21 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from no.spam.no.ddos.ru (no.spam.no.ddos.ru [77.73.233.132]) by mx1.freebsd.org (Postfix) with ESMTP id CF4358FC19 for ; Sun, 30 Aug 2009 19:51:20 +0000 (UTC) Received: from ws.ipfw.ru (secured.by.ipfw.ru [81.200.11.182]) by no.spam.no.ddos.ru (Postfix) with ESMTPA id 871DE37C5E9 for ; Sun, 30 Aug 2009 19:35:40 +0000 (UTC) Message-ID: <4A9AD483.7000108@ipfw.ru> Date: Sun, 30 Aug 2009 23:35:31 +0400 From: "Alexander V. Chernikov" User-Agent: Thunderbird 2.0.0.22 (X11/20090818) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <200908301520.n7UFKDuY098521@svn.freebsd.org> In-Reply-To: <200908301520.n7UFKDuY098521@svn.freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: svn commit: r196656 - in head: share/man/man4 sys/dev/ahci X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 19:51:21 -0000 Recent -current does not compile: /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function 'ahci_begin_transaction': /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1075: warning: statement with no effect /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1075: error: expected ';' before string constant KASSERT(tag != ch->lastslot, "ahci: ALL SLOTS BUSY!"); should be changed to KASSERT(tag != ch->lastslot, ("ahci: ALL SLOTS BUSY!")); From owner-freebsd-current@FreeBSD.ORG Sun Aug 30 20:39:58 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 E14F41065672 for ; Sun, 30 Aug 2009 20:39:58 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id BBB328FC14 for ; Sun, 30 Aug 2009 20:39:58 +0000 (UTC) Received: from gluon.draftnet (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 4137A8540 for ; Sun, 30 Aug 2009 20:39:57 +0000 (UTC) Date: Sun, 30 Aug 2009 21:39:43 +0100 From: Bruce Cran To: current@freebsd.org Message-ID: <20090830213943.599184aa@gluon.draftnet> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.16.4; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: sendfile regression test failing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Aug 2009 20:39:59 -0000 The sendfile regression test in tools/regression/sockets/sendfile is failing on 8.0-BETA3: > ./sendfile sendfile: receive_test: expected (0, 0) received 16384 It's failing the test of sending 0 bytes on line 290: send_test(connect_socket, 0, 0, 0); -- Bruce From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 08:18: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 79CD3106566B for ; Mon, 31 Aug 2009 08:18:58 +0000 (UTC) (envelope-from gad@FreeBSD.org) Received: from smtp6.server.rpi.edu (smtp6.server.rpi.edu [128.113.2.226]) by mx1.freebsd.org (Postfix) with ESMTP id 413F18FC19 for ; Mon, 31 Aug 2009 08:18:58 +0000 (UTC) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp6.server.rpi.edu (8.13.1/8.13.1) with ESMTP id n7V7HBvN015327; Mon, 31 Aug 2009 03:17:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <8819E53E-9F96-43E2-B7F5-F5393F5AE126@rabson.org> References: <8819E53E-9F96-43E2-B7F5-F5393F5AE126@rabson.org> Date: Mon, 31 Aug 2009 03:17:11 -0400 To: Doug Rabson , FreeBSD Current From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Bayes-Prob: 0.0001 (Score 0) X-RPI-SA-Score: 0.10 () [Hold at 20.00] COMBINED_FROM X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.226 Cc: Subject: Re: New BSD licensed debugger X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 08:18:58 -0000 At 8:23 PM +0100 8/28/09, Doug Rabson wrote: >As one or two of you know, I've been working recently on writing a >new debugger, primarily for the FreeBSD platform. For various >reasons, I've been writing it in a relatively obscure C-like >language called D (see http://www.digitalmars.com/d/1.0/index.html >for more details including a free download of a FreeBSD D compiler. Very interesting. I've wanted to do some work with D, but (of course) haven't had the time. >So far, I have a pretty useful (if a little raw at the edges) >command line debugger which supports ELF, Dwarf debugging >information and (currently) 32 bit FreeBSD and Linux. >If anyone is interested in taking a look at a 'Technology Preview', >I've put up a git repository at >http://people.freebsd.org/~dfr/ngdb.git. To build it you need to >install 'omake' from /usr/ports/devel/omake and you will need a D >compiler. There are three options there - DMD which you can download >from http://www.digitalmars.com/d/download.html is free, closed >source and works pretty well. GDC is a D front end to GCC and you >can find it in ports - it works well enough but hasn't been updated >for ages. Personally, I use LDC which is a D front end to LLVM but >that doesn't build out-of-the box (I have a private hacked version >of LDC and some associated libraries). A D front-end to llvm is also very welcome. I'll have to find some time to try these out! -- Garance Alistair Drosehn = drosehn@rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 08:54: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 2FC1F1065676 for ; Mon, 31 Aug 2009 08:54:12 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.freebsd.org (Postfix) with ESMTP id 7992E8FC0A for ; Mon, 31 Aug 2009 08:54:11 +0000 (UTC) Received: from mail-gw7.york.ac.uk (mail-gw7.york.ac.uk [144.32.129.30]) by mail-gw0.york.ac.uk (8.13.6/8.13.6) with ESMTP id n7V8s3HK016442; Mon, 31 Aug 2009 09:54:03 +0100 (BST) Received: from ury.york.ac.uk ([144.32.108.81]) by mail-gw7.york.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Mi2eJ-00046Y-JP; Mon, 31 Aug 2009 09:54:03 +0100 Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.14.3/8.14.3) with ESMTP id n7V8s3SV032046; Mon, 31 Aug 2009 09:54:03 +0100 (BST) (envelope-from gavin@FreeBSD.org) Received: from localhost (gavin@localhost) by ury.york.ac.uk (8.14.3/8.14.3/Submit) with ESMTP id n7V8s2LT032043; Mon, 31 Aug 2009 09:54:03 +0100 (BST) (envelope-from gavin@FreeBSD.org) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Mon, 31 Aug 2009 09:54:02 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Ed Schouten In-Reply-To: <20090826195407.GW2829@hoeg.nl> Message-ID: <20090831094627.L24691@ury.york.ac.uk> References: <4A9571EB.7090209@fsu.edu> <20090826195407.GW2829@hoeg.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin@freebsd.org Cc: freebsd-current@FreeBSD.org, Nathan Lay Subject: First keypresses after boot being discarded X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 08:54:12 -0000 (Thread hijacked, subject changed) On Wed, 26 Aug 2009, Ed Schouten wrote: > People also reported issues to me where the first keypresses after the > system has booted are discarded. I have yet to be convinced this is a > TTY issue, not the keyboard code, interrupt handling, etc. I've seen this, and might be able to offer some more information. I booted 8.0-BETA2 from the same hard drive install on about 15 machines, and saw this problem on four of them, all identical motherboards. In this setup, I had "-D" in /boot.config "console-comconsole" in /boot/loader/conf ttyu0 enabled in /etc/ttys I was then accessing them over the serial port. When the machine had booted and was showing the "login:" prompt, sometimes input would be ignored from that point, and other times it would allow me to enter "root" but would hang on the enter. Once it had hung, sometimes hammering the keyboard would bring it back, but the only reliable way of getting it to recover was to have the kernel print something out. Luckily, the three LOR's often printed a minute or so after boot would do this, but unplugging/replugging (say) a USB keyboard so that the detection lines were printed would also free things up. I don't know if that gives any clues as to where the problem lies. Gavin From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 09:52: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 EC71F1065670 for ; Mon, 31 Aug 2009 09:52:41 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 72D6B8FC16 for ; Mon, 31 Aug 2009 09:52:40 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n7V9qaSw081770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Aug 2009 11:52:36 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n7V9qXqR054680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Aug 2009 11:52:33 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n7V9qXw6059442; Mon, 31 Aug 2009 11:52:33 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n7V9qXa8059441; Mon, 31 Aug 2009 11:52:33 +0200 (CEST) (envelope-from ticso) Date: Mon, 31 Aug 2009 11:52:33 +0200 From: Bernd Walter To: Hans Petter Selasky Message-ID: <20090831095231.GD59032@cicely7.cicely.de> References: <1251570251.1238.21.camel@localhost> <19936_1251649540_4A9AA804_19936_425_1_200908301825.57281.hselasky@c2i.net> <1251650741.1187.1.camel@localhost> <200908301909.30692.hselasky@c2i.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908301909.30692.hselasky@c2i.net> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.000, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-current@freebsd.org, Tobias Grosser Subject: Re: USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 09:52:42 -0000 On Sun, Aug 30, 2009 at 07:09:29PM +0200, Hans Petter Selasky wrote: > Hi, > > I looks like your device is hanging on SCSI command 0x12,00,00,00,4a,00 0x12 is an inquiry, which is bad if the device has problems with. > This is not an USB fault. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 10:57:06 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 7B9251065679 for ; Mon, 31 Aug 2009 10:57:06 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 1979D8FC21 for ; Mon, 31 Aug 2009 10:57:05 +0000 (UTC) Received: from [41.161.16.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Mi4ZK-00010W-Oi for current@freebsd.org; Mon, 31 Aug 2009 12:57:02 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Mi4Zb-0005Sw-Ae for current@freebsd.org; Mon, 31 Aug 2009 12:57:19 +0200 To: current@freebsd.org From: "Ian Freislich" X-Attribution: BOFH Date: Mon, 31 Aug 2009 12:57:19 +0200 Message-Id: Cc: Subject: igb(4) promiscuous mode bug. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 10:57:06 -0000 Hi It appears that the igb(4) driver or hardware doesn't correctly handle 802.1Q frames when placed in promiscuous mode if vlanhwtag is enabled. The NIC omits to tag and untag the frames when placed in promiscuous mode. The following output shows the bridge address table on the connected switch with the 4 NICs (82575GB) with and without vlan hardware assistance enabled. The interfaces are placed in promiscuous mode by the carp(4) driver. With hwtag in promiscuous mode: sw3.cab10# sh bridge address-table port-channel 1 Aging time is 300 sec Vlan Mac Address Port Type -------- --------------------- ------ ---------- 1 00:1b:21:1f:01:00 ch1 dynamic 1 00:1b:21:1f:01:01 ch1 dynamic 1 00:1b:21:1f:01:04 ch1 dynamic 1 00:1b:21:1f:01:05 ch1 dynamic Without hwtag in promiscuous mode: sw3.cab10# sh bridge address-table port-channel 1 Aging time is 300 sec Vlan Mac Address Port Type -------- --------------------- ------ ---------- 1 00:1b:21:1f:01:00 ch1 dynamic 1 00:1b:21:1f:01:01 ch1 dynamic 1 00:1b:21:1f:01:04 ch1 dynamic 1 00:1b:21:1f:01:05 ch1 dynamic 2 00:1b:21:1f:01:00 ch1 dynamic 3 00:1b:21:1f:01:00 ch1 dynamic 4 00:1b:21:1f:01:00 ch1 dynamic 5 00:1b:21:1f:01:00 ch1 dynamic 6 00:1b:21:1f:01:00 ch1 dynamic 7 00:1b:21:1f:01:00 ch1 dynamic 9 00:1b:21:1f:01:00 ch1 dynamic 14 00:1b:21:1f:01:00 ch1 dynamic 19 00:1b:21:1f:01:00 ch1 dynamic 20 00:1b:21:1f:01:00 ch1 dynamic 21 00:1b:21:1f:01:00 ch1 dynamic 23 00:1b:21:1f:01:00 ch1 dynamic 25 00:1b:21:1f:01:00 ch1 dynamic 26 00:1b:21:1f:01:00 ch1 dynamic 27 00:1b:21:1f:01:00 ch1 dynamic Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 12:59:15 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 253501065670 for ; Mon, 31 Aug 2009 12:59:15 +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 5FED78FC08 for ; Mon, 31 Aug 2009 12:59:14 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA10063; Mon, 31 Aug 2009 15:59:05 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A9BC919.1070305@freebsd.org> Date: Mon, 31 Aug 2009 15:59:05 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: Hans Petter Selasky References: <20090826080554.GA2664@beastie.smeiknet> <200908271759.08044.hselasky@c2i.net> <4A96BD37.2080907@freebsd.org> <200908271913.13206.hselasky@c2i.net> In-Reply-To: <200908271913.13206.hselasky@c2i.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Paul Kuntke , freebsd-current@freebsd.org Subject: Re: Problems with mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 12:59:15 -0000 on 27/08/2009 20:13 Hans Petter Selasky said the following: > On Thursday 27 August 2009 19:07:03 Andriy Gapon wrote: >> on 27/08/2009 18:59 Hans Petter Selasky said the following: >>> Hi, >>> >>> Have you tried using an external USB HUB. >>> >>> Maybe it is not correct to turn off port power on failures? >> I don't have any external usb hubs handy. >> Maybe you'd like to see any additional debug info? > > You could try to run a reset command on the Root HUB which you think your > device is connected to. > > usbconfig -u X -a Y reset Any command I tried (including reset) resulted in "Device not configured". BTW, here is what usbconfig reports for the port/hub where mouse attachment failed: ugen0.1: at usbus0, cfg=255 md=HOST spd=FULL (12Mbps) pwr=ON It's cf=255 that is different from all other hubs. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 13:26: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 B663F106566C for ; Mon, 31 Aug 2009 13:26:09 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.tele2.se [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 4A43D8FC1E for ; Mon, 31 Aug 2009 13:26:08 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=2phIjmfE7pllIPNWYIwA:9 a=ijsRdawtF4jmVIee_5pn_Cb2xcUA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 558395240; Mon, 31 Aug 2009 15:26:06 +0200 From: Hans Petter Selasky To: Andriy Gapon Date: Mon, 31 Aug 2009 15:26:24 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <20090826080554.GA2664@beastie.smeiknet> <200908271913.13206.hselasky@c2i.net> <4A9BC919.1070305@freebsd.org> In-Reply-To: <4A9BC919.1070305@freebsd.org> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908311526.26074.hselasky@c2i.net> Cc: Paul Kuntke , freebsd-current@freebsd.org Subject: Re: Problems with mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 13:26:09 -0000 On Monday 31 August 2009 14:59:05 Andriy Gapon wrote: > on 27/08/2009 20:13 Hans Petter Selasky said the following: > > On Thursday 27 August 2009 19:07:03 Andriy Gapon wrote: > >> on 27/08/2009 18:59 Hans Petter Selasky said the following: > >>> Hi, > >>> > >>> Have you tried using an external USB HUB. > >>> > >>> Maybe it is not correct to turn off port power on failures? > >> > >> I don't have any external usb hubs handy. > >> Maybe you'd like to see any additional debug info? > > > > You could try to run a reset command on the Root HUB which you think your > > device is connected to. > > > > usbconfig -u X -a Y reset > > Any command I tried (including reset) resulted in "Device not configured". > BTW, here is what usbconfig reports for the port/hub where mouse attachment > failed: ugen0.1: at usbus0, cfg=255 md=HOST spd=FULL > (12Mbps) pwr=ON > > It's cf=255 that is different from all other hubs. Then: usbconfig -u 0 -a 1 set_config 0 --HPS From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 15:49: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 EC0C91065676 for ; Mon, 31 Aug 2009 15:49:34 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3C28FC16 for ; Mon, 31 Aug 2009 15:49:34 +0000 (UTC) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 605841998F7 for ; Mon, 31 Aug 2009 17:49:26 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 53FA61998D7 for ; Mon, 31 Aug 2009 17:49:26 +0200 (CEST) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 3C79C1998CE for ; Mon, 31 Aug 2009 17:49:26 +0200 (CEST) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2FP1HF244) with ESMTP id 2009083117492519-13359 ; Mon, 31 Aug 2009 17:49:25 +0200 Received: by wep4035 (sSMTP sendmail emulation); Mon, 31 Aug 2009 17:49:24 +0200 Date: Mon, 31 Aug 2009 17:49:24 +0200 From: Alexey Shuvaev To: freebsd-current@freebsd.org Message-ID: <20090831154924.GA40259@wep4035.physik.uni-wuerzburg.de> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 User-Agent: Mutt/1.4.2.3i Organization: Universitaet Wuerzburg X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 08/31/2009 05:49:25 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2FP1HF244 | April 7, 2009) at 08/31/2009 05:49:26 PM, Serialize complete at 08/31/2009 05:49:26 PM Content-Type: multipart/mixed; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: Update pkg_install to support 9-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, 31 Aug 2009 15:49:35 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello list! Any plans to update pkg_install so it finds INDEX-9? Thanks, Alexey. --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch-lib.h" --- lib.h.orig 2009-08-31 17:37:35.000000000 +0200 +++ lib.h 2009-08-31 17:38:45.000000000 +0200 @@ -84,7 +84,9 @@ #define DISPLAY_FNAME "+DISPLAY" #define MTREE_FNAME "+MTREE_DIRS" -#if defined(__FreeBSD_version) && __FreeBSD_version >= 800000 +#if defined(__FreeBSD_version) && __FreeBSD_version >= 900000 +#define INDEX_FNAME "INDEX-9" +#elif defined(__FreeBSD_version) && __FreeBSD_version >= 800000 #define INDEX_FNAME "INDEX-8" #elif defined(__FreeBSD_version) && __FreeBSD_version >= 700000 #define INDEX_FNAME "INDEX-7" --fdj2RfSjLxBAspz7-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 15:54: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 532E8106566B for ; Mon, 31 Aug 2009 15:54:53 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.193]) by mx1.freebsd.org (Postfix) with ESMTP id F17908FC0A for ; Mon, 31 Aug 2009 15:54:49 +0000 (UTC) X-Envelope-To: Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.3/8.14.3) with ESMTP id n7VFseLC006369 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 31 Aug 2009 16:54:40 +0100 (IST) (envelope-from nick-lists@netability.ie) Message-ID: <4A9BF23F.6070801@netability.ie> Date: Mon, 31 Aug 2009 16:54:39 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------090707070904060208060208" X-Spam-Status: No, score=-3.6 required=5.0 tests=ALL_TRUSTED,BAYES_00,TW_BD, TW_BF, TW_BP, TW_DR, TW_II, TW_KB, TW_OC, TW_TK, TW_XB, TW_XD, TW_XF autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muffin.acquirer.com Subject: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 15:54:53 -0000 This is a multi-part message in MIME format. --------------090707070904060208060208 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have a hp proliant ML115 with 6 sata ports which run in ATA mode (bios doesn't appear to give the option to use AHCI). On freebsd 7.x, all channels are detected. On freebsd8.0-beta3, the disks attached to the first two SATA ports are not detected, although it detects the ports themselves. I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. Any ideas on what's going on here? This seems like a nasty regression. Nick --------------090707070904060208060208 Content-Type: text/plain; name="dmesg-8.0b3.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg-8.0b3.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtQkVUQTMgIzA6IFNh dCBBdWcgMjIgMDI6MDA6NDUgVVRDIDIwMDkKICAgIHJvb3RAbWFzb24uY3NlLmJ1ZmZhbG8u ZWR1Oi91c3Ivb2JqL3Vzci9zcmMvc3lzL0dFTkVSSUMKV0FSTklORzogV0lUTkVTUyBvcHRp b24gZW5hYmxlZCwgZXhwZWN0IHJlZHVjZWQgcGVyZm9ybWFuY2UuClByZWxvYWRlZCBlbGYg a2VybmVsICIvYm9vdC9rZXJuZWwva2VybmVsIiBhdCAweGZmZmZmZmZmODEzZmQwMDAuClBy ZWxvYWRlZCBtZnNfcm9vdCAiL2Jvb3QvbWZzcm9vdCIgYXQgMHhmZmZmZmZmZjgxM2ZkMjUw LgpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApD YWxpYnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogMjEwMDAxNTYzOSBIegpDUFU6 IFF1YWQtQ29yZSBBTUQgT3B0ZXJvbih0bSkgUHJvY2Vzc29yIDEzNTIgKDIxMDAuMDItTUh6 IEs4LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiQXV0aGVudGljQU1EIiAgSWQgPSAweDEwMGYy MyAgU3RlcHBpbmcgPSAzCiAgRmVhdHVyZXM9MHgxNzhiZmJmZjxGUFUsVk1FLERFLFBTRSxU U0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQU0Uz NixDTEZMVVNILE1NWCxGWFNSLFNTRSxTU0UyLEhUVD4KICBGZWF0dXJlczI9MHg4MDIwMDk8 U1NFMyxNT04sQ1gxNixQT1BDTlQ+CiAgQU1EIEZlYXR1cmVzPTB4ZWU1MDA4MDA8U1lTQ0FM TCxOWCxNTVgrLEZGWFNSLFBhZ2UxR0IsUkRUU0NQLExNLDNETm93ISssM0ROb3chPgogIEFN RCBGZWF0dXJlczI9MHg3ZmY8TEFIRixDTVAsU1ZNLEV4dEFQSUMsQ1I4LEFCTSxTU0U0QSxN QVMsUHJlZmV0Y2gsT1NWVyxJQlM+CiAgVFNDOiBQLXN0YXRlIGludmFyaWFudApMMSAyTUIg ZGF0YSBUTEI6IDQ4IGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIDJNQiBpbnN0cnVj dGlvbiBUTEI6IDE2IGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZlCkwxIDRLQiBkYXRhIFRM QjogNDggZW50cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKTDEgNEtCIGluc3RydWN0aW9uIFRM QjogMzIgZW50cmllcywgZnVsbHkgYXNzb2NpYXRpdmUKTDEgZGF0YSBjYWNoZTogNjQga2J5 dGVzLCA2NCBieXRlcy9saW5lLCAxIGxpbmVzL3RhZywgMi13YXkgYXNzb2NpYXRpdmUKTDEg aW5zdHJ1Y3Rpb24gY2FjaGU6IDY0IGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90 YWcsIDItd2F5IGFzc29jaWF0aXZlCkwyIDJNQiBkYXRhIFRMQjogMTI4IGVudHJpZXMsIDIt d2F5IGFzc29jaWF0aXZlCkwyIDJNQiBpbnN0cnVjdGlvbiBUTEI6IDAgZW50cmllcywgMi13 YXkgYXNzb2NpYXRpdmUKTDIgNEtCIGRhdGEgVExCOiA1MTIgZW50cmllcywgNC13YXkgYXNz b2NpYXRpdmUKTDIgNEtCIGluc3RydWN0aW9uIFRMQjogNTEyIGVudHJpZXMsIDQtd2F5IGFz c29jaWF0aXZlCkwyIHVuaWZpZWQgY2FjaGU6IDUxMiBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUs IDEgbGluZXMvdGFnLCAxNi13YXkgYXNzb2NpYXRpdmUKcmVhbCBtZW1vcnkgID0gODU4OTkz NDU5MiAoODE5MiBNQikKUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMpOgoweDAwMDAwMDAwMDAw MDEwMDAgLSAweDAwMDAwMDAwMDAwOWJmZmYsIDYzNDg4MCBieXRlcyAoMTU1IHBhZ2VzKQow eDAwMDAwMDAwMDE0MjcwMDAgLSAweDAwMDAwMDAwY2ZmOWZmZmYsIDM0NjgxMzY0NDggYnl0 ZXMgKDg0NjcxMyBwYWdlcykKMHgwMDAwMDAwMGNmZmFlMDAwIC0gMHgwMDAwMDAwMGNmZmFm ZmZmLCA4MTkyIGJ5dGVzICgyIHBhZ2VzKQoweDAwMDAwMDAxMDAwMDAwMDAgLSAweDAwMDAw MDAyMWY4YjNmZmYsIDQ4MjQxODY4ODAgYnl0ZXMgKDExNzc3ODAgcGFnZXMpCmF2YWlsIG1l bW9yeSA9IDgyNTAzMjcwNDAgKDc4NjggTUIpCkFDUEkgQVBJQyBUYWJsZTogPEhQICAgICBQ cm9MaWFudD4KSU5UUjogQWRkaW5nIGxvY2FsIEFQSUMgMSBhcyBhIHRhcmdldApJTlRSOiBB ZGRpbmcgbG9jYWwgQVBJQyAyIGFzIGEgdGFyZ2V0CklOVFI6IEFkZGluZyBsb2NhbCBBUElD IDMgYXMgYSB0YXJnZXQKRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRl Y3RlZDogNCBDUFVzCkZyZWVCU0QvU01QOiAxIHBhY2thZ2UocykgeCA0IGNvcmUocykKIGNw dTAgKEJTUCk6IEFQSUMgSUQ6ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxCiBjcHUyIChB UCk6IEFQSUMgSUQ6ICAyCiBjcHUzIChBUCk6IEFQSUMgSUQ6ICAzCkFQSUM6IENQVSAwIGhh cyBBQ1BJIElEIDEKQVBJQzogQ1BVIDEgaGFzIEFDUEkgSUQgMgpBUElDOiBDUFUgMiBoYXMg QUNQSSBJRCAzCkFQSUM6IENQVSAzIGhhcyBBQ1BJIElEIDQKVUxFOiBzZXR1cCBjcHUgMApV TEU6IHNldHVwIGNwdSAxClVMRTogc2V0dXAgY3B1IDIKVUxFOiBzZXR1cCBjcHUgMwpBQ1BJ OiBSU0RQIDB4Zjk5MTAgMDAwMjQgKHYyIEhQICAgICkKQUNQSTogWFNEVCAweGNmZmIwMTAw IDAwMDdDICh2MSBIUCAgICAgUHJvTGlhbnQgMjAwODA1MjYgRk9YQyAwMDAwMDA5NykKQUNQ STogRkFDUCAweGNmZmIwMjkwIDAwMEY0ICh2NCBIUCAgICAgUHJvTGlhbnQgMjAwODA1MjYg Rk9YQyAwMDAwMDA5NykKQUNQSTogRFNEVCAweGNmZmIwNjgwIDA0RDk3ICh2MiBIUCAgICAg UHJvTGlhbnQgMDAwMDA4MDAgSU5UTCAyMDA1MTExNykKQUNQSTogRkFDUyAweGNmZmJlMDAw IDAwMDQwCkFDUEk6IEFQSUMgMHhjZmZiMDM5MCAwMDA4NiAodjIgSFAgICAgIFByb0xpYW50 IDIwMDgwNTI2IEZPWEMgMDAwMDAwOTcpCkFDUEk6IE1DRkcgMHhjZmZiMDQ3MCAwMDAzQyAo djEgSFAgICAgIFByb0xpYW50IDIwMDgwNTI2IEZPWEMgMDAwMDAwOTcpCkFDUEk6IFNQTUkg MHhjZmZiMDRiMCAwMDA0MSAodjUgSFAgICAgIFByb0xpYW50IDIwMDgwNTI2IEZPWEMgMDAw MDAwOTcpCkFDUEk6IE9FTUIgMHhjZmZiZTA0MCAwMDA3MSAodjEgSFAgICAgIFByb0xpYW50 IDIwMDgwNTI2IEZPWEMgMDAwMDAwOTcpCkFDUEk6IEhQRVQgMHhjZmZiNTQyMCAwMDAzOCAo djEgSFAgICAgIFByb0xpYW50IDIwMDgwNTI2IEZPWEMgMDAwMDAwOTcpCkFDUEk6IEVJTkog MHhjZmZiNTQ2MCAwMDEzMCAodjEgSFAgICAgIFByb0xpYW50IDIwMDgwNTI2IEZPWEMgMDAw MDAwOTcpCkFDUEk6IEJFUlQgMHhjZmZiNTVmMCAwMDAzMCAodjEgSFAgICAgIFByb0xpYW50 IDIwMDgwNTI2IEZPWEMgMDAwMDAwOTcpCkFDUEk6IEVSU1QgMHhjZmZiNTYyMCAwMDFCMCAo djEgSFAgICAgIFByb0xpYW50IDIwMDgwNTI2IEZPWEMgMDAwMDAwOTcpCkFDUEk6IEhFU1Qg MHhjZmZiNTdkMCAwMDBBOCAodjEgSFAgICAgIFByb0xpYW50IDIwMDgwNTI2IEZPWEMgMDAw MDAwOTcpCkFDUEk6IFNTRFQgMHhjZmZiNTg4MCAwMEEzMCAodjEgSFAgICAgIFByb0xpYW50 IDIwMDgwNTI2IEZPWEMgMDAwMDAwOTcpCk1BRFQ6IEZvdW5kIElPIEFQSUMgSUQgNCwgSW50 ZXJydXB0IDAgYXQgMHhmZWMwMDAwMAppb2FwaWMwOiBSb3V0aW5nIGV4dGVybmFsIDgyNTlB J3MgLT4gaW50cGluIDAKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRlOiBzb3VyY2UgMCwgaXJx IDIKaW9hcGljMDogUm91dGluZyBJUlEgMCAtPiBpbnRwaW4gMgpNQURUOiBJbnRlcnJ1cHQg b3ZlcnJpZGU6IHNvdXJjZSA5LCBpcnEgOQppb2FwaWMwOiBpbnRwaW4gOSB0cmlnZ2VyOiBs ZXZlbApNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSAxNCwgaXJxIDE0Ck1BRFQ6 IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDE1LCBpcnEgMTUKbGFwaWMwOiBSb3V0aW5n IE5NSSAtPiBMSU5UMQpsYXBpYzA6IExJTlQxIHRyaWdnZXI6IGVkZ2UKbGFwaWMwOiBMSU5U MSBwb2xhcml0eTogaGlnaAppb2FwaWMwIDxWZXJzaW9uIDEuMT4gaXJxcyAwLTIzIG9uIG1v dGhlcmJvYXJkCmNwdTAgQlNQOgogICAgIElEOiAweDAwMDAwMDAwICAgVkVSOiAweDgwMDUw MDEwIExEUjogMHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcw MCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAg dGltZXI6IDB4MDAwMTAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDBmIHBj bTogMHgwMDAxMDQwMAp3bGFuOiA8ODAyLjExIExpbmsgTGF5ZXI+Cm5mc2xvY2s6IHBzZXVk by1kZXZpY2UKa2JkOiBuZXcgYXJyYXkgc2l6ZSA0CmtiZDEgYXQga2JkbXV4MAptZW06IDxt ZW1vcnk+Cm51bGw6IDxudWxsIGRldmljZSwgemVybyBkZXZpY2U+CmlvOiA8SS9PPgpyYW5k b206IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdhcmUsIFlhcnJvdz4KaHB0cnI6IFJvY2tldFJB SUQgMTd4eC8yeHh4IFNBVEEgY29udHJvbGxlciBkcml2ZXIgdjEuMgphY3BpMDogPEhQIFBy b0xpYW50PiBvbiBtb3RoZXJib2FyZApQQ0llOiBNZW1vcnkgTWFwcGVkIGNvbmZpZ3VyYXRp b24gYmFzZSBAIDB4ZTAwMDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElS USA5KSB0byBsYXBpYyAwIHZlY3RvciA0OAphY3BpMDogW01QU0FGRV0KYWNwaTA6IFtJVEhS RUFEXQphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkKYWNwaTA6IHdha2V1cCBjb2RlIHZh IDB4ZmZmZmZmODAwMDAxYTAwMCBwYSAweDQwMDAKQWNwaU9zRGVyaXZlUGNpSWQ6IFxcX1NC Xy5QQ0kwLlNCUkcuUElNQyAtPiBidXMgMCBkZXYgMSBmdW5jIDAKYWNwaTA6IHJlc2VydmF0 aW9uIG9mIGZlYzAwMDAwLCAxMDAwICgzKSBmYWlsZWQKYWNwaTA6IHJlc2VydmF0aW9uIG9m IGZlZTAwMDAwLCAxMDAwICgzKSBmYWlsZWQKQUNQSSB0aW1lcjogMS8xIDEvMiAxLzIgMS8y IDEvMiAxLzIgMS8yIDEvMiAxLzIgMS8yIC0+IDEwClRpbWVjb3VudGVyICJBQ1BJLWZhc3Qi IGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJp dCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDIwMDgtMHgyMDBiIG9uIGFjcGkwCnBj aV9saW5rMDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQ cm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAxNiAxNyAxOCAxOQogIFZhbGlkYXRpb24g ICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CnBjaV9saW5rMTogICAgICAg IEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAy NTUgICBOICAgICAwICAxNiAxNyAxOCAxOQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDE2IDE3IDE4IDE5CnBjaV9saW5rMjogICAgICAgIEluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAx NiAxNyAxOCAxOQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYg MTcgMTggMTkKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3 IDE4IDE5CnBjaV9saW5rMzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg SW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAxNiAxNyAxOCAxOQogIFZh bGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKICBBZnRl ciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CnBjaV9saW5r NDogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAg ICAgICAwICAgIDcgICBOICAgICAwICAxNiAxNyAxOCAxOQogIFZhbGlkYXRpb24gICAgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKICBBZnRlciBEaXNhYmxlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CnBjaV9saW5rNTogICAgICAgIEluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBO ICAgICAwICAxNiAxNyAxOCAxOQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMTYgMTcgMTggMTkKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDE2IDE3IDE4IDE5CnBjaV9saW5rNjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICAxNiAxNyAx OCAxOQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTgg MTkKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5 CnBjaV9saW5rNzogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlh bCBQcm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICAxNiAxNyAxOCAxOQogIFZhbGlkYXRp b24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKICBBZnRlciBEaXNh YmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CnBjaV9saW5rODogICAg ICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAw ICAgIDUgICBOICAgICAwICAyMSAyMiAyMwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMjEgMjIgMjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4g ICAgIDAgIDIxIDIyIDIzCnBjaV9saW5rOTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMAogIFZh bGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAKICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIwCnBjaV9saW5rMTA6ICAgICAgIEluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgIDUgICBOICAg ICAwICAyMSAyMiAyMwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAg MjEgMjIgMjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxIDIy IDIzCnBjaV9saW5rMTE6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5p dGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMAogIFZhbGlkYXRpb24gICAg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjAKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDIwCnBjaV9saW5rMTI6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVm ICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMSAyMiAy MwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjEgMjIgMjMKICBB ZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxIDIyIDIzCnBjaV9saW5r MTM6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAg ICAgICAwICAgMTEgICBOICAgICAwICAyMSAyMiAyMwogIFZhbGlkYXRpb24gICAgICAgICAg MCAgMjU1ICAgTiAgICAgMCAgMjEgMjIgMjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1 NSAgIE4gICAgIDAgIDIxIDIyIDIzCnBjaV9saW5rMTQ6ICAgICAgIEluZGV4ICBJUlEgIFJ0 ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgIDcgICBOICAgICAwICAy MSAyMiAyMwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjEgMjIg MjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxIDIyIDIzCnBj aV9saW5rMTU6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQ cm9iZSAgICAgICAwICAgMTAgICBOICAgICAwICAyMSAyMiAyMwogIFZhbGlkYXRpb24gICAg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjEgMjIgMjMKICBBZnRlciBEaXNhYmxlICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDIxIDIyIDIzCnBjaV9saW5rMTY6ICAgICAgIEluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTEgICBOICAg ICAwICAyMSAyMiAyMwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAg MjEgMjIgMjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxIDIy IDIzCnBjaV9saW5rMTc6ICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5p dGlhbCBQcm9iZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMSAyMiAyMwogIFZhbGlkYXRp b24gICAgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMjEgMjIgMjMKICBBZnRlciBEaXNhYmxl ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxIDIyIDIzCnBjaV9saW5rMTg6ICAgICAgIElu ZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgIDcg ICBOICAgICAwICAyMSAyMiAyMwogIFZhbGlkYXRpb24gICAgICAgICAgMCAgMjU1ICAgTiAg ICAgMCAgMjEgMjIgMjMKICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDIxIDIyIDIzCmFjcGlfaHBldDA6IDxIaWdoIFByZWNpc2lvbiBFdmVudCBUaW1lcj4gaW9t ZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmIG9uIGFjcGkwCmFjcGlfaHBldDA6IHZlbmQ6IDB4 MTBkZSByZXY6IDB4MSBudW06IDIgaHo6IDI1MDAwMDAwIG9wdHM6IGxlZ2FjeV9yb3V0ZQpU aW1lY291bnRlciAiSFBFVCIgZnJlcXVlbmN5IDI1MDAwMDAwIEh6IHF1YWxpdHkgOTAwCnBj aWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAK cGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAKcGNpMDogZG9tYWluPTAsIHBoeXNpY2Fs IGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDM2OSwgcmV2aWQ9MHhhMgoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9MDUtMDAtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNiwgc3RhdHJlZz0weDAwYjAsIGNhY2hl bG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgw MzYwLCByZXZpZD0weGEzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MSwgZnVuYz0wCgljbGFz cz0wNi0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDBmLCBzdGF0 cmVnPTB4MDBhMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMp LCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJbWFwWzEwXTogdHlw ZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgyZjAwLCBzaXplICA3LCBlbmFibGVkCmZv dW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDM2OCwgcmV2aWQ9MHhhMwoJZG9tYWluPTAs IGJ1cz0wLCBzbG90PTEsIGZ1bmM9MQoJY2xhc3M9MGMtMDUtMDAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MQoJY21kcmVnPTB4MDAwMSwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChk d29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKCWludHBpbj1hLCBpcnE9MTEKCXBvd2Vyc3BlYyAyICBzdXBwb3J0 cyBEMCBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIs IGJhc2UgMHgyOTAwLCBzaXplICA2LCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0 LCByYW5nZSAzMiwgYmFzZSAweDJkMDAsIHNpemUgIDYsIGVuYWJsZWQKCW1hcFsyNF06IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MmUwMCwgc2l6ZSAgNiwgZW5hYmxlZApw Y2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4xLklOVEEgKHNyYyBcXF9TQl8uTFNNQjowKQpw Y2lfbGluazEzOiBQaWNrZWQgSVJRIDIxIHdpdGggd2VpZ2h0IDAKcGNpYjA6IHNsb3QgMSBJ TlRBIHJvdXRlZCB0byBpcnEgMjEgdmlhIFxcX1NCXy5MU01CCmZvdW5kLT4JdmVuZG9yPTB4 MTBkZSwgZGV2PTB4MDM2YywgcmV2aWQ9MHhhMQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIs IGZ1bmM9MAoJY2xhc3M9MGMtMDMtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVn PTB4MDAwNywgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAxICgyNTAg bnMpCglpbnRwaW49YSwgaXJxPTUKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBE MyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4 ZmNlYmYwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAu Mi5JTlRBIChzcmMgXFxfU0JfLkxVQjA6MCkKcGNpX2xpbms4OiBQaWNrZWQgSVJRIDIyIHdp dGggd2VpZ2h0IDAKcGNpYjA6IHNsb3QgMiBJTlRBIHJvdXRlZCB0byBpcnEgMjIgdmlhIFxc X1NCXy5MVUIwCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDM2ZCwgcmV2aWQ9MHhh MgoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIsIGZ1bmM9MQoJY2xhc3M9MGMtMDMtMjAsIGhk cnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAwYjAsIGNh Y2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMg KDc1MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMpCglpbnRwaW49YiwgaXJxPTUKCXBvd2Vy c3BlYyAyICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlw ZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmNlYmVjMDAsIHNpemUgIDgsIGVuYWJsZWQK cGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMi5JTlRCIChzcmMgXFxfU0JfLkxVQjI6MCkK cGNpX2xpbmsxMDogUGlja2VkIElSUSAyMyB3aXRoIHdlaWdodCAwCnBjaWIwOiBzbG90IDIg SU5UQiByb3V0ZWQgdG8gaXJxIDIzIHZpYSBcXF9TQl8uTFVCMgpmb3VuZC0+CXZlbmRvcj0w eDEwZGUsIGRldj0weDAzN2YsIHJldmlkPTB4YTMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD01 LCBmdW5jPTAKCWNsYXNzPTAxLTAxLTg1LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJl Zz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMSAoMjUw IG5zKQoJaW50cGluPWEsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBj dXJyZW50IEQwCglNU0kgc3VwcG9ydHMgNCBtZXNzYWdlcywgNjQgYml0CgltYXBbMTBdOiB0 eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGRkODAsIHNpemUgIDMsIGVuYWJsZWQK CW1hcFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZGQwMCwgc2l6ZSAg MiwgZW5hYmxlZAoJbWFwWzE4XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhk YzAwLCBzaXplICAzLCBlbmFibGVkCgltYXBbMWNdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAz MiwgYmFzZSAweGRiODAsIHNpemUgIDIsIGVuYWJsZWQKCW1hcFsyMF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4ZGIwMCwgc2l6ZSAgNCwgZW5hYmxlZAoJbWFwWzI0XTog dHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmNlYmQwMDAsIHNpemUgMTIsIGVuYWJs ZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNS5JTlRBIChzcmMgXFxfU0JfLkxTQTA6 MCkKcGNpX2xpbmsxNTogUGlja2VkIElSUSAyMSB3aXRoIHdlaWdodCAxCnBjaWIwOiBzbG90 IDUgSU5UQSByb3V0ZWQgdG8gaXJxIDIxIHZpYSBcXF9TQl8uTFNBMApmb3VuZC0+CXZlbmRv cj0weDEwZGUsIGRldj0weDAzN2YsIHJldmlkPTB4YTMKCWRvbWFpbj0wLCBidXM9MCwgc2xv dD01LCBmdW5jPTEKCWNsYXNzPTAxLTAxLTg1LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNt ZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMSAo MjUwIG5zKQoJaW50cGluPWIsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQz ICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgNCBtZXNzYWdlcywgNjQgYml0CgltYXBbMTBd OiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGRhODAsIHNpemUgIDMsIGVuYWJs ZWQKCW1hcFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZGEwMCwgc2l6 ZSAgMiwgZW5hYmxlZAoJbWFwWzE4XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2Ug MHhkOTgwLCBzaXplICAzLCBlbmFibGVkCgltYXBbMWNdOiB0eXBlIEkvTyBQb3J0LCByYW5n ZSAzMiwgYmFzZSAweGQ5MDAsIHNpemUgIDIsIGVuYWJsZWQKCW1hcFsyMF06IHR5cGUgSS9P IFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZDg4MCwgc2l6ZSAgNCwgZW5hYmxlZAoJbWFwWzI0 XTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmNlYmMwMDAsIHNpemUgMTIsIGVu YWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNS5JTlRCIChzcmMgXFxfU0JfLkxT QTE6MCkKcGNpX2xpbmsxNjogUGlja2VkIElSUSAyMiB3aXRoIHdlaWdodCAxCnBjaWIwOiBz bG90IDUgSU5UQiByb3V0ZWQgdG8gaXJxIDIyIHZpYSBcXF9TQl8uTFNBMQpmb3VuZC0+CXZl bmRvcj0weDEwZGUsIGRldj0weDAzN2YsIHJldmlkPTB4YTMKCWRvbWFpbj0wLCBidXM9MCwg c2xvdD01LCBmdW5jPTIKCWNsYXNzPTAxLTAxLTg1LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEK CWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJ bGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgw MSAoMjUwIG5zKQoJaW50cGluPWMsIGlycT03Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyA0IG1lc3NhZ2VzLCA2NCBiaXQKCW1hcFsx MF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZDgwMCwgc2l6ZSAgMywgZW5h YmxlZAoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhkNzgwLCBz aXplICAyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFz ZSAweGQ3MDAsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxY106IHR5cGUgSS9PIFBvcnQsIHJh bmdlIDMyLCBiYXNlIDB4ZDY4MCwgc2l6ZSAgMiwgZW5hYmxlZAoJbWFwWzIwXTogdHlwZSBJ L08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhkNjAwLCBzaXplICA0LCBlbmFibGVkCgltYXBb MjRdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmY2ViYjAwMCwgc2l6ZSAxMiwg ZW5hYmxlZApwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC41LklOVEMgKHNyYyBcXF9TQl8u TFNBMjowKQpwY2lfbGluazE4OiBQaWNrZWQgSVJRIDIzIHdpdGggd2VpZ2h0IDEKcGNpYjA6 IHNsb3QgNSBJTlRDIHJvdXRlZCB0byBpcnEgMjMgdmlhIFxcX1NCXy5MU0EyCmZvdW5kLT4J dmVuZG9yPTB4MTBkZSwgZGV2PTB4MDM3MCwgcmV2aWQ9MHhhMgoJZG9tYWluPTAsIGJ1cz0w LCBzbG90PTYsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDEsIGhkcnR5cGU9MHgwMSwgbWZkZXY9 MQoJY21kcmVnPTB4MDAwNCwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMp CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDIgKDUwMCBucyksIG1heGxhdD0w eDAyICg1MDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDM3NiwgcmV2aWQ9 MHhhMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTEwLCBmdW5jPTAKCWNsYXNzPTA2LTA0LTAw LCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDQsIHN0YXRyZWc9MHgwMDEw LCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMiAoNTAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMgMiAgc3VwcG9y dHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCA2NCBiaXQK Zm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMzc0LCByZXZpZD0weGEzCglkb21haW49 MCwgYnVzPTAsIHNsb3Q9MTEsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgw MSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0x NiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAyICg1MDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3Vy cmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJpdApmb3VuZC0+CXZlbmRv cj0weDEwZGUsIGRldj0weDAzNzQsIHJldmlkPTB4YTMKCWRvbWFpbj0wLCBidXM9MCwgc2xv dD0xMiwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCglj bWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDIgKDUwMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kg c3VwcG9ydHMgMiBtZXNzYWdlcywgNjQgYml0CmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2 PTB4MDM3OCwgcmV2aWQ9MHhhMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTEzLCBmdW5jPTAK CWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcs IHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgxYSAoNjUwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJcG93 ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMiBt ZXNzYWdlcywgNjQgYml0CmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDM3NSwgcmV2 aWQ9MHhhMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE0LCBmdW5jPTAKCWNsYXNzPTA2LTA0 LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgw MDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5n bnQ9MHgwMiAoNTAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglwb3dlcnNwZWMgMiAgc3Vw cG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1lc3NhZ2VzLCA2NCBi aXQKZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMzc3LCByZXZpZD0weGEzCglkb21h aW49MCwgYnVzPTAsIHNsb3Q9MTUsIGZ1bmM9MAoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9 MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z ej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAyICg1MDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAg Y3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJpdApmb3VuZC0+CXZl bmRvcj0weDEwMjIsIGRldj0weDEyMDAsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwg c2xvdD0yNCwgZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0x CgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDEyMDEsIHJldmlkPTB4MDAK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNCwgZnVuYz0xCgljbGFzcz0wNi0wMC0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0w eDEyMDIsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNCwgZnVuYz0yCglj bGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBz dGF0cmVnPTB4MDAwMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAg bnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZl bmRvcj0weDEwMjIsIGRldj0weDEyMDMsIHJldmlkPTB4MDAKCWRvbWFpbj0wLCBidXM9MCwg c2xvdD0yNCwgZnVuYz0zCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0x CgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykK CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwMjIsIGRldj0weDEyMDQsIHJldmlkPTB4MDAK CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNCwgZnVuYz00CgljbGFzcz0wNi0wMC0wMCwgaGRy dHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVnPTB4MDAwMCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmlj ZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gcG9y dCAweDJmMDAtMHgyZjdmIGF0IGRldmljZSAxLjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4g b24gaXNhYjAKcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMS4xIChubyBk cml2ZXIgYXR0YWNoZWQpCm9oY2kwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+ IG1lbSAweGZjZWJmMDAwLTB4ZmNlYmZmZmYgaXJxIDIyIGF0IGRldmljZSAyLjAgb24gcGNp MApvaGNpMDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQg MHhmY2ViZjAwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMiAoUENJIElSUSAyMikgdG8g bGFwaWMgMCB2ZWN0b3IgNDkKb2hjaTA6IFtNUFNBRkVdCm9oY2kwOiBbSVRIUkVBRF0KdXNi dXMwOiA8T0hDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwCmVoY2kwOiA8 RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9sbGVyPiBtZW0gMHhmY2ViZWMwMC0weGZj ZWJlY2ZmIGlycSAyMyBhdCBkZXZpY2UgMi4xIG9uIHBjaTAKZWhjaTA6IFJlc2VydmVkIDB4 MTAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhmY2ViZWMwMAppb2FwaWMwOiBy b3V0aW5nIGludHBpbiAyMyAoUENJIElSUSAyMykgdG8gbGFwaWMgMCB2ZWN0b3IgNTAKZWhj aTA6IFtNUFNBRkVdCmVoY2kwOiBbSVRIUkVBRF0KdXNidXMxOiBFSENJIHZlcnNpb24gMS4w CnVzYnVzMTogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTAK YXRhcGNpMDogPG5WaWRpYSBuRm9yY2UgTUNQNTUgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0 IDB4ZGQ4MC0weGRkODcsMHhkZDAwLTB4ZGQwMywweGRjMDAtMHhkYzA3LDB4ZGI4MC0weGRi ODMsMHhkYjAwLTB4ZGIwZiBtZW0gMHhmY2ViZDAwMC0weGZjZWJkZmZmIGlycSAyMSBhdCBk ZXZpY2UgNS4wIG9uIHBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3Igcmlk IDB4MjAgdHlwZSA0IGF0IDB4ZGIwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMSAoUENJ IElSUSAyMSkgdG8gbGFwaWMgMCB2ZWN0b3IgNTEKYXRhcGNpMDogW01QU0FGRV0KYXRhcGNp MDogW0lUSFJFQURdCmF0YXBjaTA6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4 MjQgdHlwZSAzIGF0IDB4ZmNlYmQwMDAKYXRhMjogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBj aTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDQgYXQg MHhkZDgwCmF0YXBjaTA6IFJlc2VydmVkIDB4NCBieXRlcyBmb3IgcmlkIDB4MTQgdHlwZSA0 IGF0IDB4ZGQwMAphdGEyOiBTQVRBIGNvbm5lY3QgdGltZT0wbXMgc3RhdHVzPTAwMDAwMTIz CmF0YTI6IHJlc2V0IHRwMSBtYXNrPTAxIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMjogc3Rh dDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGEyOiByZXNldCB0cDIgc3Rh dDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDEKYXRhMjogW01QU0FGRV0KYXRhMjogW0lUSFJF QURdCmF0YTM6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YXBjaTA6IFJlc2VydmVk IDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4ZGMwMAphdGFwY2kwOiBSZXNl cnZlZCAweDQgYnl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgNCBhdCAweGRiODAKYXRhMzogU0FU QSBjb25uZWN0IHRpbWU9MG1zIHN0YXR1cz0wMDAwMDEyMwphdGEzOiByZXNldCB0cDEgbWFz az0wMSBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTM6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNi PTB4MDAgbXNiPTB4MDAKYXRhMzogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAwIGRldmlj ZXM9MHgxCmF0YTM6IFtNUFNBRkVdCmF0YTM6IFtJVEhSRUFEXQphdGFwY2kxOiA8blZpZGlh IG5Gb3JjZSBNQ1A1NSBTQVRBMzAwIGNvbnRyb2xsZXI+IHBvcnQgMHhkYTgwLTB4ZGE4Nyww eGRhMDAtMHhkYTAzLDB4ZDk4MC0weGQ5ODcsMHhkOTAwLTB4ZDkwMywweGQ4ODAtMHhkODhm IG1lbSAweGZjZWJjMDAwLTB4ZmNlYmNmZmYgaXJxIDIyIGF0IGRldmljZSA1LjEgb24gcGNp MAphdGFwY2kxOiBSZXNlcnZlZCAweDEwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQg MHhkODgwCmF0YXBjaTE6IFtNUFNBRkVdCmF0YXBjaTE6IFtJVEhSRUFEXQphdGFwY2kxOiBS ZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDI0IHR5cGUgMyBhdCAweGZjZWJjMDAw CmF0YTQ6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kxCmF0YXBjaTE6IFJlc2VydmVkIDB4 OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4ZGE4MAphdGFwY2kxOiBSZXNlcnZl ZCAweDQgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweGRhMDAKYXRhNDogU0FUQSBj b25uZWN0IHRpbWU9MG1zIHN0YXR1cz0wMDAwMDEyMwphdGE0OiByZXNldCB0cDEgbWFzaz0w MSBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTQ6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4 MDAgbXNiPTB4MDAKYXRhNDogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAwIGRldmljZXM9 MHgxCmF0YTQ6IFtNUFNBRkVdCmF0YTQ6IFtJVEhSRUFEXQphdGE1OiA8QVRBIGNoYW5uZWwg MT4gb24gYXRhcGNpMQphdGFwY2kxOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4 IHR5cGUgNCBhdCAweGQ5ODAKYXRhcGNpMTogUmVzZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQg MHgxYyB0eXBlIDQgYXQgMHhkOTAwCmF0YTU6IFNBVEEgY29ubmVjdCB0aW1lPTBtcyBzdGF0 dXM9MDAwMDAxMjMKYXRhNTogcmVzZXQgdHAxIG1hc2s9MDEgb3N0YXQwPTUwIG9zdGF0MT0w MAphdGE1OiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTU6IHJl c2V0IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MQphdGE1OiBbTVBTQUZFXQph dGE1OiBbSVRIUkVBRF0KYXRhcGNpMjogPG5WaWRpYSBuRm9yY2UgTUNQNTUgU0FUQTMwMCBj b250cm9sbGVyPiBwb3J0IDB4ZDgwMC0weGQ4MDcsMHhkNzgwLTB4ZDc4MywweGQ3MDAtMHhk NzA3LDB4ZDY4MC0weGQ2ODMsMHhkNjAwLTB4ZDYwZiBtZW0gMHhmY2ViYjAwMC0weGZjZWJi ZmZmIGlycSAyMyBhdCBkZXZpY2UgNS4yIG9uIHBjaTAKYXRhcGNpMjogUmVzZXJ2ZWQgMHgx MCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4ZDYwMAphdGFwY2kyOiBbTVBTQUZF XQphdGFwY2kyOiBbSVRIUkVBRF0KYXRhcGNpMjogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZv ciByaWQgMHgyNCB0eXBlIDMgYXQgMHhmY2ViYjAwMAphdGE2OiA8QVRBIGNoYW5uZWwgMD4g b24gYXRhcGNpMgphdGFwY2kyOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5 cGUgNCBhdCAweGQ4MDAKYXRhcGNpMjogUmVzZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgx NCB0eXBlIDQgYXQgMHhkNzgwCmF0YTY6IFNBVEEgY29ubmVjdCB0aW1lPTBtcyBzdGF0dXM9 MDAwMDAxMTMKYXRhNjogcmVzZXQgdHAxIG1hc2s9MDEgb3N0YXQwPTUwIG9zdGF0MT0wMAph dGE2OiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTY6IHJlc2V0 IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MQphdGE2OiBbTVBTQUZFXQphdGE2 OiBbSVRIUkVBRF0KYXRhNzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTIKYXRhcGNpMjog UmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHhkNzAwCmF0YXBj aTI6IFJlc2VydmVkIDB4NCBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4ZDY4MAph dGE3OiBTQVRBIGNvbm5lY3QgdGltZT0wbXMgc3RhdHVzPTAwMDAwMTEzCmF0YTc6IHJlc2V0 IHRwMSBtYXNrPTAxIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhNzogc3RhdDA9MHgwMCBlcnI9 MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGE3OiByZXNldCB0cDIgc3RhdDA9MDAgc3RhdDE9 MDAgZGV2aWNlcz0weDEwMDAwCmF0YTc6IFtNUFNBRkVdCmF0YTc6IFtJVEhSRUFEXQpwY2li MTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA2LjAgb24gcGNpMApwY2liMTog ICBkb21haW4gICAgICAgICAgICAwCnBjaWIxOiAgIHNlY29uZGFyeSBidXMgICAgIDEKcGNp YjE6ICAgc3Vib3JkaW5hdGUgYnVzICAgMQpwY2liMTogICBJL08gZGVjb2RlICAgICAgICAw eDAtMHgwCnBjaWIxOiAgIG5vIHByZWZldGNoZWQgZGVjb2RlCnBjaWIxOiAgIFN1YnRyYWN0 aXZlbHkgZGVjb2RlZCBicmlkZ2UuCnBjaTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCnBj aTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MQpwY2liMjogPEFDUEkgUENJLVBDSSBicmlk Z2U+IGF0IGRldmljZSAxMC4wIG9uIHBjaTAKcGNpYjI6ICAgZG9tYWluICAgICAgICAgICAg MApwY2liMjogICBzZWNvbmRhcnkgYnVzICAgICAyCnBjaWIyOiAgIHN1Ym9yZGluYXRlIGJ1 cyAgIDIKcGNpYjI6ICAgSS9PIGRlY29kZSAgICAgICAgMHgwLTB4MApwY2liMjogICBubyBw cmVmZXRjaGVkIGRlY29kZQpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMgpwY2kyOiBk b21haW49MCwgcGh5c2ljYWwgYnVzPTIKcGNpYjM6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2 aWNlIDExLjAgb24gcGNpMApwY2liMzogICBkb21haW4gICAgICAgICAgICAwCnBjaWIzOiAg IHNlY29uZGFyeSBidXMgICAgIDMKcGNpYjM6ICAgc3Vib3JkaW5hdGUgYnVzICAgMwpwY2li MzogICBJL08gZGVjb2RlICAgICAgICAweDAtMHgwCnBjaWIzOiAgIG5vIHByZWZldGNoZWQg ZGVjb2RlCnBjaTM6IDxQQ0kgYnVzPiBvbiBwY2liMwpwY2kzOiBkb21haW49MCwgcGh5c2lj YWwgYnVzPTMKcGNpYjQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTIuMCBv biBwY2kwCnBjaWI0OiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjQ6ICAgc2Vjb25kYXJ5 IGJ1cyAgICAgNApwY2liNDogICBzdWJvcmRpbmF0ZSBidXMgICA0CnBjaWI0OiAgIEkvTyBk ZWNvZGUgICAgICAgIDB4ZTAwMC0weGVmZmYKcGNpYjQ6ICAgbWVtb3J5IGRlY29kZSAgICAg MHhmY2YwMDAwMC0weGZjZmZmZmZmCnBjaWI0OiAgIG5vIHByZWZldGNoZWQgZGVjb2RlCnBj aTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI0CnBjaTQ6IGRvbWFpbj0wLCBwaHlzaWNhbCBi dXM9NApmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDEwYjksIHJldmlkPTB4MDYKCWRv bWFpbj0wLCBidXM9NCwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxu c3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT03Cglwb3dlcnNwZWMgMiAg c3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UsIDY0 IGJpdAoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmNmZTAwMDAs IHNpemUgMTcsIGVuYWJsZWQKcGNpYjQ6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmY2Zl MDAwMC0weGZjZmZmZmZmOiBnb29kCgltYXBbMTRdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIs IGJhc2UgMHhmY2ZjMDAwMCwgc2l6ZSAxNywgZW5hYmxlZApwY2liNDogcmVxdWVzdGVkIG1l bW9yeSByYW5nZSAweGZjZmMwMDAwLTB4ZmNmZGZmZmY6IGdvb2QKCW1hcFsxOF06IHR5cGUg SS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZWY4MCwgc2l6ZSAgNSwgZW5hYmxlZApwY2li NDogcmVxdWVzdGVkIEkvTyByYW5nZSAweGVmODAtMHhlZjlmOiBpbiByYW5nZQpwY2liNDog bWF0Y2hlZCBlbnRyeSBmb3IgNC4wLklOVEEgKHNyYyBcXF9TQl8uTE5FQTowKQpwY2lfbGlu azQ6IFBpY2tlZCBJUlEgMTYgd2l0aCB3ZWlnaHQgMApwY2liNDogc2xvdCAwIElOVEEgcm91 dGVkIHRvIGlycSAxNiB2aWEgXFxfU0JfLkxORUEKZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAg TmV0d29yayBDb25uZWN0aW9uIDYuOS4xND4gcG9ydCAweGVmODAtMHhlZjlmIG1lbSAweGZj ZmUwMDAwLTB4ZmNmZmZmZmYsMHhmY2ZjMDAwMC0weGZjZmRmZmZmIGlycSAxNiBhdCBkZXZp Y2UgMC4wIG9uIHBjaTQKZW0wOiBSZXNlcnZlZCAweDIwMDAwIGJ5dGVzIGZvciByaWQgMHgx MCB0eXBlIDMgYXQgMHhmY2ZlMDAwMAplbTA6IGF0dGVtcHRpbmcgdG8gYWxsb2NhdGUgMSBN U0kgdmVjdG9ycyAoMSBzdXBwb3J0ZWQpCm1zaTogcm91dGluZyBNU0kgSVJRIDI1NiB0byBs b2NhbCBBUElDIDAgdmVjdG9yIDUyCmVtMDogdXNpbmcgSVJRIDI1NiBmb3IgTVNJCmVtMDog VXNpbmcgTVNJIGludGVycnVwdAplbTA6IFtGSUxURVJdCmVtMDogYnBmIGF0dGFjaGVkCmVt MDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjM6N2Q6ZmQ6MjY6ZTQKcGNpYjU6IDxBQ1BJIFBD SS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTMuMCBvbiBwY2kwCnBjaWI1OiAgIGRvbWFpbiAg ICAgICAgICAgIDAKcGNpYjU6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMTYKcGNpYjU6ICAgc3Vi b3JkaW5hdGUgYnVzICAgMTYKcGNpYjU6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAwLTB4 ZmZmCnBjaWI1OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmQwMDAwMDAtMHhmZGVmZmZmZgpw Y2liNTogICBwcmVmZXRjaGVkIGRlY29kZSAweGZiMDAwMDAwLTB4ZmJmZmZmZmYKcGNpMTY6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1CnBjaTE2OiBkb21haW49MCwgcGh5c2ljYWwgYnVz PTE2CmZvdW5kLT4JdmVuZG9yPTB4MTAyYiwgZGV2PTB4MDUyMiwgcmV2aWQ9MHgwMgoJZG9t YWluPTAsIGJ1cz0xNiwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgxMDEwLCBjYWNoZWxu c3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBu cyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJcG93ZXJzcGVjIDIg IHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlCglt YXBbMTBdOiB0eXBlIFByZWZldGNoYWJsZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4ZmIw MDAwMDAsIHNpemUgMjQsIGVuYWJsZWQKcGNpYjU6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2Ug MHhmYjAwMDAwMC0weGZiZmZmZmZmOiBnb29kCgltYXBbMTRdOiB0eXBlIE1lbW9yeSwgcmFu Z2UgMzIsIGJhc2UgMHhmZGVmYzAwMCwgc2l6ZSAxNCwgZW5hYmxlZApwY2liNTogcmVxdWVz dGVkIG1lbW9yeSByYW5nZSAweGZkZWZjMDAwLTB4ZmRlZmZmZmY6IGdvb2QKCW1hcFsxOF06 IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZkMDAwMDAwLCBzaXplIDIzLCBlbmFi bGVkCnBjaWI1OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmQwMDAwMDAtMHhmZDdmZmZm ZjogZ29vZApwY2liNTogbWF0Y2hlZCBlbnRyeSBmb3IgMTYuMC5JTlRBIChzcmMgXFxfU0Jf LkxORUQ6MCkKcGNpX2xpbms3OiBQaWNrZWQgSVJRIDE3IHdpdGggd2VpZ2h0IDAKcGNpYjU6 IHNsb3QgMCBJTlRBIHJvdXRlZCB0byBpcnEgMTcgdmlhIFxcX1NCXy5MTkVECnZnYXBjaTA6 IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBtZW0gMHhmYjAwMDAwMC0weGZiZmZmZmZmLDB4 ZmRlZmMwMDAtMHhmZGVmZmZmZiwweGZkMDAwMDAwLTB4ZmQ3ZmZmZmYgaXJxIDE3IGF0IGRl dmljZSAwLjAgb24gcGNpMTYKcGNpYjY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZp Y2UgMTQuMCBvbiBwY2kwCnBjaWI2OiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjY6ICAg c2Vjb25kYXJ5IGJ1cyAgICAgMTcKcGNpYjY6ICAgc3Vib3JkaW5hdGUgYnVzICAgMTcKcGNp YjY6ICAgSS9PIGRlY29kZSAgICAgICAgMHgwLTB4MApwY2liNjogICBtZW1vcnkgZGVjb2Rl ICAgICAweGZkZjAwMDAwLTB4ZmRmZmZmZmYKcGNpYjY6ICAgbm8gcHJlZmV0Y2hlZCBkZWNv ZGUKcGNpMTc6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2CnBjaTE3OiBkb21haW49MCwgcGh5 c2ljYWwgYnVzPTE3CmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2PTB4MTY1YSwgcmV2aWQ9 MHgwMAoJZG9tYWluPTAsIGJ1cz0xNywgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAyLTAwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgwMDEw LCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJcG93 ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBt ZXNzYWdlLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFzZSAw eGZkZmYwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWI2OiByZXF1ZXN0ZWQgbWVtb3J5IHJh bmdlIDB4ZmRmZjAwMDAtMHhmZGZmZmZmZjogZ29vZApwY2liNjogbWF0Y2hlZCBlbnRyeSBm b3IgMTcuMC5JTlRBIChzcmMgXFxfU0JfLkxORUM6MCkKcGNpX2xpbms2OiBQaWNrZWQgSVJR IDE4IHdpdGggd2VpZ2h0IDAKcGNpYjY6IHNsb3QgMCBJTlRBIHJvdXRlZCB0byBpcnEgMTgg dmlhIFxcX1NCXy5MTkVDCnBjaTA6MTc6MDowOiBmYWlsZWQgdG8gcmVhZCBWUEQgZGF0YS4K YmdlMDogPEJyb2FkY29tIEJDTTU3MjIgQTAsIEFTSUMgcmV2LiAweGEyMDA+IG1lbSAweGZk ZmYwMDAwLTB4ZmRmZmZmZmYgaXJxIDE4IGF0IGRldmljZSAwLjAgb24gcGNpMTcKYmdlMDog UmVzZXJ2ZWQgMHgxMDAwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmRmZjAw MDAKYmdlMDogYWRqdXN0IGRldmljZSBjb250cm9sIDB4MjAwMCAtPiAweDUwMDAKYmdlMDog YXR0ZW1wdGluZyB0byBhbGxvY2F0ZSAxIE1TSSB2ZWN0b3JzICgxIHN1cHBvcnRlZCkKbXNp OiByb3V0aW5nIE1TSSBJUlEgMjU3IHRvIGxvY2FsIEFQSUMgMCB2ZWN0b3IgNTMKYmdlMDog dXNpbmcgSVJRIDI1NyBmb3IgTVNJCmJnZTA6IENISVAgSUQgMHhhMjAwMDAwMDsgQVNJQyBS RVYgMHgwYTsgQ0hJUCBSRVYgMHhhMjsgUENJLUUKYmdlMDogRGlzYWJsaW5nIGZhc3Rib290 CmJnZTA6IERpc2FibGluZyBmYXN0Ym9vdAptaWlidXMwOiA8TUlJIGJ1cz4gb24gYmdlMApi cmdwaHkwOiA8QkNNNTcyMiAxMC8xMDAvMTAwMGJhc2VUWCBQSFk+IFBIWSAxIG9uIG1paWJ1 czAKYnJncGh5MDogT1VJIDB4MDA1MGVmLCBtb2RlbCAweDAwMmQsIHJldi4gMApicmdwaHkw OiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAw MGJhc2VULCAxMDAwYmFzZVQtRkRYLCBhdXRvCmJnZTA6IGJwZiBhdHRhY2hlZApiZ2UwOiBF dGhlcm5ldCBhZGRyZXNzOiAwMDoyMzo3ZDpkYjpiNjpkOApiZ2UwOiBbTVBTQUZFXQpiZ2Uw OiBbSVRIUkVBRF0KcGNpYjc6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTUu MCBvbiBwY2kwCnBjaWI3OiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjc6ICAgc2Vjb25k YXJ5IGJ1cyAgICAgMTgKcGNpYjc6ICAgc3Vib3JkaW5hdGUgYnVzICAgMTgKcGNpYjc6ICAg SS9PIGRlY29kZSAgICAgICAgMHgwLTB4MApwY2liNzogICBubyBwcmVmZXRjaGVkIGRlY29k ZQpwY2kxODogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcKcGNpMTg6IGRvbWFpbj0wLCBwaHlz aWNhbCBidXM9MTgKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBhY3BpMAp1YXJ0 MDogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3Mg MHgxMCBvbiBhY3BpMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiA0IChJU0EgSVJRIDQpIHRv IGxhcGljIDAgdmVjdG9yIDU0CnVhcnQwOiBbRklMVEVSXQp1YXJ0MDogZmFzdCBpbnRlcnJ1 cHQKYXRydGMxOiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDcxIG9uIGFjcGkw CmF0cnRjMTogcmVnaXN0ZXJlZCBhcyBhIHRpbWUtb2YtZGF5IGNsb2NrIChyZXNvbHV0aW9u IDEwMDAwMDB1cykKY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUwOiBzd2l0Y2hpbmcg dG8gZ2VuZXJpYyBDeCBtb2RlCmh3cHN0YXRlMDogPENvb2xgbidRdWlldCAyLjA+IG9uIGNw dTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUyOiA8QUNQSSBDUFU+IG9uIGFjcGkw CmNwdTM6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXhfaXNhX2lkZW50aWZ5KCkKYWhjX2lzYV9w cm9iZSAyOiBpb3BvcnQgMHgyYzAwIGFsbG9jIGZhaWxlZAphaGNfaXNhX3Byb2JlIDEzOiBp b3BvcnQgMHhkYzAwIGFsbG9jIGZhaWxlZAppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGlu ZyBQblAgZGV2aWNlcwpzYzogc2MwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAp1YXJ0 OiB1YXJ0MCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2NoaWxkcmVu OiBwcm9iaW5nIG5vbi1QblAgZGV2aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBp b21lbSAweGMwMDAwLTB4YzdmZmYsMHhjYTAwMC0weGNhZmZmIG9uIGlzYTAKYXRrYmQ6IHRo ZSBjdXJyZW50IGtiZCBjb250cm9sbGVyIGNvbW1hbmQgYnl0ZSAwMDY1CmF0a2JkOiBrZXli b2FyZCBJRCAweDQxYWIgKDIpCnNjMDogPFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEw MCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4K c2MwOiBmYjAsIGtiZDEsIHRlcm1pbmFsIGVtdWxhdG9yOiBzY3Rla2VuICh0ZWtlbiB0ZXJt aW5hbCkKdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBpb21l bSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxl ciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBvbiBpc2EwCmF0a2JkMDogPEFUIEtleWJv YXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmtiZDA6IGF0a2JkMCwgQVQg MTAxLzEwMiAoMiksIGNvbmZpZzoweDAsIGZsYWdzOjB4M2QwMDAwCmlvYXBpYzA6IHJvdXRp bmcgaW50cGluIDEgKElTQSBJUlEgMSkgdG8gbGFwaWMgMCB2ZWN0b3IgNTUKYXRrYmQwOiBb R0lBTlQtTE9DS0VEXQphdGtiZDA6IFtJVEhSRUFEXQpwc20wOiBjdXJyZW50IGNvbW1hbmQg Ynl0ZTowMDY1CnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMAppb2FwaWMw OiByb3V0aW5nIGludHBpbiAxMiAoSVNBIElSUSAxMikgdG8gbGFwaWMgMCB2ZWN0b3IgNTYK cHNtMDogW0dJQU5ULUxPQ0tFRF0KcHNtMDogW0lUSFJFQURdCnBzbTA6IG1vZGVsIEdsaWRl UG9pbnQsIGRldmljZSBJRCAwLTAwLCAzIGJ1dHRvbnMKcHNtMDogY29uZmlnOjAwMDAwMDAw LCBmbGFnczowMDAwMDAwOCwgcGFja2V0IHNpemU6Mwpwc20wOiBzeW5jbWFzazpjMCwgc3lu Y2JpdHM6MDAKYXRydGMwOiA8QVQgUmVhbCBUaW1lIENsb2NrPiBhdCBwb3J0IDB4NzAgaXJx IDggb24gaXNhMAphdHJ0YzA6IFdhcm5pbmc6IENvdWxkbid0IG1hcCBJL08uCmF0cnRjMDog V2FybmluZzogQ291bGRuJ3QgbWFwIEludGVycnVwdC4KYXRydGMxOiByZW1vdmVkIGFzIHRp bWUtb2YtZGF5IGNsb2NrOiBjbG9jayBhdHJ0YyBoYXMgaGlnaGVyIHJlc29sdXRpb24KYXRy dGMwOiByZWdpc3RlcmVkIGFzIGEgdGltZS1vZi1kYXkgY2xvY2sgKHJlc29sdXRpb24gMTAw MDAwMHVzKQpmZGMwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2YwLTB4M2Y1LDB4M2Y3 IGlycSA2IGRycSAyIG9uIGlzYTAKcHBjMDogY2Fubm90IHJlc2VydmUgSS9PIHBvcnQgcmFu Z2UKcHBjMDogPFBhcmFsbGVsIHBvcnQ+IGZhaWxlZCB0byBwcm9iZSBhdCBpcnEgNyBvbiBp c2EwCnVhcnQxOiA8bnM4MjUwPiBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDJmOC0weDJm ZiBpcnEgMyBvbiBpc2EwCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQblAgZGV2aWNl cwpEZXZpY2UgY29uZmlndXJhdGlvbiBmaW5pc2hlZC4KUmVkdWNpbmcga2Vybi5tYXh2bm9k ZXMgNTEyMzI2IC0+IDEwMDAwMApwcm9jZnMgcmVnaXN0ZXJlZApsYXBpYzogRGl2aXNvciAy LCBGcmVxdWVuY3kgMTAwMDAwNzU0IGh6ClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAy MTAwMDE1NjM5IEh6IHF1YWxpdHkgLTEwMApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAw MCBtc2VjCmxvMDogYnBmIGF0dGFjaGVkCmhwdHJyOiBubyBjb250cm9sbGVyIGRldGVjdGVk LgphdGEyOiBJZGVudGlmeWluZyBkZXZpY2VzOiAwMDAwMDAwMQphdGEyOiBOZXcgZGV2aWNl czogMDAwMDAwMDEKbWQwOiBQcmVsb2FkZWQgaW1hZ2UgPC9ib290L21mc3Jvb3Q+IDQxOTQz MDQgYnl0ZXMgYXQgMHhmZmZmZmZmZjgwZmZiNjAwCnVzYnVzMDogMTJNYnBzIEZ1bGwgU3Bl ZWQgVVNCIHYxLjAKdXNidXMxOiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdWdlbjAu MTogPG5WaWRpYT4gYXQgdXNidXMwCnVodWIwOiA8blZpZGlhIE9IQ0kgcm9vdCBIVUIsIGNs YXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czAKdWdlbjEuMTogPG5W aWRpYT4gYXQgdXNidXMxCnVodWIxOiA8blZpZGlhIEVIQ0kgcm9vdCBIVUIsIGNsYXNzIDkv MCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czEKdWh1YjA6IDEwIHBvcnRzIHdp dGggMTAgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKYXRhMjogcmVpbml0aW5nIGNoYW5uZWwg Li4KYXRhMjogU0FUQSBjb25uZWN0IHRpbWU9MG1zIHN0YXR1cz0wMDAwMDEyMwphdGEyOiBy ZXNldCB0cDEgbWFzaz0wMSBvc3RhdDA9NTggb3N0YXQxPTAwCmF0YTI6IHN0YXQwPTB4ZDgg ZXJyPTB4MDAgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMjogc3RhdDA9MHg1MCBlcnI9MHgwMSBs c2I9MHgwMCBtc2I9MHgwMAphdGEyOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2 aWNlcz0weDEKYXRhMjogcmVpbml0IGRvbmUgLi4KdW5rbm93bjogRkFJTFVSRSAtIEFUQV9J REVOVElGWSB0aW1lZCBvdXQgTEJBPTAKYXRhMjogcmVpbml0aW5nIGNoYW5uZWwgLi4KYXRh MjogU0FUQSBjb25uZWN0IHRpbWU9MG1zIHN0YXR1cz0wMDAwMDEyMwphdGEyOiByZXNldCB0 cDEgbWFzaz0wMSBvc3RhdDA9NTggb3N0YXQxPTAwCmF0YTI6IHN0YXQwPTB4ZDggZXJyPTB4 MDAgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMjogc3RhdDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgw MCBtc2I9MHgwMAphdGEyOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0w eDEKYXRhMjogcmVpbml0IGRvbmUgLi4KdW5rbm93bjogRkFJTFVSRSAtIEFUQV9JREVOVElG WSB0aW1lZCBvdXQgTEJBPTAKYXRhMzogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMDAwMDEK YXRhMzogTmV3IGRldmljZXM6IDAwMDAwMDAxCmF0YTM6IHJlaW5pdGluZyBjaGFubmVsIC4u CmF0YTM6IFNBVEEgY29ubmVjdCB0aW1lPTBtcyBzdGF0dXM9MDAwMDAxMjMKYXRhMzogcmVz ZXQgdHAxIG1hc2s9MDEgb3N0YXQwPTU4IG9zdGF0MT0wMAphdGEzOiBzdGF0MD0weGQ4IGVy cj0weDAwIGxzYj0weDAwIG1zYj0weDAwCmF0YTM6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNi PTB4MDAgbXNiPTB4MDAKYXRhMzogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAwIGRldmlj ZXM9MHgxCmF0YTM6IHJlaW5pdCBkb25lIC4uCnVua25vd246IEZBSUxVUkUgLSBBVEFfSURF TlRJRlkgdGltZWQgb3V0IExCQT0wCnVodWIxOiAxMCBwb3J0cyB3aXRoIDEwIHJlbW92YWJs ZSwgc2VsZiBwb3dlcmVkCmF0YTM6IHJlaW5pdGluZyBjaGFubmVsIC4uCmF0YTM6IFNBVEEg Y29ubmVjdCB0aW1lPTBtcyBzdGF0dXM9MDAwMDAxMjMKYXRhMzogcmVzZXQgdHAxIG1hc2s9 MDEgb3N0YXQwPTU4IG9zdGF0MT0wMAphdGEzOiBzdGF0MD0weGQ4IGVycj0weDAwIGxzYj0w eDAwIG1zYj0weDAwCmF0YTM6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4 MDAKYXRhMzogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAwIGRldmljZXM9MHgxCmF0YTM6 IHJlaW5pdCBkb25lIC4uCnVua25vd246IEZBSUxVUkUgLSBBVEFfSURFTlRJRlkgdGltZWQg b3V0IExCQT0wCmF0YTQ6IElkZW50aWZ5aW5nIGRldmljZXM6IDAwMDAwMDAxCmF0YTQ6IE5l dyBkZXZpY2VzOiAwMDAwMDAwMQphdGE0LW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1 ZG1hPVVETUExMzMgY2FibGU9NDAgd2lyZQphZDg6IDE0MzA3OTlNQiA8U2VhZ2F0ZSBTVDMx NTAwMzQxQVMgQ0MxSD4gYXQgYXRhNC1tYXN0ZXIgU0FUQTMwMAphZDg6IDI5MzAyNzcxNjgg c2VjdG9ycyBbMjkwNzAyMUMvMTZILzYzU10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0 aCBxdWV1ZQpHRU9NOiBuZXcgZGlzayBhZDgKYWQ4OiBuVmlkaWEgY2hlY2sxIGZhaWxlZAph ZDg6IEFkYXB0ZWMgY2hlY2sxIGZhaWxlZAphZDg6IExTSSAodjMpIGNoZWNrMSBmYWlsZWQK YWQ4OiBMU0kgKHYyKSBjaGVjazEgZmFpbGVkCmFkODogRnJlZUJTRCBjaGVjazEgZmFpbGVk CmF0YTU6IElkZW50aWZ5aW5nIGRldmljZXM6IDAwMDAwMDAxCmF0YTU6IE5ldyBkZXZpY2Vz OiAwMDAwMDAwMQphdGE1LW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUEx MzMgY2FibGU9NDAgd2lyZQphZDEwOiAxNDMwNzk5TUIgPFNlYWdhdGUgU1QzMTUwMDM0MUFT IENDMUg+IGF0IGF0YTUtbWFzdGVyIFNBVEEzMDAKYWQxMDogMjkzMDI3NzE2OCBzZWN0b3Jz IFsyOTA3MDIxQy8xNkgvNjNTXSAxNiBzZWN0b3JzL2ludGVycnVwdCAxIGRlcHRoIHF1ZXVl CkdFT006IG5ldyBkaXNrIGFkMTAKYWQxMDogblZpZGlhIGNoZWNrMSBmYWlsZWQKYWQxMDog QWRhcHRlYyBjaGVjazEgZmFpbGVkCmFkMTA6IExTSSAodjMpIGNoZWNrMSBmYWlsZWQKYWQx MDogTFNJICh2MikgY2hlY2sxIGZhaWxlZAphZDEwOiBGcmVlQlNEIGNoZWNrMSBmYWlsZWQK YXRhNjogSWRlbnRpZnlpbmcgZGV2aWNlczogMDAwMDAwMDEKYXRhNjogTmV3IGRldmljZXM6 IDAwMDAwMDAxCmF0YTYtbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEz MyBjYWJsZT00MCB3aXJlCmFkMTI6IDIzODQ3NU1CIDxTZWFnYXRlIFNUMzI1MDMxME5TIFNO MDY+IGF0IGF0YTYtbWFzdGVyIFNBVEExNTAKYWQxMjogNDg4Mzk3MTY4IHNlY3RvcnMgWzQ4 NDUyMUMvMTZILzYzU10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQpHRU9N OiBuZXcgZGlzayBhZDEyCmFkMTI6IG5WaWRpYSBjaGVjazEgZmFpbGVkCmFkMTI6IEFkYXB0 ZWMgY2hlY2sxIGZhaWxlZAphZDEyOiBMU0kgKHYzKSBjaGVjazEgZmFpbGVkCmFkMTI6IExT SSAodjIpIGNoZWNrMSBmYWlsZWQKYWQxMjogRnJlZUJTRCBjaGVjazEgZmFpbGVkCmF0YTc6 IElkZW50aWZ5aW5nIGRldmljZXM6IDAwMDEwMDAwCmF0YTc6IE5ldyBkZXZpY2VzOiAwMDAx MDAwMAphdGE3LW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMDAgY2Fi bGU9NDAgd2lyZQphY2QwOiA8VFNTVGNvcnBEVkQtUk9NIFRTLUgzNTNCL0lHMDE+IERWRFJP TSBkcml2ZSBhdCBhdGE3IGFzIG1hc3RlcgphY2QwOiByZWFkIDgyNjhLQi9zICg4MjY4S0Iv cyksIDE5OEtCIGJ1ZmZlciwgU0FUQTE1MAphY2QwOiBSZWFkczogQ0RSLCBDRFJXLCBDRERB IHN0cmVhbSwgRFZEUk9NLCBEVkRSLCBEVkRSQU0sIHBhY2tldAphY2QwOiBXcml0ZXM6CmFj ZDA6IEF1ZGlvOiBwbGF5LCAyNTUgdm9sdW1lIGxldmVscwphY2QwOiBNZWNoYW5pc206IGVq ZWN0YWJsZSB0cmF5LCB1bmxvY2tlZAphY2QwOiBNZWRpdW06IENELVJPTSAxMjBtbSBkYXRh IGRpc2MKQVRBIFBzZXVkb1JBSUQgbG9hZGVkClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpj cHUxIEFQOgogICAgIElEOiAweDAxMDAwMDAwICAgVkVSOiAweDgwMDUwMDEwIExEUjogMHgw MDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgw MDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAw MjAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDQw MApTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEKY3B1MiBBUDoKICAgICBJRDogMHgwMjAwMDAw MCAgIFZFUjogMHg4MDA1MDAxMCBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAg bGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNW UjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAwMDIwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVy cjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTA0MDAKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQh CmNwdTMgQVA6CiAgICAgSUQ6IDB4MDMwMDAwMDAgICBWRVI6IDB4ODAwNTAwMTAgTERSOiAw eDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAw eDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgw MDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEw NDAwCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDQgKElTQSBJUlEgNCkgdG8gbGFwaWMgMSB2 ZWN0b3IgNDgKaW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byBsYXBp YyAyIHZlY3RvciA0OAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxMiAoSVNBIElSUSAxMikg dG8gbGFwaWMgMyB2ZWN0b3IgNDgKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjIgKFBDSSBJ UlEgMjIpIHRvIGxhcGljIDEgdmVjdG9yIDQ5CmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDIz IChQQ0kgSVJRIDIzKSB0byBsYXBpYyAyIHZlY3RvciA0OQptc2k6IEFzc2lnbmluZyBNU0kg SVJRIDI1NiB0byBsb2NhbCBBUElDIDMgdmVjdG9yIDQ5CldBUk5JTkc6IFdJVE5FU1Mgb3B0 aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNlLgpHRU9NOiBhZDEyczE6 IGdlb21ldHJ5IGRvZXMgbm90IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAhPSAxNmgsNjNzKS4K dWdlbjAuMjogPFNlcnZlckVuZ2luZXM+IGF0IHVzYnVzMAp1a2JkMDogPFNlcnZlckVuZ2lu ZXMgU0UgVVNCIERldmljZSwgY2xhc3MgMC8wLCByZXYgMS4xMC8wLjAxLCBhZGRyIDI+IG9u IHVzYnVzMAprYmQyIGF0IHVrYmQwCmtiZDI6IHVrYmQwLCBnZW5lcmljICgwKSwgY29uZmln OjB4MCwgZmxhZ3M6MHgzZDAwMDAKdW1zMDogPFNlcnZlckVuZ2luZXMgU0UgVVNCIERldmlj ZSwgY2xhc3MgMC8wLCByZXYgMS4xMC8wLjAxLCBhZGRyIDI+IG9uIHVzYnVzMAp1bXMwOiA4 IGJ1dHRvbnMgYW5kIFtYWVpdIGNvb3JkaW5hdGVzIElEPTAKVHJ5aW5nIHRvIG1vdW50IHJv b3QgZnJvbSB1ZnM6L2Rldi9tZDAKY3RfdG9fdHMoWzIwMDktMDgtMzEgMTY6NDI6MTldKSA9 IDEyNTE3MzY5MzkuMDAwMDAwMDAwCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0Cg== --------------090707070904060208060208 Content-Type: text/plain; name="dmesg-7.1.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dmesg-7.1.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA3LjEtUkVMRUFTRSAjMDog VGh1IEphbiAgMSAwODo1ODoyNCBVVEMgMjAwOQogICAgcm9vdEBkcmlzY29sbC5jc2UuYnVm ZmFsby5lZHU6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQwpQcmVsb2FkZWQgZWxmIGtl cm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQgMHhmZmZmZmZmZjgwYzRlMDAwLgpQcmVs b2FkZWQgL2Jvb3QvemZzL3pwb29sLmNhY2hlICIvYm9vdC96ZnMvenBvb2wuY2FjaGUiIGF0 IDB4ZmZmZmZmZmY4MGM0ZTIxMC4KQ2FsaWJyYXRpbmcgY2xvY2socykgLi4uIGk4MjU0IGNs b2NrOiAxMTkzMjc5IEh6CkNMS19VU0VfSTgyNTRfQ0FMSUJSQVRJT04gbm90IHNwZWNpZmll ZCAtIHVzaW5nIGRlZmF1bHQgZnJlcXVlbmN5ClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVl bmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNhbGlicmF0aW5nIFRTQyBjbG9jayAuLi4gVFND IGNsb2NrOiAyMTAwMDE1MTg3IEh6CkNQVTogUXVhZC1Db3JlIEFNRCBPcHRlcm9uKHRtKSBQ cm9jZXNzb3IgMTM1MiAoMjEwMC4wMi1NSHogSzgtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJB dXRoZW50aWNBTUQiICBJZCA9IDB4MTAwZjIzICBTdGVwcGluZyA9IDMKICBGZWF0dXJlcz0w eDE3OGJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAs TVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsTU1YLEZYU1IsU1NFLFNTRTIs SFRUPgogIEZlYXR1cmVzMj0weDgwMjAwOTxTU0UzLE1PTixDWDE2LDxiMjM+PgogIEFNRCBG ZWF0dXJlcz0weGVlNTAwODAwPFNZU0NBTEwsTlgsTU1YKyxGRlhTUixQYWdlMUdCLFJEVFND UCxMTSwzRE5vdyErLDNETm93IT4KICBBTUQgRmVhdHVyZXMyPTB4N2ZmPExBSEYsQ01QLFNW TSxFeHRBUElDLENSOCw8YjU+LDxiNj4sPGI3PixQcmVmZXRjaCw8Yjk+LDxiMTA+PgogIENv cmVzIHBlciBwYWNrYWdlOiA0CkwxIDJNQiBkYXRhIFRMQjogNDggZW50cmllcywgZnVsbHkg YXNzb2NpYXRpdmUKTDEgMk1CIGluc3RydWN0aW9uIFRMQjogMTYgZW50cmllcywgZnVsbHkg YXNzb2NpYXRpdmUKTDEgNEtCIGRhdGEgVExCOiA0OCBlbnRyaWVzLCBmdWxseSBhc3NvY2lh dGl2ZQpMMSA0S0IgaW5zdHJ1Y3Rpb24gVExCOiAzMiBlbnRyaWVzLCBmdWxseSBhc3NvY2lh dGl2ZQpMMSBkYXRhIGNhY2hlOiA2NCBrYnl0ZXMsIDY0IGJ5dGVzL2xpbmUsIDEgbGluZXMv dGFnLCAyLXdheSBhc3NvY2lhdGl2ZQpMMSBpbnN0cnVjdGlvbiBjYWNoZTogNjQga2J5dGVz LCA2NCBieXRlcy9saW5lLCAxIGxpbmVzL3RhZywgMi13YXkgYXNzb2NpYXRpdmUKTDIgMk1C IGRhdGEgVExCOiAxMjggZW50cmllcywgMi13YXkgYXNzb2NpYXRpdmUKTDIgMk1CIGluc3Ry dWN0aW9uIFRMQjogMCBlbnRyaWVzLCAyLXdheSBhc3NvY2lhdGl2ZQpMMiA0S0IgZGF0YSBU TEI6IDUxMiBlbnRyaWVzLCA0LXdheSBhc3NvY2lhdGl2ZQpMMiA0S0IgaW5zdHJ1Y3Rpb24g VExCOiA1MTIgZW50cmllcywgNC13YXkgYXNzb2NpYXRpdmUKTDIgdW5pZmllZCBjYWNoZTog NTEyIGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDE2LXdheSBhc3NvY2lh dGl2ZQp1c2FibGUgbWVtb3J5ID0gODU3NjIxNzA4OCAoODE3OCBNQikKUGh5c2ljYWwgbWVt b3J5IGNodW5rKHMpOgoweDAwMDAwMDAwMDAwMDEwMDAgLSAweDAwMDAwMDAwMDAwOWJmZmYs IDYzNDg4MCBieXRlcyAoMTU1IHBhZ2VzKQoweDAwMDAwMDAwMDBkNTAwMDAgLSAweDAwMDAw MDAwY2ZmOWZmZmYsIDM0NzUzMDg1NDQgYnl0ZXMgKDg0ODQ2NCBwYWdlcykKMHgwMDAwMDAw MTAwMDAwMDAwIC0gMHgwMDAwMDAwMjFmOGY5ZmZmLCA0ODI0NDczNjAwIGJ5dGVzICgxMTc3 ODUwIHBhZ2VzKQphdmFpbCBtZW1vcnkgID0gODI4ODgwNDg2NCAoNzkwNCBNQikKQUNQSSBB UElDIFRhYmxlOiA8SFAgICAgIFByb0xpYW50PgpJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyAx IGFzIGEgdGFyZ2V0CklOVFI6IEFkZGluZyBsb2NhbCBBUElDIDIgYXMgYSB0YXJnZXQKSU5U UjogQWRkaW5nIGxvY2FsIEFQSUMgMyBhcyBhIHRhcmdldApGcmVlQlNEL1NNUDogTXVsdGlw cm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA0IENQVXMKIGNwdTAgKEJTUCk6IEFQSUMgSUQ6 ICAwCiBjcHUxIChBUCk6IEFQSUMgSUQ6ICAxCiBjcHUyIChBUCk6IEFQSUMgSUQ6ICAyCiBj cHUzIChBUCk6IEFQSUMgSUQ6ICAzCkFQSUM6IENQVSAwIGhhcyBBQ1BJIElEIDEKQVBJQzog Q1BVIDEgaGFzIEFDUEkgSUQgMgpBUElDOiBDUFUgMiBoYXMgQUNQSSBJRCAzCkFQSUM6IENQ VSAzIGhhcyBBQ1BJIElEIDQKVUxFOiBzZXR1cCBjcHUgZ3JvdXAgMApVTEU6IHNldHVwIGNw dSAwClVMRTogYWRkaW5nIGNwdSAwIHRvIGdyb3VwIDA6IGNwdXMgMSBtYXNrIDB4MQpVTEU6 IHNldHVwIGNwdSBncm91cCAxClVMRTogc2V0dXAgY3B1IDEKVUxFOiBhZGRpbmcgY3B1IDEg dG8gZ3JvdXAgMTogY3B1cyAxIG1hc2sgMHgyClVMRTogc2V0dXAgY3B1IGdyb3VwIDIKVUxF OiBzZXR1cCBjcHUgMgpVTEU6IGFkZGluZyBjcHUgMiB0byBncm91cCAyOiBjcHVzIDEgbWFz ayAweDQKVUxFOiBzZXR1cCBjcHUgZ3JvdXAgMwpVTEU6IHNldHVwIGNwdSAzClVMRTogYWRk aW5nIGNwdSAzIHRvIGdyb3VwIDM6IGNwdXMgMSBtYXNrIDB4OApBQ1BJOiBSU0RQIEAgMHgw eGY5OTEwLzB4MDAyNCAodiAgMiBIUCAgICApCkFDUEk6IFhTRFQgQCAweDB4Y2ZmYjAxMDAv MHgwMDdDICh2ICAxIEhQICAgICBQcm9MaWFudCAweDIwMDgwNTI2IEZPWEMgMHgwMDAwMDA5 NykKQUNQSTogRkFDUCBAIDB4MHhjZmZiMDI5MC8weDAwRjQgKHYgIDQgSFAgICAgIFByb0xp YW50IDB4MjAwODA1MjYgRk9YQyAweDAwMDAwMDk3KQpBQ1BJOiBEU0RUIEAgMHgweGNmZmIw NjgwLzB4NEQ5NyAodiAgMiBIUCAgICAgUHJvTGlhbnQgMHgwMDAwMDgwMCBJTlRMIDB4MjAw NTExMTcpCkFDUEk6IEZBQ1MgQCAweDB4Y2ZmYmUwMDAvMHgwMDQwCkFDUEk6IEFQSUMgQCAw eDB4Y2ZmYjAzOTAvMHgwMDg2ICh2ICAyIEhQICAgICBQcm9MaWFudCAweDIwMDgwNTI2IEZP WEMgMHgwMDAwMDA5NykKQUNQSTogTUNGRyBAIDB4MHhjZmZiMDQ3MC8weDAwM0MgKHYgIDEg SFAgICAgIFByb0xpYW50IDB4MjAwODA1MjYgRk9YQyAweDAwMDAwMDk3KQpBQ1BJOiBTUE1J IEAgMHgweGNmZmIwNGIwLzB4MDA0MSAodiAgNSBIUCAgICAgUHJvTGlhbnQgMHgyMDA4MDUy NiBGT1hDIDB4MDAwMDAwOTcpCkFDUEk6IE9FTUIgQCAweDB4Y2ZmYmUwNDAvMHgwMDcxICh2 ICAxIEhQICAgICBQcm9MaWFudCAweDIwMDgwNTI2IEZPWEMgMHgwMDAwMDA5NykKQUNQSTog SFBFVCBAIDB4MHhjZmZiNTQyMC8weDAwMzggKHYgIDEgSFAgICAgIFByb0xpYW50IDB4MjAw ODA1MjYgRk9YQyAweDAwMDAwMDk3KQpBQ1BJOiBFSU5KIEAgMHgweGNmZmI1NDYwLzB4MDEz MCAodiAgMSBIUCAgICAgUHJvTGlhbnQgMHgyMDA4MDUyNiBGT1hDIDB4MDAwMDAwOTcpCkFD UEk6IEJFUlQgQCAweDB4Y2ZmYjU1ZjAvMHgwMDMwICh2ICAxIEhQICAgICBQcm9MaWFudCAw eDIwMDgwNTI2IEZPWEMgMHgwMDAwMDA5NykKQUNQSTogRVJTVCBAIDB4MHhjZmZiNTYyMC8w eDAxQjAgKHYgIDEgSFAgICAgIFByb0xpYW50IDB4MjAwODA1MjYgRk9YQyAweDAwMDAwMDk3 KQpBQ1BJOiBIRVNUIEAgMHgweGNmZmI1N2QwLzB4MDBBOCAodiAgMSBIUCAgICAgUHJvTGlh bnQgMHgyMDA4MDUyNiBGT1hDIDB4MDAwMDAwOTcpCkFDUEk6IFNTRFQgQCAweDB4Y2ZmYjU4 ODAvMHgwQTMwICh2ICAxIEhQICAgICBQcm9MaWFudCAweDIwMDgwNTI2IEZPWEMgMHgwMDAw MDA5NykKTUFEVDogRm91bmQgSU8gQVBJQyBJRCA0LCBJbnRlcnJ1cHQgMCBhdCAweGZlYzAw MDAwCmlvYXBpYzA6IFJvdXRpbmcgZXh0ZXJuYWwgODI1OUEncyAtPiBpbnRwaW4gMApNQURU OiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSAwLCBpcnEgMgppb2FwaWMwOiBSb3V0aW5n IElSUSAwIC0+IGludHBpbiAyCk1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDks IGlycSA5CmlvYXBpYzA6IGludHBpbiA5IHRyaWdnZXI6IGxldmVsCk1BRFQ6IEludGVycnVw dCBvdmVycmlkZTogc291cmNlIDE0LCBpcnEgMTQKTUFEVDogSW50ZXJydXB0IG92ZXJyaWRl OiBzb3VyY2UgMTUsIGlycSAxNQpsYXBpYzA6IFJvdXRpbmcgTk1JIC0+IExJTlQxCmxhcGlj MDogTElOVDEgdHJpZ2dlcjogZWRnZQpsYXBpYzA6IExJTlQxIHBvbGFyaXR5OiBoaWdoCmlv YXBpYzAgPFZlcnNpb24gMS4xPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQKY3B1MCBCU1A6 CiAgICAgSUQ6IDB4MDAwMDAwMDAgICBWRVI6IDB4ODAwNTAwMTAgTERSOiAweDAwMDAwMDAw IERGUjogMHhmZmZmZmZmZgogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAw IFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAxMDBlZiB0 aGVybTogMHgwMDAxMDAwMCBlcnI6IDB4MDAwMTAwMGYgcGNtOiAweDAwMDEwMDAwCmF0aF9y YXRlOiB2ZXJzaW9uIDEuMiA8U2FtcGxlUmF0ZSBiaXQtcmF0ZSBzZWxlY3Rpb24gYWxnb3Jp dGhtPgp3bGFuX2FtcnI6IDxBTVJSIFRyYW5zbWl0IFJhdGUgQ29udHJvbCBBbGdvcml0aG0+ CndsYW46IDw4MDIuMTEgTGluayBMYXllcj4KbnVsbDogPG51bGwgZGV2aWNlLCB6ZXJvIGRl dmljZT4KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJlLCBZYXJyb3c+Cm5mc2xv Y2s6IHBzZXVkby1kZXZpY2UKa2JkOiBuZXcgYXJyYXkgc2l6ZSA0CmtiZDEgYXQga2JkbXV4 MAptZW06IDxtZW1vcnk+CmlvOiA8SS9PPgphdGhfaGFsOiAwLjkuMjAuMyAoQVI1MjEwLCBB UjUyMTEsIEFSNTIxMiwgUkY1MTExLCBSRjUxMTIsIFJGMjQxMywgUkY1NDEzKQpocHRycjog Um9ja2V0UkFJRCAxN3h4LzJ4eHggU0FUQSBjb250cm9sbGVyIGRyaXZlciB2MS4yIChKYW4g IDEgMjAwOSAwODo1NzoyNCkKYWNwaTA6IDxIUCBQcm9MaWFudD4gb24gbW90aGVyYm9hcmQK aW9hcGljMDogcm91dGluZyBpbnRwaW4gOSAoSVNBIElSUSA5KSB0byB2ZWN0b3IgNDgKYWNw aTA6IFtNUFNBRkVdCmFjcGkwOiBbSVRIUkVBRF0KYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4 ZWQpCkFjcGlPc0Rlcml2ZVBjaUlkOiBcXF9TQl8uUENJMC5TQlJHLlBJTUMgLT4gYnVzIDAg ZGV2IDEgZnVuYyAwCmFjcGkwOiByZXNlcnZhdGlvbiBvZiBmZWMwMDAwMCwgMTAwMCAoMykg ZmFpbGVkCmFjcGkwOiByZXNlcnZhdGlvbiBvZiBmZWUwMDAwMCwgMTAwMCAoMykgZmFpbGVk CkFDUEkgdGltZXI6IDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAxLzEgMS8xIDEvMSAt PiAxMApUaW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFs aXR5IDEwMDAKYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBv cnQgMHgyMDA4LTB4MjAwYiBvbiBhY3BpMApwY2lfbGluazA6ICAgICAgICBJbmRleCAgSVJR ICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAg MCAgMTYgMTcgMTggMTkKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAg IDE2IDE3IDE4IDE5CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAx NiAxNyAxOCAxOQpwY2lfbGluazE6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR cwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkK ICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CiAg QWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAxNiAxNyAxOCAxOQpwY2lf bGluazI6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJv YmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKICBWYWxpZGF0aW9uICAg ICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICAxNiAxNyAxOCAxOQpwY2lfbGluazM6ICAgICAgICBJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1 ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDE2IDE3IDE4IDE5CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBO ICAgICAwICAxNiAxNyAxOCAxOQpwY2lfbGluazQ6ICAgICAgICBJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA3ICAgTiAgICAgMCAgMTYg MTcgMTggMTkKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3 IDE4IDE5CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAxNiAxNyAx OCAxOQpwY2lfbGluazU6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIElu aXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMTYgMTcgMTggMTkKICBWYWxp ZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CiAgQWZ0ZXIg RGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAxNiAxNyAxOCAxOQpwY2lfbGluazY6 ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAg ICAgMCAgIDEwICAgTiAgICAgMCAgMTYgMTcgMTggMTkKICBWYWxpZGF0aW9uICAgICAgICAg IDAgIDI1NSAgIE4gICAgIDAgIDE2IDE3IDE4IDE5CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAw ICAyNTUgICBOICAgICAwICAxNiAxNyAxOCAxOQpwY2lfbGluazc6ICAgICAgICBJbmRleCAg SVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDEwICAgTiAg ICAgMCAgMTYgMTcgMTggMTkKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDE2IDE3IDE4IDE5CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAw ICAxNiAxNyAxOCAxOQpwY2lfbGluazg6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA1ICAgTiAgICAgMCAgMjEgMjIgMjMK ICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxIDIyIDIzCiAgQWZ0 ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMSAyMiAyMwpwY2lfbGluazk6 ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMjAKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAg IE4gICAgIDAgIDIwCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAy MApwY2lfbGluazEwOiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRp YWwgUHJvYmUgICAgICAgMCAgICA1ICAgTiAgICAgMCAgMjEgMjIgMjMKICBWYWxpZGF0aW9u ICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxIDIyIDIzCiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICAyMSAyMiAyMwpwY2lfbGluazExOiAgICAgICBJbmRl eCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMjAKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIw CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMApwY2lfbGluazEy OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAg ICAgMCAgMjU1ICAgTiAgICAgMCAgMjEgMjIgMjMKICBWYWxpZGF0aW9uICAgICAgICAgIDAg IDI1NSAgIE4gICAgIDAgIDIxIDIyIDIzCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUg ICBOICAgICAwICAyMSAyMiAyMwpwY2lfbGluazEzOiAgICAgICBJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMjEg MjIgMjMKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxIDIyIDIz CiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMSAyMiAyMwpwY2lf bGluazE0OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJv YmUgICAgICAgMCAgICA3ICAgTiAgICAgMCAgMjEgMjIgMjMKICBWYWxpZGF0aW9uICAgICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxIDIyIDIzCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAw ICAyNTUgICBOICAgICAwICAyMSAyMiAyMwpwY2lfbGluazE1OiAgICAgICBJbmRleCAgSVJR ICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgIDEwICAgTiAgICAg MCAgMjEgMjIgMjMKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIx IDIyIDIzCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMSAyMiAy MwpwY2lfbGluazE2OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRp YWwgUHJvYmUgICAgICAgMCAgIDExICAgTiAgICAgMCAgMjEgMjIgMjMKICBWYWxpZGF0aW9u ICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxIDIyIDIzCiAgQWZ0ZXIgRGlzYWJsZSAg ICAgICAwICAyNTUgICBOICAgICAwICAyMSAyMiAyMwpwY2lfbGluazE3OiAgICAgICBJbmRl eCAgSVJRICBSdGQgIFJlZiAgSVJRcwogIEluaXRpYWwgUHJvYmUgICAgICAgMCAgMjU1ICAg TiAgICAgMCAgMjEgMjIgMjMKICBWYWxpZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAg IDAgIDIxIDIyIDIzCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAy MSAyMiAyMwpwY2lfbGluazE4OiAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwog IEluaXRpYWwgUHJvYmUgICAgICAgMCAgICA3ICAgTiAgICAgMCAgMjEgMjIgMjMKICBWYWxp ZGF0aW9uICAgICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDIxIDIyIDIzCiAgQWZ0ZXIgRGlz YWJsZSAgICAgICAwICAyNTUgICBOICAgICAwICAyMSAyMiAyMwphY3BpX2hwZXQwOiA8SGln aCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4ZmVkMDAwMDAtMHhmZWQwMDNmZiBv biBhY3BpMAphY3BpX2hwZXQwOiB2ZW5kOiAweDEwZGUgcmV2OiAweDEgbnVtOiAyIGh6OiAy NTAwMDAwMCBvcHRzOiBsZWdhY3lfcm91dGUKVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1ZW5j eSAyNTAwMDAwMCBIeiBxdWFsaXR5IDkwMApwY2liMDogPEFDUEkgSG9zdC1QQ0kgYnJpZGdl PiBwb3J0IDB4Y2Y4LTB4Y2ZmIG9uIGFjcGkwCnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBj aWIwCnBjaTA6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MApmb3VuZC0+CXZlbmRvcj0weDEw ZGUsIGRldj0weDAzNjksIHJldmlkPTB4YTIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0wLCBm dW5jPTAKCWNsYXNzPTA1LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0w eDAxMDYsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9 MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZv dW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDM2MCwgcmV2aWQ9MHhhMwoJZG9tYWluPTAs IGJ1cz0wLCBzbG90PTEsIGZ1bmM9MAoJY2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MQoJY21kcmVnPTB4MDAwZiwgc3RhdHJlZz0weDAwYTAsIGNhY2hlbG5zej0wIChk d29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhs YXQ9MHgwMCAoMCBucykKCW1hcFsxMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNl IDB4MmYwMCwgc2l6ZSAgNywgZW5hYmxlZApmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0w eDAzNjgsIHJldmlkPTB4YTMKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xLCBmdW5jPTEKCWNs YXNzPTBjLTA1LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDEsIHN0 YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwg aXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsx MF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4MjkwMCwgc2l6ZSAgNiwgZW5h YmxlZAoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHgyZDAwLCBz aXplICA2LCBlbmFibGVkCgltYXBbMjRdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFz ZSAweDJlMDAsIHNpemUgIDYsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAu MS5JTlRBIChzcmMgXFxfU0JfLkxTTUI6MCkKcGNpX2xpbmsxMzogUGlja2VkIElSUSAyMSB3 aXRoIHdlaWdodCAwCnBjaWIwOiBzbG90IDEgSU5UQSByb3V0ZWQgdG8gaXJxIDIxIHZpYSBc XF9TQl8uTFNNQgpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAzNmMsIHJldmlkPTB4 YTEKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yLCBmdW5jPTAKCWNsYXNzPTBjLTAzLTEwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAz ICg3NTAgbnMpLCBtYXhsYXQ9MHgwMSAoMjUwIG5zKQoJaW50cGluPWEsIGlycT01Cglwb3dl cnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5 cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZjZWJmMDAwLCBzaXplIDEyLCBlbmFibGVk CnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjIuSU5UQSAoc3JjIFxcX1NCXy5MVUIwOjAp CnBjaV9saW5rODogUGlja2VkIElSUSAyMiB3aXRoIHdlaWdodCAwCnBjaWIwOiBzbG90IDIg SU5UQSByb3V0ZWQgdG8gaXJxIDIyIHZpYSBcXF9TQl8uTFVCMApmb3VuZC0+CXZlbmRvcj0w eDEwZGUsIGRldj0weDAzNmQsIHJldmlkPTB4YTIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0y LCBmdW5jPTEKCWNsYXNzPTBjLTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJl Zz0weDAwMDYsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMSAoMjUw IG5zKQoJaW50cGluPWIsIGlycT01Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIg RDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAw eGZjZWJlYzAwLCBzaXplICA4LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAw LjIuSU5UQiAoc3JjIFxcX1NCXy5MVUIyOjApCnBjaV9saW5rMTA6IFBpY2tlZCBJUlEgMjMg d2l0aCB3ZWlnaHQgMApwY2liMDogc2xvdCAyIElOVEIgcm91dGVkIHRvIGlycSAyMyB2aWEg XFxfU0JfLkxVQjIKZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMzdmLCByZXZpZD0w eGEzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9NSwgZnVuYz0wCgljbGFzcz0wMS0wMS04NSwg aGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDBiMCwg Y2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgw MyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBv d2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDQg bWVzc2FnZXMsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJh c2UgMHhkZDgwLCBzaXplICAzLCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0LCBy YW5nZSAzMiwgYmFzZSAweGRkMDAsIHNpemUgIDIsIGVuYWJsZWQKCW1hcFsxOF06IHR5cGUg SS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZGMwMCwgc2l6ZSAgMywgZW5hYmxlZAoJbWFw WzFjXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhkYjgwLCBzaXplICAyLCBl bmFibGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGRiMDAs IHNpemUgIDQsIGVuYWJsZWQKCW1hcFsyNF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFz ZSAweGZjZWJkMDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjUuSU5UQSAoc3JjIFxcX1NCXy5MU0EwOjApCnBjaV9saW5rMTU6IFBpY2tlZCBJUlEg MjEgd2l0aCB3ZWlnaHQgMQpwY2liMDogc2xvdCA1IElOVEEgcm91dGVkIHRvIGlycSAyMSB2 aWEgXFxfU0JfLkxTQTAKZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMzdmLCByZXZp ZD0weGEzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9NSwgZnVuYz0xCgljbGFzcz0wMS0wMS04 NSwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDBi MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykKCWludHBpbj1iLCBpcnE9MTEK CXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRz IDQgbWVzc2FnZXMsIDY0IGJpdAoJbWFwWzEwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIs IGJhc2UgMHhkYTgwLCBzaXplICAzLCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIEkvTyBQb3J0 LCByYW5nZSAzMiwgYmFzZSAweGRhMDAsIHNpemUgIDIsIGVuYWJsZWQKCW1hcFsxOF06IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZDk4MCwgc2l6ZSAgMywgZW5hYmxlZAoJ bWFwWzFjXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhkOTAwLCBzaXplICAy LCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGQ4 ODAsIHNpemUgIDQsIGVuYWJsZWQKCW1hcFsyNF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwg YmFzZSAweGZjZWJjMDAwLCBzaXplIDEyLCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5 IGZvciAwLjUuSU5UQiAoc3JjIFxcX1NCXy5MU0ExOjApCnBjaV9saW5rMTY6IFBpY2tlZCBJ UlEgMjIgd2l0aCB3ZWlnaHQgMQpwY2liMDogc2xvdCA1IElOVEIgcm91dGVkIHRvIGlycSAy MiB2aWEgXFxfU0JfLkxTQTEKZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMzdmLCBy ZXZpZD0weGEzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9NSwgZnVuYz0yCgljbGFzcz0wMS0w MS04NSwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4 MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5n bnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykKCWludHBpbj1jLCBpcnE9 NwoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9y dHMgNCBtZXNzYWdlcywgNjQgYml0CgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAz MiwgYmFzZSAweGQ4MDAsIHNpemUgIDMsIGVuYWJsZWQKCW1hcFsxNF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4ZDc4MCwgc2l6ZSAgMiwgZW5hYmxlZAoJbWFwWzE4XTog dHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhkNzAwLCBzaXplICAzLCBlbmFibGVk CgltYXBbMWNdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGQ2ODAsIHNpemUg IDIsIGVuYWJsZWQKCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4 ZDYwMCwgc2l6ZSAgNCwgZW5hYmxlZAoJbWFwWzI0XTogdHlwZSBNZW1vcnksIHJhbmdlIDMy LCBiYXNlIDB4ZmNlYmIwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50 cnkgZm9yIDAuNS5JTlRDIChzcmMgXFxfU0JfLkxTQTI6MCkKcGNpX2xpbmsxODogUGlja2Vk IElSUSAyMyB3aXRoIHdlaWdodCAxCnBjaWIwOiBzbG90IDUgSU5UQyByb3V0ZWQgdG8gaXJx IDIzIHZpYSBcXF9TQl8uTFNBMgpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAzNzAs IHJldmlkPTB4YTIKCWRvbWFpbj0wLCBidXM9MCwgc2xvdD02LCBmdW5jPTAKCWNsYXNzPTA2 LTA0LTAxLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDQsIHN0YXRyZWc9 MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAyICg1MDAgbnMpLCBtYXhsYXQ9MHgwMiAoNTAwIG5zKQpmb3VuZC0+CXZlbmRv cj0weDEwZGUsIGRldj0weDAzNzYsIHJldmlkPTB4YTMKCWRvbWFpbj0wLCBidXM9MCwgc2xv dD0xMCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wCglj bWRyZWc9MHgwMDA0LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDIgKDUwMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kg c3VwcG9ydHMgMiBtZXNzYWdlcywgNjQgYml0CmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2 PTB4MDM3NCwgcmV2aWQ9MHhhMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTExLCBmdW5jPTAK CWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDQs IHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMiAoNTAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglwb3dl cnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAyIG1l c3NhZ2VzLCA2NCBiaXQKZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMzc0LCByZXZp ZD0weGEzCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MTIsIGZ1bmM9MAoJY2xhc3M9MDYtMDQt MDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAw MTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu dD0weDAyICg1MDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJp dApmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAzNzgsIHJldmlkPTB4YTMKCWRvbWFp bj0wLCBidXM9MCwgc2xvdD0xMywgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0w eDAxLCBtZmRldj0wCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6 PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MWEgKDY1MDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAg Y3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIDY0IGJpdApmb3VuZC0+CXZl bmRvcj0weDEwZGUsIGRldj0weDAzNzUsIHJldmlkPTB4YTMKCWRvbWFpbj0wLCBidXM9MCwg c2xvdD0xNCwgZnVuYz0wCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0w CgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMp CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDIgKDUwMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglN U0kgc3VwcG9ydHMgMiBtZXNzYWdlcywgNjQgYml0CmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwg ZGV2PTB4MDM3NywgcmV2aWQ9MHhhMwoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTE1LCBmdW5j PTAKCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTAKCWNtZHJlZz0weDAw MDQsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMiAoNTAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglw b3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCU1TSSBzdXBwb3J0cyAy IG1lc3NhZ2VzLCA2NCBiaXQKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMjAwLCBy ZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MAoJY2xhc3M9MDYt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0w eDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgx MDIyLCBkZXY9MHgxMjAxLCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQs IGZ1bmM9MQoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVn PTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK Zm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMjAyLCByZXZpZD0weDAwCglkb21haW49 MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MgoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0w IChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMjAzLCBy ZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MwoJY2xhc3M9MDYt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0w eDAwMTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgx MDIyLCBkZXY9MHgxMjA0LCByZXZpZD0weDAwCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjQs IGZ1bmM9NAoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVn PTB4MDAwMCwgc3RhdHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykK cGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMC4wIChubyBkcml2ZXIgYXR0YWNoZWQp CmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IHBvcnQgMHgyZjAwLTB4MmY3ZiBhdCBkZXZpY2Ug MS4wIG9uIHBjaTAKaXNhMDogPElTQSBidXM+IG9uIGlzYWIwCnBjaTA6IDxzZXJpYWwgYnVz LCBTTUJ1cz4gYXQgZGV2aWNlIDEuMSAobm8gZHJpdmVyIGF0dGFjaGVkKQpvaGNpMDogPE9I Q0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBtZW0gMHhmY2ViZjAwMC0weGZjZWJmZmZm IGlycSAyMiBhdCBkZXZpY2UgMi4wIG9uIHBjaTAKb2hjaTA6IFJlc2VydmVkIDB4MTAwMCBi eXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmNlYmYwMDAKaW9hcGljMDogcm91dGlu ZyBpbnRwaW4gMjIgKFBDSSBJUlEgMjIpIHRvIHZlY3RvciA0OQpvaGNpMDogW0dJQU5ULUxP Q0tFRF0Kb2hjaTA6IFtJVEhSRUFEXQp1c2IwOiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kg c3VwcG9ydAp1c2IwOiBTTU0gZG9lcyBub3QgcmVzcG9uZCwgcmVzZXR0aW5nCnVzYjA6IDxP SENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gb2hjaTAKdXNiMDogVVNCIHJldmlz aW9uIDEuMAp1aHViMDogPG5WaWRpYSBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMAp1aHViMDogMTAgcG9ydHMgd2l0aCAxMCByZW1v dmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMDogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29u dHJvbGxlcj4gbWVtIDB4ZmNlYmVjMDAtMHhmY2ViZWNmZiBpcnEgMjMgYXQgZGV2aWNlIDIu MSBvbiBwY2kwCmVoY2kwOiBSZXNlcnZlZCAweDEwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlw ZSAzIGF0IDB4ZmNlYmVjMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMjMgKFBDSSBJUlEg MjMpIHRvIHZlY3RvciA1MAplaGNpMDogW0dJQU5ULUxPQ0tFRF0KZWhjaTA6IFtJVEhSRUFE XQp1c2IxOiBFSENJIHZlcnNpb24gMS4wCnVzYjE6IGNvbXBhbmlvbiBjb250cm9sbGVyLCAx MCBwb3J0cyBlYWNoOiB1c2IwCnVzYjE6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRy b2xsZXI+IG9uIGVoY2kwCnVzYjE6IFVTQiByZXZpc2lvbiAyLjAKdWh1YjE6IDxuVmlkaWEg RUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVz YjEKdWh1YjE6IDEwIHBvcnRzIHdpdGggMTAgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKYXRh cGNpMDogPG5WaWRpYSBuRm9yY2UgTUNQNTUgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4 ZGQ4MC0weGRkODcsMHhkZDAwLTB4ZGQwMywweGRjMDAtMHhkYzA3LDB4ZGI4MC0weGRiODMs MHhkYjAwLTB4ZGIwZiBtZW0gMHhmY2ViZDAwMC0weGZjZWJkZmZmIGlycSAyMSBhdCBkZXZp Y2UgNS4wIG9uIHBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4 MjAgdHlwZSA0IGF0IDB4ZGIwMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAyMSAoUENJIElS USAyMSkgdG8gdmVjdG9yIDUxCmF0YXBjaTA6IFtNUFNBRkVdCmF0YXBjaTA6IFtJVEhSRUFE XQphdGFwY2kwOiBSZXNlcnZlZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDI0IHR5cGUgMyBh dCAweGZjZWJkMDAwCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwCmF0YXBjaTA6 IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4ZGQ4MAphdGFw Y2kwOiBSZXNlcnZlZCAweDQgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweGRkMDAK YXRhMjogU0FUQSBjb25uZWN0IHRpbWU9MG1zCmF0YTI6IHJlc2V0IHRwMSBtYXNrPTAxIG9z dGF0MD01MCBvc3RhdDE9MDAKYXRhMjogc3RhdDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBt c2I9MHgwMAphdGEyOiByZXNldCB0cDIgc3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDE8 QVRBX01BU1RFUj4KYXRhMjogW01QU0FGRV0KYXRhMjogW0lUSFJFQURdCmF0YTM6IDxBVEEg Y2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YXBjaTA6IFJlc2VydmVkIDB4OCBieXRlcyBmb3Ig cmlkIDB4MTggdHlwZSA0IGF0IDB4ZGMwMAphdGFwY2kwOiBSZXNlcnZlZCAweDQgYnl0ZXMg Zm9yIHJpZCAweDFjIHR5cGUgNCBhdCAweGRiODAKYXRhMzogU0FUQSBjb25uZWN0IHRpbWU9 MG1zCmF0YTM6IHJlc2V0IHRwMSBtYXNrPTAxIG9zdGF0MD01MCBvc3RhdDE9MDAKYXRhMzog c3RhdDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMAphdGEzOiByZXNldCB0cDIg c3RhdDA9NTAgc3RhdDE9MDAgZGV2aWNlcz0weDE8QVRBX01BU1RFUj4KYXRhMzogW01QU0FG RV0KYXRhMzogW0lUSFJFQURdCmF0YXBjaTE6IDxuVmlkaWEgbkZvcmNlIE1DUDU1IFNBVEEz MDAgY29udHJvbGxlcj4gcG9ydCAweGRhODAtMHhkYTg3LDB4ZGEwMC0weGRhMDMsMHhkOTgw LTB4ZDk4NywweGQ5MDAtMHhkOTAzLDB4ZDg4MC0weGQ4OGYgbWVtIDB4ZmNlYmMwMDAtMHhm Y2ViY2ZmZiBpcnEgMjIgYXQgZGV2aWNlIDUuMSBvbiBwY2kwCmF0YXBjaTE6IFJlc2VydmVk IDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGQ4ODAKYXRhcGNpMTogW01Q U0FGRV0KYXRhcGNpMTogW0lUSFJFQURdCmF0YXBjaTE6IFJlc2VydmVkIDB4MTAwMCBieXRl cyBmb3IgcmlkIDB4MjQgdHlwZSAzIGF0IDB4ZmNlYmMwMDAKYXRhNDogPEFUQSBjaGFubmVs IDA+IG9uIGF0YXBjaTEKYXRhcGNpMTogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgx MCB0eXBlIDQgYXQgMHhkYTgwCmF0YXBjaTE6IFJlc2VydmVkIDB4NCBieXRlcyBmb3Igcmlk IDB4MTQgdHlwZSA0IGF0IDB4ZGEwMAphdGE0OiBTQVRBIGNvbm5lY3QgdGltZT0wbXMKYXRh NDogcmVzZXQgdHAxIG1hc2s9MDEgb3N0YXQwPTUwIG9zdGF0MT0wMAphdGE0OiBzdGF0MD0w eDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0weDAwCmF0YTQ6IHJlc2V0IHRwMiBzdGF0MD01 MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxBVEFfTUFTVEVSPgphdGE0OiBbTVBTQUZFXQphdGE0 OiBbSVRIUkVBRF0KYXRhNTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTEKYXRhcGNpMTog UmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHhkOTgwCmF0YXBj aTE6IFJlc2VydmVkIDB4NCBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4ZDkwMAph dGE1OiBTQVRBIGNvbm5lY3QgdGltZT0wbXMKYXRhNTogcmVzZXQgdHAxIG1hc2s9MDEgb3N0 YXQwPTUwIG9zdGF0MT0wMAphdGE1OiBzdGF0MD0weDUwIGVycj0weDAxIGxzYj0weDAwIG1z Yj0weDAwCmF0YTU6IHJlc2V0IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxB VEFfTUFTVEVSPgphdGE1OiBbTVBTQUZFXQphdGE1OiBbSVRIUkVBRF0KYXRhcGNpMjogPG5W aWRpYSBuRm9yY2UgTUNQNTUgU0FUQTMwMCBjb250cm9sbGVyPiBwb3J0IDB4ZDgwMC0weGQ4 MDcsMHhkNzgwLTB4ZDc4MywweGQ3MDAtMHhkNzA3LDB4ZDY4MC0weGQ2ODMsMHhkNjAwLTB4 ZDYwZiBtZW0gMHhmY2ViYjAwMC0weGZjZWJiZmZmIGlycSAyMyBhdCBkZXZpY2UgNS4yIG9u IHBjaTAKYXRhcGNpMjogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0 IGF0IDB4ZDYwMAphdGFwY2kyOiBbTVBTQUZFXQphdGFwY2kyOiBbSVRIUkVBRF0KYXRhcGNp MjogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgyNCB0eXBlIDMgYXQgMHhmY2Vi YjAwMAphdGE2OiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMgphdGFwY2kyOiBSZXNlcnZl ZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweGQ4MDAKYXRhcGNpMjogUmVz ZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHhkNzgwCmF0YTY6IFNB VEEgY29ubmVjdCB0aW1lPTBtcwphdGE2OiByZXNldCB0cDEgbWFzaz0wMSBvc3RhdDA9NTAg b3N0YXQxPTAwCmF0YTY6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAK YXRhNjogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAwIGRldmljZXM9MHgxPEFUQV9NQVNU RVI+CmF0YTY6IFtNUFNBRkVdCmF0YTY6IFtJVEhSRUFEXQphdGE3OiA8QVRBIGNoYW5uZWwg MT4gb24gYXRhcGNpMgphdGFwY2kyOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4 IHR5cGUgNCBhdCAweGQ3MDAKYXRhcGNpMjogUmVzZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQg MHgxYyB0eXBlIDQgYXQgMHhkNjgwCmF0YTc6IFNBVEEgY29ubmVjdCB0aW1lPTBtcwphdGE3 OiByZXNldCB0cDEgbWFzaz0wMSBvc3RhdDA9NTAgb3N0YXQxPTAwCmF0YTc6IHN0YXQwPTB4 MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIKYXRhNzogcmVzZXQgdHAyIHN0YXQwPTAw IHN0YXQxPTAwIGRldmljZXM9MHg0PEFUQVBJX01BU1RFUj4KYXRhNzogW01QU0FGRV0KYXRh NzogW0lUSFJFQURdCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDYu MCBvbiBwY2kwCnBjaWIxOiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjE6ICAgc2Vjb25k YXJ5IGJ1cyAgICAgMQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMgICAxCnBjaWIxOiAgIEkv TyBkZWNvZGUgICAgICAgIDB4MC0weDAKcGNpYjE6ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUK cGNpYjE6ICAgU3VidHJhY3RpdmVseSBkZWNvZGVkIGJyaWRnZS4KcGNpMTogPEFDUEkgUENJ IGJ1cz4gb24gcGNpYjEKcGNpMTogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0xCnBjaWIyOiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDEwLjAgb24gcGNpMApwY2liMjogICBk b21haW4gICAgICAgICAgICAwCnBjaWIyOiAgIHNlY29uZGFyeSBidXMgICAgIDIKcGNpYjI6 ICAgc3Vib3JkaW5hdGUgYnVzICAgMgpwY2liMjogICBJL08gZGVjb2RlICAgICAgICAweDAt MHgwCnBjaWIyOiAgIG5vIHByZWZldGNoZWQgZGVjb2RlCnBjaTI6IDxBQ1BJIFBDSSBidXM+ IG9uIHBjaWIyCnBjaTI6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MgpwY2liMzogPFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgMTEuMCBvbiBwY2kwCnBjaWIzOiAgIGRvbWFpbiAgICAg ICAgICAgIDAKcGNpYjM6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMwpwY2liMzogICBzdWJvcmRp bmF0ZSBidXMgICAzCnBjaWIzOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MC0weDAKcGNpYjM6 ICAgbm8gcHJlZmV0Y2hlZCBkZWNvZGUKcGNpMzogPFBDSSBidXM+IG9uIHBjaWIzCnBjaTM6 IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MwpwY2liNDogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGF0IGRldmljZSAxMi4wIG9uIHBjaTAKcGNpYjQ6ICAgZG9tYWluICAgICAgICAgICAgMApw Y2liNDogICBzZWNvbmRhcnkgYnVzICAgICA0CnBjaWI0OiAgIHN1Ym9yZGluYXRlIGJ1cyAg IDQKcGNpYjQ6ICAgSS9PIGRlY29kZSAgICAgICAgMHhlMDAwLTB4ZWZmZgpwY2liNDogICBt ZW1vcnkgZGVjb2RlICAgICAweGZjZjAwMDAwLTB4ZmNmZmZmZmYKcGNpYjQ6ICAgbm8gcHJl ZmV0Y2hlZCBkZWNvZGUKcGNpNDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjQKcGNpNDogZG9t YWluPTAsIHBoeXNpY2FsIGJ1cz00CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MTBi OSwgcmV2aWQ9MHgwNgoJZG9tYWluPTAsIGJ1cz00LCBzbG90PTAsIGZ1bmM9MAoJY2xhc3M9 MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDEwNywgc3RhdHJl Zz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJx PTcKCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBv cnRzIDEgbWVzc2FnZSwgNjQgYml0CgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIs IGJhc2UgMHhmY2ZlMDAwMCwgc2l6ZSAxNywgZW5hYmxlZApwY2liNDogcmVxdWVzdGVkIG1l bW9yeSByYW5nZSAweGZjZmUwMDAwLTB4ZmNmZmZmZmY6IGdvb2QKCW1hcFsxNF06IHR5cGUg TWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZjZmMwMDAwLCBzaXplIDE3LCBlbmFibGVkCnBj aWI0OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmNmYzAwMDAtMHhmY2ZkZmZmZjogZ29v ZAoJbWFwWzE4XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhlZjgwLCBzaXpl ICA1LCBlbmFibGVkCnBjaWI0OiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4ZWY4MC0weGVmOWY6 IGluIHJhbmdlCnBjaWI0OiBtYXRjaGVkIGVudHJ5IGZvciA0LjAuSU5UQSAoc3JjIFxcX1NC Xy5MTkVBOjApCnBjaV9saW5rNDogUGlja2VkIElSUSAxNiB3aXRoIHdlaWdodCAwCnBjaWI0 OiBzbG90IDAgSU5UQSByb3V0ZWQgdG8gaXJxIDE2IHZpYSBcXF9TQl8uTE5FQQplbTA6IDxJ bnRlbChSKSBQUk8vMTAwMCBOZXR3b3JrIENvbm5lY3Rpb24gNi45LjY+IHBvcnQgMHhlZjgw LTB4ZWY5ZiBtZW0gMHhmY2ZlMDAwMC0weGZjZmZmZmZmLDB4ZmNmYzAwMDAtMHhmY2ZkZmZm ZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2k0CmVtMDogUmVzZXJ2ZWQgMHgyMDAwMCBi eXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmNmZTAwMDAKZW0wOiBhdHRlbXB0aW5n IHRvIGFsbG9jYXRlIDEgTVNJIHZlY3RvcnMgKDEgc3VwcG9ydGVkKQptc2k6IHJvdXRpbmcg TVNJIElSUSAyNTYgdG8gdmVjdG9yIDUyCmVtMDogdXNpbmcgSVJRIDI1NiBmb3IgTVNJCmVt MDogVXNpbmcgTVNJIGludGVycnVwdAplbTA6IFtGSUxURVJdCmVtMDogYnBmIGF0dGFjaGVk CmVtMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjM6N2Q6ZmQ6MjY6ZTQKcGNpYjU6IDxBQ1BJ IFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMTMuMCBvbiBwY2kwCnBjaWI1OiAgIGRvbWFp biAgICAgICAgICAgIDAKcGNpYjU6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMTYKcGNpYjU6ICAg c3Vib3JkaW5hdGUgYnVzICAgMTYKcGNpYjU6ICAgSS9PIGRlY29kZSAgICAgICAgMHhmMDAw LTB4ZmZmCnBjaWI1OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmQwMDAwMDAtMHhmZGVmZmZm ZgpwY2liNTogICBwcmVmZXRjaGVkIGRlY29kZSAweGZiMDAwMDAwLTB4ZmJmZmZmZmYKcGNp MTY6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI1CnBjaTE2OiBkb21haW49MCwgcGh5c2ljYWwg YnVzPTE2CmZvdW5kLT4JdmVuZG9yPTB4MTAyYiwgZGV2PTB4MDUyMiwgcmV2aWQ9MHgwMgoJ ZG9tYWluPTAsIGJ1cz0xNiwgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgxMDEwLCBjYWNo ZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAo MCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdl CgltYXBbMTBdOiB0eXBlIFByZWZldGNoYWJsZSBNZW1vcnksIHJhbmdlIDMyLCBiYXNlIDB4 ZmIwMDAwMDAsIHNpemUgMjQsIGVuYWJsZWQKcGNpYjU6IHJlcXVlc3RlZCBtZW1vcnkgcmFu Z2UgMHhmYjAwMDAwMC0weGZiZmZmZmZmOiBnb29kCgltYXBbMTRdOiB0eXBlIE1lbW9yeSwg cmFuZ2UgMzIsIGJhc2UgMHhmZGVmYzAwMCwgc2l6ZSAxNCwgZW5hYmxlZApwY2liNTogcmVx dWVzdGVkIG1lbW9yeSByYW5nZSAweGZkZWZjMDAwLTB4ZmRlZmZmZmY6IGdvb2QKCW1hcFsx OF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZkMDAwMDAwLCBzaXplIDIzLCBl bmFibGVkCnBjaWI1OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmQwMDAwMDAtMHhmZDdm ZmZmZjogZ29vZApwY2liNTogbWF0Y2hlZCBlbnRyeSBmb3IgMTYuMC5JTlRBIChzcmMgXFxf U0JfLkxORUQ6MCkKcGNpX2xpbms3OiBQaWNrZWQgSVJRIDE3IHdpdGggd2VpZ2h0IDAKcGNp YjU6IHNsb3QgMCBJTlRBIHJvdXRlZCB0byBpcnEgMTcgdmlhIFxcX1NCXy5MTkVECnZnYXBj aTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBtZW0gMHhmYjAwMDAwMC0weGZiZmZmZmZm LDB4ZmRlZmMwMDAtMHhmZGVmZmZmZiwweGZkMDAwMDAwLTB4ZmQ3ZmZmZmYgaXJxIDE3IGF0 IGRldmljZSAwLjAgb24gcGNpMTYKcGNpYjY6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMTQuMCBvbiBwY2kwCnBjaWI2OiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjY6 ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMTcKcGNpYjY6ICAgc3Vib3JkaW5hdGUgYnVzICAgMTcK cGNpYjY6ICAgSS9PIGRlY29kZSAgICAgICAgMHgwLTB4MApwY2liNjogICBtZW1vcnkgZGVj b2RlICAgICAweGZkZjAwMDAwLTB4ZmRmZmZmZmYKcGNpYjY6ICAgbm8gcHJlZmV0Y2hlZCBk ZWNvZGUKcGNpMTc6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWI2CnBjaTE3OiBkb21haW49MCwg cGh5c2ljYWwgYnVzPTE3CmZvdW5kLT4JdmVuZG9yPTB4MTRlNCwgZGV2PTB4MTY1YSwgcmV2 aWQ9MHgwMAoJZG9tYWluPTAsIGJ1cz0xNywgc2xvdD0wLCBmdW5jPTAKCWNsYXNzPTAyLTAw LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgw MDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5n bnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQoJaW50cGluPWEsIGlycT0xMAoJ cG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9ydHMg MSBtZXNzYWdlLCA2NCBiaXQKCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSA2NCwgYmFz ZSAweGZkZmYwMDAwLCBzaXplIDE2LCBlbmFibGVkCnBjaWI2OiByZXF1ZXN0ZWQgbWVtb3J5 IHJhbmdlIDB4ZmRmZjAwMDAtMHhmZGZmZmZmZjogZ29vZApwY2liNjogbWF0Y2hlZCBlbnRy eSBmb3IgMTcuMC5JTlRBIChzcmMgXFxfU0JfLkxORUM6MCkKcGNpX2xpbms2OiBQaWNrZWQg SVJRIDE4IHdpdGggd2VpZ2h0IDAKcGNpYjY6IHNsb3QgMCBJTlRBIHJvdXRlZCB0byBpcnEg MTggdmlhIFxcX1NCXy5MTkVDCmJnZTA6IDxIUCBOQzEwNWkgUENJZSBHaWdhYml0IFNlcnZl ciBBZGFwdGVyLCBBU0lDIHJldi4gMHhhMjAwPiBtZW0gMHhmZGZmMDAwMC0weGZkZmZmZmZm IGlycSAxOCBhdCBkZXZpY2UgMC4wIG9uIHBjaTE3CmJnZTA6IFJlc2VydmVkIDB4MTAwMDAg Ynl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGZkZmYwMDAwCmJnZTA6IERpc2FibGlu ZyBmYXN0Ym9vdApiZ2UwOiBEaXNhYmxpbmcgZmFzdGJvb3QKbWlpYnVzMDogPE1JSSBidXM+ IG9uIGJnZTAKYnJncGh5MDogPEJDTTU3MjIgMTAvMTAwLzEwMDBiYXNlVFggUEhZPiBQSFkg MSBvbiBtaWlidXMwCmJyZ3BoeTA6IE9VSSAweDAwNTBlZiwgbW9kZWwgMHgwMDJkLCByZXYu IDAKYnJncGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VU WC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULUZEWCwgYXV0bwpiZ2UwOiBicGYgYXR0YWNo ZWQKYmdlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MjM6N2Q6ZGI6YjY6ZDgKaW9hcGljMDog cm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEgMTgpIHRvIHZlY3RvciA1MwpiZ2UwOiBbTVBT QUZFXQpiZ2UwOiBbSVRIUkVBRF0KcGNpYjc6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBk ZXZpY2UgMTUuMCBvbiBwY2kwCnBjaWI3OiAgIGRvbWFpbiAgICAgICAgICAgIDAKcGNpYjc6 ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMTgKcGNpYjc6ICAgc3Vib3JkaW5hdGUgYnVzICAgMTgK cGNpYjc6ICAgSS9PIGRlY29kZSAgICAgICAgMHgwLTB4MApwY2liNzogICBubyBwcmVmZXRj aGVkIGRlY29kZQpwY2kxODogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcKcGNpMTg6IGRvbWFp bj0wLCBwaHlzaWNhbCBidXM9MTgKYWNwaV9idXR0b24wOiA8UG93ZXIgQnV0dG9uPiBvbiBh Y3BpMApzaW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGly cXMgMApzaW8wOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8wOiBpcnEgbWFwczogMCAw IDAgMApzaW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGly cXMgMApzaW8wOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8wOiBpcnEgbWFwczogMCAw IDAgMApzaW8wOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IHBvcnQgMHgzZjgtMHgz ZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBhY3BpMApzaW8wOiB0eXBlIDE2NTUwQQppb2FwaWMw OiByb3V0aW5nIGludHBpbiA0IChJU0EgSVJRIDQpIHRvIHZlY3RvciA1NApzaW8wOiBbRklM VEVSXQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTA6IHN3aXRjaGluZyB0byBnZW5l cmljIEN4IG1vZGUKY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHUyOiA8QUNQSSBDUFU+ IG9uIGFjcGkwCmNwdTM6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXhfaXNhX2lkZW50aWZ5KCkK c2lvOiBzaW8wIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAphaGNfaXNhX3Byb2JlIDI6 IGlvcG9ydCAweDJjMDAgYWxsb2MgZmFpbGVkCmFoY19pc2FfcHJvYmUgMTM6IGlvcG9ydCAw eGRjMDAgYWxsb2MgZmFpbGVkCnNjOiBzYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0 CnZnYTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2NoaWxk cmVuOiBkaXNhYmxpbmcgUG5QIGRldmljZXMKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5n IG5vbi1QblAgZGV2aWNlcwpvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMw MDAwLTB4YzdmZmYsMHhjYTAwMC0weGNhZmZmIG9uIGlzYTAKYXRrYmRjMDogPEtleWJvYXJk IGNvbnRyb2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMAphdGtiZDA6 IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRrYmRjMAphdGtiZDogdGhlIGN1cnJlbnQga2Jk IGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAwODcKYXRrYmQ6IGtleWJvYXJkIElEIDB4ODNh YiAoMikKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRrYmQwLCBBVCAxMDEvMTAyICgyKSwgY29u ZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKaW9hcGljMDogcm91dGluZyBpbnRwaW4gMSAoSVNB IElSUSAxKSB0byB2ZWN0b3IgNTUKYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQphdGtiZDA6IFtJ VEhSRUFEXQpwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDg3CnBzbTA6IDxQUy8yIE1v dXNlPiBpcnEgMTIgb24gYXRrYmRjMAppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxMiAoSVNB IElSUSAxMikgdG8gdmVjdG9yIDU2CnBzbTA6IFtHSUFOVC1MT0NLRURdCnBzbTA6IFtJVEhS RUFEXQpwc20wOiBtb2RlbCBHbGlkZVBvaW50LCBkZXZpY2UgSUQgMC0wMCwgMyBidXR0b25z CnBzbTA6IGNvbmZpZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBzaXplOjMK cHNtMDogc3luY21hc2s6YzAsIHN5bmNiaXRzOjAwCmZkYzAgZmFpbGVkIHRvIHByb2JlIGF0 IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24gaXNhMApwcGMwOiBjYW5u b3QgcmVzZXJ2ZSBJL08gcG9ydCByYW5nZQpwcGMwOiA8UGFyYWxsZWwgcG9ydD4gZmFpbGVk IHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZs YWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29sZXMsIGZsYWdz PTB4MzAwPgpzYzA6IGZiMCwga2JkMSwgdGVybWluYWwgZW11bGF0b3I6IHNjIChzeXNjb25z IHRlcm1pbmFsKQpzaW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRtYXAgb2YgcHJv YmVkIGlycXMgMApzaW8xOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZApzaW8xOiBpcnEgbWFw czogMCAwIDAgMApzaW8xOiBwcm9iZSBmYWlsZWQgdGVzdChzKTogMCAxIDIgNCA2IDcgOQpz aW8xIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlzYTAK c2lvMjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzM6IG5vdCBwcm9iZWQgKGRpc2FibGVk KQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4 YTAwMDAtMHhiZmZmZiBvbiBpc2EwCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQblAg ZGV2aWNlcwp1a2JkMDogPFNlcnZlckVuZ2luZXMgU0UgVVNCIERldmljZSwgY2xhc3MgMC8w LCByZXYgMS4xMC8wLjAxLCBhZGRyIDI+IG9uIHVodWIwCmtiZDIgYXQgdWtiZDAKa2JkMjog dWtiZDAsIGdlbmVyaWMgKDApLCBjb25maWc6MHgwLCBmbGFnczoweDNkMDAwMAp1bXMwOiA8 U2VydmVyRW5naW5lcyBTRSBVU0IgRGV2aWNlLCBjbGFzcyAwLzAsIHJldiAxLjEwLzAuMDEs IGFkZHIgMj4gb24gdWh1YjAKdW1zMDogOCBidXR0b25zIGFuZCBaIGRpci4KRGV2aWNlIGNv bmZpZ3VyYXRpb24gZmluaXNoZWQuClJlZHVjaW5nIGtlcm4ubWF4dm5vZGVzIDIzNTYzNSAt PiAxMDAwMDAKcHJvY2ZzIHJlZ2lzdGVyZWQKbGFwaWM6IERpdmlzb3IgMiwgRnJlcXVlbmN5 IDEwMDAwMDcyOSBoegpUaW1lY291bnRlciAiVFNDIiBmcmVxdWVuY3kgMjEwMDAxNTE4NyBI eiBxdWFsaXR5IC0xMDAKVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpsbzA6 IGJwZiBhdHRhY2hlZApocHRycjogbm8gY29udHJvbGxlciBkZXRlY3RlZC4KYXRhMi1tYXN0 ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMTMzIGNhYmxlPTQwIHdpcmUKYWQ0 OiAxNDMwNzk5TUIgPFNlYWdhdGUgU1QzMTUwMDM0MUFTIENDMUg+IGF0IGF0YTItbWFzdGVy IFNBVEEzMDAKYWQ0OiAyOTMwMjc3MTY4IHNlY3RvcnMgWzI5MDcwMjFDLzE2SC82M1NdIDE2 IHNlY3RvcnMvaW50ZXJydXB0IDEgZGVwdGggcXVldWUKR0VPTTogbmV3IGRpc2sgYWQ0CmFk NDogblZpZGlhIGNoZWNrMSBmYWlsZWQKYWQ0OiBBZGFwdGVjIGNoZWNrMSBmYWlsZWQKYWQ0 OiBMU0kgKHYzKSBjaGVjazEgZmFpbGVkCmFkNDogTFNJICh2MikgY2hlY2sxIGZhaWxlZAph ZDQ6IEZyZWVCU0QgY2hlY2sxIGZhaWxlZAphdGEzLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1X RE1BMiB1ZG1hPVVETUExMzMgY2FibGU9NDAgd2lyZQphZDY6IDE0MzA3OTlNQiA8U2VhZ2F0 ZSBTVDMxNTAwMzQxQVMgQ0MxSD4gYXQgYXRhMy1tYXN0ZXIgU0FUQTMwMAphZDY6IDI5MzAy NzcxNjggc2VjdG9ycyBbMjkwNzAyMUMvMTZILzYzU10gMTYgc2VjdG9ycy9pbnRlcnJ1cHQg MSBkZXB0aCBxdWV1ZQpHRU9NOiBuZXcgZGlzayBhZDYKYWQ2OiBuVmlkaWEgY2hlY2sxIGZh aWxlZAphZDY6IEFkYXB0ZWMgY2hlY2sxIGZhaWxlZAphZDY6IExTSSAodjMpIGNoZWNrMSBm YWlsZWQKYWQ2OiBMU0kgKHYyKSBjaGVjazEgZmFpbGVkCmFkNjogRnJlZUJTRCBjaGVjazEg ZmFpbGVkCmF0YTQtbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEzMyBj YWJsZT00MCB3aXJlCmFkODogMTQzMDc5OU1CIDxTZWFnYXRlIFNUMzE1MDAzNDFBUyBDQzFI PiBhdCBhdGE0LW1hc3RlciBTQVRBMzAwCmFkODogMjkzMDI3NzE2OCBzZWN0b3JzIFsyOTA3 MDIxQy8xNkgvNjNTXSAxNiBzZWN0b3JzL2ludGVycnVwdCAxIGRlcHRoIHF1ZXVlCkdFT006 IG5ldyBkaXNrIGFkOAphZDg6IG5WaWRpYSBjaGVjazEgZmFpbGVkCmFkODogQWRhcHRlYyBj aGVjazEgZmFpbGVkCmFkODogTFNJICh2MykgY2hlY2sxIGZhaWxlZAphZDg6IExTSSAodjIp IGNoZWNrMSBmYWlsZWQKYWQ4OiBGcmVlQlNEIGNoZWNrMSBmYWlsZWQKYXRhNS1tYXN0ZXI6 IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMTMzIGNhYmxlPTQwIHdpcmUKYWQxMDog MTQzMDc5OU1CIDxTZWFnYXRlIFNUMzE1MDAzNDFBUyBDQzFIPiBhdCBhdGE1LW1hc3RlciBT QVRBMzAwCmFkMTA6IDI5MzAyNzcxNjggc2VjdG9ycyBbMjkwNzAyMUMvMTZILzYzU10gMTYg c2VjdG9ycy9pbnRlcnJ1cHQgMSBkZXB0aCBxdWV1ZQpHRU9NOiBuZXcgZGlzayBhZDEwCmFk MTA6IG5WaWRpYSBjaGVjazEgZmFpbGVkCmFkMTA6IEFkYXB0ZWMgY2hlY2sxIGZhaWxlZAph ZDEwOiBMU0kgKHYzKSBjaGVjazEgZmFpbGVkCmFkMTA6IExTSSAodjIpIGNoZWNrMSBmYWls ZWQKYWQxMDogRnJlZUJTRCBjaGVjazEgZmFpbGVkCmF0YTYtbWFzdGVyOiBwaW89UElPNCB3 ZG1hPVdETUEyIHVkbWE9VURNQTEzMyBjYWJsZT00MCB3aXJlCmFkMTI6IDIzODQ3NU1CIDxT ZWFnYXRlIFNUMzI1MDMxME5TIFNOMDY+IGF0IGF0YTYtbWFzdGVyIFNBVEExNTAKYWQxMjog NDg4Mzk3MTY4IHNlY3RvcnMgWzQ4NDUyMUMvMTZILzYzU10gMTYgc2VjdG9ycy9pbnRlcnJ1 cHQgMSBkZXB0aCBxdWV1ZQpHRU9NOiBuZXcgZGlzayBhZDEyCmFkMTI6IG5WaWRpYSBjaGVj azEgZmFpbGVkCmFkMTI6IEFkYXB0ZWMgY2hlY2sxIGZhaWxlZAphZDEyOiBMU0kgKHYzKSBj aGVjazEgZmFpbGVkCmFkMTI6IExTSSAodjIpIGNoZWNrMSBmYWlsZWQKYWQxMjogRnJlZUJT RCBjaGVjazEgZmFpbGVkCmF0YTctbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9 VURNQTEwMCBjYWJsZT00MCB3aXJlCmFjZDA6IDxUU1NUY29ycERWRC1ST00gVFMtSDM1M0Iv SUcwMT4gRFZEUk9NIGRyaXZlIGF0IGF0YTcgYXMgbWFzdGVyCmFjZDA6IHJlYWQgNjg5S0Iv cyAoODI2OEtCL3MpLCAxOThLQiBidWZmZXIsIFNBVEExNTAKYWNkMDogUmVhZHM6IENEUiwg Q0RSVywgQ0REQSBzdHJlYW0sIERWRFJPTSwgRFZEUiwgRFZEUkFNLCBwYWNrZXQKYWNkMDog V3JpdGVzOgphY2QwOiBBdWRpbzogcGxheSwgMjU1IHZvbHVtZSBsZXZlbHMKYWNkMDogTWVj aGFuaXNtOiBlamVjdGFibGUgdHJheSwgdW5sb2NrZWQKYWNkMDogTWVkaXVtOiBuby9ibGFu ayBkaXNjCkFUQSBQc2V1ZG9SQUlEIGxvYWRlZApTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEK Y3B1MiBBUDoKICAgICBJRDogMHgwMjAwMDAwMCAgIFZFUjogMHg4MDA1MDAxMCBMRFI6IDB4 MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmCiAgbGludDA6IDB4MDAwMTA3MDAgbGludDE6IDB4 MDAwMDA0MDAgVFBSOiAweDAwMDAwMDAwIFNWUjogMHgwMDAwMDFmZgogIHRpbWVyOiAweDAw MDIwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTAw MDAKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhCmNwdTMgQVA6CiAgICAgSUQ6IDB4MDMwMDAw MDAgICBWRVI6IDB4ODAwNTAwMTAgTERSOiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZgog IGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBT VlI6IDB4MDAwMDAxZmYKICB0aW1lcjogMHgwMDAyMDBlZiB0aGVybTogMHgwMDAxMDAwMCBl cnI6IDB4MDAwMTAwMDAgcGNtOiAweDAwMDEwMDAwClNNUDogQVAgQ1BVICMxIExhdW5jaGVk IQpjcHUxIEFQOgogICAgIElEOiAweDAxMDAwMDAwICAgVkVSOiAweDgwMDUwMDEwIExEUjog MHgwMDAwMDAwMCBERlI6IDB4ZmZmZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTog MHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4 MDAwMjAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAx MDAwMAppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElSUSAxIHRvIGxvY2FsIEFQSUMgMAppb2Fw aWMwOiBBc3NpZ25pbmcgSVNBIElSUSA0IHRvIGxvY2FsIEFQSUMgMQppb2FwaWMwOiBBc3Np Z25pbmcgSVNBIElSUSA5IHRvIGxvY2FsIEFQSUMgMgppb2FwaWMwOiBBc3NpZ25pbmcgSVNB IElSUSAxMiB0byBsb2NhbCBBUElDIDMKaW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEgMTgg dG8gbG9jYWwgQVBJQyAwCmlvYXBpYzA6IEFzc2lnbmluZyBQQ0kgSVJRIDIxIHRvIGxvY2Fs IEFQSUMgMQppb2FwaWMwOiBBc3NpZ25pbmcgUENJIElSUSAyMiB0byBsb2NhbCBBUElDIDIK aW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEgMjMgdG8gbG9jYWwgQVBJQyAzCm1zaTogQXNz aWduaW5nIE1TSSBJUlEgMjU2IHRvIGxvY2FsIEFQSUMgMApUcnlpbmcgdG8gbW91bnQgcm9v dCBmcm9tIHVmczovZGV2L2FkMTJzMWEKc3RhcnRfaW5pdDogdHJ5aW5nIC9zYmluL2luaXQK --------------090707070904060208060208-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 16:14: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 6876B106566B for ; Mon, 31 Aug 2009 16:14:00 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.193]) by mx1.freebsd.org (Postfix) with ESMTP id E623B8FC1B for ; Mon, 31 Aug 2009 16:13:59 +0000 (UTC) X-Envelope-To: freebsd-current@freebsd.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.3/8.14.3) with ESMTP id n7VGDtsO061703 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 31 Aug 2009 17:13:55 +0100 (IST) (envelope-from nick-lists@netability.ie) Message-ID: <4A9BF6C3.5080308@netability.ie> Date: Mon, 31 Aug 2009 17:13:55 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Florian Smeets References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im> In-Reply-To: <4A9BF438.1000006@smeets.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muffin.acquirer.com Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 16:14:00 -0000 On 31/08/2009 17:03, Florian Smeets wrote: > i386 version should recognize the disks. amd64 does when you set > hw.pci.mcfg=0 in loader.conf. ok, thanks for the pointers - i'll try the sysctl when i get a free moment. Any followups of mine to -amd64 are just going to be noise, so I'll just track those bugs and lurk on -amd64 until it's fixed. Nick From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 16:19: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 6F95010656AA; Mon, 31 Aug 2009 16:19:28 +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 838A48FC26; Mon, 31 Aug 2009 16:19:27 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA13517; Mon, 31 Aug 2009 19:19:26 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A9BF80D.3070106@icyb.net.ua> Date: Mon, 31 Aug 2009 19:19:25 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: Alexander Motin References: <4A97D0E1.6050001@icyb.net.ua> <4A97D32F.6070707@FreeBSD.org> <4A97D563.7010803@icyb.net.ua> <4A97DDC1.3030400@FreeBSD.org> In-Reply-To: <4A97DDC1.3030400@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: ada/ahci and smartmontools X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 16:19:28 -0000 on 28/08/2009 16:38 Alexander Motin said the following: > Andriy Gapon wrote: >> on 28/08/2009 15:53 Alexander Motin said the following: >>> Andriy Gapon wrote: >>>> Do smartmontools work with ada/ahci disks? >>>> Any tweaks/hacks to make it possible? >>> It needs new interface module. Somebody have to combine CAM API >>> smartmontools interface module used for SCSI devices and ATA SMART commands. >> So you mean it should practically be the same as existing ATA module, but instead >> of ATA ioctl it should use cam(3)? > > Yes. > Thinking out loud - maybe it's possible to support IOCATAREQUEST on ada devices and internally convert it to appropriate CAM command. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 16:19: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 5B5901065701 for ; Mon, 31 Aug 2009 16:19:18 +0000 (UTC) (envelope-from flo@smeets.im) Received: from mail.solomo.de (mail.solomo.de [85.214.49.72]) by mx1.freebsd.org (Postfix) with ESMTP id 11D448FC1B for ; Mon, 31 Aug 2009 16:19:18 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.solomo.de (Postfix) with ESMTP id 59B923F512; Mon, 31 Aug 2009 18:03:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at vistream.de Received: from mail.solomo.de ([127.0.0.1]) by localhost (mail.solomo.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id x0twdblHr6PP; Mon, 31 Aug 2009 18:03:07 +0200 (CEST) Received: from [192.168.0.100] (p50913412.dip.t-dialin.net [80.145.52.18]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.solomo.de (Postfix) with ESMTPSA id A02B63F483; Mon, 31 Aug 2009 18:03:06 +0200 (CEST) Message-ID: <4A9BF438.1000006@smeets.im> Date: Mon, 31 Aug 2009 18:03:04 +0200 From: Florian Smeets User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090830 Shredder/3.0b4pre MIME-Version: 1.0 To: Nick Hilliard References: <4A9BF23F.6070801@netability.ie> In-Reply-To: <4A9BF23F.6070801@netability.ie> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 31 Aug 2009 16:33:37 +0000 Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 16:19:18 -0000 On 8/31/09 5:54 PM, Nick Hilliard wrote: > Hi, > > I have a hp proliant ML115 with 6 sata ports which run in ATA mode (bios > doesn't appear to give the option to use AHCI). On freebsd 7.x, all > channels are detected. On freebsd8.0-beta3, the disks attached to the > first two SATA ports are not detected, although it detects the ports > themselves. > > I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. > > Any ideas on what's going on here? This seems like a nasty regression. There are 3 PRs about this problem: 128686, 132372, 137942. i386 version should recognize the disks. amd64 does when you set hw.pci.mcfg=0 in loader.conf. Cheers, Florian From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 16:59: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 513471065672 for ; Mon, 31 Aug 2009 16:59:29 +0000 (UTC) (envelope-from grosser@fim.uni-passau.de) Received: from smtprelay08.ispgateway.de (smtprelay08.ispgateway.de [80.67.31.31]) by mx1.freebsd.org (Postfix) with ESMTP id 6EB3E8FC08 for ; Mon, 31 Aug 2009 16:59:26 +0000 (UTC) Received: from [84.56.34.153] (helo=[192.168.178.29]) by smtprelay08.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MiADy-0007KP-Bx; Mon, 31 Aug 2009 18:59:25 +0200 From: Tobias Grosser To: ticso@cicely.de In-Reply-To: <16272_1251712358_4A9B9D66_16272_77_1_20090831095231.GD59032@cicely7.cicely.de> References: <1251570251.1238.21.camel@localhost> <19936_1251649540_4A9AA804_19936_425_1_200908301825.57281.hselasky@c2i.net> <1251650741.1187.1.camel@localhost> <200908301909.30692.hselasky@c2i.net> <16272_1251712358_4A9B9D66_16272_77_1_20090831095231.GD59032@cicely7.cicely.de> Content-Type: multipart/mixed; boundary="=-FXSqk9find9veh0W83n2" Date: Mon, 31 Aug 2009 18:59:18 +0200 Message-Id: <1251737958.1216.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port X-Df-Sender: imapboxtobias@web-wahnsinn.de X-Mailman-Approved-At: Mon, 31 Aug 2009 17:09:24 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 16:59:29 -0000 --=-FXSqk9find9veh0W83n2 Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2009-08-31 at 11:52 +0200, Bernd Walter wrote: > On Sun, Aug 30, 2009 at 07:09:29PM +0200, Hans Petter Selasky wrote: > > Hi, > > > > I looks like your device is hanging on SCSI command 0x12,00,00,00,4a,00 > > 0x12 is an inquiry, which is bad if the device has problems with. I tried Linux on the same computer and the drive worked without any problems. --------------------------------------- linux_dmesg.log is attached. --------------------------------------- There was also another report where the drive did not work on FreeBSD. I mailed the user and he did not get it to run on FreeBSD, but his drive also works on Linux. http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028999.html As I have two of these drives, I am pretty sure my device is not completely broken, but WD has some uncommon/broken way to interact with FreeBSD. To narrow it down I run the usb.org compliance test utility. http://www.usb.org/developers/tools/ : USB20CV R1.3.5.5 The results for the generic device test and for the USB mass storage test are attached. --------------------------------------- umass_compliance.html usb_device_compliance.html --------------------------------------- The device passed all tests. I do not understand all the details, but at least the test suites also issues "Inquiries" without hanging the device. Hopefully these logs can give us some insights where the problem might be hidden. > > This is not an USB fault. Tobi --=-FXSqk9find9veh0W83n2 Content-Disposition: attachment; filename="umass_compliance.html" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; name="umass_compliance.html"; charset="us-ascii" WORKSTATION: OMICRON DATE: Monday, August 31, 2009 TIME: 09:50:13 AM OPERATOR: Michael NUMBER OF TESTS: 22 RESULT: passed _________________________________________________________________ InitializeTestSuite INFO Log initialized INFO Microsoft Windows NT version 6.0 (Build 6000) INFO Service Pack 0.0 INFO USBCommandVerifier.dll ver 1.3.3.3 INFO TestServices.dll ver 1.3.3.5 INFO StackSwitcher.dll ver 1.3.3.3 MSC SerialNumberTest_DeviceAddressed Passed INFO =============== Now Starting Test: USB Mass Storage Serial Number Test (Configuration Index 0) INFO Start time: 09:48:42 INFO Serial Number string for MSC device : iSerialNumber = 0x3 INFO ENGLISH_US language string descriptor is : 57442D575835304136 395033343438 INFO Using Language ID 0x409 INFO MSC Serial Number length = 62 INFO MSC Serial Number length = 62 INFO MSC Serial Number string descriptor type = 0x3 INFO MSC Serial Number length = 62 INFO MSC Serial Number string descriptor type = 0x3 INFO MSC Serial Number character [0] = 0x35 INFO MSC Serial Number character [1] = 0x37 INFO MSC Serial Number character [2] = 0x34 INFO MSC Serial Number character [3] = 0x34 INFO MSC Serial Number character [4] = 0x32 INFO MSC Serial Number character [5] = 0x44 INFO MSC Serial Number character [6] = 0x35 INFO MSC Serial Number character [7] = 0x37 INFO MSC Serial Number character [8] = 0x35 INFO MSC Serial Number character [9] = 0x38 INFO MSC Serial Number character [10] = 0x33 INFO MSC Serial Number character [11] = 0x35 INFO MSC Serial Number character [12] = 0x33 INFO MSC Serial Number character [13] = 0x30 INFO MSC Serial Number character [14] = 0x34 INFO MSC Serial Number character [15] = 0x31 INFO MSC Serial Number character [16] = 0x33 INFO MSC Serial Number character [17] = 0x36 INFO MSC Serial Number character [18] = 0x33 INFO MSC Serial Number character [19] = 0x39 INFO MSC Serial Number character [20] = 0x35 INFO MSC Serial Number character [21] = 0x30 INFO MSC Serial Number character [22] = 0x33 INFO MSC Serial Number character [23] = 0x33 INFO MSC Serial Number character [24] = 0x33 INFO MSC Serial Number character [25] = 0x34 INFO MSC Serial Number character [26] = 0x33 INFO MSC Serial Number character [27] = 0x34 INFO MSC Serial Number character [28] = 0x33 INFO MSC Serial Number character [29] = 0x38 INFO MSC Serial Number length = 62 INFO MSC Serial Number string descriptor type = 0x3 INFO MSC Serial Number character [0] = 0x35 INFO MSC Serial Number character [1] = 0x37 INFO MSC Serial Number character [2] = 0x34 INFO MSC Serial Number character [3] = 0x34 INFO MSC Serial Number character [4] = 0x32 INFO MSC Serial Number character [5] = 0x44 INFO MSC Serial Number character [6] = 0x35 INFO MSC Serial Number character [7] = 0x37 INFO MSC Serial Number character [8] = 0x35 INFO MSC Serial Number character [9] = 0x38 INFO MSC Serial Number character [10] = 0x33 INFO MSC Serial Number character [11] = 0x35 INFO MSC Serial Number character [12] = 0x33 INFO MSC Serial Number character [13] = 0x30 INFO MSC Serial Number character [14] = 0x34 INFO MSC Serial Number character [15] = 0x31 INFO MSC Serial Number character [16] = 0x33 INFO MSC Serial Number character [17] = 0x36 INFO MSC Serial Number character [18] = 0x33 INFO MSC Serial Number character [19] = 0x39 INFO MSC Serial Number character [20] = 0x35 INFO MSC Serial Number character [21] = 0x30 INFO MSC Serial Number character [22] = 0x33 INFO MSC Serial Number character [23] = 0x33 INFO MSC Serial Number character [24] = 0x33 INFO MSC Serial Number character [25] = 0x34 INFO MSC Serial Number character [26] = 0x33 INFO MSC Serial Number character [27] = 0x34 INFO MSC Serial Number character [28] = 0x33 INFO MSC Serial Number character [29] = 0x38 INFO Unconfiguring the device INFO Stop time: 09:48:43 INFO Stopping Test [ USB Mass Storage Serial Number Test (Configuration Inde x 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC SerialNumberTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Serial Number Test (Configuration Index 0) INFO Start time: 09:48:43 INFO Serial Number string for MSC device : iSerialNumber = 0x3 INFO ENGLISH_US language string descriptor is : 57442D575835304136 395033343438 INFO Using Language ID 0x409 INFO MSC Serial Number length = 62 INFO MSC Serial Number length = 62 INFO MSC Serial Number string descriptor type = 0x3 INFO MSC Serial Number length = 62 INFO MSC Serial Number string descriptor type = 0x3 INFO MSC Serial Number character [0] = 0x35 INFO MSC Serial Number character [1] = 0x37 INFO MSC Serial Number character [2] = 0x34 INFO MSC Serial Number character [3] = 0x34 INFO MSC Serial Number character [4] = 0x32 INFO MSC Serial Number character [5] = 0x44 INFO MSC Serial Number character [6] = 0x35 INFO MSC Serial Number character [7] = 0x37 INFO MSC Serial Number character [8] = 0x35 INFO MSC Serial Number character [9] = 0x38 INFO MSC Serial Number character [10] = 0x33 INFO MSC Serial Number character [11] = 0x35 INFO MSC Serial Number character [12] = 0x33 INFO MSC Serial Number character [13] = 0x30 INFO MSC Serial Number character [14] = 0x34 INFO MSC Serial Number character [15] = 0x31 INFO MSC Serial Number character [16] = 0x33 INFO MSC Serial Number character [17] = 0x36 INFO MSC Serial Number character [18] = 0x33 INFO MSC Serial Number character [19] = 0x39 INFO MSC Serial Number character [20] = 0x35 INFO MSC Serial Number character [21] = 0x30 INFO MSC Serial Number character [22] = 0x33 INFO MSC Serial Number character [23] = 0x33 INFO MSC Serial Number character [24] = 0x33 INFO MSC Serial Number character [25] = 0x34 INFO MSC Serial Number character [26] = 0x33 INFO MSC Serial Number character [27] = 0x34 INFO MSC Serial Number character [28] = 0x33 INFO MSC Serial Number character [29] = 0x38 INFO MSC Serial Number length = 62 INFO MSC Serial Number string descriptor type = 0x3 INFO MSC Serial Number character [0] = 0x35 INFO MSC Serial Number character [1] = 0x37 INFO MSC Serial Number character [2] = 0x34 INFO MSC Serial Number character [3] = 0x34 INFO MSC Serial Number character [4] = 0x32 INFO MSC Serial Number character [5] = 0x44 INFO MSC Serial Number character [6] = 0x35 INFO MSC Serial Number character [7] = 0x37 INFO MSC Serial Number character [8] = 0x35 INFO MSC Serial Number character [9] = 0x38 INFO MSC Serial Number character [10] = 0x33 INFO MSC Serial Number character [11] = 0x35 INFO MSC Serial Number character [12] = 0x33 INFO MSC Serial Number character [13] = 0x30 INFO MSC Serial Number character [14] = 0x34 INFO MSC Serial Number character [15] = 0x31 INFO MSC Serial Number character [16] = 0x33 INFO MSC Serial Number character [17] = 0x36 INFO MSC Serial Number character [18] = 0x33 INFO MSC Serial Number character [19] = 0x39 INFO MSC Serial Number character [20] = 0x35 INFO MSC Serial Number character [21] = 0x30 INFO MSC Serial Number character [22] = 0x33 INFO MSC Serial Number character [23] = 0x33 INFO MSC Serial Number character [24] = 0x33 INFO MSC Serial Number character [25] = 0x34 INFO MSC Serial Number character [26] = 0x33 INFO MSC Serial Number character [27] = 0x34 INFO MSC Serial Number character [28] = 0x33 INFO MSC Serial Number character [29] = 0x38 INFO Unconfiguring the device INFO Stop time: 09:48:44 INFO Stopping Test [ USB Mass Storage Serial Number Test (Configuration Inde x 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC InterfaceDescriptorTest_DeviceAddressed Passed INFO =============== Now Starting Test: USB Mass Storage Interface Descriptor Test (Configuration In dex 0) INFO Start time: 09:48:44 INFO MSC Interface Class code = 0x8 INFO MSC Interface Sub Class code = 0x6 INFO MSC Interface Protocol code = 0x50 INFO Number of endpoints for MSC Interface = 2 INFO Serial Number string for MSC device : iSerialNumber = 0x3 INFO Using Language ID 0x409 INFO Unconfiguring the device INFO Stop time: 09:48:45 INFO Stopping Test [ USB Mass Storage Interface Descriptor Test (Configurati on Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC InterfaceDescriptorTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Interface Descriptor Test (Configuration In dex 0) INFO Start time: 09:48:45 INFO MSC Interface Class code = 0x8 INFO MSC Interface Sub Class code = 0x6 INFO MSC Interface Protocol code = 0x50 INFO Number of endpoints for MSC Interface = 2 INFO Serial Number string for MSC device : iSerialNumber = 0x3 INFO Using Language ID 0x409 INFO Unconfiguring the device INFO Stop time: 09:48:46 INFO Stopping Test [ USB Mass Storage Interface Descriptor Test (Configurati on Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC ClassRequestTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Class Request Test (Configuration Index 0) INFO Start time: 09:48:46 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Issuing valid Get Max LUN request INFO Max LUN value = 0 INFO Issuing Get Max LUN request with invalid wIndex parameter INFO Issuing Get Max LUN request with invalid wValue parameter INFO Issuing Get Max LUN request with incorrect Length parameter (=0) INFO Issuing Get Max LUN request with incorrect Length parameter (>1) INFO Issuing valid Get Max LUN request INFO Max LUN value = 0 INFO Issuing valid BOT MSC Reset request INFO Issuing BOT MSC Reset request with incorrect wIndex parameter INFO Issuing BOT MSC Reset request with incorrect wValue parameter INFO Issuing BOT MSC Reset request with incorrect Length parameter (>0) INFO Issuing valid BOT MSC Reset request INFO Unconfiguring the device INFO Stop time: 09:48:53 INFO Stopping Test [ USB Mass Storage Class Request Test (Configuration Inde x 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC ErrorRecoveryTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Error Recovery Test (Configuration Index 0) INFO Start time: 09:48:53 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Issue CBW with invalid signature INFO Issuing invalid CBW INFO CBW successful INFO Issuing CSW 2 times, CSW should stall in every case INFO Issuing CSW 1 INFO Issuing CSW 2 INFO Retrieving status on CSW endpoint INFO CSW endpoint status = 0x1 INFO CSW endpoint stalled INFO Clearing stalled CSW endpoint INFO Issuing CSW 2 times, CSW should stall in every case INFO Issuing CSW 1 INFO Bulk Request timed out! ERROR Invalid response, CSW should STALL INFO ************************* WARNING (5.2.1) Devices receiving a CBW with an invalid signature should stall further traffic on the Bulk In pipe, and either stall further traffic or accept and discard further traffic on the Bulk Out pipe, until reset recovery. If the device does not react in this manner, it should at least respond correctly to a Reset Recovery. INFO ************************* INFO Issuing BOT MSC Reset, reset should always succeed INFO Retrieving status on CBW endpoint INFO CBW endpoint status = 0x0 INFO Retrieving status on CSW endpoint INFO CSW endpoint status = 0x0 INFO Issuing required command (Test Unit Ready) to verify device has recover ed INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issue a short CBW (<31 bytes) INFO Issuing invalid CBW INFO CBW successful INFO Issuing CSW 2 times, CSW should stall in every case INFO Issuing CSW 1 INFO Issuing CSW 2 INFO Retrieving status on CSW endpoint INFO CSW endpoint status = 0x1 INFO CSW endpoint stalled INFO Clearing stalled CSW endpoint INFO Issuing CSW 2 times, CSW should stall in every case INFO Issuing CSW 1 INFO Bulk Request timed out! ERROR Invalid response, CSW should STALL INFO ************************* WARNING (5.2.2) Devices receiving a CBW with the wrong length should stall further traffic on the Bulk In pipe, and either stall further traffic or accept and discard further traffic on the Bulk Out pipe, until reset recovery. If the device does not react in this manner, it should at least respond correctly to a Reset Recovery. INFO ************************* INFO Issuing BOT MSC Reset, reset should always succeed INFO Retrieving status on CBW endpoint INFO CBW endpoint status = 0x0 INFO Retrieving status on CSW endpoint INFO CSW endpoint status = 0x0 INFO Issuing required command (Test Unit Ready) to verify device has recover ed INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issue a long CBW (>31 bytes) INFO Issuing invalid CBW INFO CBW successful INFO Issuing CSW 2 times, CSW should stall in every case INFO Issuing CSW 1 INFO Issuing CSW 2 INFO Retrieving status on CSW endpoint INFO CSW endpoint status = 0x1 INFO CSW endpoint stalled INFO Clearing stalled CSW endpoint INFO Issuing CSW 2 times, CSW should stall in every case INFO Issuing CSW 1 INFO Bulk Request timed out! ERROR Invalid response, CSW should STALL INFO ************************* WARNING (5.2.2) Devices receiving a CBW with the wrong length should stall further traffic on the Bulk In pipe, and either stall further traffic or accept and discard further traffic on the Bulk Out pipe, until reset recovery. If the device does not react in this manner, it should at least respond correctly to a Reset Recovery. INFO ************************* INFO Issuing BOT MSC Reset, reset should always succeed INFO Retrieving status on CBW endpoint INFO CBW endpoint status = 0x0 INFO Retrieving status on CSW endpoint INFO CSW endpoint status = 0x0 INFO Issuing required command (Test Unit Ready) to verify device has recover ed INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Unconfiguring the device INFO Stop time: 09:49:25 INFO Stopping Test [ USB Mass Storage Error Recovery Test (Configuration Ind ex 0): Number of: Fails (0); Aborts (0); Warnings (3) ] MSC CaseOneTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case One Test (Configuration Index 0) INFO Start time: 09:49:25 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 1 (Hn = Dn) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Unconfiguring the device INFO Stop time: 09:49:26 INFO Stopping Test [ USB Mass Storage Case One Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseTwoTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Two Test (Configuration Index 0) INFO Start time: 09:49:26 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 2 (Hn < Di) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x28 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x1 INFO |----- CBW CDB-09 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x2 INFO CSW reported a phase error, issuing BOT MSC Reset INFO Unconfiguring the device INFO Stop time: 09:49:27 INFO Stopping Test [ USB Mass Storage Case Two Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseThreeTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Three Test (Configuration Index 0) INFO Start time: 09:49:27 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 3 (Hn < Do) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x1 INFO |----- CBW CDB-09 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x2 INFO CSW reported a phase error, issuing BOT MSC Reset INFO Unconfiguring the device INFO Stop time: 09:49:28 INFO Stopping Test [ USB Mass Storage Case Three Test (Configuration Index 0 ): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseFourTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Four Test (Configuration Index 0) INFO Start time: 09:49:28 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 4 (Hi > Dn) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x200 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x28 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO DATA phase stalled INFO Retrieving status on stalled bulk endpoint INFO Bulk endpoint status = 0x1 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x200 INFO CSW status returned = 0x0 INFO Unconfiguring the device INFO Stop time: 09:49:29 INFO Stopping Test [ USB Mass Storage Case Four Test (Configuration Index 0) : Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseFiveTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Five Test (Configuration Index 0) INFO Start time: 09:49:29 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 5 (Hi > Di) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x400 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x28 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x1 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO DATA phase stalled INFO Retrieving status on stalled bulk endpoint INFO Bulk endpoint status = 0x1 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x200 INFO CSW status returned = 0x0 INFO Unconfiguring the device INFO Stop time: 09:49:30 INFO Stopping Test [ USB Mass Storage Case Five Test (Configuration Index 0) : Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseSixTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Six Test (Configuration Index 0) INFO Start time: 09:49:30 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 6 (Hi = Di) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x200 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x28 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x1 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Unconfiguring the device INFO Stop time: 09:49:31 INFO Stopping Test [ USB Mass Storage Case Six Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseSevenTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Seven Test (Configuration Index 0) INFO Start time: 09:49:31 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 7 (Hi < Di) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x200 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x28 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x2 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO DATA phase stalled INFO Retrieving status on stalled bulk endpoint INFO Bulk endpoint status = 0x1 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x2 INFO CSW reported a phase error, issuing BOT MSC Reset INFO Unconfiguring the device INFO Stop time: 09:49:32 INFO Stopping Test [ USB Mass Storage Case Seven Test (Configuration Index 0 ): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseEightTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Eight Test (Configuration Index 0) INFO Start time: 09:49:33 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 8 (Hi <> Do) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x200 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x1 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO DATA phase stalled INFO Retrieving status on stalled bulk endpoint INFO Bulk endpoint status = 0x1 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x200 INFO CSW status returned = 0x2 INFO CSW reported a phase error, issuing BOT MSC Reset INFO Unconfiguring the device INFO Stop time: 09:49:34 INFO Stopping Test [ USB Mass Storage Case Eight Test (Configuration Index 0 ): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseNineTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Nine Test (Configuration Index 0) INFO Start time: 09:49:34 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 9 (Ho > Dn) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x200 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x200 INFO CSW status returned = 0x0 INFO Unconfiguring the device INFO Stop time: 09:49:35 INFO Stopping Test [ USB Mass Storage Case Nine Test (Configuration Index 0) : Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseTenTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Ten Test (Configuration Index 0) INFO Start time: 09:49:35 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 10 (Ho <> Di) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x200 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x28 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x1 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x200 INFO CSW status returned = 0x2 INFO CSW reported a phase error, issuing BOT MSC Reset INFO Unconfiguring the device INFO Stop time: 09:49:36 INFO Stopping Test [ USB Mass Storage Case Ten Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseElevenTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Eleven Test (Configuration Index 0) INFO Start time: 09:49:36 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 11 (Ho > Do) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x400 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x1 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x200 INFO CSW status returned = 0x0 INFO Unconfiguring the device INFO Stop time: 09:49:37 INFO Stopping Test [ USB Mass Storage Case Eleven Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseTwelveTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Twelve Test (Configuration Index 0) INFO Start time: 09:49:37 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 12 (Ho = Do) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x400 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x2 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Unconfiguring the device INFO Stop time: 09:49:38 INFO Stopping Test [ USB Mass Storage Case Twelve Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CaseThirteenTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Case Thirteen Test (Configuration Index 0) INFO Start time: 09:49:38 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing BOT Case 13 (Ho < Do) INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x200 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x2 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x200 INFO CSW status returned = 0x2 INFO CSW reported a phase error, issuing BOT MSC Reset INFO Unconfiguring the device INFO Stop time: 09:49:39 INFO Stopping Test [ USB Mass Storage Case Thirteen Test (Configuration Inde x 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CBLengthTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage CBLength Test (Configuration Index 0) INFO Start time: 09:49:39 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing CBLength test w/ pad bytes = 0xff INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing CBLength test w/ pad bytes = 0x55 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing CBLength test w/ pad bytes = 0xaa INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Unconfiguring the device INFO Stop time: 09:49:40 INFO Stopping Test [ USB Mass Storage CBLength Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CommandSetTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Required Command Test (Configuration Index 0) INFO Start time: 09:49:40 INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x12, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x12, Test Variation #2 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x1 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x1 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x12, Test Variation #3 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x2 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x2 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x12, Test Variation #4 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x4 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x4 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x12, Test Variation #5 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x5 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x5 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x12, Test Variation #6 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x12, Test Variation #7 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0xff INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0xff INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO ************************* WARNING Expecting a STALL after data phase completes with a zero-length or shor t packet INFO ************************* INFO If the device actually transfers less data than the host indicated, the device shall STALL the Bulk-In pipe INFO CSW residue returned = 0xb5 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x03, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x3 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x03, Test Variation #2 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x1 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x3 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x1 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x03, Test Variation #3 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x2 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x3 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x2 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x03, Test Variation #4 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x12 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x3 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x12 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x03, Test Variation #5 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0xff INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x3 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0xff INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO ************************* WARNING Expecting a STALL after data phase completes with a zero-length or shor t packet INFO ************************* INFO If the device actually transfers less data than the host indicated, the device shall STALL the Bulk-In pipe INFO CSW residue returned = 0xed INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x00, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x28, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x1000 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x28 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x8 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x28, Test Variation #2 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x2000 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x28 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x10 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x28, Test Variation #3 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x4000 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x28 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x20 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x28, Test Variation #4 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8000 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x28 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x40 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x28, Test Variation #5 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x10000 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x28 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x80 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0xa8, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x1000 INFO |----- CBW CDB Length = 0xc INFO |----- CBW CDB-00 = 0xa8 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x8 INFO |----- CBW CDB-10 = 0x0 INFO |----- CBW CDB-11 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0xa8, Test Variation #2 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x2000 INFO |----- CBW CDB Length = 0xc INFO |----- CBW CDB-00 = 0xa8 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x10 INFO |----- CBW CDB-10 = 0x0 INFO |----- CBW CDB-11 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0xa8, Test Variation #3 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x4000 INFO |----- CBW CDB Length = 0xc INFO |----- CBW CDB-00 = 0xa8 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x20 INFO |----- CBW CDB-10 = 0x0 INFO |----- CBW CDB-11 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0xa8, Test Variation #4 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8000 INFO |----- CBW CDB Length = 0xc INFO |----- CBW CDB-00 = 0xa8 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x40 INFO |----- CBW CDB-10 = 0x0 INFO |----- CBW CDB-11 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0xa8, Test Variation #5 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x10000 INFO |----- CBW CDB Length = 0xc INFO |----- CBW CDB-00 = 0xa8 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x80 INFO |----- CBW CDB-10 = 0x0 INFO |----- CBW CDB-11 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x25, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x2a, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x1000 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x8 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x2a, Test Variation #2 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x2000 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x10 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x2a, Test Variation #3 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x4000 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x20 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x2a, Test Variation #4 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x8000 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x40 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x2a, Test Variation #5 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x10000 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x80 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0xaa, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x1000 INFO |----- CBW CDB Length = 0xc INFO |----- CBW CDB-00 = 0xaa INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x8 INFO |----- CBW CDB-10 = 0x0 INFO |----- CBW CDB-11 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0xaa, Test Variation #2 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x2000 INFO |----- CBW CDB Length = 0xc INFO |----- CBW CDB-00 = 0xaa INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x10 INFO |----- CBW CDB-10 = 0x0 INFO |----- CBW CDB-11 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0xaa, Test Variation #3 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x4000 INFO |----- CBW CDB Length = 0xc INFO |----- CBW CDB-00 = 0xaa INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x20 INFO |----- CBW CDB-10 = 0x0 INFO |----- CBW CDB-11 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0xaa, Test Variation #4 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x8000 INFO |----- CBW CDB Length = 0xc INFO |----- CBW CDB-00 = 0xaa INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x40 INFO |----- CBW CDB-10 = 0x0 INFO |----- CBW CDB-11 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0xaa, Test Variation #5 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x10000 INFO |----- CBW CDB Length = 0xc INFO |----- CBW CDB-00 = 0xaa INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x80 INFO |----- CBW CDB-10 = 0x0 INFO |----- CBW CDB-11 = 0x0 INFO Issuing DATA OUT INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x15, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x15 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x55, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x55 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x1a, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x4 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x1a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x3f INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x4 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x5a, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x5a INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x3f INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x8 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x1e, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x1e INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x1 INFO Request failed, issuing Request Sense INFO Issuing CBW: INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x12 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x3 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x12 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO REQUEST_SENSE - Key = 0x5, Code = 0x20, Qualifier 0x0 INFO Allowing Errors on odd-byte transfers INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x1b, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x1b INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x1 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Command Set Test for Op Code 0x43 not applicable for PDT = 0x00 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Issuing Command Set Test for Op Code 0x2f, Test Variation #1 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2f INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x8 INFO |----- CBW CDB-09 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x2f, Test Variation #2 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2f INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x10 INFO |----- CBW CDB-09 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x2f, Test Variation #3 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2f INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x20 INFO |----- CBW CDB-09 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x2f, Test Variation #4 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2f INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x40 INFO |----- CBW CDB-09 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Issuing Command Set Test for Op Code 0x2f, Test Variation #5 INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x2f INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x80 INFO |----- CBW CDB-09 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Unconfiguring the device INFO Stop time: 09:49:41 INFO Stopping Test [ USB Mass Storage Required Command Test (Configuration I ndex 0): Number of: Fails (0); Aborts (0); Warnings (2) ] MSC PowerUpTest_DeviceConfigured Passed INFO =============== Now Starting Test: USB Mass Storage Power Up Test (Configuration Index 0) INFO Start time: 09:49:42 INFO Attempting to re-enumerate device ERROR CVHub_ReEnumerateAll::Could not find device under test after enumeratio n ERROR CVHub_ReEnumerateAll::Could not find device under test after enumeratio n ERROR CVHub_ReEnumerateAll::Could not find device under test after enumeratio n ERROR CVHub_ReEnumerateAll::Could not find device under test after enumeratio n ERROR CVHub_ReEnumerateAll::Could not find device under test after enumeratio n ERROR CVHub_ReEnumerateAll::Could not find device under test after enumeratio n ERROR CVHub_ReEnumerateAll::Could not find device under test after enumeratio n ERROR CVHub_ReEnumerateAll::Could not find device under test after enumeratio n ERROR CVHub_ReEnumerateAll::Could not find device under test after enumeratio n INFO Device has been re-enumerated, perform PowerUp test INFO Configuring device, set configuration = 0x1 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call INFO Setting device interface, interface number = 0x0 and alternate setting = 0x0 INFO NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call INFO Issuing Get Max LUN request INFO Max LUN value = 0 INFO Getting Device Type INFO Issuing INQUIRY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x24 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x12 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x24 INFO |----- CBW CDB-05 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO INQUIRY - Devicetype = 0x0 INFO ** INFO Now testing device 'WD : 3200BMV External', LUN - 0 INFO ** INFO Waiting for device to become ready... INFO Issuing TEST UNIT READY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x0 INFO |----- CBW Data Transfer Length = 0x0 INFO |----- CBW CDB Length = 0x6 INFO |----- CBW CDB-00 = 0x0 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO Device ready INFO Getting Device BlockSize INFO Issuing READ_CAPACITY INFO Issuing CBW (attempt #1): INFO |----- CBW LUN = 0x0 INFO |----- CBW Flags = 0x80 INFO |----- CBW Data Transfer Length = 0x8 INFO |----- CBW CDB Length = 0xa INFO |----- CBW CDB-00 = 0x25 INFO |----- CBW CDB-01 = 0x0 INFO |----- CBW CDB-02 = 0x0 INFO |----- CBW CDB-03 = 0x0 INFO |----- CBW CDB-04 = 0x0 INFO |----- CBW CDB-05 = 0x0 INFO |----- CBW CDB-06 = 0x0 INFO |----- CBW CDB-07 = 0x0 INFO |----- CBW CDB-08 = 0x0 INFO |----- CBW CDB-09 = 0x0 INFO Issuing DATA IN INFO Issuing CSW : try 1 INFO CSW residue returned = 0x0 INFO CSW status returned = 0x0 INFO READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200 INFO Unconfiguring the device INFO Stop time: 09:50:13 INFO Stopping Test [ USB Mass Storage Power Up Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] MSC CompleteTests INFO ** INFO Device is considered compliant with the Bootability specification. INFO ** INFO Summary Log Counts [ Fails (0); Aborts (0); Warnings (5) ] --=-FXSqk9find9veh0W83n2 Content-Disposition: attachment; filename="usb_device_compliance.html" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Content-Type: text/plain; name="usb_device_compliance.html"; charset="us-ascii" WORKSTATION: OMICRON DATE: Monday, August 31, 2009 TIME: 09:54:23 AM OPERATOR: Michael NUMBER OF TESTS: 21 RESULT: passed _________________________________________________________________ InitializeTestSuite INFO Log initialized INFO Microsoft Windows NT version 6.0 (Build 6000) INFO Service Pack 0.0 INFO USBCommandVerifier.dll ver 1.3.3.3 INFO TestServices.dll ver 1.3.3.5 INFO StackSwitcher.dll ver 1.3.3.3 DeviceDescriptorTest_DeviceConfigured Passed INFO =============== Now Starting Test: Device Descriptor Test (Configuration Index 0) INFO Start time: 09:53:17 INFO Device descriptor length : 12 INFO Device descriptor type : 1 INFO Major version : 2 INFO Minor version : 0 INFO Each interface specifies its own device class type INFO Device sub class : 0 INFO Device protocol : 0 INFO Device MaxPacketSize0 : 40 ABORT Create file on 'usb.if' failed WARNING Failed to get vendor information for VendorID : 1058 INFO Device ProductID : 704 INFO Device BCD : 175 INFO ENGLISH_US language string descriptor is : Western Digital INFO ENGLISH_US language string descriptor is : External HDD INFO ENGLISH_US language string descriptor is : 57442D575835304136 395033343438 INFO Number of configurations device supports : 1 INFO Stop time: 09:53:18 INFO Stopping Test [ Device Descriptor Test (Configuration Index 0): Number of: Fails (0); Aborts (1); Warnings (1) ] DeviceDescriptorTest_DeviceAddressed Passed INFO =============== Now Starting Test: Device Descriptor Test (Configuration Index 0) INFO Start time: 09:53:18 INFO Device descriptor length : 12 INFO Device descriptor type : 1 INFO Major version : 2 INFO Minor version : 0 INFO Each interface specifies its own device class type INFO Device sub class : 0 INFO Device protocol : 0 INFO Device MaxPacketSize0 : 40 ABORT Create file on 'usb.if' failed WARNING Failed to get vendor information for VendorID : 1058 INFO Device ProductID : 704 INFO Device BCD : 175 INFO ENGLISH_US language string descriptor is : Western Digital INFO ENGLISH_US language string descriptor is : External HDD INFO ENGLISH_US language string descriptor is : 57442D575835304136 395033343438 INFO Number of configurations device supports : 1 INFO Stop time: 09:53:19 INFO Stopping Test [ Device Descriptor Test (Configuration Index 0): Number of: Fails (0); Aborts (1); Warnings (1) ] ConfigDescriptorTest_DeviceConfigured Passed INFO =============== Now Starting Test: Configuration Descriptor Test (Configuration Index 0) INFO Start time: 09:53:19 INFO Number of interface descriptors found 1 INFO Number of alternate interface descriptors found : 0 INFO Number of endpoint descriptors found : 2 INFO Configuration descriptor length : 9 INFO Configuration descriptor type : 2 INFO Configuration descriptor TotalLength : 20 INFO Configuration descriptor NumInterfaces : 1 INFO Configuration descriptor ConfigurationValue: 1 INFO Configuration descriptor string descriptor index : 0 INFO Configuration descriptor bmAttributes : c0 INFO Device does not support remote wake up INFO Maximum power device requires : 2mA INFO Device is BUS/SELF-POWERED INFO Device is currently SELF POWERED INFO Currently remote wakeup is DISABLED INFO Stop time: 09:53:20 INFO Stopping Test [ Configuration Descriptor Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] ConfigDescriptorTest_DeviceAddressed Passed INFO =============== Now Starting Test: Configuration Descriptor Test (Configuration Index 0) INFO Start time: 09:53:20 INFO Number of interface descriptors found 1 INFO Number of alternate interface descriptors found : 0 INFO Number of endpoint descriptors found : 2 INFO Configuration descriptor length : 9 INFO Configuration descriptor type : 2 INFO Configuration descriptor TotalLength : 20 INFO Configuration descriptor NumInterfaces : 1 INFO Configuration descriptor ConfigurationValue: 1 INFO Configuration descriptor string descriptor index : 0 INFO Configuration descriptor bmAttributes : c0 INFO Device does not support remote wake up INFO Maximum power device requires : 2mA INFO Device is BUS/SELF-POWERED INFO Device is currently SELF POWERED INFO Currently remote wakeup is DISABLED INFO Stop time: 09:53:21 INFO Stopping Test [ Configuration Descriptor Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] InterfaceDescriptorTest Passed INFO =============== Now Starting Test: Interface Descriptor Test (Configuration Index 0) INFO Start time: 09:53:21 INFO Bandwidth check passed INFO Testing Interface number : 0 Alternate setting : 0 INFO Interface descriptor length : 9 INFO Interface descriptor bDescriptorType : 4 INFO Interface descriptor bAlternateSetting : 0 INFO Interface descriptor bNumEndPoints: 2 INFO Interface descriptor bInterfaceClass reserved for assignment by the USB -IF : 8 INFO Interface class code indicates [Mass-Storage] Interface INFO Interface descriptor bInterfaceSubClass : 6 INFO Interface descriptor bInterfaceProtocol assigned by the USB-IF : 50 INFO Interface descriptor iInterface : 0x0 INFO Stop time: 09:53:22 INFO Stopping Test [ Interface Descriptor Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] EndpointDescriptorTest_DeviceConfigured Passed INFO =============== Now Starting Test: Endpoint Descriptor Test (Configuration Index 0) INFO Start time: 09:53:22 INFO Testing Interface number : 0 Alternate setting : 0 INFO Endpoint descriptor length : 7 INFO Endpoint descriptor type : 5 INFO Endpoint Type : Bulk, Number : 1, Direction : IN INFO Endpoint descriptor bmAttributes : 2 INFO Endpoint descriptor raw MaxPacketSize : 200 INFO Endpoint descriptor interval : 0 INFO Endpoint descriptor length : 7 INFO Endpoint descriptor type : 5 INFO Endpoint Type : Bulk, Number : 2, Direction : OUT INFO Endpoint descriptor bmAttributes : 2 INFO Endpoint descriptor raw MaxPacketSize : 200 INFO Endpoint descriptor interval : 0 INFO Stop time: 09:53:23 INFO Stopping Test [ Endpoint Descriptor Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] EndpointDescriptorTest_DeviceAddressed Passed INFO =============== Now Starting Test: Endpoint Descriptor Test (Configuration Index 0) INFO Start time: 09:53:23 INFO Testing Interface number : 0 Alternate setting : 0 INFO Endpoint descriptor length : 7 INFO Endpoint descriptor type : 5 INFO Endpoint Type : Bulk, Number : 1, Direction : IN INFO Endpoint descriptor bmAttributes : 2 INFO Endpoint descriptor raw MaxPacketSize : 200 INFO Endpoint descriptor interval : 0 INFO Endpoint descriptor length : 7 INFO Endpoint descriptor type : 5 INFO Endpoint Type : Bulk, Number : 2, Direction : OUT INFO Endpoint descriptor bmAttributes : 2 INFO Endpoint descriptor raw MaxPacketSize : 200 INFO Endpoint descriptor interval : 0 INFO Stop time: 09:53:24 INFO Stopping Test [ Endpoint Descriptor Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] HaltEndpointTest Passed INFO =============== Now Starting Test: Halt Endpoint Test (Configuration Index 0) INFO Start time: 09:53:24 INFO Testing Interface number : 0 Alternate setting : 0 INFO Testing EndPoint type : Bulk, Address : 81 INFO Endpoint is currently not halted INFO Endpoint is halted INFO Cleared endpoint halt INFO Testing EndPoint type : Bulk, Address : 2 INFO Endpoint is currently not halted INFO Endpoint is halted INFO Cleared endpoint halt INFO Stop time: 09:53:25 INFO Stopping Test [ Halt Endpoint Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] SetConfigurationTest Passed INFO =============== Now Starting Test: SetConfiguration Test (Configuration Index 0) INFO Start time: 09:53:25 INFO SetConfiguration with configuration value : 1 INFO Unconfigured the device INFO SetConfiguration with configuration value : 1 INFO Stop time: 09:53:26 INFO Stopping Test [ SetConfiguration Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] SuspendResumeTest Passed INFO =============== Now Starting Test: Suspend/Resume Test (Configuration Index 0) INFO Start time: 09:53:26 INFO Suspended the parent port of the device INFO Stop time: 09:53:28 INFO Stopping Test [ Suspend/Resume Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] RemoteWakeupTestEnabled Passed INFO =============== Now Starting Test: Remote Wakeup Test (Configuration Index 0) INFO Start time: 09:53:28 INFO The device does not support remote wakeup INFO Stop time: 09:53:29 INFO Stopping Test [ Remote Wakeup Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] RemoteWakeupTestDisabled Passed INFO =============== Now Starting Test: Remote Wakeup Test (Configuration Index 0) INFO Start time: 09:53:29 INFO The device does not support remote wakeup INFO Stop time: 09:53:30 INFO Stopping Test [ Remote Wakeup Test (Configuration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] OtherSpeedConfigTest_DeviceAddressed Passed INFO =============== Now Starting Test: Other Speed Configuration Test (Configuration Index 0 OtherS peedConfiguration Index 0) INFO Start time: 09:53:30 INFO Number of interface descriptors found 1 INFO Number of alternate interface descriptors found : 0 INFO Number of endpoint descriptors found : 2 INFO Configuration descriptor length : 9 INFO Configuration descriptor type : 7 INFO Configuration descriptor TotalLength : 20 INFO Configuration descriptor NumInterfaces : 1 INFO Configuration descriptor ConfigurationValue: 1 INFO Configuration descriptor string descriptor index : 0 INFO Configuration descriptor bmAttributes : c0 INFO Device does not support remote wake up INFO Maximum power device requires : 2mA INFO Device is BUS/SELF-POWERED INFO Stop time: 09:53:31 INFO Stopping Test [ Other Speed Configuration Test (Configuration Index 0 O therSpeedConfiguration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] OtherSpeedInterfaceDescriptorTest_DeviceAddressed Passed INFO =============== Now Starting Test: Interface Descriptor Test (Configuration Index 0 OtherSpeedC onfiguration Index 0) INFO Start time: 09:53:31 INFO Bandwidth check passed INFO Testing Interface number : 0 Alternate setting : 0 INFO Interface descriptor length : 9 INFO Interface descriptor bDescriptorType : 4 INFO Interface descriptor bAlternateSetting : 0 INFO Interface descriptor bNumEndPoints: 2 INFO Interface descriptor bInterfaceClass reserved for assignment by the USB -IF : 8 INFO Interface class code indicates [Mass-Storage] Interface INFO Interface descriptor bInterfaceSubClass : 6 INFO Interface descriptor bInterfaceProtocol assigned by the USB-IF : 50 INFO Interface descriptor iInterface : 0x0 INFO Stop time: 09:53:32 INFO Stopping Test [ Interface Descriptor Test (Configuration Index 0 OtherS peedConfiguration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] OtherSpeedEndpointDescriptorTest_DeviceAddressed Passed INFO =============== Now Starting Test: Endpoint Descriptor Test (Configuration Index 0 OtherSpeedCo nfiguration Index 0) INFO Start time: 09:53:32 INFO Testing Interface number : 0 Alternate setting : 0 INFO Endpoint descriptor length : 7 INFO Endpoint descriptor type : 5 INFO Endpoint Type : Bulk, Number : 1, Direction : IN INFO Endpoint descriptor bmAttributes : 2 INFO Endpoint descriptor raw MaxPacketSize : 40 INFO Endpoint descriptor interval : 0 INFO Endpoint descriptor length : 7 INFO Endpoint descriptor type : 5 INFO Endpoint Type : Bulk, Number : 2, Direction : OUT INFO Endpoint descriptor bmAttributes : 2 INFO Endpoint descriptor raw MaxPacketSize : 40 INFO Endpoint descriptor interval : 0 INFO Stop time: 09:53:33 INFO Stopping Test [ Endpoint Descriptor Test (Configuration Index 0 OtherSp eedConfiguration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] DeviceQualifierTest_DeviceAddressed Passed INFO =============== Now Starting Test: Device Qualifier Descriptor Test (Configuration Index 0) INFO Start time: 09:53:33 INFO Device qualifier length : a INFO Device qualifier type : 6 INFO Major version : 2 INFO Minor version : 0 INFO Device Qualifier device class : 0 INFO Device qualifier device subclass : 0 INFO Device qualifier device protocol : 0 INFO Device qualifier MaxPacketSize0 : 40 INFO Device qualifier bNumConfigurations : 1 INFO Stop time: 09:53:34 INFO Stopping Test [ Device Qualifier Descriptor Test (Configuration Index 0 ): Number of: Fails (0); Aborts (0); Warnings (0) ] DeviceQualifierTest_DeviceConfigured Passed INFO =============== Now Starting Test: Device Qualifier Descriptor Test (Configuration Index 0) INFO Start time: 09:53:34 INFO Device qualifier length : a INFO Device qualifier type : 6 INFO Major version : 2 INFO Minor version : 0 INFO Device Qualifier device class : 0 INFO Device qualifier device subclass : 0 INFO Device qualifier device protocol : 0 INFO Device qualifier MaxPacketSize0 : 40 INFO Device qualifier bNumConfigurations : 1 INFO Stop time: 09:53:35 INFO Stopping Test [ Device Qualifier Descriptor Test (Configuration Index 0 ): Number of: Fails (0); Aborts (0); Warnings (0) ] OtherSpeedConfigTest_DeviceConfigured Passed INFO =============== Now Starting Test: Other Speed Configuration Test (Configuration Index 0 OtherS peedConfiguration Index 0) INFO Start time: 09:53:35 INFO Number of interface descriptors found 1 INFO Number of alternate interface descriptors found : 0 INFO Number of endpoint descriptors found : 2 INFO Configuration descriptor length : 9 INFO Configuration descriptor type : 7 INFO Configuration descriptor TotalLength : 20 INFO Configuration descriptor NumInterfaces : 1 INFO Configuration descriptor ConfigurationValue: 1 INFO Configuration descriptor string descriptor index : 0 INFO Configuration descriptor bmAttributes : c0 INFO Device does not support remote wake up INFO Maximum power device requires : 2mA INFO Device is BUS/SELF-POWERED INFO Stop time: 09:53:36 INFO Stopping Test [ Other Speed Configuration Test (Configuration Index 0 O therSpeedConfiguration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] OtherSpeedInterfaceDescriptorTest_DeviceConfigured Passed INFO =============== Now Starting Test: Interface Descriptor Test (Configuration Index 0 OtherSpeedC onfiguration Index 0) INFO Start time: 09:53:36 INFO Bandwidth check passed INFO Testing Interface number : 0 Alternate setting : 0 INFO Interface descriptor length : 9 INFO Interface descriptor bDescriptorType : 4 INFO Interface descriptor bAlternateSetting : 0 INFO Interface descriptor bNumEndPoints: 2 INFO Interface descriptor bInterfaceClass reserved for assignment by the USB -IF : 8 INFO Interface class code indicates [Mass-Storage] Interface INFO Interface descriptor bInterfaceSubClass : 6 INFO Interface descriptor bInterfaceProtocol assigned by the USB-IF : 50 INFO Interface descriptor iInterface : 0x0 INFO Stop time: 09:53:37 INFO Stopping Test [ Interface Descriptor Test (Configuration Index 0 OtherS peedConfiguration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] OtherSpeedEndpointDescriptorTest_DeviceConfigured Passed INFO =============== Now Starting Test: Endpoint Descriptor Test (Configuration Index 0 OtherSpeedCo nfiguration Index 0) INFO Start time: 09:53:37 INFO Testing Interface number : 0 Alternate setting : 0 INFO Endpoint descriptor length : 7 INFO Endpoint descriptor type : 5 INFO Endpoint Type : Bulk, Number : 1, Direction : IN INFO Endpoint descriptor bmAttributes : 2 INFO Endpoint descriptor raw MaxPacketSize : 40 INFO Endpoint descriptor interval : 0 INFO Endpoint descriptor length : 7 INFO Endpoint descriptor type : 5 INFO Endpoint Type : Bulk, Number : 2, Direction : OUT INFO Endpoint descriptor bmAttributes : 2 INFO Endpoint descriptor raw MaxPacketSize : 40 INFO Endpoint descriptor interval : 0 INFO Stop time: 09:53:38 INFO Stopping Test [ Endpoint Descriptor Test (Configuration Index 0 OtherSp eedConfiguration Index 0): Number of: Fails (0); Aborts (0); Warnings (0) ] EnumerationTest Passed INFO =============== Now Starting Test: Enumeration Test (repeat 150 times) INFO Start time: 09:53:38 INFO Device speed is High INFO Stop time: 09:54:14 INFO Stopping Test [ Enumeration Test (repeat 150 times): Number of: Fails (0); Aborts (0); Warnings (0) ] Summary INFO Summary Log Counts [ Fails (0); Aborts (2); Warnings (2) ] --=-FXSqk9find9veh0W83n2-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 17:51: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 46A741065704 for ; Mon, 31 Aug 2009 17:51:10 +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 CEDE48FC0A for ; Mon, 31 Aug 2009 17:51:09 +0000 (UTC) Received: (qmail 948 invoked by uid 399); 31 Aug 2009 17:51:04 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 31 Aug 2009 17:51:04 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4A9C0D82.8080909@FreeBSD.org> Date: Mon, 31 Aug 2009 10:50:58 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20090831154924.GA40259@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090831154924.GA40259@wep4035.physik.uni-wuerzburg.de> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Update pkg_install to support 9-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, 31 Aug 2009 17:51:10 -0000 Alexey Shuvaev wrote: > Hello list! > > Any plans to update pkg_install so it finds INDEX-9? Fixed, thanks for the suggestion. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 19:07: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 0AAB61065676 for ; Mon, 31 Aug 2009 19:07:49 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id 6C9018FC19 for ; Mon, 31 Aug 2009 19:07:47 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n7VJ7e5m017857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 31 Aug 2009 21:07:41 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n7VJ7Zv3069364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Aug 2009 21:07:35 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n7VJ7ZRX060742; Mon, 31 Aug 2009 21:07:35 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n7VJ7Zv8060741; Mon, 31 Aug 2009 21:07:35 +0200 (CEST) (envelope-from ticso) Date: Mon, 31 Aug 2009 21:07:35 +0200 From: Bernd Walter To: Tobias Grosser Message-ID: <20090831190735.GF60240@cicely7.cicely.de> References: <1251570251.1238.21.camel@localhost> <19936_1251649540_4A9AA804_19936_425_1_200908301825.57281.hselasky@c2i.net> <1251650741.1187.1.camel@localhost> <200908301909.30692.hselasky@c2i.net> <16272_1251712358_4A9B9D66_16272_77_1_20090831095231.GD59032@cicely7.cicely.de> <1251737958.1216.15.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1251737958.1216.15.camel@localhost> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.000, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: freebsd-current@freebsd.org, ticso@cicely.de, Hans Petter Selasky Subject: Re: USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 19:07:49 -0000 On Mon, Aug 31, 2009 at 06:59:18PM +0200, Tobias Grosser wrote: > On Mon, 2009-08-31 at 11:52 +0200, Bernd Walter wrote: > > On Sun, Aug 30, 2009 at 07:09:29PM +0200, Hans Petter Selasky wrote: > > > Hi, > > > > > > I looks like your device is hanging on SCSI command 0x12,00,00,00,4a,00 > > > > 0x12 is an inquiry, which is bad if the device has problems with. > > I tried Linux on the same computer and the drive worked without any > problems. > If those are timestamps then there is a 5 second delay. I wouldn't say that this is without problems. Maybe Linux just has a different handling of the case. > --------------------------------------- > linux_dmesg.log is attached. > --------------------------------------- > > There was also another report where the drive did not work on FreeBSD. I > mailed the user and he did not get it to run on FreeBSD, but his drive > also works on Linux. > > http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028999.html > > As I have two of these drives, I am pretty sure my device is not > completely broken, but WD has some uncommon/broken way to interact with > FreeBSD. > > To narrow it down I run the usb.org compliance test utility. > > http://www.usb.org/developers/tools/ : USB20CV R1.3.5.5 As Hans Petter said: this is not a USB problem, it is at SCSI. > The results for the generic device test and for the USB mass storage > test are attached. If this is just are startup problem you won't see anything at all after probing is over. My assumption would be that the device missbehaves until it spun up. But this is just an assumption. > --------------------------------------- > umass_compliance.html > usb_device_compliance.html > --------------------------------------- > > The device passed all tests. I do not understand all the details, but at > least the test suites also issues "Inquiries" without hanging the > device. > > Hopefully these logs can give us some insights where the problem might > be hidden. > > > > This is not an USB fault. > > Tobi > [ 121.526008] usb 1-2: new high speed USB device using ehci_hcd and address 4 > [ 121.651218] usb 1-2: configuration #1 chosen from 1 choice > [ 121.651806] scsi4 : SCSI emulation for USB Mass Storage devices > [ 121.659671] usb-storage: device found at 4 > [ 121.659676] usb-storage: waiting for device to settle before scanning > [ 121.659976] usb 1-2: New USB device found, idVendor=1058, idProduct=0704 > [ 121.659982] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > [ 121.659987] usb 1-2: Product: External HDD > [ 121.659991] usb 1-2: Manufacturer: Western Digital > [ 121.659995] usb 1-2: SerialNumber: 57442D575835304136395033343438 > [ 126.660009] scsi 4:0:0:0: Direct-Access WD 3200BMV External 1.75 PQ: 0 ANSI: 4 > [ 126.676485] sd 4:0:0:0: [sdb] 625142448 512-byte hardware sectors: (320 GB/298 GiB) > [ 126.676975] sd 4:0:0:0: [sdb] Write Protect is off > [ 126.676980] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00 > [ 126.676985] sd 4:0:0:0: [sdb] Assuming drive cache: write through > [ 126.677725] sd 4:0:0:0: [sdb] 625142448 512-byte hardware sectors: (320 GB/298 GiB) > [ 126.678221] sd 4:0:0:0: [sdb] Write Protect is off > [ 126.678226] sd 4:0:0:0: [sdb] Mode Sense: 23 00 00 00 > [ 126.678230] sd 4:0:0:0: [sdb] Assuming drive cache: write through > [ 126.678238] sdb: unknown partition table > [ 126.723728] sd 4:0:0:0: [sdb] Attached SCSI disk > [ 126.723919] sd 4:0:0:0: Attached scsi generic sg1 type 0 > [ 126.724381] usb-storage: device scan complete > > > MSC Tests 2009-08-31 09-48-31WORKSTATION: OMICRON
> DATE: Monday, August 31, 2009
> TIME: 09:50:13 AM
> OPERATOR: Michael
> NUMBER OF TESTS: 22
> RESULT: passed
>

> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
InitializeTestSuite
INFO    Log initialized
> INFO    Microsoft Windows NT version 6.0 (Build 6000)
> INFO    Service Pack 0.0
> INFO    USBCommandVerifier.dll ver 1.3.3.3
> INFO    TestServices.dll ver 1.3.3.5
> INFO    StackSwitcher.dll ver 1.3.3.3
>
MSC SerialNumberTest_DeviceAddressedPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Serial Number Test (Configuration Index 0)
> 
> INFO    Start time: 09:48:42
> 
> INFO    Serial Number string for MSC device : iSerialNumber = 0x3
> INFO    ENGLISH_US           language string descriptor is : 57442D575835304136395033343438
> INFO    Using Language ID 0x409
> INFO    MSC Serial Number length = 62
> INFO    MSC Serial Number length = 62
> INFO    MSC Serial Number string descriptor type = 0x3
> INFO    MSC Serial Number length = 62
> INFO    MSC Serial Number string descriptor type = 0x3
> INFO    MSC Serial Number character [0] = 0x35
> INFO    MSC Serial Number character [1] = 0x37
> INFO    MSC Serial Number character [2] = 0x34
> INFO    MSC Serial Number character [3] = 0x34
> INFO    MSC Serial Number character [4] = 0x32
> INFO    MSC Serial Number character [5] = 0x44
> INFO    MSC Serial Number character [6] = 0x35
> INFO    MSC Serial Number character [7] = 0x37
> INFO    MSC Serial Number character [8] = 0x35
> INFO    MSC Serial Number character [9] = 0x38
> INFO    MSC Serial Number character [10] = 0x33
> INFO    MSC Serial Number character [11] = 0x35
> INFO    MSC Serial Number character [12] = 0x33
> INFO    MSC Serial Number character [13] = 0x30
> INFO    MSC Serial Number character [14] = 0x34
> INFO    MSC Serial Number character [15] = 0x31
> INFO    MSC Serial Number character [16] = 0x33
> INFO    MSC Serial Number character [17] = 0x36
> INFO    MSC Serial Number character [18] = 0x33
> INFO    MSC Serial Number character [19] = 0x39
> INFO    MSC Serial Number character [20] = 0x35
> INFO    MSC Serial Number character [21] = 0x30
> INFO    MSC Serial Number character [22] = 0x33
> INFO    MSC Serial Number character [23] = 0x33
> INFO    MSC Serial Number character [24] = 0x33
> INFO    MSC Serial Number character [25] = 0x34
> INFO    MSC Serial Number character [26] = 0x33
> INFO    MSC Serial Number character [27] = 0x34
> INFO    MSC Serial Number character [28] = 0x33
> INFO    MSC Serial Number character [29] = 0x38
> INFO    MSC Serial Number length = 62
> INFO    MSC Serial Number string descriptor type = 0x3
> INFO    MSC Serial Number character [0] = 0x35
> INFO    MSC Serial Number character [1] = 0x37
> INFO    MSC Serial Number character [2] = 0x34
> INFO    MSC Serial Number character [3] = 0x34
> INFO    MSC Serial Number character [4] = 0x32
> INFO    MSC Serial Number character [5] = 0x44
> INFO    MSC Serial Number character [6] = 0x35
> INFO    MSC Serial Number character [7] = 0x37
> INFO    MSC Serial Number character [8] = 0x35
> INFO    MSC Serial Number character [9] = 0x38
> INFO    MSC Serial Number character [10] = 0x33
> INFO    MSC Serial Number character [11] = 0x35
> INFO    MSC Serial Number character [12] = 0x33
> INFO    MSC Serial Number character [13] = 0x30
> INFO    MSC Serial Number character [14] = 0x34
> INFO    MSC Serial Number character [15] = 0x31
> INFO    MSC Serial Number character [16] = 0x33
> INFO    MSC Serial Number character [17] = 0x36
> INFO    MSC Serial Number character [18] = 0x33
> INFO    MSC Serial Number character [19] = 0x39
> INFO    MSC Serial Number character [20] = 0x35
> INFO    MSC Serial Number character [21] = 0x30
> INFO    MSC Serial Number character [22] = 0x33
> INFO    MSC Serial Number character [23] = 0x33
> INFO    MSC Serial Number character [24] = 0x33
> INFO    MSC Serial Number character [25] = 0x34
> INFO    MSC Serial Number character [26] = 0x33
> INFO    MSC Serial Number character [27] = 0x34
> INFO    MSC Serial Number character [28] = 0x33
> INFO    MSC Serial Number character [29] = 0x38
> INFO    Unconfiguring the device
> INFO    Stop time: 09:48:43
> INFO    Stopping Test [ USB Mass Storage Serial Number Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC SerialNumberTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Serial Number Test (Configuration Index 0)
> 
> INFO    Start time: 09:48:43
> 
> INFO    Serial Number string for MSC device : iSerialNumber = 0x3
> INFO    ENGLISH_US           language string descriptor is : 57442D575835304136395033343438
> INFO    Using Language ID 0x409
> INFO    MSC Serial Number length = 62
> INFO    MSC Serial Number length = 62
> INFO    MSC Serial Number string descriptor type = 0x3
> INFO    MSC Serial Number length = 62
> INFO    MSC Serial Number string descriptor type = 0x3
> INFO    MSC Serial Number character [0] = 0x35
> INFO    MSC Serial Number character [1] = 0x37
> INFO    MSC Serial Number character [2] = 0x34
> INFO    MSC Serial Number character [3] = 0x34
> INFO    MSC Serial Number character [4] = 0x32
> INFO    MSC Serial Number character [5] = 0x44
> INFO    MSC Serial Number character [6] = 0x35
> INFO    MSC Serial Number character [7] = 0x37
> INFO    MSC Serial Number character [8] = 0x35
> INFO    MSC Serial Number character [9] = 0x38
> INFO    MSC Serial Number character [10] = 0x33
> INFO    MSC Serial Number character [11] = 0x35
> INFO    MSC Serial Number character [12] = 0x33
> INFO    MSC Serial Number character [13] = 0x30
> INFO    MSC Serial Number character [14] = 0x34
> INFO    MSC Serial Number character [15] = 0x31
> INFO    MSC Serial Number character [16] = 0x33
> INFO    MSC Serial Number character [17] = 0x36
> INFO    MSC Serial Number character [18] = 0x33
> INFO    MSC Serial Number character [19] = 0x39
> INFO    MSC Serial Number character [20] = 0x35
> INFO    MSC Serial Number character [21] = 0x30
> INFO    MSC Serial Number character [22] = 0x33
> INFO    MSC Serial Number character [23] = 0x33
> INFO    MSC Serial Number character [24] = 0x33
> INFO    MSC Serial Number character [25] = 0x34
> INFO    MSC Serial Number character [26] = 0x33
> INFO    MSC Serial Number character [27] = 0x34
> INFO    MSC Serial Number character [28] = 0x33
> INFO    MSC Serial Number character [29] = 0x38
> INFO    MSC Serial Number length = 62
> INFO    MSC Serial Number string descriptor type = 0x3
> INFO    MSC Serial Number character [0] = 0x35
> INFO    MSC Serial Number character [1] = 0x37
> INFO    MSC Serial Number character [2] = 0x34
> INFO    MSC Serial Number character [3] = 0x34
> INFO    MSC Serial Number character [4] = 0x32
> INFO    MSC Serial Number character [5] = 0x44
> INFO    MSC Serial Number character [6] = 0x35
> INFO    MSC Serial Number character [7] = 0x37
> INFO    MSC Serial Number character [8] = 0x35
> INFO    MSC Serial Number character [9] = 0x38
> INFO    MSC Serial Number character [10] = 0x33
> INFO    MSC Serial Number character [11] = 0x35
> INFO    MSC Serial Number character [12] = 0x33
> INFO    MSC Serial Number character [13] = 0x30
> INFO    MSC Serial Number character [14] = 0x34
> INFO    MSC Serial Number character [15] = 0x31
> INFO    MSC Serial Number character [16] = 0x33
> INFO    MSC Serial Number character [17] = 0x36
> INFO    MSC Serial Number character [18] = 0x33
> INFO    MSC Serial Number character [19] = 0x39
> INFO    MSC Serial Number character [20] = 0x35
> INFO    MSC Serial Number character [21] = 0x30
> INFO    MSC Serial Number character [22] = 0x33
> INFO    MSC Serial Number character [23] = 0x33
> INFO    MSC Serial Number character [24] = 0x33
> INFO    MSC Serial Number character [25] = 0x34
> INFO    MSC Serial Number character [26] = 0x33
> INFO    MSC Serial Number character [27] = 0x34
> INFO    MSC Serial Number character [28] = 0x33
> INFO    MSC Serial Number character [29] = 0x38
> INFO    Unconfiguring the device
> INFO    Stop time: 09:48:44
> INFO    Stopping Test [ USB Mass Storage Serial Number Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC InterfaceDescriptorTest_DeviceAddressedPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Interface Descriptor Test (Configuration Index 0)
> 
> INFO    Start time: 09:48:44
> 
> INFO    MSC Interface Class code = 0x8
> INFO    MSC Interface Sub Class code = 0x6
> INFO    MSC Interface Protocol code = 0x50
> INFO    Number of endpoints for MSC Interface = 2
> INFO    Serial Number string for MSC device : iSerialNumber = 0x3
> INFO    Using Language ID 0x409
> INFO    Unconfiguring the device
> INFO    Stop time: 09:48:45
> INFO    Stopping Test [ USB Mass Storage Interface Descriptor Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC InterfaceDescriptorTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Interface Descriptor Test (Configuration Index 0)
> 
> INFO    Start time: 09:48:45
> 
> INFO    MSC Interface Class code = 0x8
> INFO    MSC Interface Sub Class code = 0x6
> INFO    MSC Interface Protocol code = 0x50
> INFO    Number of endpoints for MSC Interface = 2
> INFO    Serial Number string for MSC device : iSerialNumber = 0x3
> INFO    Using Language ID 0x409
> INFO    Unconfiguring the device
> INFO    Stop time: 09:48:46
> INFO    Stopping Test [ USB Mass Storage Interface Descriptor Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC ClassRequestTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Class Request Test (Configuration Index 0)
> 
> INFO    Start time: 09:48:46
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Issuing valid Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Issuing Get Max LUN request with invalid wIndex parameter
> INFO    Issuing Get Max LUN request with invalid wValue parameter
> INFO    Issuing Get Max LUN request with incorrect Length parameter (=0)
> INFO    Issuing Get Max LUN request with incorrect Length parameter (>1)
> INFO    Issuing valid Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Issuing valid BOT MSC Reset request
> INFO    Issuing BOT MSC Reset request with incorrect wIndex parameter
> INFO    Issuing BOT MSC Reset request with incorrect wValue parameter
> INFO    Issuing BOT MSC Reset request with incorrect Length parameter (>0)
> INFO    Issuing valid BOT MSC Reset request
> INFO    Unconfiguring the device
> INFO    Stop time: 09:48:53
> INFO    Stopping Test [ USB Mass Storage Class Request Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC ErrorRecoveryTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Error Recovery Test (Configuration Index 0)
> 
> INFO    Start time: 09:48:53
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Issue CBW with invalid signature
> INFO    Issuing invalid CBW
> INFO    CBW successful
> INFO    Issuing CSW 2 times, CSW should stall in every case
> INFO    Issuing CSW 1
> INFO    Issuing CSW 2
> INFO    Retrieving status on CSW endpoint
> INFO    CSW endpoint status = 0x1
> INFO    CSW endpoint stalled
> INFO    Clearing stalled CSW endpoint
> INFO    Issuing CSW 2 times, CSW should stall in every case
> INFO    Issuing CSW 1
> INFO    Bulk Request timed out!
> ERROR   Invalid response, CSW should STALL
> INFO    *************************
> WARNING (5.2.1) Devices receiving a CBW with an invalid signature should stall 
>  further traffic on the Bulk In pipe, and either stall further traffic 
>  or accept and discard further traffic on the Bulk Out pipe, until 
>  reset recovery.  If the device does not react in this manner, it 
>  should at least respond correctly to a Reset Recovery.
> INFO    *************************
> INFO    Issuing BOT MSC Reset, reset should always succeed
> INFO    Retrieving status on CBW endpoint
> INFO    CBW endpoint status = 0x0
> INFO    Retrieving status on CSW endpoint
> INFO    CSW endpoint status = 0x0
> INFO    Issuing required command (Test Unit Ready) to verify device has recovered
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issue a short CBW (<31 bytes)
> INFO    Issuing invalid CBW
> INFO    CBW successful
> INFO    Issuing CSW 2 times, CSW should stall in every case
> INFO    Issuing CSW 1
> INFO    Issuing CSW 2
> INFO    Retrieving status on CSW endpoint
> INFO    CSW endpoint status = 0x1
> INFO    CSW endpoint stalled
> INFO    Clearing stalled CSW endpoint
> INFO    Issuing CSW 2 times, CSW should stall in every case
> INFO    Issuing CSW 1
> INFO    Bulk Request timed out!
> ERROR   Invalid response, CSW should STALL
> INFO    *************************
> WARNING (5.2.2) Devices receiving a CBW with the wrong length should stall 
>  further traffic on the Bulk In pipe, and either stall further 
>  traffic or accept and discard further traffic on the Bulk Out 
>  pipe, until reset recovery.  If the device does not react in this 
>  manner, it should at least respond correctly to a Reset Recovery.
> INFO    *************************
> INFO    Issuing BOT MSC Reset, reset should always succeed
> INFO    Retrieving status on CBW endpoint
> INFO    CBW endpoint status = 0x0
> INFO    Retrieving status on CSW endpoint
> INFO    CSW endpoint status = 0x0
> INFO    Issuing required command (Test Unit Ready) to verify device has recovered
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issue a long CBW (>31 bytes)
> INFO    Issuing invalid CBW
> INFO    CBW successful
> INFO    Issuing CSW 2 times, CSW should stall in every case
> INFO    Issuing CSW 1
> INFO    Issuing CSW 2
> INFO    Retrieving status on CSW endpoint
> INFO    CSW endpoint status = 0x1
> INFO    CSW endpoint stalled
> INFO    Clearing stalled CSW endpoint
> INFO    Issuing CSW 2 times, CSW should stall in every case
> INFO    Issuing CSW 1
> INFO    Bulk Request timed out!
> ERROR   Invalid response, CSW should STALL
> INFO    *************************
> WARNING (5.2.2) Devices receiving a CBW with the wrong length should stall 
>  further traffic on the Bulk In pipe, and either stall further 
>  traffic or accept and discard further traffic on the Bulk Out 
>  pipe, until reset recovery.  If the device does not react in this 
>  manner, it should at least respond correctly to a Reset Recovery.
> INFO    *************************
> INFO    Issuing BOT MSC Reset, reset should always succeed
> INFO    Retrieving status on CBW endpoint
> INFO    CBW endpoint status = 0x0
> INFO    Retrieving status on CSW endpoint
> INFO    CSW endpoint status = 0x0
> INFO    Issuing required command (Test Unit Ready) to verify device has recovered
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:25
> INFO    Stopping Test [ USB Mass Storage Error Recovery Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (3) ]
> 
> 
> 
>
MSC CaseOneTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case One Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:25
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 1 (Hn = Dn)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:26
> INFO    Stopping Test [ USB Mass Storage Case One Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseTwoTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Two Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:26
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 2 (Hn < Di)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x28
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x1
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x2
> INFO    CSW reported a phase error, issuing BOT MSC Reset
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:27
> INFO    Stopping Test [ USB Mass Storage Case Two Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseThreeTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Three Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:27
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 3 (Hn < Do)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x1
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x2
> INFO    CSW reported a phase error, issuing BOT MSC Reset
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:28
> INFO    Stopping Test [ USB Mass Storage Case Three Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseFourTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Four Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:28
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 4 (Hi > Dn)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x200
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x28
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    DATA phase stalled
> INFO    Retrieving status on stalled bulk endpoint
> INFO    Bulk endpoint status = 0x1
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x200
> INFO    CSW status returned = 0x0
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:29
> INFO    Stopping Test [ USB Mass Storage Case Four Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseFiveTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Five Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:29
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 5 (Hi > Di)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x400
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x28
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x1
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    DATA phase stalled
> INFO    Retrieving status on stalled bulk endpoint
> INFO    Bulk endpoint status = 0x1
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x200
> INFO    CSW status returned = 0x0
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:30
> INFO    Stopping Test [ USB Mass Storage Case Five Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseSixTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Six Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:30
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 6 (Hi = Di)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x200
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x28
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x1
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:31
> INFO    Stopping Test [ USB Mass Storage Case Six Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseSevenTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Seven Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:31
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 7 (Hi < Di)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x200
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x28
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x2
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    DATA phase stalled
> INFO    Retrieving status on stalled bulk endpoint
> INFO    Bulk endpoint status = 0x1
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x2
> INFO    CSW reported a phase error, issuing BOT MSC Reset
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:32
> INFO    Stopping Test [ USB Mass Storage Case Seven Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseEightTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Eight Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:33
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 8 (Hi <> Do)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x200
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x1
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    DATA phase stalled
> INFO    Retrieving status on stalled bulk endpoint
> INFO    Bulk endpoint status = 0x1
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x200
> INFO    CSW status returned = 0x2
> INFO    CSW reported a phase error, issuing BOT MSC Reset
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:34
> INFO    Stopping Test [ USB Mass Storage Case Eight Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseNineTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Nine Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:34
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 9 (Ho > Dn)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x200
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x200
> INFO    CSW status returned = 0x0
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:35
> INFO    Stopping Test [ USB Mass Storage Case Nine Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseTenTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Ten Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:35
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 10 (Ho <> Di)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x200
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x28
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x1
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x200
> INFO    CSW status returned = 0x2
> INFO    CSW reported a phase error, issuing BOT MSC Reset
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:36
> INFO    Stopping Test [ USB Mass Storage Case Ten Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseElevenTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Eleven Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:36
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 11 (Ho > Do)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x400
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x1
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x200
> INFO    CSW status returned = 0x0
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:37
> INFO    Stopping Test [ USB Mass Storage Case Eleven Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseTwelveTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Twelve Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:37
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 12 (Ho = Do)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x400
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x2
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:38
> INFO    Stopping Test [ USB Mass Storage Case Twelve Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CaseThirteenTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Case Thirteen Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:38
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing BOT Case 13 (Ho < Do)
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x200
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x2
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x200
> INFO    CSW status returned = 0x2
> INFO    CSW reported a phase error, issuing BOT MSC Reset
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:39
> INFO    Stopping Test [ USB Mass Storage Case Thirteen Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CBLengthTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage CBLength Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:39
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing CBLength test w/ pad bytes = 0xff
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing CBLength test w/ pad bytes = 0x55
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing CBLength test w/ pad bytes = 0xaa
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:40
> INFO    Stopping Test [ USB Mass Storage CBLength Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CommandSetTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Required Command Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:40
> 
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x12, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x12, Test Variation #2
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x1
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x1
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x12, Test Variation #3
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x2
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x2
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x12, Test Variation #4
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x4
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x4
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x12, Test Variation #5
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x5
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x5
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x12, Test Variation #6
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x12, Test Variation #7
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0xff
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0xff
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    *************************
> WARNING Expecting a STALL after data phase completes with a zero-length or short packet
> INFO    *************************
> INFO    If the device actually transfers less data than the host indicated, the device shall STALL the Bulk-In pipe
> INFO    CSW residue returned = 0xb5
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x03, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x3
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x03, Test Variation #2
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x1
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x3
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x1
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x03, Test Variation #3
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x2
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x3
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x2
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x03, Test Variation #4
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x12
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x3
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x12
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x03, Test Variation #5
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0xff
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x3
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0xff
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    *************************
> WARNING Expecting a STALL after data phase completes with a zero-length or short packet
> INFO    *************************
> INFO    If the device actually transfers less data than the host indicated, the device shall STALL the Bulk-In pipe
> INFO    CSW residue returned = 0xed
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x00, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x28, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x1000
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x28
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x8
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x28, Test Variation #2
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x2000
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x28
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x10
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x28, Test Variation #3
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x4000
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x28
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x20
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x28, Test Variation #4
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8000
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x28
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x40
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x28, Test Variation #5
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x10000
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x28
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x80
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0xa8, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x1000
> INFO    |----- CBW CDB Length           = 0xc
> INFO    |----- CBW CDB-00 = 0xa8
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x8
> INFO    |----- CBW CDB-10 = 0x0
> INFO    |----- CBW CDB-11 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0xa8, Test Variation #2
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x2000
> INFO    |----- CBW CDB Length           = 0xc
> INFO    |----- CBW CDB-00 = 0xa8
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x10
> INFO    |----- CBW CDB-10 = 0x0
> INFO    |----- CBW CDB-11 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0xa8, Test Variation #3
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x4000
> INFO    |----- CBW CDB Length           = 0xc
> INFO    |----- CBW CDB-00 = 0xa8
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x20
> INFO    |----- CBW CDB-10 = 0x0
> INFO    |----- CBW CDB-11 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0xa8, Test Variation #4
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8000
> INFO    |----- CBW CDB Length           = 0xc
> INFO    |----- CBW CDB-00 = 0xa8
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x40
> INFO    |----- CBW CDB-10 = 0x0
> INFO    |----- CBW CDB-11 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0xa8, Test Variation #5
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x10000
> INFO    |----- CBW CDB Length           = 0xc
> INFO    |----- CBW CDB-00 = 0xa8
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x80
> INFO    |----- CBW CDB-10 = 0x0
> INFO    |----- CBW CDB-11 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x25, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x2a, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x1000
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x8
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x2a, Test Variation #2
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x2000
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x10
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x2a, Test Variation #3
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x4000
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x20
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x2a, Test Variation #4
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x8000
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x40
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x2a, Test Variation #5
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x10000
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x80
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0xaa, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x1000
> INFO    |----- CBW CDB Length           = 0xc
> INFO    |----- CBW CDB-00 = 0xaa
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x8
> INFO    |----- CBW CDB-10 = 0x0
> INFO    |----- CBW CDB-11 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0xaa, Test Variation #2
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x2000
> INFO    |----- CBW CDB Length           = 0xc
> INFO    |----- CBW CDB-00 = 0xaa
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x10
> INFO    |----- CBW CDB-10 = 0x0
> INFO    |----- CBW CDB-11 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0xaa, Test Variation #3
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x4000
> INFO    |----- CBW CDB Length           = 0xc
> INFO    |----- CBW CDB-00 = 0xaa
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x20
> INFO    |----- CBW CDB-10 = 0x0
> INFO    |----- CBW CDB-11 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0xaa, Test Variation #4
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x8000
> INFO    |----- CBW CDB Length           = 0xc
> INFO    |----- CBW CDB-00 = 0xaa
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x40
> INFO    |----- CBW CDB-10 = 0x0
> INFO    |----- CBW CDB-11 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0xaa, Test Variation #5
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x10000
> INFO    |----- CBW CDB Length           = 0xc
> INFO    |----- CBW CDB-00 = 0xaa
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x80
> INFO    |----- CBW CDB-10 = 0x0
> INFO    |----- CBW CDB-11 = 0x0
> INFO    Issuing DATA OUT
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x15, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x15
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x55, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x55
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x1a, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x4
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x1a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x3f
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x4
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x5a, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x5a
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x3f
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x8
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x1e, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x1e
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x1
> INFO    Request failed, issuing Request Sense
> INFO    Issuing CBW:
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x12
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x3
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x12
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    REQUEST_SENSE - Key = 0x5, Code = 0x20, Qualifier  0x0
> INFO    Allowing Errors on odd-byte transfers
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x1b, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x1b
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x1
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Command Set Test for Op Code 0x43 not applicable for PDT = 0x00
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Issuing Command Set Test for Op Code 0x2f, Test Variation #1
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2f
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x8
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x2f, Test Variation #2
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2f
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x10
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x2f, Test Variation #3
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2f
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x20
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x2f, Test Variation #4
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2f
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x40
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Issuing Command Set Test for Op Code 0x2f, Test Variation #5
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x2f
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x80
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Unconfiguring the device
> INFO    Stop time: 09:49:41
> INFO    Stopping Test [ USB Mass Storage Required Command Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (2) ]
> 
> 
> 
>
MSC PowerUpTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: USB Mass Storage Power Up Test (Configuration Index 0)
> 
> INFO    Start time: 09:49:42
> 
> INFO    Attempting to re-enumerate device
> ERROR   CVHub_ReEnumerateAll::Could not find device under test after enumeration
> ERROR   CVHub_ReEnumerateAll::Could not find device under test after enumeration
> ERROR   CVHub_ReEnumerateAll::Could not find device under test after enumeration
> ERROR   CVHub_ReEnumerateAll::Could not find device under test after enumeration
> ERROR   CVHub_ReEnumerateAll::Could not find device under test after enumeration
> ERROR   CVHub_ReEnumerateAll::Could not find device under test after enumeration
> ERROR   CVHub_ReEnumerateAll::Could not find device under test after enumeration
> ERROR   CVHub_ReEnumerateAll::Could not find device under test after enumeration
> ERROR   CVHub_ReEnumerateAll::Could not find device under test after enumeration
> INFO    Device has been re-enumerated, perform PowerUp test
> INFO    Configuring device, set configuration = 0x1
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetConfiguration call
> INFO    Setting device interface, interface number = 0x0 and alternate setting = 0x0
> INFO    NOTE: It is expected the device has reset the data toggles on all Bulk endpoints after the above SetInterface call
> INFO    Issuing Get Max LUN request
> INFO    Max LUN value = 0
> INFO    Getting Device Type
> INFO    Issuing INQUIRY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x24
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x12
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x24
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    INQUIRY - Devicetype = 0x0
> INFO    **
> INFO    Now testing device 'WD       : 3200BMV External', LUN - 0
> INFO    **
> INFO    Waiting for device to become ready...
> INFO    Issuing TEST UNIT READY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x0
> INFO    |----- CBW Data Transfer Length = 0x0
> INFO    |----- CBW CDB Length           = 0x6
> INFO    |----- CBW CDB-00 = 0x0
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    Device ready
> INFO    Getting Device BlockSize
> INFO    Issuing READ_CAPACITY
> INFO    Issuing CBW (attempt #1):
> INFO    |----- CBW LUN                  = 0x0
> INFO    |----- CBW Flags                = 0x80
> INFO    |----- CBW Data Transfer Length = 0x8
> INFO    |----- CBW CDB Length           = 0xa
> INFO    |----- CBW CDB-00 = 0x25
> INFO    |----- CBW CDB-01 = 0x0
> INFO    |----- CBW CDB-02 = 0x0
> INFO    |----- CBW CDB-03 = 0x0
> INFO    |----- CBW CDB-04 = 0x0
> INFO    |----- CBW CDB-05 = 0x0
> INFO    |----- CBW CDB-06 = 0x0
> INFO    |----- CBW CDB-07 = 0x0
> INFO    |----- CBW CDB-08 = 0x0
> INFO    |----- CBW CDB-09 = 0x0
> INFO    Issuing DATA IN
> INFO    Issuing CSW : try 1
> INFO    CSW residue returned = 0x0
> INFO    CSW status returned = 0x0
> INFO    READ_CAPACITY - LBA = 0x2542eaaf, BlockSize = 0x200
> INFO    Unconfiguring the device
> INFO    Stop time: 09:50:13
> INFO    Stopping Test [ USB Mass Storage Power Up Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
MSC CompleteTests
INFO    **
> INFO    Device is considered compliant with the Bootability specification.
> INFO    **
> INFO    Summary Log Counts [ Fails (0); Aborts (0); Warnings (5) ]
>
> > > Chapter 9 Tests 2009-08-31 09-53-09WORKSTATION: OMICRON
> DATE: Monday, August 31, 2009
> TIME: 09:54:23 AM
> OPERATOR: Michael
> NUMBER OF TESTS: 21
> RESULT: passed
>

> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
InitializeTestSuite
INFO    Log initialized
> INFO    Microsoft Windows NT version 6.0 (Build 6000)
> INFO    Service Pack 0.0
> INFO    USBCommandVerifier.dll ver 1.3.3.3
> INFO    TestServices.dll ver 1.3.3.5
> INFO    StackSwitcher.dll ver 1.3.3.3
>
DeviceDescriptorTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Device Descriptor Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:17
> 
> INFO    Device descriptor length : 12
> INFO    Device descriptor type : 1
> INFO    Major version : 2
> INFO    Minor version : 0
> INFO    Each interface specifies its own device class type
> INFO    Device sub class : 0
> INFO    Device protocol : 0
> INFO    Device MaxPacketSize0 : 40
> ABORT   Create file on 'usb.if' failed
> WARNING Failed to get vendor information for VendorID : 1058
> INFO    Device ProductID : 704
> INFO    Device BCD : 175
> INFO    ENGLISH_US           language string descriptor is : Western Digital 
> INFO    ENGLISH_US           language string descriptor is : External HDD    
> INFO    ENGLISH_US           language string descriptor is : 57442D575835304136395033343438
> INFO    Number of configurations device supports : 1
> INFO    Stop time: 09:53:18
> INFO    Stopping Test [ Device Descriptor Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (1); Warnings (1) ]
> 
> 
> 
>
DeviceDescriptorTest_DeviceAddressedPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Device Descriptor Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:18
> 
> INFO    Device descriptor length : 12
> INFO    Device descriptor type : 1
> INFO    Major version : 2
> INFO    Minor version : 0
> INFO    Each interface specifies its own device class type
> INFO    Device sub class : 0
> INFO    Device protocol : 0
> INFO    Device MaxPacketSize0 : 40
> ABORT   Create file on 'usb.if' failed
> WARNING Failed to get vendor information for VendorID : 1058
> INFO    Device ProductID : 704
> INFO    Device BCD : 175
> INFO    ENGLISH_US           language string descriptor is : Western Digital 
> INFO    ENGLISH_US           language string descriptor is : External HDD    
> INFO    ENGLISH_US           language string descriptor is : 57442D575835304136395033343438
> INFO    Number of configurations device supports : 1
> INFO    Stop time: 09:53:19
> INFO    Stopping Test [ Device Descriptor Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (1); Warnings (1) ]
> 
> 
> 
>
ConfigDescriptorTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Configuration Descriptor Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:19
> 
> INFO    Number of interface descriptors found 1
> INFO    Number of alternate interface descriptors found : 0
> INFO    Number of endpoint descriptors found : 2
> INFO    Configuration descriptor length : 9
> INFO    Configuration descriptor type : 2
> INFO    Configuration descriptor TotalLength : 20
> INFO    Configuration descriptor NumInterfaces : 1
> INFO    Configuration descriptor ConfigurationValue: 1
> INFO    Configuration descriptor string descriptor index : 0
> INFO    Configuration descriptor bmAttributes : c0
> INFO    Device does not support remote wake up
> INFO    Maximum power device requires : 2mA
> INFO    Device is BUS/SELF-POWERED
> INFO    Device is currently SELF POWERED
> INFO    Currently remote wakeup is DISABLED
> INFO    Stop time: 09:53:20
> INFO    Stopping Test [ Configuration Descriptor Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
ConfigDescriptorTest_DeviceAddressedPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Configuration Descriptor Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:20
> 
> INFO    Number of interface descriptors found 1
> INFO    Number of alternate interface descriptors found : 0
> INFO    Number of endpoint descriptors found : 2
> INFO    Configuration descriptor length : 9
> INFO    Configuration descriptor type : 2
> INFO    Configuration descriptor TotalLength : 20
> INFO    Configuration descriptor NumInterfaces : 1
> INFO    Configuration descriptor ConfigurationValue: 1
> INFO    Configuration descriptor string descriptor index : 0
> INFO    Configuration descriptor bmAttributes : c0
> INFO    Device does not support remote wake up
> INFO    Maximum power device requires : 2mA
> INFO    Device is BUS/SELF-POWERED
> INFO    Device is currently SELF POWERED
> INFO    Currently remote wakeup is DISABLED
> INFO    Stop time: 09:53:21
> INFO    Stopping Test [ Configuration Descriptor Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
InterfaceDescriptorTestPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Interface Descriptor Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:21
> 
> INFO    Bandwidth check passed
> INFO    Testing Interface number : 0 Alternate setting : 0
> INFO    Interface descriptor length : 9
> INFO    Interface descriptor bDescriptorType : 4
> INFO    Interface descriptor bAlternateSetting : 0
> INFO    Interface descriptor bNumEndPoints: 2
> INFO    Interface descriptor bInterfaceClass reserved for assignment by the USB-IF : 8
> INFO    Interface class code indicates [Mass-Storage] Interface
> INFO    Interface descriptor bInterfaceSubClass : 6
> INFO    Interface descriptor bInterfaceProtocol assigned by the USB-IF : 50
> INFO    Interface descriptor iInterface : 0x0
> INFO    Stop time: 09:53:22
> INFO    Stopping Test [ Interface Descriptor Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
EndpointDescriptorTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Endpoint Descriptor Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:22
> 
> INFO    Testing Interface number : 0 Alternate setting : 0
> INFO    Endpoint descriptor length : 7
> INFO    Endpoint descriptor type : 5
> INFO    Endpoint Type : Bulk, Number : 1, Direction : IN
> INFO    Endpoint descriptor bmAttributes : 2
> INFO    Endpoint descriptor raw MaxPacketSize : 200
> INFO    Endpoint descriptor interval : 0
> INFO    Endpoint descriptor length : 7
> INFO    Endpoint descriptor type : 5
> INFO    Endpoint Type : Bulk, Number : 2, Direction : OUT
> INFO    Endpoint descriptor bmAttributes : 2
> INFO    Endpoint descriptor raw MaxPacketSize : 200
> INFO    Endpoint descriptor interval : 0
> INFO    Stop time: 09:53:23
> INFO    Stopping Test [ Endpoint Descriptor Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
EndpointDescriptorTest_DeviceAddressedPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Endpoint Descriptor Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:23
> 
> INFO    Testing Interface number : 0 Alternate setting : 0
> INFO    Endpoint descriptor length : 7
> INFO    Endpoint descriptor type : 5
> INFO    Endpoint Type : Bulk, Number : 1, Direction : IN
> INFO    Endpoint descriptor bmAttributes : 2
> INFO    Endpoint descriptor raw MaxPacketSize : 200
> INFO    Endpoint descriptor interval : 0
> INFO    Endpoint descriptor length : 7
> INFO    Endpoint descriptor type : 5
> INFO    Endpoint Type : Bulk, Number : 2, Direction : OUT
> INFO    Endpoint descriptor bmAttributes : 2
> INFO    Endpoint descriptor raw MaxPacketSize : 200
> INFO    Endpoint descriptor interval : 0
> INFO    Stop time: 09:53:24
> INFO    Stopping Test [ Endpoint Descriptor Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
HaltEndpointTestPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Halt Endpoint Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:24
> 
> INFO    Testing Interface number : 0 Alternate setting : 0
> INFO    Testing EndPoint type : Bulk, Address : 81
> INFO    Endpoint is currently not halted
> INFO    Endpoint is halted
> INFO    Cleared endpoint halt
> INFO    Testing EndPoint type : Bulk, Address : 2
> INFO    Endpoint is currently not halted
> INFO    Endpoint is halted
> INFO    Cleared endpoint halt
> INFO    Stop time: 09:53:25
> INFO    Stopping Test [ Halt Endpoint Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
SetConfigurationTestPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: SetConfiguration Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:25
> 
> INFO    SetConfiguration with configuration value : 1
> INFO    Unconfigured the device
> INFO    SetConfiguration with configuration value : 1
> INFO    Stop time: 09:53:26
> INFO    Stopping Test [ SetConfiguration Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
SuspendResumeTestPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Suspend/Resume Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:26
> 
> INFO    Suspended the parent port of the device
> INFO    Stop time: 09:53:28
> INFO    Stopping Test [ Suspend/Resume Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
RemoteWakeupTestEnabledPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Remote Wakeup Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:28
> 
> INFO    The device does not support remote wakeup
> INFO    Stop time: 09:53:29
> INFO    Stopping Test [ Remote Wakeup Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
RemoteWakeupTestDisabledPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Remote Wakeup Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:29
> 
> INFO    The device does not support remote wakeup
> INFO    Stop time: 09:53:30
> INFO    Stopping Test [ Remote Wakeup Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
OtherSpeedConfigTest_DeviceAddressedPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Other Speed Configuration Test (Configuration Index 0 OtherSpeedConfiguration Index 0)
> 
> INFO    Start time: 09:53:30
> 
> INFO    Number of interface descriptors found 1
> INFO    Number of alternate interface descriptors found : 0
> INFO    Number of endpoint descriptors found : 2
> INFO    Configuration descriptor length : 9
> INFO    Configuration descriptor type : 7
> INFO    Configuration descriptor TotalLength : 20
> INFO    Configuration descriptor NumInterfaces : 1
> INFO    Configuration descriptor ConfigurationValue: 1
> INFO    Configuration descriptor string descriptor index : 0
> INFO    Configuration descriptor bmAttributes : c0
> INFO    Device does not support remote wake up
> INFO    Maximum power device requires : 2mA
> INFO    Device is BUS/SELF-POWERED
> INFO    Stop time: 09:53:31
> INFO    Stopping Test [ Other Speed Configuration Test (Configuration Index 0 OtherSpeedConfiguration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
OtherSpeedInterfaceDescriptorTest_DeviceAddressedPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Interface Descriptor Test (Configuration Index 0 OtherSpeedConfiguration Index 0)
> 
> INFO    Start time: 09:53:31
> 
> INFO    Bandwidth check passed
> INFO    Testing Interface number : 0 Alternate setting : 0
> INFO    Interface descriptor length : 9
> INFO    Interface descriptor bDescriptorType : 4
> INFO    Interface descriptor bAlternateSetting : 0
> INFO    Interface descriptor bNumEndPoints: 2
> INFO    Interface descriptor bInterfaceClass reserved for assignment by the USB-IF : 8
> INFO    Interface class code indicates [Mass-Storage] Interface
> INFO    Interface descriptor bInterfaceSubClass : 6
> INFO    Interface descriptor bInterfaceProtocol assigned by the USB-IF : 50
> INFO    Interface descriptor iInterface : 0x0
> INFO    Stop time: 09:53:32
> INFO    Stopping Test [ Interface Descriptor Test (Configuration Index 0 OtherSpeedConfiguration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
OtherSpeedEndpointDescriptorTest_DeviceAddressedPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Endpoint Descriptor Test (Configuration Index 0 OtherSpeedConfiguration Index 0)
> 
> INFO    Start time: 09:53:32
> 
> INFO    Testing Interface number : 0 Alternate setting : 0
> INFO    Endpoint descriptor length : 7
> INFO    Endpoint descriptor type : 5
> INFO    Endpoint Type : Bulk, Number : 1, Direction : IN
> INFO    Endpoint descriptor bmAttributes : 2
> INFO    Endpoint descriptor raw MaxPacketSize : 40
> INFO    Endpoint descriptor interval : 0
> INFO    Endpoint descriptor length : 7
> INFO    Endpoint descriptor type : 5
> INFO    Endpoint Type : Bulk, Number : 2, Direction : OUT
> INFO    Endpoint descriptor bmAttributes : 2
> INFO    Endpoint descriptor raw MaxPacketSize : 40
> INFO    Endpoint descriptor interval : 0
> INFO    Stop time: 09:53:33
> INFO    Stopping Test [ Endpoint Descriptor Test (Configuration Index 0 OtherSpeedConfiguration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
DeviceQualifierTest_DeviceAddressedPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Device Qualifier Descriptor Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:33
> 
> INFO    Device qualifier length : a
> INFO    Device qualifier type : 6
> INFO    Major version : 2
> INFO    Minor version : 0
> INFO    Device Qualifier device class : 0
> INFO    Device qualifier device subclass : 0
> INFO    Device qualifier device protocol : 0
> INFO    Device qualifier MaxPacketSize0 : 40
> INFO    Device qualifier bNumConfigurations : 1
> INFO    Stop time: 09:53:34
> INFO    Stopping Test [ Device Qualifier Descriptor Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
DeviceQualifierTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Device Qualifier Descriptor Test (Configuration Index 0)
> 
> INFO    Start time: 09:53:34
> 
> INFO    Device qualifier length : a
> INFO    Device qualifier type : 6
> INFO    Major version : 2
> INFO    Minor version : 0
> INFO    Device Qualifier device class : 0
> INFO    Device qualifier device subclass : 0
> INFO    Device qualifier device protocol : 0
> INFO    Device qualifier MaxPacketSize0 : 40
> INFO    Device qualifier bNumConfigurations : 1
> INFO    Stop time: 09:53:35
> INFO    Stopping Test [ Device Qualifier Descriptor Test (Configuration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
OtherSpeedConfigTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Other Speed Configuration Test (Configuration Index 0 OtherSpeedConfiguration Index 0)
> 
> INFO    Start time: 09:53:35
> 
> INFO    Number of interface descriptors found 1
> INFO    Number of alternate interface descriptors found : 0
> INFO    Number of endpoint descriptors found : 2
> INFO    Configuration descriptor length : 9
> INFO    Configuration descriptor type : 7
> INFO    Configuration descriptor TotalLength : 20
> INFO    Configuration descriptor NumInterfaces : 1
> INFO    Configuration descriptor ConfigurationValue: 1
> INFO    Configuration descriptor string descriptor index : 0
> INFO    Configuration descriptor bmAttributes : c0
> INFO    Device does not support remote wake up
> INFO    Maximum power device requires : 2mA
> INFO    Device is BUS/SELF-POWERED
> INFO    Stop time: 09:53:36
> INFO    Stopping Test [ Other Speed Configuration Test (Configuration Index 0 OtherSpeedConfiguration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
OtherSpeedInterfaceDescriptorTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Interface Descriptor Test (Configuration Index 0 OtherSpeedConfiguration Index 0)
> 
> INFO    Start time: 09:53:36
> 
> INFO    Bandwidth check passed
> INFO    Testing Interface number : 0 Alternate setting : 0
> INFO    Interface descriptor length : 9
> INFO    Interface descriptor bDescriptorType : 4
> INFO    Interface descriptor bAlternateSetting : 0
> INFO    Interface descriptor bNumEndPoints: 2
> INFO    Interface descriptor bInterfaceClass reserved for assignment by the USB-IF : 8
> INFO    Interface class code indicates [Mass-Storage] Interface
> INFO    Interface descriptor bInterfaceSubClass : 6
> INFO    Interface descriptor bInterfaceProtocol assigned by the USB-IF : 50
> INFO    Interface descriptor iInterface : 0x0
> INFO    Stop time: 09:53:37
> INFO    Stopping Test [ Interface Descriptor Test (Configuration Index 0 OtherSpeedConfiguration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
OtherSpeedEndpointDescriptorTest_DeviceConfiguredPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Endpoint Descriptor Test (Configuration Index 0 OtherSpeedConfiguration Index 0)
> 
> INFO    Start time: 09:53:37
> 
> INFO    Testing Interface number : 0 Alternate setting : 0
> INFO    Endpoint descriptor length : 7
> INFO    Endpoint descriptor type : 5
> INFO    Endpoint Type : Bulk, Number : 1, Direction : IN
> INFO    Endpoint descriptor bmAttributes : 2
> INFO    Endpoint descriptor raw MaxPacketSize : 40
> INFO    Endpoint descriptor interval : 0
> INFO    Endpoint descriptor length : 7
> INFO    Endpoint descriptor type : 5
> INFO    Endpoint Type : Bulk, Number : 2, Direction : OUT
> INFO    Endpoint descriptor bmAttributes : 2
> INFO    Endpoint descriptor raw MaxPacketSize : 40
> INFO    Endpoint descriptor interval : 0
> INFO    Stop time: 09:53:38
> INFO    Stopping Test [ Endpoint Descriptor Test (Configuration Index 0 OtherSpeedConfiguration Index 0):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
EnumerationTestPassed
INFO    
> 
> ===============
> 
> 
> 
> Now Starting Test: Enumeration Test (repeat 150 times)
> 
> INFO    Start time: 09:53:38
> 
> INFO    Device speed is High
> INFO    Stop time: 09:54:14
> INFO    Stopping Test [ Enumeration Test (repeat 150 times):
>      Number of: Fails (0); Aborts (0); Warnings (0) ]
> 
> 
> 
>
Summary
INFO    Summary Log Counts [ Fails (0); Aborts (2); Warnings (2) ]
>
-- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 19:54:26 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 BFAA0106566C; Mon, 31 Aug 2009 19:54:26 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5C2C78FC0A; Mon, 31 Aug 2009 19:54:25 +0000 (UTC) Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 31 Aug 2009 15:54:25 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.10.7-GA) with ESMTP id LCD55488; Mon, 31 Aug 2009 15:53:39 -0400 (EDT) X-Auth-ID: roberthuff Received: from 209-6-159-252.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO [209.6.159.252]) ([209.6.159.252]) by smtp01.lnh.mail.rcn.net with ESMTP; 31 Aug 2009 15:53:22 -0400 Message-ID: <4A9C2A0E.4010203@rcn.com> Date: Mon, 31 Aug 2009 15:52:46 -0400 From: Robert Huff User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Randi Harper References: <4A8AD86E.5020302@rcn.com> <4A8B4679.7090704@rcn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Junkmail-Whitelist: YES (by domain whitelist at mr08.lnh.mail.rcn.net) Cc: current@freebsd.org Subject: Re: HEAD newfs/sysinstall issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 19:54:26 -0000 Hello: About two weeks ago we had a discussion about my inability to complete an install because the partition/label part of sysinstall was getting confused. Your last comment was: > This all really comes down to some geom weirdness. In the latest builds > of sysinstall, the dd option has been removed from the menu - but you > won't see this until BETA3. Are you using BETA2 install media or did you > build your own? Well, now I'm using the beta-3/amd64 dvd, and I've still got the problem. Robert Huff From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 20:26: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 69854106566C for ; Mon, 31 Aug 2009 20:26: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 037F28FC18 for ; Mon, 31 Aug 2009 20:26:55 +0000 (UTC) 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 n7VKQoBv019134 for ; Mon, 31 Aug 2009 22:26:51 +0200 Received: from ubm.mine.nu ([85.181.48.119] helo=ubm.mine.nu) by ASSP.nospam.UpPeRnEt; 31 Aug 2009 22:26:50 +0200 Date: Mon, 31 Aug 2009 22:26:50 +0200 From: Marc "UBM" Bocklet To: current@freebsd.org Message-Id: <20090831222650.45b6c806.ubm@u-boot-man.de> In-Reply-To: <200908241631.06112.jhb@freebsd.org> References: <20090822115958.f93fcf29.ubm.freebsd@gmail.com> <200908241631.06112.jhb@freebsd.org> X-Mailer: Sylpheed 2.7.0 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 31 Aug 2009 20:28:17 +0000 Cc: Subject: Re: panic: apic_free_vector: Thread already bound. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 20:26:56 -0000 On Mon, 24 Aug 2009 16:31:05 -0400 John Baldwin wrote: > On Saturday 22 August 2009 5:59:58 am Marc UBM wrote: > > > > Hiho! :-) > > > > I'm seeing above panic in the final stages of the shutdown process. > > Coredump is available, bt as follows, textdump attached. > > > > > > FreeBSD hamstor 8.0-BETA2 FreeBSD 8.0-BETA2 #14: Wed Aug 19 22:43:17 > > CEST 2009 oni0@hamstor:/usr/obj/usr/src/sys/HAMSTOR amd64 > > > > > > (kgdb) bt > > #0 doadump () at pcpu.h:223 > > #1 0xffffffff801b561c in db_fncall (dummy1=Variable "dummy1" is not > > #available. > > ) at /usr/src/sys/ddb/db_command.c:548 > > #2 0xffffffff801b5951 in db_command (last_cmdp=0xffffffff808594a0, > > #cmd_table=Variable "cmd_table" is not available. > > ) at /usr/src/sys/ddb/db_command.c:445 > > #3 0xffffffff801b5ba0 in db_command_loop () > > #at /usr/src/sys/ddb/db_command.c:498 4 0xffffffff801b7b69 in > > #db_trap (type=Variable "type" is not available. > > ) at /usr/src/sys/ddb/db_main.c:229 > > #5 0xffffffff8038d775 in kdb_trap (type=3, code=0, > > #tf=0xffffff8000017760) at /usr/src/sys/kern/subr_kdb.c:535 6 > > #0xffffffff8060e170 in trap (frame=0xffffff8000017760) > > #at /usr/src/sys/amd64/amd64/trap.c:611 7 0xffffffff805f3b23 in > > #calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 8 > > #0xffffffff8038d94d in kdb_enter (why=0xffffffff80681954 "panic", > > #msg=0xa
) at cpufunc.h:63 9 > > #0xffffffff8035e04b in panic (fmt=Variable "fmt" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:562 > > #10 0xffffffff805fafbb in apic_free_vector (apic_id=Variable > > #"apic_id" is not available. > > ) at /usr/src/sys/amd64/amd64/local_apic.c:995 > > #11 0xffffffff805f7560 in intr_remove_handler (cookie=Variable > > #"cookie" is not available. > > ) at /usr/src/sys/amd64/amd64/intr_machdep.c:203 > > #12 0xffffffff806250d4 in hpt_shutdown_vbus > > #(vbus_ext=0xffffff8000254000, howto=Variable "howto" is not > > #available. > > ) at /usr/src/sys/dev/hptrr/hptrr_osm_bsd.c:361 > > #13 0xffffffff8035da8b in boot (howto=16392) > > #at /usr/src/sys/kern/kern_shutdown.c:419 14 0xffffffff8035e126 in > > #reboot (td=Variable "td" is not available. > > ) at /usr/src/sys/kern/kern_shutdown.c:173 > > #15 0xffffffff8060dbba in syscall (frame=0xffffff8000017c80) > > #at /usr/src/sys/amd64/amd64/trap.c:982 16 0xffffffff805f3e01 in > > #Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 17 > > #0x000000000040892c in ?? () > > Previous frame inner to this frame (corrupt stack?) > > > > frame #12 & #13 make me suspect the hptrr driver (again :-)), but > > I'm not sure. > > Ah, any driver shutting off its interrupt handler during shutdown > would actually trigger this. The hptrr driver doesn't really need to > do this during shutdown, but I think we don't want to panic in this > case. Unfortunately we don't currently have a "in_shutdown" type of > global flag that we can check in apic_free_vector() to not worry > about the thread already being bound. Is there any chance this fix might make it into 8.0? It's not a real problem for me since I can just power-off by force, but I imagine it might be a real pita for people who only have remote access and want to reboot, etc. Bye Marc -- "Come away, O human child! To the waters and the wild With a faery, hand in hand, For the world's more full of weeping than you can understand." W.B. Yeats, The Stolen Child From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 20:31:52 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 55D581065679 for ; Mon, 31 Aug 2009 20:31:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id C8D5A8FC23 for ; Mon, 31 Aug 2009 20:31:51 +0000 (UTC) Received: by bwz2 with SMTP id 2so2876900bwz.43 for ; Mon, 31 Aug 2009 13:31: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=dVDyVO0nLbB0RLG+DnTjbPdN3uXHB2uCOOr381A4o/U=; b=SvNyTy2ImwJ+0kK2vUEANS1ySDNMee4nDeR8x4ArxMrtuK9S6A3b8RwbrlE7TPOq8n vbYlJCEIlqZ5De4zkoaET2pIwmeeEqCF6BJO7PNUSalvHm2Z3hdDoSFOkePa476raxye FiAFlgTKfW38uBJptPUlkvyT2Og5TRXzomnKE= 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=NfzGzsPozefpWsR2HBKsp41BxZyMWGT7y6etCtpm9S02VHit3UntmGWf3Kd1zIk7wH mVIzXEgQN2m1ewr4I/f7jTDhiWzzI9ufRHNUHGJbJl+guNM9r3QxRyntS558D+KGgZYN d9P4WjExuCc3mOhUR5NFRIwEdlschWrsoldhY= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.4.150 with SMTP id 22mr1990200far.38.1251750710538; Mon, 31 Aug 2009 13:31:50 -0700 (PDT) In-Reply-To: <20090831222650.45b6c806.ubm@u-boot-man.de> References: <20090822115958.f93fcf29.ubm.freebsd@gmail.com> <200908241631.06112.jhb@freebsd.org> <20090831222650.45b6c806.ubm@u-boot-man.de> Date: Mon, 31 Aug 2009 22:31:50 +0200 X-Google-Sender-Auth: 1840a131ad3d61fa Message-ID: <3bbf2fe10908311331k3e871898tc36a9846651cc53@mail.gmail.com> From: Attilio Rao To: Marc UBM Content-Type: text/plain; charset=UTF-8 Cc: current@freebsd.org Subject: Re: panic: apic_free_vector: Thread already bound. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 20:31:52 -0000 2009/8/31 Marc UBM : > On Mon, 24 Aug 2009 16:31:05 -0400 > John Baldwin wrote: > >> On Saturday 22 August 2009 5:59:58 am Marc UBM wrote: >> > >> > Hiho! :-) >> > >> > I'm seeing above panic in the final stages of the shutdown process. >> > Coredump is available, bt as follows, textdump attached. >> > >> > >> > FreeBSD hamstor 8.0-BETA2 FreeBSD 8.0-BETA2 #14: Wed Aug 19 22:43:17 >> > CEST 2009 oni0@hamstor:/usr/obj/usr/src/sys/HAMSTOR amd64 >> > >> > >> > (kgdb) bt >> > #0 doadump () at pcpu.h:223 >> > #1 0xffffffff801b561c in db_fncall (dummy1=Variable "dummy1" is not >> > #available. >> > ) at /usr/src/sys/ddb/db_command.c:548 >> > #2 0xffffffff801b5951 in db_command (last_cmdp=0xffffffff808594a0, >> > #cmd_table=Variable "cmd_table" is not available. >> > ) at /usr/src/sys/ddb/db_command.c:445 >> > #3 0xffffffff801b5ba0 in db_command_loop () >> > #at /usr/src/sys/ddb/db_command.c:498 4 0xffffffff801b7b69 in >> > #db_trap (type=Variable "type" is not available. >> > ) at /usr/src/sys/ddb/db_main.c:229 >> > #5 0xffffffff8038d775 in kdb_trap (type=3, code=0, >> > #tf=0xffffff8000017760) at /usr/src/sys/kern/subr_kdb.c:535 6 >> > #0xffffffff8060e170 in trap (frame=0xffffff8000017760) >> > #at /usr/src/sys/amd64/amd64/trap.c:611 7 0xffffffff805f3b23 in >> > #calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 8 >> > #0xffffffff8038d94d in kdb_enter (why=0xffffffff80681954 "panic", >> > #msg=0xa
) at cpufunc.h:63 9 >> > #0xffffffff8035e04b in panic (fmt=Variable "fmt" is not available. >> > ) at /usr/src/sys/kern/kern_shutdown.c:562 >> > #10 0xffffffff805fafbb in apic_free_vector (apic_id=Variable >> > #"apic_id" is not available. >> > ) at /usr/src/sys/amd64/amd64/local_apic.c:995 >> > #11 0xffffffff805f7560 in intr_remove_handler (cookie=Variable >> > #"cookie" is not available. >> > ) at /usr/src/sys/amd64/amd64/intr_machdep.c:203 >> > #12 0xffffffff806250d4 in hpt_shutdown_vbus >> > #(vbus_ext=0xffffff8000254000, howto=Variable "howto" is not >> > #available. >> > ) at /usr/src/sys/dev/hptrr/hptrr_osm_bsd.c:361 >> > #13 0xffffffff8035da8b in boot (howto=16392) >> > #at /usr/src/sys/kern/kern_shutdown.c:419 14 0xffffffff8035e126 in >> > #reboot (td=Variable "td" is not available. >> > ) at /usr/src/sys/kern/kern_shutdown.c:173 >> > #15 0xffffffff8060dbba in syscall (frame=0xffffff8000017c80) >> > #at /usr/src/sys/amd64/amd64/trap.c:982 16 0xffffffff805f3e01 in >> > #Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 17 >> > #0x000000000040892c in ?? () >> > Previous frame inner to this frame (corrupt stack?) >> > >> > frame #12 & #13 make me suspect the hptrr driver (again :-)), but >> > I'm not sure. >> >> Ah, any driver shutting off its interrupt handler during shutdown >> would actually trigger this. The hptrr driver doesn't really need to >> do this during shutdown, but I think we don't want to panic in this >> case. Unfortunately we don't currently have a "in_shutdown" type of >> global flag that we can check in apic_free_vector() to not worry >> about the thread already being bound. > > Is there any chance this fix might make it into 8.0? It's not a real > problem for me since I can just power-off by force, but I imagine it > might be a real pita for people who only have remote access and want > to reboot, etc. Maybe we can ship 8 with a printf() instrad than a panic()? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Aug 31 23:27: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 C1BF6106566B for ; Mon, 31 Aug 2009 23:27:38 +0000 (UTC) (envelope-from grosser@fim.uni-passau.de) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.43]) by mx1.freebsd.org (Postfix) with ESMTP id 40C908FC08 for ; Mon, 31 Aug 2009 23:27:38 +0000 (UTC) Received: from [84.56.34.153] (helo=[192.168.178.32]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MiGH6-0003od-Ix; Tue, 01 Sep 2009 01:27:36 +0200 From: Tobias Grosser To: ticso@cicely.de In-Reply-To: <11278_1251745674_4A9C1F89_11278_90_1_20090831190735.GF60240@cicely7.cicely.de> References: <1251570251.1238.21.camel@localhost> <19936_1251649540_4A9AA804_19936_425_1_200908301825.57281.hselasky@c2i.net> <1251650741.1187.1.camel@localhost> <200908301909.30692.hselasky@c2i.net> <16272_1251712358_4A9B9D66_16272_77_1_20090831095231.GD59032@cicely7.cicely.de> <1251737958.1216.15.camel@localhost> <11278_1251745674_4A9C1F89_11278_90_1_20090831190735.GF60240@cicely7.cicely.de> Content-Type: multipart/mixed; boundary="=-65egvB1PoKNSGJJbjYrX" Date: Tue, 01 Sep 2009 01:26:57 +0200 Message-Id: <1251761217.1186.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port X-Df-Sender: imapboxtobias@web-wahnsinn.de Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: [PATCH] USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Aug 2009 23:27:38 -0000 --=-65egvB1PoKNSGJJbjYrX Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2009-08-31 at 21:07 +0200, Bernd Walter wrote: > On Mon, Aug 31, 2009 at 06:59:18PM +0200, Tobias Grosser wrote: > > On Mon, 2009-08-31 at 11:52 +0200, Bernd Walter wrote: > > > On Sun, Aug 30, 2009 at 07:09:29PM +0200, Hans Petter Selasky wrote: > > > > Hi, > > > > > > > > I looks like your device is hanging on SCSI command 0x12,00,00,00,4a,00 > > > > > > 0x12 is an inquiry, which is bad if the device has problems with. > > > > I tried Linux on the same computer and the drive worked without any > > problems. > > > > If those are timestamps then there is a 5 second delay. > I wouldn't say that this is without problems. > Maybe Linux just has a different handling of the case. > > > --------------------------------------- > > linux_dmesg.log is attached. > > --------------------------------------- > > > > There was also another report where the drive did not work on FreeBSD. I > > mailed the user and he did not get it to run on FreeBSD, but his drive > > also works on Linux. > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028999.html > > > > As I have two of these drives, I am pretty sure my device is not > > completely broken, but WD has some uncommon/broken way to interact with > > FreeBSD. > > > > To narrow it down I run the usb.org compliance test utility. > > > > http://www.usb.org/developers/tools/ : USB20CV R1.3.5.5 > > As Hans Petter said: this is not a USB problem, it is at SCSI. > > > The results for the generic device test and for the USB mass storage > > test are attached. > > If this is just are startup problem you won't see anything at all after > probing is over. > My assumption would be that the device missbehaves until it spun up. > But this is just an assumption. Thanks to all of you who pointed me in the right direction. It seems the way inquiries are handled was broken. I solved the problem by adding a new quirk for the WD MyPassword Series. Do you think this is the right approach? May this break anything else? And finally if everything is alright, can someone commit this patch? Thanks Tobi --=-65egvB1PoKNSGJJbjYrX Content-Disposition: attachment; filename="umass_western_mypassword.patch" Content-Type: text/x-patch; name="umass_western_mypassword.patch"; charset="us-ascii" Content-Transfer-Encoding: 7bit diff --git a/sys/dev/usb/storage/umass.c b/sys/dev/usb/storage/umass.c index 2e412d9..00f1baa 100644 --- a/sys/dev/usb/storage/umass.c +++ b/sys/dev/usb/storage/umass.c @@ -937,6 +937,10 @@ static const struct umass_devdescr umass_devdescr[] = { UMASS_PROTO_SCSI | UMASS_PROTO_BBB, NO_INQUIRY_EVPD }, + {USB_VENDOR_WESTERN, USB_PRODUCT_WESTERN_MYPASSWORD, RID_WILDCARD, + UMASS_PROTO_SCSI | UMASS_PROTO_BBB, + FORCE_SHORT_INQUIRY + }, {USB_VENDOR_WINMAXGROUP, USB_PRODUCT_WINMAXGROUP_FLASH64MC, RID_WILDCARD, UMASS_PROTO_SCSI | UMASS_PROTO_BBB, NO_INQUIRY diff --git a/sys/dev/usb/usbdevs b/sys/dev/usb/usbdevs index 288750c..372bfa6 100644 --- a/sys/dev/usb/usbdevs +++ b/sys/dev/usb/usbdevs @@ -2490,6 +2490,7 @@ product WESTERN COMBO 0x0200 Firewire USB Combo product WESTERN EXTHDD 0x0400 External HDD product WESTERN HUB 0x0500 USB HUB product WESTERN MYBOOK 0x0901 MyBook External HDD +product WESTERN MYPASSWORD 0x0704 MyPassword External HDD /* Windbond Electronics */ product WINBOND UH104 0x5518 4-port USB Hub --=-65egvB1PoKNSGJJbjYrX-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 01:35: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 87C351065676; Tue, 1 Sep 2009 01:35:48 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mail-yw0-f191.google.com (mail-yw0-f191.google.com [209.85.211.191]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6C38FC18; Tue, 1 Sep 2009 01:35:47 +0000 (UTC) Received: by ywh29 with SMTP id 29so6584140ywh.33 for ; Mon, 31 Aug 2009 18:35:47 -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=UuQjVTB1Lze7SZn08Cw58ZmDk0QFlKOhA2O/ELUd10s=; b=Gq2MnBnEpZyZUn8q3/mtmojmh32Lq3pNM3gX0ADYWJN2r0YbJVJolkIo9Sg/ZL1RoD bMV02j0aS5f5gHBJ6JBVAiI8c3xA1UhgYIZz4sxUC4vEeBL/SMAu6+UpyEjGsSkQ47UV p5kclNzIIe99qMmMYB2+926OV0UuOSzT3SjNA= 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=QtLbGhgYZgT+T+FP/U/hvCe49NdJNY4aODdG3gn3veuqH5wXg3bMW10rLlF78PQxQW TynFGiIwm6pWcfMUk4MyTPPSNR/X5yMuZlwb26C8YkiHj0vVY/gWBJ+dn2EGtZKIZxCS TrfRtnBRT3iIgkHdwaioiRuUjVyvFFy63DcJ0= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.101.46.15 with SMTP id y15mr6714082anj.4.1251768947390; Mon, 31 Aug 2009 18:35:47 -0700 (PDT) In-Reply-To: References: Date: Mon, 31 Aug 2009 18:35:47 -0700 X-Google-Sender-Auth: eba3b95a456ff52d Message-ID: <3c1674c90908311835i7f70e6d8mbfa8ce619e7ff911@mail.gmail.com> From: Kip Macy To: fabient@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Forwarding benchmark X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 01:35:48 -0000 We're not going to see much more 700kpps on forwarding workloads until we do something about the rtentry locking. I had some interesting ideas I was exploring, but I don't have the luxury of side projects right now. em(9)'s transmit performance has been substantially improved in 8 by using a buf_ring instead of IFQ so I assume that you're entirely gated by rx performance. Jeff did some work in that area to reduce the per-packet overhead of dequeue and to do some NAPI-like opportunistic polling using a variant of the taskqueue API. It won't give you any idea about latency breakdown, but it would be useful for a general time breakdown to look at unhalted core cycles in PMC. Good Luck, Kip On Fri, Aug 21, 2009 at 02:25, Fabien Thomas wrot= e: > =A0 =A0 =A0 =A0Hi all, > > Just a quick benchmark on 8.0 Beta2+ (18/08) show no regression vs 7.2. > > Result in FPS for 64bytes frame using Breakingpoint Elite > > Breakingpoint P1 =3D=3D=3D DUT =3D=3D=3D Breakingpoint P2 > > Stream1 : P1 -> P2 > Stream2: P2 -> P1 > > GENERIC kernel + netisr.direct > > 4.11 : 236 (with 1 stream down for unknown reason) > 6.3 =A0 : 248 > 7.2 =A0 : 350 > 8.0b : 352 > > POLLING kernel + netisr.direct > > 4.11 : 526 > 6.3 =A0 : 246 > 7.2 =A0 : 230 > 8.0b : 330 > > Note that the perf grow a little bit from version to version but 4.11 wit= h > polling is always a lot better. > > There is a lot a more in depth testing to do (HW flow tag, 10gb, lot of > interface, latency ...) but it give a rough idea of the perf in the > forwarding area. > > Regards, > Fabien > > dmesg: > > CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2793.02-MHz 686-class CPU) > =A0Origin =3D "GenuineIntel" =A0Id =3D 0xf47 =A0Stepping =3D 7 > =A0Features=3D0xbfebfbff > =A0Features2=3D0x641d > =A0AMD Features=3D0x20100000 > =A0AMD Features2=3D0x1 > =A0TSC: P-state invariant > real memory =A0=3D 1073741824 (1024 MB) > avail memory =3D 1035210752 (987 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > =A0cpu0 (BSP): APIC ID: =A00 > =A0cpu1 (AP): APIC ID: =A01 > ... > em8: port 0x7000-0x701f mem > 0xed700000-0xed71ffff irq 18 at device 0.0 on pci6 > em8: Using MSI interrupt > em8: [FILTER] > em8: Ethernet address: 00:30:48:5c:40:82 > pcib7: irq 19 at device 28.3 on pci0 > pci8: on pcib7 > em9: port 0x8000-0x801f mem > 0xed800000-0xed81ffff irq 19 at device 0.0 on pci8 > em9: Using MSI interrupt > em9: [FILTER] > em9: Ethernet address: 00:30:48:5c:40:83 > > _______________________________________________ > 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 When harsh accusations depart too far from the truth, they leave bitter consequences. --Tacitus From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 01:44: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 90CB6106568B; Tue, 1 Sep 2009 01:44:33 +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 750198FC1A; Tue, 1 Sep 2009 01:44:33 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n811iWP8006106; Mon, 31 Aug 2009 18:44:32 -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: Mon, 31 Aug 2009 18:44:25 -0700 Message-ID: In-Reply-To: <20090830.024420.174808572.hrs@allbsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 regression on 8.x Thread-Index: Acoo0HsjKhik75XsQjG/X1fWVdINtwB1IOFw References: <20090830.024420.174808572.hrs@allbsd.org> From: "Li, Qing" To: "Hiroki Sato" Cc: qingli@freebsd.org, freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: RE: IPv6 regression on 8.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 01:44:33 -0000 Hi Hiroki, > > 2) Issue of subnet-router anycast address with a global address >=20 > Thanks for the fixes! With the two patches 1) and 3) are gone, but > 2) still remains. Is there something I can help to narrow down it? >=20 Hmm... I tried multiple test cases and all seem to work as expected. I also tried the exact configuration sequence as you outlined in your original bug report email, and that case worked, too. The only difference I can see from the given information, is I have=20 3 em interfaces, whereas you have 2 em interfaces and 1 re, but I=20 don't see how that would make a difference. Would it be possible for you to email me your system configuration=20 produced from "ifconfig" and "netstat" privately ? Thank you. -- Qing From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 01:52: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 28F581065672 for ; Tue, 1 Sep 2009 01:52:55 +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 E2BCF8FC08 for ; Tue, 1 Sep 2009 01:52:53 +0000 (UTC) Received: from ip-149.ish.com.au ([203.29.62.149]:53179 helo=Aris-MacBook-Pro.local) by fish.ish.com.au with esmtpa (Exim 4.69) (envelope-from ) id 1MiJjW-0003C7-24; Tue, 01 Sep 2009 13:08:34 +1000 Message-ID: <4A9C7E73.4040004@ish.com.au> Date: Tue, 01 Sep 2009 11:52:51 +1000 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090821 Shredder/3.0b4pre MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jurgen Weber Subject: [beta3] ld-elf Undefined symbol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 01:52:55 -0000 Upgraded an amd64 FreeBSD machine from beta 2 to beta 3 via freebsd-update. When trying to use the bacula port (a backup tool), the application will die with the following error: /libexec/ld-elf.so.1: /usr/local/sbin/bacula-dir: Undefined symbol "_ZN5BSOCK18set_source_addressEP5dlist" Naturally we have rebuilt all ports and rebuilt (just to be sure) all ports that bacula depends on. Is this a bug in beta3 or something we are doing wrong? 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 Sep 1 04:12: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 F1A9A106566C for ; Tue, 1 Sep 2009 04:12:59 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (ns1.jnielsen.net [69.55.238.237]) by mx1.freebsd.org (Postfix) with ESMTP id D7C318FC15 for ; Tue, 1 Sep 2009 04:12:59 +0000 (UTC) Received: from [172.17.2.19] (jn@stealth.jnielsen.net [74.218.226.254]) (authenticated bits=0) by ns1.jnielsen.net (8.12.9p2/8.12.9) with ESMTP id n813wtel098918; Mon, 31 Aug 2009 23:58:55 -0400 (EDT) (envelope-from lists@jnielsen.net) From: John Nielsen To: freebsd-current@freebsd.org Date: Mon, 31 Aug 2009 23:58:51 -0400 User-Agent: KMail/1.9.10 References: <20090807165850.3e8541f8@vaio> <20090808134101.44d7d210@vaio> <4A7E5E2B.6060204@errno.com> In-Reply-To: <4A7E5E2B.6060204@errno.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200908312358.51491.lists@jnielsen.net> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on ns1.jnielsen.net X-Virus-Status: Clean Cc: Subject: WEP on wi(4) [was: Re: LOR wlan0 wi0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 04:13:00 -0000 On Sunday 09 August 2009 01:27:07 am Sam Leffler wrote: > > Sam Leffler wrote: > I can confirm WEP is broken on wi in sta mode (and probably ap mode). > I found at least two bugs but couldn't get it to work so am going to > leave it as an errata for 8.0. But what's truly odd is that WPA works > fine despite a bug that should've caused it to not work. I knew WPA > worked which is probably why I ignored WEP (noone in their right mind > uses WEP when WPA is available :-)). So for us wrong-minded people with wi(4) hardware that lacks WPA support is it better to stick with 7.x for now? Any patches available or a rough ETA? Is there a specific set of 8-CURRENT commits before which WEP is known (or strongly suspected) to work? Anything others can do to help besides ask annoying questions? (Sadly I'm not quite enough of a kernel hacker to adopt maintainership of wi.) Thanks! JN From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 04:20: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 B2663106566B; Tue, 1 Sep 2009 04:20:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8DECF8FC23; Tue, 1 Sep 2009 04:20:31 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n814KUh2033597; Tue, 1 Sep 2009 00:20:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n814KU3p033582; Tue, 1 Sep 2009 04:20:30 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 1 Sep 2009 04:20:30 GMT Message-Id: <200909010420.n814KU3p033582@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 04:20:31 -0000 TB --- 2009-09-01 02:20:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-01 02:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-09-01 02:20:00 - cleaning the object tree TB --- 2009-09-01 02:20:43 - cvsupping the source tree TB --- 2009-09-01 02:20:43 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-09-01 02:22:00 - building world TB --- 2009-09-01 02:22:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-01 02:22:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-01 02:22:00 - TARGET=i386 TB --- 2009-09-01 02:22:00 - TARGET_ARCH=i386 TB --- 2009-09-01 02:22:00 - TZ=UTC TB --- 2009-09-01 02:22:00 - __MAKE_CONF=/dev/null TB --- 2009-09-01 02:22:00 - cd /src TB --- 2009-09-01 02:22:00 - /usr/bin/make -B buildworld >>> World build started on Tue Sep 1 02:22:01 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Tue Sep 1 03:27:03 UTC 2009 TB --- 2009-09-01 03:27:03 - generating LINT kernel config TB --- 2009-09-01 03:27:03 - cd /src/sys/i386/conf TB --- 2009-09-01 03:27:03 - /usr/bin/make -B LINT TB --- 2009-09-01 03:27:03 - building LINT kernel TB --- 2009-09-01 03:27:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-01 03:27:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-01 03:27:03 - TARGET=i386 TB --- 2009-09-01 03:27:03 - TARGET_ARCH=i386 TB --- 2009-09-01 03:27:03 - TZ=UTC TB --- 2009-09-01 03:27:03 - __MAKE_CONF=/dev/null TB --- 2009-09-01 03:27:03 - cd /src TB --- 2009-09-01 03:27:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Sep 1 03:27:03 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Tue Sep 1 03:52:37 UTC 2009 TB --- 2009-09-01 03:52:37 - building GENERIC kernel TB --- 2009-09-01 03:52:37 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-01 03:52:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-01 03:52:37 - TARGET=i386 TB --- 2009-09-01 03:52:37 - TARGET_ARCH=i386 TB --- 2009-09-01 03:52:37 - TZ=UTC TB --- 2009-09-01 03:52:37 - __MAKE_CONF=/dev/null TB --- 2009-09-01 03:52:37 - cd /src TB --- 2009-09-01 03:52:37 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Sep 1 03:52:37 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue Sep 1 04:12:57 UTC 2009 TB --- 2009-09-01 04:12:57 - building PAE kernel TB --- 2009-09-01 04:12:57 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-01 04:12:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-01 04:12:57 - TARGET=i386 TB --- 2009-09-01 04:12:57 - TARGET_ARCH=i386 TB --- 2009-09-01 04:12:57 - TZ=UTC TB --- 2009-09-01 04:12:57 - __MAKE_CONF=/dev/null TB --- 2009-09-01 04:12:57 - cd /src TB --- 2009-09-01 04:12:57 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Tue Sep 1 04:12:57 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Tue Sep 1 04:18:03 UTC 2009 TB --- 2009-09-01 04:18:03 - building XEN kernel TB --- 2009-09-01 04:18:03 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-01 04:18:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-01 04:18:03 - TARGET=i386 TB --- 2009-09-01 04:18:03 - TARGET_ARCH=i386 TB --- 2009-09-01 04:18:03 - TZ=UTC TB --- 2009-09-01 04:18:03 - __MAKE_CONF=/dev/null TB --- 2009-09-01 04:18:03 - cd /src TB --- 2009-09-01 04:18:03 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Tue Sep 1 04:18:03 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/i386/xen/pmap.c: In function 'pmap_pinit': /src/sys/i386/xen/pmap.c:1546: warning: implicit declaration of function 'pagezero' /src/sys/i386/xen/pmap.c:1546: warning: nested extern declaration of 'pagezero' /src/sys/i386/xen/pmap.c: At top level: /src/sys/i386/xen/pmap.c:3332: warning: conflicting types for 'pagezero' /src/sys/i386/xen/pmap.c:3332: error: static declaration of 'pagezero' follows non-static declaration /src/sys/i386/xen/pmap.c:1546: error: previous implicit declaration of 'pagezero' was here *** Error code 1 Stop in /obj/i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-01 04:20:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-01 04:20:30 - ERROR: failed to build XEN kernel TB --- 2009-09-01 04:20:30 - 5088.27 user 709.88 system 7230.04 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 06:55: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 D23E31065672 for ; Tue, 1 Sep 2009 06:55:01 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 628B68FC13 for ; Tue, 1 Sep 2009 06:55:01 +0000 (UTC) Received: by bwz2 with SMTP id 2so3109020bwz.43 for ; Mon, 31 Aug 2009 23:55:00 -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=1BOJX64jvqsyPDTR/8T55GY9+4pZX6WA4AQSTH+Hgec=; b=WuZXODT1p38oBpnjHao4dAq6iRWlJyRam4WNt76e9s8q3B8CcM2F0FJtRdCZxDtGei dhVqpSIGVLDrRMoMpOrmKY4FiurQtwSqcs33PhNjmBVJVWj9bJPerPloT3OEsErmbTnn 7o6MU2ofi2wwNz2poGBOb0D+FVvbUS0FRiD14= 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=PqXgHvbIgrO7w2ugjIhOVcZxCpM6baHthphQVrb2h64Sg8tiFBSEavufQrI/e5iZsI BUifMy8X0Wo2lOwFzJIEbUZlP3pFATbLlPUqvCSw47Zo+FTSA2wjh9TAWkixCYL7hqbF jpOyGtwHl6epW5c0LO99VYpVs3p0RyWxOuQ/4= MIME-Version: 1.0 Received: by 10.204.141.18 with SMTP id k18mr5206818bku.139.1251788100307; Mon, 31 Aug 2009 23:55:00 -0700 (PDT) In-Reply-To: <4A9C7E73.4040004@ish.com.au> References: <4A9C7E73.4040004@ish.com.au> Date: Tue, 1 Sep 2009 10:55:00 +0400 Message-ID: From: pluknet To: Aristedes Maniatis Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Jurgen Weber Subject: Re: [beta3] ld-elf Undefined symbol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 06:55:01 -0000 2009/9/1 Aristedes Maniatis : > Upgraded an amd64 FreeBSD machine from beta 2 to beta 3 via freebsd-update. > When trying to use the bacula port (a backup tool), the application will die > with the following error: > > /libexec/ld-elf.so.1: /usr/local/sbin/bacula-dir: Undefined symbol > "_ZN5BSOCK18set_source_addressEP5dlist" > > Naturally we have rebuilt all ports and rebuilt (just to be sure) all ports > that bacula depends on. Is this a bug in beta3 or something we are doing > wrong? > Hi. Quoting Ken Smith: "There was a shared library version bump after BETA2 was announced (bump was done July 19th with svn commit r195767) so if you update a system that was last rebuilt earlier than that it would be a good idea to rebuild all user-level applications including the ports/packages." You definitely need to rebuild all installed packages. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 06:56: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 9CEB11065670 for ; Tue, 1 Sep 2009 06:56:17 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe13.tele2.se [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 058038FC1D for ; Tue, 1 Sep 2009 06:56:16 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=qiM62AFXJF0A:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=G0XHSz-fAAAA:8 a=3B_WLAnUy2AoDVHacLoA:9 a=_lXTQmjGwB7Qw_xK-qzUpRjXLSIA:4 a=G55ziAPEpLgA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 914365730; Tue, 01 Sep 2009 08:56:14 +0200 From: Hans Petter Selasky To: Tobias Grosser Date: Tue, 1 Sep 2009 08:56:20 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <1251570251.1238.21.camel@localhost> <11278_1251745674_4A9C1F89_11278_90_1_20090831190735.GF60240@cicely7.cicely.de> <1251761217.1186.9.camel@localhost> In-Reply-To: <1251761217.1186.9.camel@localhost> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909010856.23045.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: [PATCH] USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 06:56:17 -0000 On Tuesday 01 September 2009 01:26:57 Tobias Grosser wrote: > On Mon, 2009-08-31 at 21:07 +0200, Bernd Walter wrote: > > On Mon, Aug 31, 2009 at 06:59:18PM +0200, Tobias Grosser wrote: > > > On Mon, 2009-08-31 at 11:52 +0200, Bernd Walter wrote: > > > > On Sun, Aug 30, 2009 at 07:09:29PM +0200, Hans Petter Selasky wrote: > > > > > Hi, > > > > > > > > > > I looks like your device is hanging on SCSI command > > > > > 0x12,00,00,00,4a,00 > > > > > > > > 0x12 is an inquiry, which is bad if the device has problems with. > > > > > > I tried Linux on the same computer and the drive worked without any > > > problems. > > > > If those are timestamps then there is a 5 second delay. > > I wouldn't say that this is without problems. > > Maybe Linux just has a different handling of the case. > > > > > --------------------------------------- > > > linux_dmesg.log is attached. > > > --------------------------------------- > > > > > > There was also another report where the drive did not work on FreeBSD. > > > I mailed the user and he did not get it to run on FreeBSD, but his > > > drive also works on Linux. > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028999 > > >.html > > > > > > As I have two of these drives, I am pretty sure my device is not > > > completely broken, but WD has some uncommon/broken way to interact with > > > FreeBSD. > > > > > > To narrow it down I run the usb.org compliance test utility. > > > > > > http://www.usb.org/developers/tools/ : USB20CV R1.3.5.5 > > > > As Hans Petter said: this is not a USB problem, it is at SCSI. > > > > > The results for the generic device test and for the USB mass storage > > > test are attached. > > > > If this is just are startup problem you won't see anything at all after > > probing is over. > > My assumption would be that the device missbehaves until it spun up. > > But this is just an assumption. > > Thanks to all of you who pointed me in the right direction. It seems the > way inquiries are handled was broken. > I solved the problem by adding a new quirk for the WD MyPassword Series. > > Do you think this is the right approach? May this break anything else? > And finally if everything is alright, can someone commit this patch? > > Thanks > > Tobi Can you try this: + {USB_VENDOR_WESTERN, USB_PRODUCT_WESTERN_MYPASSWORD, RID_WILDCARD, + UMASS_PROTO_DEFAULT, + FORCE_SHORT_INQUIRY + }, --HPS From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 07:31: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 CE96A106568B for ; Tue, 1 Sep 2009 07:31:24 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from baranao.anywi.com (baranao.anywi.com [213.207.101.176]) by mx1.freebsd.org (Postfix) with ESMTP id 920F18FC1F for ; Tue, 1 Sep 2009 07:31:24 +0000 (UTC) Received: from hind.van-laarhoven.org (ip51cfcfde.direct-adsl.nl [81.207.207.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by baranao.anywi.com (Postfix) with ESMTPSA id 85A593F41F; Tue, 1 Sep 2009 09:31:20 +0200 (CEST) From: Nick Hibma To: FreeBSD CURRENT Mailing List Date: Tue, 1 Sep 2009 09:31:16 +0200 User-Agent: KMail/1.12.0 (FreeBSD/7.2-STABLE; KDE/4.3.0; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200909010931.16880.nick@van-laarhoven.org> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on baranao.anywi.com Subject: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 07:31:25 -0000 Folks, dmesg is getting cluttered with random bits of irrelevant information which either should be behind bootverbose or not at all present. Below two locations where I intend to remove that information. The fact that a module is loaded can be seen in the output of kldstat -v | grep netsmb the amount of stolen memory and aperture size might be interesting when configuring your X server. Then again, most X servers nowadays HAVE no configuration file anymore because of auto-configuration. Any objections? Nick Index: kern/kern_shutdown.c =================================================================== --- kern/kern_shutdown.c (revision 196710) +++ kern/kern_shutdown.c (working copy) @@ -581,6 +581,10 @@ /* * Support for poweroff delay. + * + * Please note that setting this delay too short might power off your machine + * before the write cache on your hard disk has been flushed, leading to + * soft-updates inconsistencies. */ #ifndef POWEROFF_DELAY # define POWEROFF_DELAY 5000 Index: dev/agp/agp_i810.c =================================================================== --- dev/agp/agp_i810.c (revision 196589) +++ dev/agp/agp_i810.c (working copy) @@ -474,12 +474,15 @@ agp_generic_detach(dev); return EINVAL; } - if (sc->stolen > 0) { - device_printf(dev, "detected %dk stolen memory\n", - sc->stolen * 4); + if (bootverbose) { + if (sc->stolen > 0) { + device_printf(dev, + "detected %dk stolen memory\n", + sc->stolen * 4); + } + device_printf(dev, "aperture size is %dM\n", + sc->initial_aperture / 1024 / 1024); } - device_printf(dev, "aperture size is %dM\n", - sc->initial_aperture / 1024 / 1024); /* GATT address is already in there, make sure it's enabled */ pgtblctl = bus_read_4(sc->sc_res[0], AGP_I810_PGTBL_CTL); @@ -664,9 +667,11 @@ gtt_size += 4; sc->stolen = (stolen - gtt_size) * 1024 / 4096; - if (sc->stolen > 0) - device_printf(dev, "detected %dk stolen memory\n", sc->stolen * 4); - device_printf(dev, "aperture size is %dM\n", sc->initial_aperture / 1024 / 1024); + if (bootverbose) { + if (sc->stolen > 0) + device_printf(dev, "detected %dk stolen memory\n", sc->stolen * 4); + device_printf(dev, "aperture size is %dM\n", sc->initial_aperture / 1024 / 1024); + } /* GATT address is already in there, make sure it's enabled */ pgtblctl = bus_read_4(sc->sc_res[0], AGP_I810_PGTBL_CTL); Index: netsmb/smb_dev.c =================================================================== --- netsmb/smb_dev.c (revision 196589) +++ netsmb/smb_dev.c (working copy) @@ -352,7 +352,6 @@ } clone_setup(&nsmb_clones); nsmb_dev_tag = EVENTHANDLER_REGISTER(dev_clone, nsmb_dev_clone, 0, 1000); - printf("netsmb_dev: loaded\n"); break; case MOD_UNLOAD: smb_iod_done(); @@ -363,7 +362,6 @@ drain_dev_clone_events(); clone_cleanup(&nsmb_clones); destroy_dev_drain(&nsmb_cdevsw); - printf("netsmb_dev: unloaded\n"); break; default: error = EINVAL; From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 08:08: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 28DA0106566C for ; Tue, 1 Sep 2009 08:08:14 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id E1B578FC08 for ; Tue, 1 Sep 2009 08:08:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id E150C6D423; Tue, 1 Sep 2009 10:08:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjk+RqFar6fN; Tue, 1 Sep 2009 10:08:30 +0200 (CEST) Received: by mx1.rink.nu (Postfix, from userid 1000) id 450086D41E; Tue, 1 Sep 2009 10:08:30 +0200 (CEST) Date: Tue, 1 Sep 2009 10:08:30 +0200 From: Rink Springer To: Nick Hibma Message-ID: <20090901080830.GA52168@rink.nu> References: <200909010931.16880.nick@van-laarhoven.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200909010931.16880.nick@van-laarhoven.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD CURRENT Mailing List Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 08:08:14 -0000 Hi Nick, On Tue, Sep 01, 2009 at 09:31:16AM +0200, Nick Hibma wrote: > dmesg is getting cluttered with random bits of irrelevant information which > either should be behind bootverbose or not at all present. Below two > locations where I intend to remove that information. The fact that a module > is loaded can be seen in the output of I'd say this is an useful change; the netsmb messages seem just leftovers from debugging and I never saw the need for the aperture size either (granted, I don't know what it indicates...) Regards, -- Rink P.W. Springer - http://rink.nu "Beauty often seduces us on the road to truth." - Dr. Wilson From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 08:08:37 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 C537E106566C for ; Tue, 1 Sep 2009 08:08:37 +0000 (UTC) (envelope-from grosser@fim.uni-passau.de) Received: from smtprelay09.ispgateway.de (smtprelay09.ispgateway.de [80.67.31.32]) by mx1.freebsd.org (Postfix) with ESMTP id 48E4C8FC15 for ; Tue, 1 Sep 2009 08:08:37 +0000 (UTC) Received: from [84.56.60.206] (helo=[192.168.178.32]) by smtprelay09.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MiOSC-0002wo-Mn; Tue, 01 Sep 2009 10:11:01 +0200 From: Tobias Grosser To: Hans Petter Selasky In-Reply-To: <20490_1251788178_4A9CC592_20490_149_1_200909010856.23045.hselasky@c2i.net> References: <1251570251.1238.21.camel@localhost> <11278_1251745674_4A9C1F89_11278_90_1_20090831190735.GF60240@cicely7.cicely.de> <1251761217.1186.9.camel@localhost> <20490_1251788178_4A9CC592_20490_149_1_200909010856.23045.hselasky@c2i.net> Content-Type: text/plain Date: Tue, 01 Sep 2009 10:08:30 +0200 Message-Id: <1251792510.1176.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Df-Sender: imapboxtobias@web-wahnsinn.de Cc: freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: [PATCH] USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 08:08:37 -0000 On Tue, 2009-09-01 at 08:56 +0200, Hans Petter Selasky wrote: > On Tuesday 01 September 2009 01:26:57 Tobias Grosser wrote: > > On Mon, 2009-08-31 at 21:07 +0200, Bernd Walter wrote: > > > On Mon, Aug 31, 2009 at 06:59:18PM +0200, Tobias Grosser wrote: > > > > On Mon, 2009-08-31 at 11:52 +0200, Bernd Walter wrote: > > > > > On Sun, Aug 30, 2009 at 07:09:29PM +0200, Hans Petter Selasky wrote: > > > > > > Hi, > > > > > > > > > > > > I looks like your device is hanging on SCSI command > > > > > > 0x12,00,00,00,4a,00 > > > > > > > > > > 0x12 is an inquiry, which is bad if the device has problems with. > > > > > > > > I tried Linux on the same computer and the drive worked without any > > > > problems. > > > > > > If those are timestamps then there is a 5 second delay. > > > I wouldn't say that this is without problems. > > > Maybe Linux just has a different handling of the case. > > > > > > > --------------------------------------- > > > > linux_dmesg.log is attached. > > > > --------------------------------------- > > > > > > > > There was also another report where the drive did not work on FreeBSD. > > > > I mailed the user and he did not get it to run on FreeBSD, but his > > > > drive also works on Linux. > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-stable/2006-September/028999 > > > >.html > > > > > > > > As I have two of these drives, I am pretty sure my device is not > > > > completely broken, but WD has some uncommon/broken way to interact with > > > > FreeBSD. > > > > > > > > To narrow it down I run the usb.org compliance test utility. > > > > > > > > http://www.usb.org/developers/tools/ : USB20CV R1.3.5.5 > > > > > > As Hans Petter said: this is not a USB problem, it is at SCSI. > > > > > > > The results for the generic device test and for the USB mass storage > > > > test are attached. > > > > > > If this is just are startup problem you won't see anything at all after > > > probing is over. > > > My assumption would be that the device missbehaves until it spun up. > > > But this is just an assumption. > > > > Thanks to all of you who pointed me in the right direction. It seems the > > way inquiries are handled was broken. > > I solved the problem by adding a new quirk for the WD MyPassword Series. > > > > Do you think this is the right approach? May this break anything else? > > And finally if everything is alright, can someone commit this patch? > > > > Thanks > > > > Tobi > > Can you try this: > > + {USB_VENDOR_WESTERN, USB_PRODUCT_WESTERN_MYPASSWORD, RID_WILDCARD, > + UMASS_PROTO_DEFAULT, > + FORCE_SHORT_INQUIRY > + }, OK. I forgot to remove unnecessary quirks. I just tried your patch and it also works. Thanks Tobi From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 10:30: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 F3BCA1065670 for ; Tue, 1 Sep 2009 10:30:43 +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 B13C58FC08 for ; Tue, 1 Sep 2009 10:30:43 +0000 (UTC) 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 <1MiQdO-0005pt-70>; Tue, 01 Sep 2009 12:30:42 +0200 Received: from telesto.geoinf.fu-berlin.de ([130.133.86.198]) by inpost2.zedat.fu-berlin.de (Exim 4.69) with esmtpsa (envelope-from ) id <1MiQdO-0000xO-5X>; Tue, 01 Sep 2009 12:30:42 +0200 Message-ID: <4A9CF7CF.1000608@zedat.fu-berlin.de> Date: Tue, 01 Sep 2009 10:30:39 +0000 From: "O. Hartmann" Organization: Freie =?ISO-8859-15?Q?Universit=E4t_Berlin?= User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: freebsd-ports@FreeBSD.org, freebsd-current@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 130.133.86.198 Cc: Subject: ports/devel/automake-wrapper: ln: /usr/local/bin/aclocal: File exists X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 10:30:44 -0000 I get permanently this error when doing portmaster -dvf lighttpd. It is essentiel having build everything along the lighttpd server due to a /usr/local/lib corruption. ports/devl/autotools are already installed. Now I get stuck in this nasty error shown below, I can not circumvent. How to simply force the installation? Please respond to my email address also since I'm not member of the ports-list. Thanks in advance, Oliver ===> Installing for automake-wrapper-20071109 ===> Generating temporary packing list ln: /usr/local/bin/aclocal: File exists *** Error code 1 Stop in /usr/ports/devel/automake-wrapper. From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 11:58: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 62F8F106566B; Tue, 1 Sep 2009 11:58:49 +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 BD16B8FC1D; Tue, 1 Sep 2009 11:58:48 +0000 (UTC) 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 1MiS0d-0000VL-E3; Tue, 01 Sep 2009 13:58:47 +0200 Received: from td068.t.pppool.de ([89.55.208.104]:43297 helo=ernst.jennejohn.org) by 0.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1MiS0c-0000oM-2h; Tue, 01 Sep 2009 13:58:46 +0200 Date: Tue, 1 Sep 2009 13:58:45 +0200 From: Gary Jennejohn To: "O. Hartmann" Message-ID: <20090901135845.0901d4b8@ernst.jennejohn.org> In-Reply-To: <4A9CF7CF.1000608@zedat.fu-berlin.de> References: <4A9CF7CF.1000608@zedat.fu-berlin.de> 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 Cc: freebsd-current@FreeBSD.org, freebsd-ports@FreeBSD.org Subject: Re: ports/devel/automake-wrapper: ln: /usr/local/bin/aclocal: File exists 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: Tue, 01 Sep 2009 11:58:49 -0000 On Tue, 01 Sep 2009 10:30:39 +0000 "O. Hartmann" wrote: > I get permanently this error when doing portmaster -dvf lighttpd. > > It is essentiel having build everything along the lighttpd server due to > a /usr/local/lib corruption. ports/devl/autotools are already installed. > Now I get stuck in this nasty error shown below, I can not circumvent. > How to simply force the installation? > > Please respond to my email address also since I'm not member of the > ports-list. > > Thanks in advance, > > Oliver > > ===> Installing for automake-wrapper-20071109 > ===> Generating temporary packing list > ln: usr/local/bin/aclocal: File exists > *** Error code 1 > > Stop in /usr/ports/devel/automake-wrapper. > Try moving /usr/local/bin/aclocal away? --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 13:56: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 381FA1065670 for ; Tue, 1 Sep 2009 13:56:07 +0000 (UTC) (envelope-from gausus@gausus.net) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id D03B68FC1A for ; Tue, 1 Sep 2009 13:56:06 +0000 (UTC) Received: by fxm6 with SMTP id 6so15954fxm.43 for ; Tue, 01 Sep 2009 06:56:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.48.17 with SMTP id a17mr2914838muk.82.1251811464948; Tue, 01 Sep 2009 06:24:24 -0700 (PDT) Date: Tue, 1 Sep 2009 15:24:24 +0200 Message-ID: From: Maciej Jan Broniarz To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Problems with ZFS on 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: Tue, 01 Sep 2009 13:56:07 -0000 Hello, I have installed Freebsd8-beta3 on a Phenom II Quad Core with 8 gb ram. When I create a zfs volume all works fine. Still, when I reboot the system it doesn't come up. It hangs with the following error: http://img525.imageshack.us/img525/3832/freebsd8zfs.jpg What might be the problem? Best regards, mjb -- [ -----< Maciej Jan Broniarz || gausus@gausus.net >------ ] | Siamo qui \ sotto la stessa luce \ sotto la sua croce \ | | cantando ad una voce \ E l'Emmanuel Emmanuel, Emmanuel, | [ ---------------< E l'Emmanuel, Emmanuel >-------------- ] From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 14:16: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 B3CFA1065693; Tue, 1 Sep 2009 14:16:36 +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 732E88FC1E; Tue, 1 Sep 2009 14:16:36 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1FAC546B03; Tue, 1 Sep 2009 10:16:36 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 226D08A040; Tue, 1 Sep 2009 10:16:35 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 1 Sep 2009 09:55:33 -0400 User-Agent: KMail/1.9.7 References: <20090822115958.f93fcf29.ubm.freebsd@gmail.com> <20090831222650.45b6c806.ubm@u-boot-man.de> <3bbf2fe10908311331k3e871898tc36a9846651cc53@mail.gmail.com> In-Reply-To: <3bbf2fe10908311331k3e871898tc36a9846651cc53@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909010955.33747.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 01 Sep 2009 10:16:35 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Attilio Rao , Marc UBM Subject: Re: panic: apic_free_vector: Thread already bound. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 14:16:36 -0000 On Monday 31 August 2009 4:31:50 pm Attilio Rao wrote: > 2009/8/31 Marc UBM : > > On Mon, 24 Aug 2009 16:31:05 -0400 > > John Baldwin wrote: > > > >> On Saturday 22 August 2009 5:59:58 am Marc UBM wrote: > >> > > >> > Hiho! :-) > >> > > >> > I'm seeing above panic in the final stages of the shutdown process. > >> > Coredump is available, bt as follows, textdump attached. > >> > > >> > > >> > FreeBSD hamstor 8.0-BETA2 FreeBSD 8.0-BETA2 #14: Wed Aug 19 22:43:17 > >> > CEST 2009 oni0@hamstor:/usr/obj/usr/src/sys/HAMSTOR amd64 > >> > > >> > > >> > (kgdb) bt > >> > #0 doadump () at pcpu.h:223 > >> > #1 0xffffffff801b561c in db_fncall (dummy1=Variable "dummy1" is not > >> > #available. > >> > ) at /usr/src/sys/ddb/db_command.c:548 > >> > #2 0xffffffff801b5951 in db_command (last_cmdp=0xffffffff808594a0, > >> > #cmd_table=Variable "cmd_table" is not available. > >> > ) at /usr/src/sys/ddb/db_command.c:445 > >> > #3 0xffffffff801b5ba0 in db_command_loop () > >> > #at /usr/src/sys/ddb/db_command.c:498 4 0xffffffff801b7b69 in > >> > #db_trap (type=Variable "type" is not available. > >> > ) at /usr/src/sys/ddb/db_main.c:229 > >> > #5 0xffffffff8038d775 in kdb_trap (type=3, code=0, > >> > #tf=0xffffff8000017760) at /usr/src/sys/kern/subr_kdb.c:535 6 > >> > #0xffffffff8060e170 in trap (frame=0xffffff8000017760) > >> > #at /usr/src/sys/amd64/amd64/trap.c:611 7 0xffffffff805f3b23 in > >> > #calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 8 > >> > #0xffffffff8038d94d in kdb_enter (why=0xffffffff80681954 "panic", > >> > #msg=0xa
) at cpufunc.h:63 9 > >> > #0xffffffff8035e04b in panic (fmt=Variable "fmt" is not available. > >> > ) at /usr/src/sys/kern/kern_shutdown.c:562 > >> > #10 0xffffffff805fafbb in apic_free_vector (apic_id=Variable > >> > #"apic_id" is not available. > >> > ) at /usr/src/sys/amd64/amd64/local_apic.c:995 > >> > #11 0xffffffff805f7560 in intr_remove_handler (cookie=Variable > >> > #"cookie" is not available. > >> > ) at /usr/src/sys/amd64/amd64/intr_machdep.c:203 > >> > #12 0xffffffff806250d4 in hpt_shutdown_vbus > >> > #(vbus_ext=0xffffff8000254000, howto=Variable "howto" is not > >> > #available. > >> > ) at /usr/src/sys/dev/hptrr/hptrr_osm_bsd.c:361 > >> > #13 0xffffffff8035da8b in boot (howto=16392) > >> > #at /usr/src/sys/kern/kern_shutdown.c:419 14 0xffffffff8035e126 in > >> > #reboot (td=Variable "td" is not available. > >> > ) at /usr/src/sys/kern/kern_shutdown.c:173 > >> > #15 0xffffffff8060dbba in syscall (frame=0xffffff8000017c80) > >> > #at /usr/src/sys/amd64/amd64/trap.c:982 16 0xffffffff805f3e01 in > >> > #Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 17 > >> > #0x000000000040892c in ?? () > >> > Previous frame inner to this frame (corrupt stack?) > >> > > >> > frame #12 & #13 make me suspect the hptrr driver (again :-)), but > >> > I'm not sure. > >> > >> Ah, any driver shutting off its interrupt handler during shutdown > >> would actually trigger this. The hptrr driver doesn't really need to > >> do this during shutdown, but I think we don't want to panic in this > >> case. Unfortunately we don't currently have a "in_shutdown" type of > >> global flag that we can check in apic_free_vector() to not worry > >> about the thread already being bound. > > > > Is there any chance this fix might make it into 8.0? It's not a real > > problem for me since I can just power-off by force, but I imagine it > > might be a real pita for people who only have remote access and want > > to reboot, etc. > > Maybe we can ship 8 with a printf() instrad than a panic()? Actually, it looks like 'rebooting' is what we want. Try this: --- //depot/vendor/freebsd/src/sys/amd64/amd64/local_apic.c 2009/08/14 21:10:13 +++ //depot/user/jhb/acpipci/amd64/amd64/local_apic.c 2009/09/01 13:54:23 @@ -990,18 +990,21 @@ * we don't lose an interrupt delivery race. */ td = curthread; - thread_lock(td); - if (sched_is_bound(td)) - panic("apic_free_vector: Thread already bound.\n"); - sched_bind(td, apic_cpuid(apic_id)); - thread_unlock(td); + if (!rebooting) { + thread_lock(td); + if (sched_is_bound(td)) + panic("apic_free_vector: Thread already bound.\n"); + sched_bind(td, apic_cpuid(apic_id)); + thread_unlock(td); + } mtx_lock_spin(&icu_lock); lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] = -1; mtx_unlock_spin(&icu_lock); - thread_lock(td); - sched_unbind(td); - thread_unlock(td); - + if (!rebooting) { + thread_lock(td); + sched_unbind(td); + thread_unlock(td); + } } /* Map an IDT vector (APIC) to an IRQ (interrupt source). */ --- //depot/vendor/freebsd/src/sys/i386/i386/local_apic.c 2009/08/14 21:10:13 +++ //depot/user/jhb/acpipci/i386/i386/local_apic.c 2009/09/01 13:53:14 @@ -994,18 +994,21 @@ * we don't lose an interrupt delivery race. */ td = curthread; - thread_lock(td); - if (sched_is_bound(td)) - panic("apic_free_vector: Thread already bound.\n"); - sched_bind(td, apic_cpuid(apic_id)); - thread_unlock(td); + if (!rebooting) { + thread_lock(td); + if (sched_is_bound(td)) + panic("apic_free_vector: Thread already bound.\n"); + sched_bind(td, apic_cpuid(apic_id)); + thread_unlock(td); + } mtx_lock_spin(&icu_lock); lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] = -1; mtx_unlock_spin(&icu_lock); - thread_lock(td); - sched_unbind(td); - thread_unlock(td); - + if (!rebooting) { + thread_lock(td); + sched_unbind(td); + thread_unlock(td); + } } /* Map an IDT vector (APIC) to an IRQ (interrupt source). */ -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 14:16: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 126091065696 for ; Tue, 1 Sep 2009 14:16:38 +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 D7C2B8FC14 for ; Tue, 1 Sep 2009 14:16:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8753B46B2C; Tue, 1 Sep 2009 10:16:37 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id BEBC68A043; Tue, 1 Sep 2009 10:16:36 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 1 Sep 2009 10:02:59 -0400 User-Agent: KMail/1.9.7 References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im> In-Reply-To: <4A9BF438.1000006@smeets.im> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909011002.59592.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 01 Sep 2009 10:16:36 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Nick Hilliard Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 14:16:38 -0000 On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote: > On 8/31/09 5:54 PM, Nick Hilliard wrote: > > Hi, > > > > I have a hp proliant ML115 with 6 sata ports which run in ATA mode (bios > > doesn't appear to give the option to use AHCI). On freebsd 7.x, all > > channels are detected. On freebsd8.0-beta3, the disks attached to the > > first two SATA ports are not detected, although it detects the ports > > themselves. > > > > I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. > > > > Any ideas on what's going on here? This seems like a nasty regression. > > There are 3 PRs about this problem: 128686, 132372, 137942. > > i386 version should recognize the disks. amd64 does when you set > hw.pci.mcfg=0 in loader.conf. Hmm, so an idea I had just now.. can you grab a dump of the PCI config space for the disk controller in the MCFG vs non-MCFG cases? That is, find the device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then run this command under both configurations and save the output: pciconf -r pci0:0:30:0 0:0xfc -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 14:16: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 032DF106568B for ; Tue, 1 Sep 2009 14:16:40 +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 C9DDC8FC20 for ; Tue, 1 Sep 2009 14:16:39 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 79C8A46B37; Tue, 1 Sep 2009 10:16:39 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 96A828A049; Tue, 1 Sep 2009 10:16:38 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 1 Sep 2009 10:05:17 -0400 User-Agent: KMail/1.9.7 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909011005.18200.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 01 Sep 2009 10:16:38 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Maciej Jan Broniarz Subject: Re: Problems with ZFS on 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: Tue, 01 Sep 2009 14:16:40 -0000 On Tuesday 01 September 2009 9:24:24 am Maciej Jan Broniarz wrote: > Hello, > > I have installed Freebsd8-beta3 on a Phenom II Quad Core with 8 gb ram. > When I create a zfs volume all works fine. Still, when I reboot the system > it doesn't come up. It hangs with the following error: > > http://img525.imageshack.us/img525/3832/freebsd8zfs.jpg > > What might be the problem? It's probably a NULL pointer dereference, but we would need a stack trace to investigate this further. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 14:31: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 37E3B1065672 for ; Tue, 1 Sep 2009 14:31:18 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.193]) by mx1.freebsd.org (Postfix) with ESMTP id B3E518FC08 for ; Tue, 1 Sep 2009 14:31:16 +0000 (UTC) X-Envelope-To: freebsd-current@freebsd.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.3/8.14.3) with ESMTP id n81EVCDw021018 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 1 Sep 2009 15:31:12 +0100 (IST) (envelope-from nick-lists@netability.ie) Message-ID: <4A9D3030.9040500@netability.ie> Date: Tue, 01 Sep 2009 15:31:12 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im> <200909011002.59592.jhb@freebsd.org> In-Reply-To: <200909011002.59592.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.2 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 muffin.acquirer.com Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 14:31:18 -0000 On 01/09/2009 15:02, John Baldwin wrote: > Hmm, so an idea I had just now.. can you grab a dump of the PCI config space > for the disk controller in the MCFG vs non-MCFG cases? That is, find the > device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then > run this command under both configurations and save the output: > > pciconf -r pci0:0:30:0 0:0xfc 7.1, 8.0-beta3, or does it matter? Nick From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 15:02: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 A8B0E106566C for ; Tue, 1 Sep 2009 15:02:26 +0000 (UTC) (envelope-from jamie@bishopston.net) Received: from pacha.mail.bishopston.net (pacha.mail.bishopston.net [IPv6:2001:5c0:1100:200::3]) by mx1.freebsd.org (Postfix) with ESMTP id 5DFA98FC15 for ; Tue, 1 Sep 2009 15:02:26 +0000 (UTC) X-Catflap-Envelope-From: X-Catflap-Envelope-To: Received: from catflap.bishopston.net (jamie@localhost [127.0.0.1]) by catflap.bishopston.net (8.14.3/8.14.3) with ESMTP id n81F2PWZ033292 for ; Tue, 1 Sep 2009 16:02:25 +0100 (BST) (envelope-from jamie@catflap.bishopston.net) Received: (from jamie@localhost) by catflap.bishopston.net (8.14.3/8.12.9/Submit) id n81F2PUF033284 for freebsd-current@freebsd.org; Tue, 1 Sep 2009 16:02:25 +0100 (BST) From: Jamie Landeg Jones Message-Id: <200909011502.n81F2PUF033284@catflap.bishopston.net> Date: Tue, 01 Sep 2009 16:02:25 +0100 Organization: http://www.bishopston.com/jamie/ To: freebsd-current@freebsd.org User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (catflap.bishopston.net [127.0.0.1]); Tue, 01 Sep 2009 16:02:25 +0100 (BST) X-Virus-Scanned: clamav-milter 0.95.2 at catflap.bishopston.net X-Virus-Status: Clean Subject: Re: reproducable kernel panic: page fault - 8.0-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 15:02:26 -0000 On Aug 30, 2009, at 7:58 PM, Bjoern A. Zeeb wrote: > > On Sun, 30 Aug 2009, Jamie Landeg Jones wrote: > > > >> problem still exists. no response to PR raised over a month ago :-( > > > > Now it would be really good if you had more information here, at least > > a PR number. There have been lots of them the last month. > That's what I thought, but the query PR form (by originator) worked > great. ;) > kern/137310: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/137310 Thanks. Obviuously I mneat to paste the URL - I'd looked it up especially to post in the email, but I must have forgotton! Sorry about that. Jamie From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 15:25: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 57536106568F for ; Tue, 1 Sep 2009 15:25: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 279F78FC1C for ; Tue, 1 Sep 2009 15:25:12 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id B7DB446B3B; Tue, 1 Sep 2009 11:25:11 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 094DF8A03E; Tue, 1 Sep 2009 11:25:11 -0400 (EDT) From: John Baldwin To: Nick Hilliard Date: Tue, 1 Sep 2009 11:23:04 -0400 User-Agent: KMail/1.9.7 References: <4A9BF23F.6070801@netability.ie> <200909011002.59592.jhb@freebsd.org> <4A9D3030.9040500@netability.ie> In-Reply-To: <4A9D3030.9040500@netability.ie> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909011123.04873.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 01 Sep 2009 11:25:11 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=AWL,BAYES_00,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: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 15:25:12 -0000 On Tuesday 01 September 2009 10:31:12 am Nick Hilliard wrote: > On 01/09/2009 15:02, John Baldwin wrote: > > Hmm, so an idea I had just now.. can you grab a dump of the PCI config space > > for the disk controller in the MCFG vs non-MCFG cases? That is, find the > > device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then > > run this command under both configurations and save the output: > > > > pciconf -r pci0:0:30:0 0:0xfc > > 7.1, 8.0-beta3, or does it matter? Doesn't really matter, I just want to compare a working case to a non-working case. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 15:29: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 0B21E106568B for ; Tue, 1 Sep 2009 15:29:55 +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 BEDDB8FC0C for ; Tue, 1 Sep 2009 15:29:54 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n81FTrfo018542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Sep 2009 08:29:54 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A9D3DF1.7000605@errno.com> Date: Tue, 01 Sep 2009 08:29:53 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: John Nielsen References: <20090807165850.3e8541f8@vaio> <20090808134101.44d7d210@vaio> <4A7E5E2B.6060204@errno.com> <200908312358.51491.lists@jnielsen.net> In-Reply-To: <200908312358.51491.lists@jnielsen.net> Content-Type: multipart/mixed; boundary="------------060009060109060905060909" X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: WEP on wi(4) [was: Re: LOR wlan0 wi0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 15:29:55 -0000 This is a multi-part message in MIME format. --------------060009060109060905060909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit John Nielsen wrote: > On Sunday 09 August 2009 01:27:07 am Sam Leffler wrote: >>> Sam Leffler wrote: >> I can confirm WEP is broken on wi in sta mode (and probably ap mode). >> I found at least two bugs but couldn't get it to work so am going to >> leave it as an errata for 8.0. But what's truly odd is that WPA works >> fine despite a bug that should've caused it to not work. I knew WPA >> worked which is probably why I ignored WEP (noone in their right mind >> uses WEP when WPA is available :-)). > > So for us wrong-minded people with wi(4) hardware that lacks WPA support > is it better to stick with 7.x for now? Any patches available or a rough > ETA? Is there a specific set of 8-CURRENT commits before which WEP is > known (or strongly suspected) to work? Anything others can do to help > besides ask annoying questions? (Sadly I'm not quite enough of a kernel > hacker to adopt maintainership of wi.) Attached is what I came up with when the problem was identified. As you can see it's incomplete. I have no time to work on it more so someone else will need to follow through. Given the cost of a replacement wireless card is Date: Mon, 10 Aug 2009 09:05:39 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "M. Warner Losh" Subject: wi wep patch Content-Type: multipart/mixed; boundary="------------050907030306010605060101" This is a multi-part message in MIME format. --------------050907030306010605060101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The attached patch tries to fix WEP support in wi. Presently WEP does not work for two reasons: 1. wi_start_locked does not mask the PRIVACY bit from the header flags when finding the direction to extract mac addresses to reconstruct the 802.3 frame. Why this does not break WPA also is beyond me. 2. wi marks all tx encrypted frames WI_TXCNTL_NOCRYPT but tries to use h/w WEP support for cards that support it. I've deleted the h/w crypto support and just do the work in s/w. But the above does not fix WEP and I don't see why. If you've got any ideas it'd be nice to fix this. Otherwise if you can review what I've done it'd be appreciated. I can submit just #1 to re as that's definitely correct. Sam --------------050907030306010605060101 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="wi.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="wi.patch" Index: if_wivar.h =================================================================== --- if_wivar.h (revision 196086) +++ if_wivar.h (working copy) @@ -113,7 +113,6 @@ int sc_porttype; u_int16_t sc_portnum; - u_int16_t sc_encryption; u_int16_t sc_monitor_port; /* RSSI interpretation */ Index: if_wi.c =================================================================== --- if_wi.c (revision 196086) +++ if_wi.c (working copy) @@ -137,7 +137,6 @@ static void wi_info_intr(struct wi_softc *); static int wi_write_txrate(struct wi_softc *, struct ieee80211vap *); -static int wi_write_wep(struct wi_softc *, struct ieee80211vap *); static int wi_write_multi(struct wi_softc *); static void wi_update_mcast(struct ifnet *); static void wi_update_promisc(struct ifnet *); @@ -417,15 +416,6 @@ sc->sc_dbm_offset = WI_PRISM_DBM_OFFSET; break; } - - /* - * Find out if we support WEP on this card. - */ - buflen = sizeof(val); - if (wi_read_rid(sc, WI_RID_WEP_AVAIL, &val, &buflen) == 0 && - val != htole16(0)) - ic->ic_cryptocaps |= IEEE80211_CRYPTO_WEP; - /* Find supported rates. */ buflen = sizeof(ratebuf); rs = &ic->ic_sup_rates[IEEE80211_MODE_11B]; @@ -842,12 +832,6 @@ wi_write_val(sc, WI_RID_OWN_CHNL, ieee80211_chan2ieee(ic, bss->ni_chan)); - /* Configure WEP. */ - if (ic->ic_cryptocaps & IEEE80211_CRYPTO_WEP) - wi_write_wep(sc, vap); - else - sc->sc_encryption = 0; - if ((sc->sc_flags & WI_FLAGS_HAS_WPASUPPORT) && (vap->iv_flags & IEEE80211_F_WPA)) { wi_write_val(sc, WI_RID_WPA_HANDLING, 1); @@ -932,12 +916,6 @@ wi_write_val(sc, WI_RID_PROMISC, 0); - /* Configure WEP. */ - if (ic->ic_cryptocaps & IEEE80211_CRYPTO_WEP) - wi_write_wep(sc, vap); - else - sc->sc_encryption = 0; - wi_enable(sc); /* enable port */ WI_UNLOCK(sc); } @@ -976,7 +954,7 @@ /* reconstruct 802.3 header */ wh = mtod(m0, struct ieee80211_frame *); - switch (wh->i_fc[1]) { + switch (wh->i_fc[1] & IEEE80211_FC1_DIR_MASK) { case IEEE80211_FC1_DIR_TODS: IEEE80211_ADDR_COPY(frmhdr.wi_ehdr.ether_shost, wh->i_addr2); @@ -1739,71 +1717,6 @@ } static int -wi_write_wep(struct wi_softc *sc, struct ieee80211vap *vap) -{ - int error = 0; - int i, keylen; - u_int16_t val; - struct wi_key wkey[IEEE80211_WEP_NKID]; - - switch (sc->sc_firmware_type) { - case WI_LUCENT: - val = (vap->iv_flags & IEEE80211_F_PRIVACY) ? 1 : 0; - error = wi_write_val(sc, WI_RID_ENCRYPTION, val); - if (error) - break; - if ((vap->iv_flags & IEEE80211_F_PRIVACY) == 0) - break; - error = wi_write_val(sc, WI_RID_TX_CRYPT_KEY, vap->iv_def_txkey); - if (error) - break; - memset(wkey, 0, sizeof(wkey)); - for (i = 0; i < IEEE80211_WEP_NKID; i++) { - keylen = vap->iv_nw_keys[i].wk_keylen; - wkey[i].wi_keylen = htole16(keylen); - memcpy(wkey[i].wi_keydat, vap->iv_nw_keys[i].wk_key, - keylen); - } - error = wi_write_rid(sc, WI_RID_DEFLT_CRYPT_KEYS, - wkey, sizeof(wkey)); - sc->sc_encryption = 0; - break; - - case WI_INTERSIL: - val = HOST_ENCRYPT | HOST_DECRYPT; - if (vap->iv_flags & IEEE80211_F_PRIVACY) { - /* - * ONLY HWB3163 EVAL-CARD Firmware version - * less than 0.8 variant2 - * - * If promiscuous mode disable, Prism2 chip - * does not work with WEP . - * It is under investigation for details. - * (ichiro@netbsd.org) - */ - if (sc->sc_sta_firmware_ver < 802 ) { - /* firm ver < 0.8 variant 2 */ - wi_write_val(sc, WI_RID_PROMISC, 1); - } - wi_write_val(sc, WI_RID_CNFAUTHMODE, - vap->iv_bss->ni_authmode); - val |= PRIVACY_INVOKED; - } else { - wi_write_val(sc, WI_RID_CNFAUTHMODE, IEEE80211_AUTH_OPEN); - } - error = wi_write_val(sc, WI_RID_P2_ENCRYPTION, val); - if (error) - break; - sc->sc_encryption = val; - if ((val & PRIVACY_INVOKED) == 0) - break; - error = wi_write_val(sc, WI_RID_P2_TX_CRYPT_KEY, vap->iv_def_txkey); - break; - } - return error; -} - -static int wi_cmd(struct wi_softc *sc, int cmd, int val0, int val1, int val2) { int i, s = 0; --------------050907030306010605060101-- --------------060009060109060905060909-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 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 D89B5106568F for ; Tue, 1 Sep 2009 16:48:01 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 6AD958FC15 for ; Tue, 1 Sep 2009 16:48:01 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MiWWV-0001ZP-Bm; Tue, 01 Sep 2009 18:47:59 +0200 Message-ID: <4A9D5036.9000403@gwdg.de> Date: Tue, 01 Sep 2009 18:47:50 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im> <200909011002.59592.jhb@freebsd.org> In-Reply-To: <200909011002.59592.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 16:48:01 -0000 On 01.09.2009 16:02 (UTC+2), John Baldwin wrote: > On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote: >> On 8/31/09 5:54 PM, Nick Hilliard wrote: >>> Hi, >>> >>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode (bios >>> doesn't appear to give the option to use AHCI). On freebsd 7.x, all >>> channels are detected. On freebsd8.0-beta3, the disks attached to the >>> first two SATA ports are not detected, although it detects the ports >>> themselves. >>> >>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. >>> >>> Any ideas on what's going on here? This seems like a nasty regression. >> There are 3 PRs about this problem: 128686, 132372, 137942. >> >> i386 version should recognize the disks. amd64 does when you set >> hw.pci.mcfg=0 in loader.conf. > > Hmm, so an idea I had just now.. can you grab a dump of the PCI config space > for the disk controller in the MCFG vs non-MCFG cases? That is, find the > device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then > run this command under both configurations and save the output: > > pciconf -r pci0:0:30:0 0:0xfc > I am not sure if your idea has something to do with my (and some other users) problem. So excuse me, if this posting is wrong. For some month now I am only able to boot CURRENT under amd64 with setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output under i386 and under amd64. Perhaps you are able to get a hint? Tell me if I can help in any way. Thanks in advance, Rainer Hurling #pciconf -lv atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA/RAID Controller (MCP55S)' class = mass storage subclass = ATA atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA/RAID Controller (MCP55S)' class = mass storage subclass = ATA --- i386 Config ---------------------------------------------------- #sysctl hw.pci.mcfg hw.pci.mcfg: 1 #pciconf -r pci0:0:5:0 0:0xfc 037f10de 00b00007 010185a2 00800000 0000c481 0000c401 0000c081 0000c001 0000bc01 f9ef9000 00000000 72601462 00000000 00000044 00000000 01030117 72601462 0002b001 00000000 00000000 0008680f 00000000 00000000 00000000 00000000 00000c41 42060f00 00000000 40c4782c 00001001 00001001 00200020 c0000000 0f498000 a0200000 7c750000 a0100000 00000000 10060006 0101037f 19000a12 00000000 00000000 02003133 0084cc05 00000000 00000000 00000000 00000000 00000000 000a000a a8020008 0c02000a 00000042 00000000 e7c00001 0c02000a 00000042 00000000 e030000f 00000000 00000000 000c0010 00000000 #pciconf -r pci0:0:5:1 0:0xfc 037f10de 00b00007 010185a2 00800000 0000b881 0000b801 0000b481 0000b401 0000b081 f9ef8000 00000000 72601462 00000000 00000044 00000000 01030214 72601462 0002b001 00000000 00000000 0008680f 00000000 00000000 00000000 00000000 00000c41 42060f00 00000000 40c4782c 00001001 00001001 00200020 c0000000 ffefffff 0f1f0000 f7ff7f3b 3fb70000 00000000 10060006 0101037f 00000a12 00000000 00000000 02003133 0084cc05 00000000 00000000 00000000 00000000 00000000 000a000a a8020008 0602000a 00000042 00000000 0050000f 0602000a 00000042 00000000 0040000f 00000000 00000000 000c0010 00000000 --- amd64 Config --------------------------------------------------- #sysctl hw.pci.mcfg hw.pci.mcfg: 0 #pciconf -r pci0:0:5:0 0:0xfc 037f10de 00b00007 010185a2 00800000 0000c481 0000c401 0000c081 0000c001 0000bc01 f9ef9000 00000000 72601462 00000000 00000044 00000000 01030117 72601462 0002b001 00000000 00000000 0008680f 00000000 00000000 00000000 00000000 00000c41 42060f00 00000000 40c4782c 00001001 00001001 00200020 c0000000 03562000 80080000 41403000 b0080000 00000000 10060006 0101037f 18000a12 00000000 00000000 02003133 0084cc05 00000000 00000000 00000000 00000000 00000000 000a000a a8020008 0c02000a 00000042 00000000 e7c00001 0c02000a 00000042 00000000 e030000f 00000000 00000000 000c0010 00000000 #pciconf -r pci0:0:5:1 0:0xfc 037f10de 00b00007 010185a2 00800000 0000b881 0000b801 0000b481 0000b401 0000b081 f9ef8000 00000000 72601462 00000000 00000044 00000000 01030214 72601462 0002b001 00000000 00000000 0008680f 00000000 00000000 00000000 00000000 00000c41 42060f00 00000000 40c4782c 00001001 00001001 00200020 00000000 ffefffff 0f1f0000 f7ff7f3b 3fb70000 00000000 10060006 0101037f 00000a12 00000000 00000000 02003133 0084cc05 00000000 00000000 00000000 00000000 00000000 000a000a a8020008 0602000a 00000042 00000000 0050000f 0602000a 00000042 00000000 0040000f 00000000 00000000 000c0010 00000000 From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 16:52: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 187A61065670 for ; Tue, 1 Sep 2009 16:52:08 +0000 (UTC) (envelope-from jamie@bishopston.net) Received: from pacha.mail.bishopston.net (pacha.mail.bishopston.net [IPv6:2001:5c0:1100:200::3]) by mx1.freebsd.org (Postfix) with ESMTP id BE3088FC23 for ; Tue, 1 Sep 2009 16:52:07 +0000 (UTC) X-Catflap-Envelope-From: Received: from catflap.bishopston.net (jamie@localhost [127.0.0.1]) by catflap.bishopston.net (8.14.3/8.14.3) with ESMTP id n81GokZ7022217; Tue, 1 Sep 2009 17:50:46 +0100 (BST) (envelope-from jamie@catflap.bishopston.net) Received: (from jamie@localhost) by catflap.bishopston.net (8.14.3/8.12.9/Submit) id n81GoklK022216; Tue, 1 Sep 2009 17:50:46 +0100 (BST) From: Jamie Landeg Jones Message-Id: <200909011650.n81GoklK022216@catflap.bishopston.net> Date: Tue, 01 Sep 2009 17:50:46 +0100 Organization: http://www.bishopston.com/jamie/ To: serenity@exscape.org, kostikbel@gmail.com References: <200908301750.n7UHoOwr069011@catflap.bishopston.net> <20090830175755.J93661@maildrop.int.zabbadoz.net> <20090830182951.GL1881@deviant.kiev.zoral.com.ua> In-Reply-To: <20090830182951.GL1881@deviant.kiev.zoral.com.ua> User-Agent: Heirloom mailx 12.4 7/29/08 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (catflap.bishopston.net [127.0.0.1]); Tue, 01 Sep 2009 17:50:46 +0100 (BST) X-Virus-Scanned: clamav-milter 0.95.2 at catflap.bishopston.net X-Virus-Status: Clean Cc: jamie@bishopston.net, bzeeb-lists@lists.zabbadoz.net, freebsd-current@freebsd.org Subject: Re: reproducable kernel panic: page fault - 8.0-beta X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 16:52:08 -0000 Kostik Belousov wrote: > I think this would fix the issue. > > diff --git a/sys/fs/pseudofs/pseudofs_vnops.c b/sys/fs/pseudofs/pseudofs_vnops.c > index e03749b..34ca500 100644 > --- a/sys/fs/pseudofs/pseudofs_vnops.c > +++ b/sys/fs/pseudofs/pseudofs_vnops.c > @@ -339,7 +339,6 @@ pfs_getextattr(struct vop_getextattr_args *va) > if (proc != NULL) > PROC_UNLOCK(proc); > > - pfs_unlock(pn); > PFS_RETURN (error); > } Thanks. I just tried that on my machines, and it does fix this. Cheers, Jamie From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 17:41: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 83393106568F for ; Tue, 1 Sep 2009 17:41:33 +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 54A458FC22 for ; Tue, 1 Sep 2009 17:41:33 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E6B5146B0C; Tue, 1 Sep 2009 13:41:32 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2C9098A02E; Tue, 1 Sep 2009 13:41:32 -0400 (EDT) From: John Baldwin To: Rainer Hurling Date: Tue, 1 Sep 2009 13:41:25 -0400 User-Agent: KMail/1.9.7 References: <4A9BF23F.6070801@netability.ie> <200909011002.59592.jhb@freebsd.org> <4A9D5036.9000403@gwdg.de> In-Reply-To: <4A9D5036.9000403@gwdg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909011341.26192.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 01 Sep 2009 13:41:32 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.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: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 17:41:33 -0000 On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote: > On 01.09.2009 16:02 (UTC+2), John Baldwin wrote: > > On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote: > >> On 8/31/09 5:54 PM, Nick Hilliard wrote: > >>> Hi, > >>> > >>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode (bios > >>> doesn't appear to give the option to use AHCI). On freebsd 7.x, all > >>> channels are detected. On freebsd8.0-beta3, the disks attached to the > >>> first two SATA ports are not detected, although it detects the ports > >>> themselves. > >>> > >>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. > >>> > >>> Any ideas on what's going on here? This seems like a nasty regression. > >> There are 3 PRs about this problem: 128686, 132372, 137942. > >> > >> i386 version should recognize the disks. amd64 does when you set > >> hw.pci.mcfg=0 in loader.conf. > > > > Hmm, so an idea I had just now.. can you grab a dump of the PCI config space > > for the disk controller in the MCFG vs non-MCFG cases? That is, find the > > device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then > > run this command under both configurations and save the output: > > > > pciconf -r pci0:0:30:0 0:0xfc > > > > I am not sure if your idea has something to do with my (and some other > users) problem. So excuse me, if this posting is wrong. > > For some month now I am only able to boot CURRENT under amd64 with > setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output > under i386 and under amd64. Perhaps you are able to get a hint? Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using nfsroot or an mfsroot) and capture this output? The mcfg thing only affects access to PCI config space (what pciconf -r is displaying). I want to be able to compare the "broken" case (amd64 mcfg=1) with a working case. > Tell me if I can help in any way. > > Thanks in advance, > Rainer Hurling > > > #pciconf -lv > atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA/RAID Controller (MCP55S)' > class = mass storage > subclass = ATA > atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA/RAID Controller (MCP55S)' > class = mass storage > subclass = ATA > > > --- i386 Config ---------------------------------------------------- > #sysctl hw.pci.mcfg > hw.pci.mcfg: 1 > > #pciconf -r pci0:0:5:0 0:0xfc > 037f10de 00b00007 010185a2 00800000 > 0000c481 0000c401 0000c081 0000c001 > 0000bc01 f9ef9000 00000000 72601462 > 00000000 00000044 00000000 01030117 > 72601462 0002b001 00000000 00000000 > 0008680f 00000000 00000000 00000000 > 00000000 00000c41 42060f00 00000000 > 40c4782c 00001001 00001001 00200020 > c0000000 0f498000 a0200000 7c750000 > a0100000 00000000 10060006 0101037f > 19000a12 00000000 00000000 02003133 > 0084cc05 00000000 00000000 00000000 > 00000000 00000000 000a000a a8020008 > 0c02000a 00000042 00000000 e7c00001 > 0c02000a 00000042 00000000 e030000f > 00000000 00000000 000c0010 00000000 > > #pciconf -r pci0:0:5:1 0:0xfc > 037f10de 00b00007 010185a2 00800000 > 0000b881 0000b801 0000b481 0000b401 > 0000b081 f9ef8000 00000000 72601462 > 00000000 00000044 00000000 01030214 > 72601462 0002b001 00000000 00000000 > 0008680f 00000000 00000000 00000000 > 00000000 00000c41 42060f00 00000000 > 40c4782c 00001001 00001001 00200020 > c0000000 ffefffff 0f1f0000 f7ff7f3b > 3fb70000 00000000 10060006 0101037f > 00000a12 00000000 00000000 02003133 > 0084cc05 00000000 00000000 00000000 > 00000000 00000000 000a000a a8020008 > 0602000a 00000042 00000000 0050000f > 0602000a 00000042 00000000 0040000f > 00000000 00000000 000c0010 00000000 > > > --- amd64 Config --------------------------------------------------- > #sysctl hw.pci.mcfg > hw.pci.mcfg: 0 > > #pciconf -r pci0:0:5:0 0:0xfc > 037f10de 00b00007 010185a2 00800000 > 0000c481 0000c401 0000c081 0000c001 > 0000bc01 f9ef9000 00000000 72601462 > 00000000 00000044 00000000 01030117 > 72601462 0002b001 00000000 00000000 > 0008680f 00000000 00000000 00000000 > 00000000 00000c41 42060f00 00000000 > 40c4782c 00001001 00001001 00200020 > c0000000 03562000 80080000 41403000 > b0080000 00000000 10060006 0101037f > 18000a12 00000000 00000000 02003133 > 0084cc05 00000000 00000000 00000000 > 00000000 00000000 000a000a a8020008 > 0c02000a 00000042 00000000 e7c00001 > 0c02000a 00000042 00000000 e030000f > 00000000 00000000 000c0010 00000000 > > #pciconf -r pci0:0:5:1 0:0xfc > 037f10de 00b00007 010185a2 00800000 > 0000b881 0000b801 0000b481 0000b401 > 0000b081 f9ef8000 00000000 72601462 > 00000000 00000044 00000000 01030214 > 72601462 0002b001 00000000 00000000 > 0008680f 00000000 00000000 00000000 > 00000000 00000c41 42060f00 00000000 > 40c4782c 00001001 00001001 00200020 > 00000000 ffefffff 0f1f0000 f7ff7f3b > 3fb70000 00000000 10060006 0101037f > 00000a12 00000000 00000000 02003133 > 0084cc05 00000000 00000000 00000000 > 00000000 00000000 000a000a a8020008 > 0602000a 00000042 00000000 0050000f > 0602000a 00000042 00000000 0040000f > 00000000 00000000 000c0010 00000000 > -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 18:49: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 463831065672; Tue, 1 Sep 2009 18:49:18 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id CB0AF8FC16; Tue, 1 Sep 2009 18:49:17 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MiYPr-0007Bi-Kv; Tue, 01 Sep 2009 20:49:16 +0200 Message-ID: <4A9D6CA5.1040409@gwdg.de> Date: Tue, 01 Sep 2009 20:49:09 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <200909011002.59592.jhb@freebsd.org> <4A9D5036.9000403@gwdg.de> <200909011341.26192.jhb@freebsd.org> In-Reply-To: <200909011341.26192.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 18:49:18 -0000 On 01.09.2009 19:41 (UTC+2), John Baldwin wrote: > On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote: >> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote: >>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote: >>>> On 8/31/09 5:54 PM, Nick Hilliard wrote: >>>>> Hi, >>>>> >>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode (bios >>>>> doesn't appear to give the option to use AHCI). On freebsd 7.x, all >>>>> channels are detected. On freebsd8.0-beta3, the disks attached to the >>>>> first two SATA ports are not detected, although it detects the ports >>>>> themselves. >>>>> >>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. >>>>> >>>>> Any ideas on what's going on here? This seems like a nasty regression. >>>> There are 3 PRs about this problem: 128686, 132372, 137942. >>>> >>>> i386 version should recognize the disks. amd64 does when you set >>>> hw.pci.mcfg=0 in loader.conf. >>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config > space >>> for the disk controller in the MCFG vs non-MCFG cases? That is, find the >>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and > then >>> run this command under both configurations and save the output: >>> >>> pciconf -r pci0:0:30:0 0:0xfc >>> >> I am not sure if your idea has something to do with my (and some other >> users) problem. So excuse me, if this posting is wrong. >> >> For some month now I am only able to boot CURRENT under amd64 with >> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output >> under i386 and under amd64. Perhaps you are able to get a hint? > > Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using nfsroot or > an mfsroot) and capture this output? The mcfg thing only affects access to > PCI config space (what pciconf -r is displaying). I want to be able to > compare the "broken" case (amd64 mcfg=1) with a working case. My only amd64 system is at home. Sorry, but I have no idea how to start this system using nfsroot oder mfsroot. >> Tell me if I can help in any way. >> >> Thanks in advance, >> Rainer Hurling >> >> >> #pciconf -lv >> atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de >> rev=0xa2 hdr=0x00 >> vendor = 'Nvidia Corp' >> device = 'MCP55 SATA/RAID Controller (MCP55S)' >> class = mass storage >> subclass = ATA >> atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de >> rev=0xa2 hdr=0x00 >> vendor = 'Nvidia Corp' >> device = 'MCP55 SATA/RAID Controller (MCP55S)' >> class = mass storage >> subclass = ATA >> >> >> --- i386 Config ---------------------------------------------------- >> #sysctl hw.pci.mcfg >> hw.pci.mcfg: 1 >> >> #pciconf -r pci0:0:5:0 0:0xfc >> 037f10de 00b00007 010185a2 00800000 >> 0000c481 0000c401 0000c081 0000c001 >> 0000bc01 f9ef9000 00000000 72601462 >> 00000000 00000044 00000000 01030117 >> 72601462 0002b001 00000000 00000000 >> 0008680f 00000000 00000000 00000000 >> 00000000 00000c41 42060f00 00000000 >> 40c4782c 00001001 00001001 00200020 >> c0000000 0f498000 a0200000 7c750000 >> a0100000 00000000 10060006 0101037f >> 19000a12 00000000 00000000 02003133 >> 0084cc05 00000000 00000000 00000000 >> 00000000 00000000 000a000a a8020008 >> 0c02000a 00000042 00000000 e7c00001 >> 0c02000a 00000042 00000000 e030000f >> 00000000 00000000 000c0010 00000000 >> >> #pciconf -r pci0:0:5:1 0:0xfc >> 037f10de 00b00007 010185a2 00800000 >> 0000b881 0000b801 0000b481 0000b401 >> 0000b081 f9ef8000 00000000 72601462 >> 00000000 00000044 00000000 01030214 >> 72601462 0002b001 00000000 00000000 >> 0008680f 00000000 00000000 00000000 >> 00000000 00000c41 42060f00 00000000 >> 40c4782c 00001001 00001001 00200020 >> c0000000 ffefffff 0f1f0000 f7ff7f3b >> 3fb70000 00000000 10060006 0101037f >> 00000a12 00000000 00000000 02003133 >> 0084cc05 00000000 00000000 00000000 >> 00000000 00000000 000a000a a8020008 >> 0602000a 00000042 00000000 0050000f >> 0602000a 00000042 00000000 0040000f >> 00000000 00000000 000c0010 00000000 >> >> >> --- amd64 Config --------------------------------------------------- >> #sysctl hw.pci.mcfg >> hw.pci.mcfg: 0 >> >> #pciconf -r pci0:0:5:0 0:0xfc >> 037f10de 00b00007 010185a2 00800000 >> 0000c481 0000c401 0000c081 0000c001 >> 0000bc01 f9ef9000 00000000 72601462 >> 00000000 00000044 00000000 01030117 >> 72601462 0002b001 00000000 00000000 >> 0008680f 00000000 00000000 00000000 >> 00000000 00000c41 42060f00 00000000 >> 40c4782c 00001001 00001001 00200020 >> c0000000 03562000 80080000 41403000 >> b0080000 00000000 10060006 0101037f >> 18000a12 00000000 00000000 02003133 >> 0084cc05 00000000 00000000 00000000 >> 00000000 00000000 000a000a a8020008 >> 0c02000a 00000042 00000000 e7c00001 >> 0c02000a 00000042 00000000 e030000f >> 00000000 00000000 000c0010 00000000 >> >> #pciconf -r pci0:0:5:1 0:0xfc >> 037f10de 00b00007 010185a2 00800000 >> 0000b881 0000b801 0000b481 0000b401 >> 0000b081 f9ef8000 00000000 72601462 >> 00000000 00000044 00000000 01030214 >> 72601462 0002b001 00000000 00000000 >> 0008680f 00000000 00000000 00000000 >> 00000000 00000c41 42060f00 00000000 >> 40c4782c 00001001 00001001 00200020 >> 00000000 ffefffff 0f1f0000 f7ff7f3b >> 3fb70000 00000000 10060006 0101037f >> 00000a12 00000000 00000000 02003133 >> 0084cc05 00000000 00000000 00000000 >> 00000000 00000000 000a000a a8020008 >> 0602000a 00000042 00000000 0050000f >> 0602000a 00000042 00000000 0040000f >> 00000000 00000000 000c0010 00000000 From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 19:17: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 A5D39106568D for ; Tue, 1 Sep 2009 19:17:29 +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 77B528FC1B for ; Tue, 1 Sep 2009 19:17:29 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 10D3546B45; Tue, 1 Sep 2009 15:17:29 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 73BFE8A041; Tue, 1 Sep 2009 15:17:28 -0400 (EDT) From: John Baldwin To: Rainer Hurling Date: Tue, 1 Sep 2009 15:05:31 -0400 User-Agent: KMail/1.9.7 References: <4A9BF23F.6070801@netability.ie> <200909011341.26192.jhb@freebsd.org> <4A9D6CA5.1040409@gwdg.de> In-Reply-To: <4A9D6CA5.1040409@gwdg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909011505.32243.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 01 Sep 2009 15:17:28 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.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: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 19:17:29 -0000 On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote: > On 01.09.2009 19:41 (UTC+2), John Baldwin wrote: > > On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote: > >> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote: > >>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote: > >>>> On 8/31/09 5:54 PM, Nick Hilliard wrote: > >>>>> Hi, > >>>>> > >>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode (bios > >>>>> doesn't appear to give the option to use AHCI). On freebsd 7.x, all > >>>>> channels are detected. On freebsd8.0-beta3, the disks attached to the > >>>>> first two SATA ports are not detected, although it detects the ports > >>>>> themselves. > >>>>> > >>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. > >>>>> > >>>>> Any ideas on what's going on here? This seems like a nasty regression. > >>>> There are 3 PRs about this problem: 128686, 132372, 137942. > >>>> > >>>> i386 version should recognize the disks. amd64 does when you set > >>>> hw.pci.mcfg=0 in loader.conf. > >>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config > > space > >>> for the disk controller in the MCFG vs non-MCFG cases? That is, find the > >>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and > > then > >>> run this command under both configurations and save the output: > >>> > >>> pciconf -r pci0:0:30:0 0:0xfc > >>> > >> I am not sure if your idea has something to do with my (and some other > >> users) problem. So excuse me, if this posting is wrong. > >> > >> For some month now I am only able to boot CURRENT under amd64 with > >> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output > >> under i386 and under amd64. Perhaps you are able to get a hint? > > > > Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using nfsroot or > > an mfsroot) and capture this output? The mcfg thing only affects access to > > PCI config space (what pciconf -r is displaying). I want to be able to > > compare the "broken" case (amd64 mcfg=1) with a working case. > > My only amd64 system is at home. Sorry, but I have no idea how to start > this system using nfsroot oder mfsroot. Ok, I believe some of the other folks reporting an issue with this ATA controller had other disk controllers in the system so they may be able to do this. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 19:21: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 9F9DA106568B; Tue, 1 Sep 2009 19:21:28 +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 150928FC16; Tue, 1 Sep 2009 19:21:27 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n81JLMnD009080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Sep 2009 22:21:22 +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 n81JLMPd080254; Tue, 1 Sep 2009 22:21:22 +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 n81JLMnF080253; Tue, 1 Sep 2009 22:21:22 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 1 Sep 2009 22:21:22 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20090901192122.GS1881@deviant.kiev.zoral.com.ua> References: <4A9BF23F.6070801@netability.ie> <200909011341.26192.jhb@freebsd.org> <4A9D6CA5.1040409@gwdg.de> <200909011505.32243.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Og4V1LL7XI16KR+9" Content-Disposition: inline In-Reply-To: <200909011505.32243.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 19:21:28 -0000 --Og4V1LL7XI16KR+9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 01, 2009 at 03:05:31PM -0400, John Baldwin wrote: > On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote: > > On 01.09.2009 19:41 (UTC+2), John Baldwin wrote: > > > Hmm, would you be able to boot with mcfg=3D1 on amd64 (perhaps using = nfsroot=20 > or=20 > > > an mfsroot) and capture this output? The mcfg thing only affects acc= ess=20 > to > > > PCI config space (what pciconf -r is displaying). I want to be able = to=20 > > > compare the "broken" case (amd64 mcfg=3D1) with a working case. > >=20 > > My only amd64 system is at home. Sorry, but I have no idea how to start= =20 > > this system using nfsroot oder mfsroot. >=20 > Ok, I believe some of the other folks reporting an issue with this ATA=20 > controller had other disk controllers in the system so they may be able t= o do=20 > this. Might be, LiveCD would help ? --Og4V1LL7XI16KR+9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqddDIACgkQC3+MBN1Mb4hkmgCghU7vTI9NKvGEFc85qb5uqxl0 qyoAn16bKrD+FzBRfgDL1dPS2q8Wstws =Vt69 -----END PGP SIGNATURE----- --Og4V1LL7XI16KR+9-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 19:50: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 E438C106566C for ; Tue, 1 Sep 2009 19:50:54 +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 77E918FC0A for ; Tue, 1 Sep 2009 19:50:53 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=qiM62AFXJF0A:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=6I5d2MoRAAAA:8 a=DRv_mSXjxuijhnLN6HsA:9 a=AY6wf0yC7XjxQqErdd13bWZkXH0A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 247645976; Tue, 01 Sep 2009 21:50:51 +0200 From: Hans Petter Selasky To: Tobias Grosser Date: Tue, 1 Sep 2009 21:51:07 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <1251570251.1238.21.camel@localhost> <20490_1251788178_4A9CC592_20490_149_1_200909010856.23045.hselasky@c2i.net> <1251792510.1176.2.camel@localhost> In-Reply-To: <1251792510.1176.2.camel@localhost> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909012151.09283.hselasky@c2i.net> Cc: freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: [PATCH] USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 19:50:55 -0000 Hi, Here is the commit: http://perforce.freebsd.org/chv.cgi?CH=168039 --HPS From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 20:19: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 8FA9D1065676 for ; Tue, 1 Sep 2009 20:19:56 +0000 (UTC) (envelope-from grosser@fim.uni-passau.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4AE228FC13 for ; Tue, 1 Sep 2009 20:19:56 +0000 (UTC) Received: from [84.56.60.206] (helo=[192.168.178.32]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MiZnp-0001Kg-TB; Tue, 01 Sep 2009 22:18:06 +0200 From: Tobias Grosser To: Hans Petter Selasky In-Reply-To: <200909012151.09283.hselasky@c2i.net> References: <1251570251.1238.21.camel@localhost> <20490_1251788178_4A9CC592_20490_149_1_200909010856.23045.hselasky@c2i.net> <1251792510.1176.2.camel@localhost> <200909012151.09283.hselasky@c2i.net> Content-Type: text/plain Date: Tue, 01 Sep 2009 22:19:40 +0200 Message-Id: <1251836380.6790.66.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Df-Sender: imapboxtobias@web-wahnsinn.de Cc: freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: [PATCH] USB Harddrive not recognized (umass appears, da0 not) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 20:19:56 -0000 On Tue, 2009-09-01 at 21:51 +0200, Hans Petter Selasky wrote: > Hi, > > Here is the commit: > > http://perforce.freebsd.org/chv.cgi?CH=168039 > > --HPS Thanks a lot. Hope to see this in 8.0 or at least soon in RELENG_8. Tobias From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 20:31: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 743F8106566B for ; Tue, 1 Sep 2009 20:31:07 +0000 (UTC) (envelope-from billsf@cuba.calyx.nl) Received: from cuba.calyx.nl (cuba.calyx.nl [213.130.163.36]) by mx1.freebsd.org (Postfix) with ESMTP id 3FE378FC0A for ; Tue, 1 Sep 2009 20:31:07 +0000 (UTC) Received: by cuba.calyx.nl (Postfix, from userid 1000) id 87101197BE2A; Tue, 1 Sep 2009 22:13:46 +0200 (CEST) Date: Tue, 1 Sep 2009 22:13:46 +0200 From: Bill Squire {billsf} To: freebsd-current@freebsd.org Message-ID: <20090901201346.GA2432@cuba.calyx.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: The only problems with v8.0 are: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 20:31:07 -0000 These 'bug' me: There are always going to be the bugs we never see, but the following three seem to be real. (Note I'm using yesterday's rpc/xdr.h to get the cddl stuff to build which provides zfs.) 8.0 is ready. The '/boot/loader' has been a long time problem. If I'm the only one that knows Forth (my first computer language) I probably can fix it. However, a loader from v7 should do fine. There appears to be a typo in one of the cddl 32bit Makefiles. It doesn't get a certain header file into */obj/. That file is: '/usr/include/rpc/xdr.h'. The other problem is an annoyance. I believe snd_uaudio is not expecting HID. Plugging in the driver in with hardware attached causes instant (but harmless) freezing and no dump. Tests are with the C-Media CM106 and CM108. They can be had for as little as 5 Euros. They sound excellent through my Genelecs. If you do electronics take out the descriptors for HID. Alternately the snd_hda driver is a masterpiece. The old snd_es137x cards were the last of the great 'soundblasters' and sound excellent. (Forget the new cards.) While not every- one is a 'practical audiophile' like me, I'm sure most have at least an extra soundcard. I like USB because it puts the analogue circuitry away from the digital. I can live with hda at last. :) BillSF I'm running an SMP amd64 K9 (quickly the name was realised) with 8GB RAM, a typical developer system. Believe the BSD speed -- not the BIOS and adjust to assure you are not over-clocking. Note an Athlon 3000MHz is an Opteron 2800MHz and AMD advises 2800MHzfor this part. A stack of dual 2800's makes for a killer system. Professionally, I prefer multiple singles running in NUMA mode. (Call it SMP for the kernel, but its more like clustered computers.) I'll be standing by if I can verify any bug reports not mentioned. The worst thing is bad hardware -- 100 buck motherboards in particular. Asus makes a few good ones and the "M3A78 PRO" is a 'best value'. Otherwise spend 300 bucks for a real motherboard. I keep several previous builds just in case. I'm over to v9.0 -- the easiest transition so far. B. From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 20:31: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 E5674106568B for ; Tue, 1 Sep 2009 20:31:45 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id 76C9B8FC22 for ; Tue, 1 Sep 2009 20:31:45 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so110295eyf.9 for ; Tue, 01 Sep 2009 13:31:44 -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=TaNonypaHbF1IvlPP5MAb0fGatobsuL4oSoggHLVbvQ=; b=l7Vp0eKq6PF+4L5wEvUPDrP4fIMjLtmnj6ZiWd/UYbLKR12Wq9BmTsli5ThQx9/lyx EzkQ1eIf/86RdEdI/zmJL5TKw0j00VHX1j5h1sIHmQSYvZC/kgiT7jSWCroVQbZ4Ybld VL26ydVZA15A3dtw4VSnLYssIUinuBLGLMUqk= 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=Ji8wjFWg6pHw16mWTEjW+Q6bQ/Pk7lF9G5cIEd5Gi9C8O8EwAGJ4GpY7Bb9MAZAwPh wovd2jxOiiqGRfjeRyJgIj300CZDqpJTiTrCGPWgQ24F9v+qocgrOwyD3k6OkhKYHLXV HD5jHLqB+7wEetEpUs7h0+8e9C9yV2RiT33nc= Received: by 10.211.146.17 with SMTP id y17mr7760274ebn.43.1251837104493; Tue, 01 Sep 2009 13:31:44 -0700 (PDT) Received: from localhost (95-24-78-226.broadband.corbina.ru [95.24.78.226]) by mx.google.com with ESMTPS id 7sm133305eyb.3.2009.09.01.13.31.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Sep 2009 13:31:43 -0700 (PDT) From: Anonymous To: Nick Hibma References: <200909010931.16880.nick@van-laarhoven.org> Date: Wed, 02 Sep 2009 00:31:39 +0400 In-Reply-To: <200909010931.16880.nick@van-laarhoven.org> (Nick Hibma's message of "Tue, 1 Sep 2009 09:31:16 +0200") Message-ID: <86d46ao190.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 Mailing List Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 20:31:46 -0000 Nick Hibma writes: > Folks, > > dmesg is getting cluttered with random bits of irrelevant information which > either should be behind bootverbose or not at all present. Below two > locations where I intend to remove that information. The fact that a module > is loaded can be seen in the output of > > kldstat -v | grep netsmb [...] Can you remove similar noise from ichwd(4), too? From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 20:35: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 A759E106566C for ; Tue, 1 Sep 2009 20:35:34 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe15.tele2.se [212.247.155.193]) by mx1.freebsd.org (Postfix) with ESMTP id 390F88FC1A for ; Tue, 1 Sep 2009 20:35:33 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=tiTTFRzpjXQA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=2rTjFMOR_3Zih_2YSEoA:9 a=Ez2F6LaUgdUFZV5sZrXq4cKp0PwA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe15.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 559189062; Tue, 01 Sep 2009 22:35:32 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 1 Sep 2009 22:35:50 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <20090901201346.GA2432@cuba.calyx.nl> In-Reply-To: <20090901201346.GA2432@cuba.calyx.nl> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909012235.51707.hselasky@c2i.net> Cc: Bill Squire {billsf} Subject: Re: The only problems with v8.0 are: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 20:35:34 -0000 On Tuesday 01 September 2009 22:13:46 Bill Squire {billsf} wrote: > I believe snd_uaudio is not expecting HID. > Plugging in the driver in with hardware attached causes instant (but > harmless) freezing and no dump. Hi, Could you provide more debugging in the form of: usbconfig -u XXX -a YYY dump_device_desc dump_curr_config_desc uname -a for your device. You can build a kernel without snd_uaudio. Also try to enable Uaudio debugging before plugging the device. sysctl hw.usb.uaudio.debug=15 --HPS From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 20:40: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 37AAD106568F; Tue, 1 Sep 2009 20:40:49 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id B54D18FC20; Tue, 1 Sep 2009 20:40:48 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Mia9m-0001hX-EY; Tue, 01 Sep 2009 22:40:46 +0200 Message-ID: <4A9D86C9.1020603@gwdg.de> Date: Tue, 01 Sep 2009 22:40:41 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <200909011341.26192.jhb@freebsd.org> <4A9D6CA5.1040409@gwdg.de> <200909011505.32243.jhb@freebsd.org> In-Reply-To: <200909011505.32243.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 20:40:49 -0000 On 01.09.2009 21:05 (UTC+2), John Baldwin wrote: > On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote: >> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote: >>> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote: >>>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote: >>>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote: >>>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode > (bios >>>>>>> doesn't appear to give the option to use AHCI). On freebsd 7.x, all >>>>>>> channels are detected. On freebsd8.0-beta3, the disks attached to the >>>>>>> first two SATA ports are not detected, although it detects the ports >>>>>>> themselves. >>>>>>> >>>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. >>>>>>> >>>>>>> Any ideas on what's going on here? This seems like a nasty > regression. >>>>>> There are 3 PRs about this problem: 128686, 132372, 137942. >>>>>> >>>>>> i386 version should recognize the disks. amd64 does when you set >>>>>> hw.pci.mcfg=0 in loader.conf. >>>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config >>> space >>>>> for the disk controller in the MCFG vs non-MCFG cases? That is, find > the >>>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and >>> then >>>>> run this command under both configurations and save the output: >>>>> >>>>> pciconf -r pci0:0:30:0 0:0xfc >>>>> >>>> I am not sure if your idea has something to do with my (and some other >>>> users) problem. So excuse me, if this posting is wrong. >>>> >>>> For some month now I am only able to boot CURRENT under amd64 with >>>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output >>>> under i386 and under amd64. Perhaps you are able to get a hint? >>> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using nfsroot > or >>> an mfsroot) and capture this output? The mcfg thing only affects access > to >>> PCI config space (what pciconf -r is displaying). I want to be able to >>> compare the "broken" case (amd64 mcfg=1) with a working case. >> My only amd64 system is at home. Sorry, but I have no idea how to start >> this system using nfsroot oder mfsroot. > > Ok, I believe some of the other folks reporting an issue with this ATA > controller had other disk controllers in the system so they may be able to do > this. Thanks to Kostik Belousov, I tried his hint with live CD. Here it is, only for amd64, with snapshot from todays CURRENT: #systctl hw.pci.mcfg hw.pci.mcfg: 1 #pciconf -lv atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de rev=0xa2 hdr=0x00 class = mass storage subclass = ATA atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de rev=0xa2 hdr=0x00 class = mass storage subclass = ATA #pciconf -r pci0:0:5:0 0:0xfc 037f10de 00b00007 010185a2 00800000 0000c481 0000c401 0000c081 0000c001 0000bc01 f9ef9000 00000000 72601462 00000000 00000044 00000000 01030117 72601462 0002b001 00000000 00000000 0008680f 00000000 00000000 00000000 00000000 00000c41 42060f00 00000000 40c4782c 00001001 00001001 00200020 c0000000 00061000 bd280000 00061000 bd280000 00000000 10060006 0101037f 18000a12 00000000 00000000 02003133 0084cc05 00000000 00000000 00000000 00000000 00000000 000a000a a8020008 0c02000a 00000042 00000000 e7c00001 0c02000a 00000042 00000000 e030000f 00000000 00000000 000c0010 00000000 #pciconf -r pci0:0:5:1 0:0xfc 037f10de 00b00007 010185a2 00800000 0000b881 0000b801 0000b481 0000b401 0000b081 f9ef8000 00000000 72601462 00000000 00000044 00000000 01030214 72601462 0002b001 00000000 00000000 0008680f 00000000 00000000 00000000 00000000 00000c41 42060f00 00000000 40c4782c 00001001 00001001 00200020 00000000 ffefffff 0f1f0000 f7ff7f3b 3fb70000 00000000 10060006 0101037f 00000a12 00000000 00000000 02003133 0084cc05 00000000 00000000 00000000 00000000 00000000 000a000a a8020008 0602000a 00000042 00000000 0050000f 0602000a 00000042 00000000 0040000f 00000000 00000000 000c0010 00000000 From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 20:45: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 331FD106568B for ; Tue, 1 Sep 2009 20:45:19 +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 C92278FC0C for ; Tue, 1 Sep 2009 20:45:18 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n81KjFYG020040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2009 22:45:16 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de> From: Stefan Bethke To: FreeBSD current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 1 Sep 2009 22:45:15 +0200 X-Mailer: Apple Mail (2.936) Cc: Hans Petter Selasky Subject: Elsa MicroLink 56k USB is not picked up by umodem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 20:45:19 -0000 Just dug out my sturdy old Elsa modem, and the new USB stack does not recognize it anymore. Is that intentional, or did the device IDs just dropped between the cracks on the conversion to the new USB stack? # dmesg ... ugen0.3: at usbus0 # usbconfig list ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON 7-stable sees this: # usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 addr 3: full speed, power 400 mA, config 2, ELSA Modem Board(0x2265), Lucent Technologies, Inc.(0x05cc), rev 1.00 ... # dmesg ... ucom0: on uhub0 ucom0: iclass 2/2 ucom0: data interface 1, has CM over data, has break ucom0: status change notification available Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 20:50: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 3BF10106568F for ; Tue, 1 Sep 2009 20:50:29 +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 C31648FC14 for ; Tue, 1 Sep 2009 20:50:28 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=g63cz5HrQV0A:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=PptMg8wYu3Rv6-94eFwA:9 a=_NCq5TPgoqmF9M2BIOxFges7G1YA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1300355255; Tue, 01 Sep 2009 22:50:27 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 1 Sep 2009 22:50:47 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de> In-Reply-To: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909012250.48439.hselasky@c2i.net> Cc: Stefan Bethke Subject: Re: Elsa MicroLink 56k USB is not picked up by umodem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 20:50:29 -0000 On Tuesday 01 September 2009 22:45:15 Stefan Bethke wrote: > Just dug out my sturdy old Elsa modem, and the new USB stack does not > recognize it anymore. Is that intentional, or did the device IDs just > dropped between the cracks on the conversion to the new USB stack? > > > # dmesg > ... > ugen0.3: at usbus0 > # usbconfig list > ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL > (12Mbps) pwr=ON > ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON > ugen0.2: at usbus0, cfg=0 md=HOST > spd=FULL (12Mbps) pwr=SAVE > ugen0.3: at usbus0, cfg=0 md=HOST > spd=FULL (12Mbps) pwr=ON > > > 7-stable sees this: > # usbdevs -v > Controller /dev/usb0: > addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), > Intel(0x0000), rev 1.00 > port 1 addr 3: full speed, power 400 mA, config 2, ELSA Modem > Board(0x2265), Lucent Technologies, Inc.(0x05cc), rev 1.00 > ... > # dmesg > ... > ucom0: 1.00/1.00, addr 3> on uhub0 > ucom0: iclass 2/2 > ucom0: data interface 1, has CM over data, has break > ucom0: status change notification available > > > Stefan Did you load umodem ?? kldstat ? Also check if your modem has multiple configurations. Maybe you have to set a configuration different from config index = 0. usbconfig -u XXX -a YYY set_config 1 --HPS From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 21:00: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 946B210656B1 for ; Tue, 1 Sep 2009 21:00:19 +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 0ABEC8FC13 for ; Tue, 1 Sep 2009 21:00:17 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=tiTTFRzpjXQA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=aYXbfNu94yOmfdDKzA8A:9 a=CP8uwKzzROZbkgrK7ArPv6OUxj0A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 247666626; Tue, 01 Sep 2009 23:00:16 +0200 To: freebsd-current@freebsd.org Content-Disposition: inline From: Hans Petter Selasky X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpO< =?iso-8859-1?q?Q0yAl=7E=3F=60=27F=3FjDVb=5DE6TQ7=27=23h-VlLs=7Dk/=0A=09?=(yxg(p!IL.`#ng"%`BMrham7%UK,}VH\wUOm=^>wEEQ+KWt[{J#x6ow~JO:,zwp.(t; @ =?iso-8859-1?q?Aq=0A=09=3A4=3A=26nFCgDb8=5B3oIeTb=5E=27?=",; u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv Date: Tue, 1 Sep 2009 23:00:36 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909012300.37344.hselasky@c2i.net> Cc: Bill Squire {billsf} Subject: Re: The only problems with v8.0 are: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 21:00:19 -0000 On Tuesday 01 September 2009 22:13:46 Bill Squire {billsf} wrote: > I believe snd_uaudio is not expecting HID. > Plugging in the driver in with hardware attached causes instant (but > harmless) freezing and no dump. Hi, Test proposal: Try to reduce: #define UAUDIO_RECURSE_LIMIT 24 /* rounds */ Into: #define UAUDIO_RECURSE_LIMIT 10 /* rounds */ In: /usr/src/sys/dev/sound/usb/uaudio.c Maybe the current descriptor parsing code is too CPU hungry if the descriptor is bad :-) --HPS From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 21:00: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 B158F1065670 for ; Tue, 1 Sep 2009 21:00:51 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from baranao.anywi.com (baranao.anywi.com [213.207.101.176]) by mx1.freebsd.org (Postfix) with ESMTP id 73D488FC0C for ; Tue, 1 Sep 2009 21:00:51 +0000 (UTC) Received: from hind.van-laarhoven.org (ip51cfcfde.direct-adsl.nl [81.207.207.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by baranao.anywi.com (Postfix) with ESMTPSA id B74F13F41F; Tue, 1 Sep 2009 23:00:47 +0200 (CEST) From: Nick Hibma To: Anonymous Date: Tue, 1 Sep 2009 23:00:41 +0200 User-Agent: KMail/1.12.0 (FreeBSD/7.2-STABLE; KDE/4.3.0; i386; ; ) References: <200909010931.16880.nick@van-laarhoven.org> <86d46ao190.fsf@gmail.com> In-Reply-To: <86d46ao190.fsf@gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909012300.42231.nick@van-laarhoven.org> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on baranao.anywi.com Cc: FreeBSD CURRENT Mailing List Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 21:00:51 -0000 I'll have a look. Cheers, Nick > Nick Hibma writes: > > Folks, > > > > dmesg is getting cluttered with random bits of irrelevant information > > which either should be behind bootverbose or not at all present. Below > > two locations where I intend to remove that information. The fact that > > a module is loaded can be seen in the output of > > > > kldstat -v | grep netsmb > > [...] > > Can you remove similar noise from ichwd(4), too? From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 21:08: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 DB924106566C for ; Tue, 1 Sep 2009 21:08:04 +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 826A88FC12 for ; Tue, 1 Sep 2009 21:08:04 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id A55F01CC11; Tue, 1 Sep 2009 23:08:03 +0200 (CEST) Date: Tue, 1 Sep 2009 23:08:03 +0200 From: Ed Schouten To: FreeBSD Current Message-ID: <20090901210803.GF2829@hoeg.nl> References: <01895862@bb.ipt.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3JWHCGIvlHPlU6rB" Content-Disposition: inline In-Reply-To: <01895862@bb.ipt.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: man and UTF-8 locales X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 21:08:04 -0000 --3JWHCGIvlHPlU6rB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm also a bit puzzled by the nm(1) manpage. It uses U+23AA (CURLY BRACKET EXTENSION) for the |-characters in the SYNOPSIS section. Is this character really meant to be used this way? --=20 Ed Schouten WWW: http://80386.nl/ --3JWHCGIvlHPlU6rB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqdjTMACgkQ52SDGA2eCwVoGACePk77P31Vg0NnU92hLw3C4v9q SMoAnjPnsJ6v/mOAzJmsT8x3nBPpM+SU =lyKp -----END PGP SIGNATURE----- --3JWHCGIvlHPlU6rB-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 21:43: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 8D5A5106566B for ; Tue, 1 Sep 2009 21:43:45 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 634058FC12 for ; Tue, 1 Sep 2009 21:43:45 +0000 (UTC) Received: from [192.168.1.4] (adsl-156-1-132.bna.bellsouth.net [70.156.1.132]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n81LhfQM089540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Sep 2009 17:43:42 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Nick Hibma In-Reply-To: <200909010931.16880.nick@van-laarhoven.org> References: <200909010931.16880.nick@van-laarhoven.org> Content-Type: text/plain Organization: FreeBSD Date: Tue, 01 Sep 2009 16:43:36 -0500 Message-Id: <1251841416.1689.4458.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: FreeBSD CURRENT Mailing List Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 21:43:45 -0000 On Tue, 2009-09-01 at 09:31 +0200, Nick Hibma wrote: > Folks, > > dmesg is getting cluttered with random bits of irrelevant information which > either should be behind bootverbose or not at all present. Below two > locations where I intend to remove that information. The fact that a module > is loaded can be seen in the output of What is irrelevant is subjective... I mean does the average user really need to see anything in dmesg? Please don't change agp_i810.c. A verbose boot is incredibly noisy and rarely needed for debugging anything except the most deep rooted of issues. robert. > kldstat -v | grep netsmb > > the amount of stolen memory and aperture size might be interesting when > configuring your X server. Then again, most X servers nowadays HAVE no > configuration file anymore because of auto-configuration. > > Any objections? > > Nick > > Index: kern/kern_shutdown.c > =================================================================== > --- kern/kern_shutdown.c (revision 196710) > +++ kern/kern_shutdown.c (working copy) > @@ -581,6 +581,10 @@ > > /* > * Support for poweroff delay. > + * > + * Please note that setting this delay too short might power off your > machine > + * before the write cache on your hard disk has been flushed, leading to > + * soft-updates inconsistencies. > */ > #ifndef POWEROFF_DELAY > # define POWEROFF_DELAY 5000 > Index: dev/agp/agp_i810.c > =================================================================== > --- dev/agp/agp_i810.c (revision 196589) > +++ dev/agp/agp_i810.c (working copy) > @@ -474,12 +474,15 @@ > agp_generic_detach(dev); > return EINVAL; > } > - if (sc->stolen > 0) { > - device_printf(dev, "detected %dk stolen memory\n", > - sc->stolen * 4); > + if (bootverbose) { > + if (sc->stolen > 0) { > + device_printf(dev, > + "detected %dk stolen memory\n", > + sc->stolen * 4); > + } > + device_printf(dev, "aperture size is %dM\n", > + sc->initial_aperture / 1024 / 1024); > } > - device_printf(dev, "aperture size is %dM\n", > - sc->initial_aperture / 1024 / 1024); > > /* GATT address is already in there, make sure it's enabled */ > pgtblctl = bus_read_4(sc->sc_res[0], AGP_I810_PGTBL_CTL); > @@ -664,9 +667,11 @@ > gtt_size += 4; > > sc->stolen = (stolen - gtt_size) * 1024 / 4096; > - if (sc->stolen > 0) > - device_printf(dev, "detected %dk stolen memory\n", sc->stolen * 4); > - device_printf(dev, "aperture size is %dM\n", sc->initial_aperture / 1024 > / 1024); > + if (bootverbose) { > + if (sc->stolen > 0) > + device_printf(dev, "detected %dk stolen memory\n", sc->stolen * 4); > + device_printf(dev, "aperture size is %dM\n", sc->initial_aperture / 1024 > / 1024); > + } > > /* GATT address is already in there, make sure it's enabled */ > pgtblctl = bus_read_4(sc->sc_res[0], AGP_I810_PGTBL_CTL); > Index: netsmb/smb_dev.c > =================================================================== > --- netsmb/smb_dev.c (revision 196589) > +++ netsmb/smb_dev.c (working copy) > @@ -352,7 +352,6 @@ > } > clone_setup(&nsmb_clones); > nsmb_dev_tag = EVENTHANDLER_REGISTER(dev_clone, nsmb_dev_clone, 0, 1000); > - printf("netsmb_dev: loaded\n"); > break; > case MOD_UNLOAD: > smb_iod_done(); > @@ -363,7 +362,6 @@ > drain_dev_clone_events(); > clone_cleanup(&nsmb_clones); > destroy_dev_drain(&nsmb_cdevsw); > - printf("netsmb_dev: unloaded\n"); > break; > default: > error = EINVAL; > > _______________________________________________ > 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" -- Robert Noland FreeBSD From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 21:48: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 3C9FD106568B for ; Tue, 1 Sep 2009 21:48:57 +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 D06E48FC0A for ; Tue, 1 Sep 2009 21:48:56 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n81Lmssh029965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Sep 2009 23:48:55 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: Hans Petter Selasky In-Reply-To: <200909012250.48439.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 v936) Date: Tue, 1 Sep 2009 23:48:54 +0200 References: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de> <200909012250.48439.hselasky@c2i.net> X-Mailer: Apple Mail (2.936) Cc: freebsd-current@freebsd.org Subject: Re: Elsa MicroLink 56k USB is not picked up by umodem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 21:48:57 -0000 Am 01.09.2009 um 22:50 schrieb Hans Petter Selasky: > On Tuesday 01 September 2009 22:45:15 Stefan Bethke wrote: >> # dmesg >> ... >> ugen0.3: at usbus0 > > Did you load umodem ?? > > kldstat ? Double checked, it's loaded. > Also check if your modem has multiple configurations. Maybe you have > to set a > configuration different from config index = 0. > > usbconfig -u XXX -a YYY set_config 1 Aha! That does seem to do the trick. How would this get added into umodem or the quirks, or do I have to do some devd magic? # usbconfig -u 0 -a 3 set_config 1 umodem0: on usbus0 umodem0: data interface 1, has CM over data, has break Checking quickly with cu, I can make it dial out. Thanks Stefan -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Tue Sep 1 21:57: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 9BFEF106566C for ; Tue, 1 Sep 2009 21:57:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.swipnet.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB958FC13 for ; Tue, 1 Sep 2009 21:57:27 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=g63cz5HrQV0A:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=Qo2W_4t6YABqB0whtiAA:9 a=2uK0TgkL9oxRRfRiWSuJn6OcAt4A:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 562254754; Tue, 01 Sep 2009 23:57:26 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 1 Sep 2009 23:57:41 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de> <200909012250.48439.hselasky@c2i.net> In-Reply-To: X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909012357.42238.hselasky@c2i.net> Cc: Stefan Bethke Subject: Re: Elsa MicroLink 56k USB is not picked up by umodem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Sep 2009 21:57:29 -0000 On Tuesday 01 September 2009 23:48:54 Stefan Bethke wrote: > Am 01.09.2009 um 22:50 schrieb Hans Petter Selasky: > > On Tuesday 01 September 2009 22:45:15 Stefan Bethke wrote: > >> # dmesg > >> ... > >> ugen0.3: at usbus0 > > > > Did you load umodem ?? > > > > kldstat ? > > Double checked, it's loaded. > > > Also check if your modem has multiple configurations. Maybe you have > > to set a > > configuration different from config index = 0. > > > > usbconfig -u XXX -a YYY set_config 1 > > Aha! That does seem to do the trick. How would this get added into > umodem or the quirks, or do I have to do some devd magic? > > # usbconfig -u 0 -a 3 set_config 1 > umodem0: 3> on usbus0 > umodem0: data interface 1, has CM over data, has break > > Checking quickly with cu, I can make it dial out. kldload usb_quirk usbconfig dump_quirk_names And then run something like: usbconfig add_dev_quirk_vplh 0x??? 0x??? 0x0000 0xFFFF UQ_CFG_INDEX_1 Will make the quirk permanent. If you make a patch for usbdevs and the usb_quirk.c in /sys/dev/usb/quirk/ then I can commit that. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 01:57: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 00EA7106566B; Wed, 2 Sep 2009 01:57:08 +0000 (UTC) (envelope-from skip@menantico.com) Received: from vms173005pub.verizon.net (vms173005pub.verizon.net [206.46.173.5]) by mx1.freebsd.org (Postfix) with ESMTP id D5E098FC14; Wed, 2 Sep 2009 01:57:07 +0000 (UTC) Received: from mx.menantico.com ([71.188.7.134]) by vms173005.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KPB00APDJXWUZR3@vms173005.mailsrvcs.net>; Tue, 01 Sep 2009 19:56:24 -0500 (CDT) Date: Tue, 01 Sep 2009 20:59:44 -0400 From: Skip Ford To: Gavin Atkinson Message-id: <20090902005944.GA1108@menantico.com> References: <4A9571EB.7090209@fsu.edu> <20090826195407.GW2829@hoeg.nl> <20090831094627.L24691@ury.york.ac.uk> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <20090831094627.L24691@ury.york.ac.uk> User-Agent: Mutt/1.4.2.3i Cc: Ed Schouten , freebsd-current@FreeBSD.org, Nathan Lay Subject: Re: First keypresses after boot being discarded X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 01:57:08 -0000 Gavin Atkinson wrote: > On Wed, 26 Aug 2009, Ed Schouten wrote: > >People also reported issues to me where the first keypresses after the > >system has booted are discarded. I have yet to be convinced this is a > >TTY issue, not the keyboard code, interrupt handling, etc. > > I've seen this, and might be able to offer some more information. I > booted 8.0-BETA2 from the same hard drive install on about 15 machines, > and saw this problem on four of them, all identical motherboards. I've run into a very similar-sounding problem, but not since 7.0-RELEASE. One machine would appear to hang at the initial login prompt, nothing typed is echoed. However, a soft reset would then cause whatever was typed at the prompt to finally be displayed before the shutdown messages would be displayed. This would happen possibly 4 out of 10 times on one machine only whenever it included both SCHED_ULE and kbdmux(4). It never happened with SCHED_4BSD and kbdmux(4), as 7.0 shipped, and it never happened with SCHED_ULE only. So, I had to remove kbdmux(4) to use SCHED_ULE instead of SCHED_4BSD in 7.0 to avoid that intermittent problem just on that one machine. -- Skip From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 03:04: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 04457106566C for ; Wed, 2 Sep 2009 03:04:53 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 56F9D8FC08 for ; Wed, 2 Sep 2009 03:04:52 +0000 (UTC) Received: by ewy4 with SMTP id 4so421683ewy.36 for ; Tue, 01 Sep 2009 20:04:52 -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; bh=rKnfA8RHii7B9SbLuPh/3bioAOZY82Tcz+XnXADvAL8=; b=aWvuQN2mU0XJJV5VpTduHZFoowDD3uqS9Lem5sPLVLGrZ7TC7HDwiC62+GPdrVJNGs rYY4A0E9LAcMehU4YuQCQtO/45E/sr8INaQnsSPq604h8Mh2Hc8OMpgdGphZfLkzxhaJ /s/2K2eeDL81d2vWR4a/Hdi2fK+ZqOrb1op6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JDb7s3HjtZGkXiljysPS0VUeIvpYv7a5DnaG6zC7GkV0kQC5GKPnnCLqmUusQH1b9O zualIW8qDsUghkOBxZYcxY2rkl4hDCrPPSX9aK9ewMoKMiI2pIMknl/gTYHnIfqqBLnk KiJWyUTlGuwnn5pxAC+RWWmqh7vESVQ+9E4BU= MIME-Version: 1.0 Received: by 10.211.159.2 with SMTP id l2mr8155767ebo.56.1251860691718; Tue, 01 Sep 2009 20:04:51 -0700 (PDT) Date: Tue, 1 Sep 2009 23:04:51 -0400 Message-ID: From: grarpamp To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 02 Sep 2009 03:45:27 +0000 Subject: LOR RELENG_8 umount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 03:04:54 -0000 FYI... seems to happen now and then, haven't narrowed further. lock order reversal: 1st 0xc51036a0 ufs (ufs) @ /.../src/sys/kern/vfs_mount.c:1200 2nd 0xc6104ad0 devfs (devfs) @ /.../src/sys/ufs/ffs/ffs_vfsops.c:1194 KDB: stack backtrace: db_trace_self_wrapper(c0c75d72,e6f109ec,c08c1375,c08b20fb,c0c78d15,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08b20fb,c0c78d15,c452f638,c452f568,e6f10a48,...) at kdb_backtrace+0x29 _witness_debugger(c0c78d15,c6104ad0,c0c674f6,c452f568,c0c99f1f,...) at _witness_debugger+0x25 witness_checkorder(c6104ad0,9,c0c99f1f,4aa,c6104aec,...) at witness_checkorder+0x839 __lockmgr_args(c6104ad0,80400,c6104aec,0,0,...) at __lockmgr_args+0x7a7 vop_stdlock(e6f10b50,556,e6f10b48,80400,c6104a78,...) at vop_stdlock+0x62 VOP_LOCK1_APV(c0d55960,e6f10b50,c6104b84,c0d92fe0,c6104a78,...) at VOP_LOCK1_APV+0xb5 _vn_lock(c6104a78,80400,c0c99f1f,4aa,c592a000,...) at _vn_lock+0x5e ffs_flushfiles(c6112a10,0,c5dbe900,556,3,...) at ffs_flushfiles+0xa7 softdep_flushfiles(c6112a10,0,c5dbe900,c0911420,c60feb84,...) at softdep_flushfiles+0x2e ffs_unmount(c6112a10,8000000,c0c7fa06,4f5,80,...) at ffs_unmount+0x149 dounmount(c6112a10,8000000,c5dbe900,47a,398190a5,...) at dounmount+0x46d unmount(c5dbe900,e6f10cf8,8,c5dbe900,c0d58f08,...) at unmount+0x2ff syscall(e6f10d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d9c2f, esp = 0xbfbfe58c, ebp = 0xbfbfe658 --- From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 04:26: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 4DA911065670 for ; Wed, 2 Sep 2009 04:26:59 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id DDFA68FC17 for ; Wed, 2 Sep 2009 04:26:58 +0000 (UTC) Received: by ewy4 with SMTP id 4so456132ewy.36 for ; Tue, 01 Sep 2009 21:26:57 -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; bh=kHqBmuyRz3+vhhM1rPJ/0193JS3x9GdcVpen7919CpU=; b=qFRAubDEo26iqhBnzssIU3hO8DnzSnNuI8xdQ6hRpk0dnikxvJgrzQlEGBI73yUORN HWfJY8K1VbQdiSHxxmfhVtZVb0DWRLPDtXrReYlOedBUttcIXP5j7X/JR/1FNdE7AiOU OAY0NvDVuMry84i0Behnvuv8FL5nS8/ptWcbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=UksDlvsQ9QBaeRzPMkEK75w8YAZ5T655jzQUBntAOBgb18YBuL6e+vcBQSRphdX4BJ LwKMPwCJvDwMzLgOxoqoZEZ6oHxxIE7x74Unrutu8P6OIvAYeA6Bkh8W/masFcBe3q8F KYNKm8xjRUuM0ve6RHlQerJYY7CheSy0RFOAA= MIME-Version: 1.0 Received: by 10.211.195.14 with SMTP id x14mr4706451ebp.46.1251865617770; Tue, 01 Sep 2009 21:26:57 -0700 (PDT) Date: Wed, 2 Sep 2009 00:26:57 -0400 Message-ID: From: grarpamp To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 02 Sep 2009 04:33:58 +0000 Subject: LOR RELENG_8 unlink/dirhash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 04:26:59 -0000 Two more... lock order reversal: 1st 0xd85c60e0 bufwait (bufwait) @ /.../src/sys/kern/vfs_bio.c:2559 2nd 0xc8553800 dirhash (dirhash) @ /.../src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper(c0c75d72,e6f59a74,c08c1375,c08b20fb,c0c78d15,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08b20fb,c0c78d15,c452bfc8,c452f6a0,e6f59ad0,...) at kdb_backtrace+0x29 _witness_debugger(c0c78d15,c8553800,c0c9aa71,c452f6a0,c0c9a6fa,...) at _witness_debugger+0x25 witness_checkorder(c8553800,9,c0c9a6fa,11d,0,...) at witness_checkorder+0x839 _sx_xlock(c8553800,0,c0c9a6fa,11d,db205018,...) at _sx_xlock+0x85 ufsdirhash_acquire(0,e,c4756800,d85c6080,db205018,...) at ufsdirhash_acquire+0x35 ufsdirhash_remove(c6ef7a6c,db205018,18,e6f59b60,e6f59b5c,...) at ufsdirhash_remove+0x14 ufs_dirremove(ccbb0324,c6ef7bc8,500800c,0,ccbb0324,...) at ufs_dirremove+0xe5 ufs_remove(e6f59c34,0,0,0,cb198218,...) at ufs_remove+0x6e VOP_REMOVE_APV(c0d7a580,e6f59c34,cb198218,e6f59c0c,28216238,...) at VOP_REMOVE_APV+0xa5 kern_unlinkat(c636db40,ffffff9c,28216238,0,e6f59c80,...) at kern_unlinkat+0x181 kern_unlink(c636db40,28216238,0,e6f59d2c,c0bb0a63,...) at kern_unlink+0x27 unlink(c636db40,e6f59cf8,4,c0c94eac,c0d58db8,...) at unlink+0x22 syscall(e6f59d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (10, FreeBSD ELF32, unlink), eip = 0x28168e7f, esp = 0xbfbfea4c, ebp = 0xbfbfea78 --- lock order reversal: 1st 0xd84e6460 bufwait (bufwait) @ /.../src/sys/kern/vfs_bio.c:2559 2nd 0xc4a4f200 dirhash (dirhash) @ /.../src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper(c0c75d72,e6f13a74,c08c1365,c08b20eb,c0c78d15,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08b20eb,c0c78d15,c452bfc8,c452f6a0,e6f13ad0,...) at kdb_backtrace+0x29 _witness_debugger(c0c78d15,c4a4f200,c0c9aa71,c452f6a0,c0c9a6fa,...) at _witness_debugger+0x25 witness_checkorder(c4a4f200,9,c0c9a6fa,11d,0,...) at witness_checkorder+0x839 _sx_xlock(c4a4f200,0,c0c9a6fa,11d,d874d6ec,...) at _sx_xlock+0x85 ufsdirhash_acquire(0,e,c4756800,d84e6400,d874d6ec,...) at ufsdirhash_acquire+0x35 ufsdirhash_remove(c4aacd24,d874d6ec,6ec,e6f13b60,e6f13b5c,...) at ufsdirhash_remove+0x14 ufs_dirremove(c483e648,c4ae9910,500800c,0,c483e648,...) at ufs_dirremove+0xe5 ufs_remove(e6f13c34,0,0,0,c4ae1b84,...) at ufs_remove+0x6e VOP_REMOVE_APV(c0d7a580,e6f13c34,c4ae1b84,e6f13c0c,804c2e8,...) at VOP_REMOVE_APV+0xa5 kern_unlinkat(c5fc76c0,ffffff9c,804c2e8,0,e6f13c80,...) at kern_unlinkat+0x181 kern_unlink(c5fc76c0,804c2e8,0,e6f13d2c,c0bb0a53,...) at kern_unlink+0x27 unlink(c5fc76c0,e6f13cf8,4,c0c599ce,c0d58db8,...) at unlink+0x22 syscall(e6f13d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (10, FreeBSD ELF32, unlink), eip = 0x28169dbf, esp = 0xbfbfe64c, ebp = 0xbfbfe6b8 --- From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 05:01:03 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 B8704106566C for ; Wed, 2 Sep 2009 05:01:03 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 2F9CF8FC14 for ; Wed, 2 Sep 2009 05:01:02 +0000 (UTC) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id n824kVkH014985; Wed, 2 Sep 2009 08:46:32 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1251866792; bh=DYefHUxp/ILrhTea09sC2nAa/MmJaSDrzfzWPOY6vWE=; l=337; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=kucdrHx6ESA/Pg6pL2TQltjvEuFXyI3Yzl93y+PrCERfF48JX3ZoHiFFhifZRzAtF KNbc1NQ3dyNS+9wd7yG7dT6IQgnuxZYZRv8dktGRyiWkGau2tDAqaUelz13Ta/j54W 1FknIikYBYP6KasqbDJCv2EoM4N42RlFdGM6WOzM= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id n824kV9h014984; Wed, 2 Sep 2009 08:46:31 +0400 (MSD) (envelope-from ache) Date: Wed, 2 Sep 2009 08:46:30 +0400 From: Andrey Chernov To: Patrick Lamaiziere Message-ID: <20090902044630.GA14940@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Patrick Lamaiziere , FreeBSD current mailing list References: <20090825032223.4a788a61@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090825032223.4a788a61@baby-jane.lamaiziere.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD current mailing list Subject: Re: ee(1): blinking characters X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 05:01:03 -0000 On Tue, Aug 25, 2009 at 03:22:23AM +0200, Patrick Lamaiziere wrote: > Hi, > > I've just noticed that ee displays some french characters (like > '?','?',...) in reverse video into xterm. And on the console theses > characters are blinking. No problem on the command line or with nvi. Fixed in r196750 -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 05:11: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 D6151106566B for ; Wed, 2 Sep 2009 05:11:16 +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 963A58FC0C for ; Wed, 2 Sep 2009 05:11:16 +0000 (UTC) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n824ZDPF003697; Tue, 1 Sep 2009 21:35:13 -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 nt69y3jh3ixayi595bm98t7cf6; Tue, 01 Sep 2009 21:35:13 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A9DF600.5090008@freebsd.org> Date: Tue, 01 Sep 2009 21:35:12 -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: Ed Schouten References: <01895862@bb.ipt.ru> <20090901210803.GF2829@hoeg.nl> In-Reply-To: <20090901210803.GF2829@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: man and UTF-8 locales X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 05:11:16 -0000 Ed Schouten wrote: > > I'm also a bit puzzled by the nm(1) manpage. It uses U+23AA (CURLY > BRACKET EXTENSION) for the |-characters in the SYNOPSIS section. Is this > character really meant to be used this way? That's just wrong. The bracket extension characters are meant to be used in building large-sized brackets and should never be used by themselves. Personally, I would stick with U+007C here. Tim From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 05:58: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 37E741065672 for ; Wed, 2 Sep 2009 05:58:38 +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 E9F358FC0C for ; Wed, 2 Sep 2009 05:58:36 +0000 (UTC) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 283487901C; Wed, 2 Sep 2009 09:58:32 +0400 (MSD) Message-ID: <4A9E099B.50602@haruhiism.net> Date: Wed, 02 Sep 2009 09:58:51 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: grarpamp 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: LOR RELENG_8 unlink/dirhash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 05:58:38 -0000 grarpamp wrote: > Two more... > > lock order reversal: > 1st 0xd85c60e0 bufwait (bufwait) @ /.../src/sys/kern/vfs_bio.c:2559 > 2nd 0xc8553800 dirhash (dirhash) @ /.../src/sys/ufs/ufs/ufs_dirhash.c:285 > > lock order reversal: > 1st 0xd84e6460 bufwait (bufwait) @ /.../src/sys/kern/vfs_bio.c:2559 > 2nd 0xc4a4f200 dirhash (dirhash) @ /.../src/sys/ufs/ufs/ufs_dirhash.c:28 http://sources.zabbadoz.net/freebsd/lor/261.html -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 06:00: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 7B5BC106568B for ; Wed, 2 Sep 2009 06:00:35 +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 39E378FC24 for ; Wed, 2 Sep 2009 06:00:35 +0000 (UTC) Received: from [192.168.0.2] (unknown [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 075337901D; Wed, 2 Sep 2009 10:00:33 +0400 (MSD) Message-ID: <4A9E0A16.8070706@haruhiism.net> Date: Wed, 02 Sep 2009 10:00:54 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: grarpamp 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: LOR RELENG_8 umount X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 06:00:35 -0000 grarpamp wrote: > FYI... seems to happen now and then, haven't narrowed further. > > lock order reversal: > 1st 0xc51036a0 ufs (ufs) @ /.../src/sys/kern/vfs_mount.c:1200 > 2nd 0xc6104ad0 devfs (devfs) @ /.../src/sys/ufs/ffs/ffs_vfsops.c:119 This is a known LOR. http://sources.zabbadoz.net/freebsd/lor/276.html -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 06:42: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 76BAB1065696 for ; Wed, 2 Sep 2009 06:42:08 +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 008DA8FC1A for ; Wed, 2 Sep 2009 06:42:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=-wX2jEReKLgA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=5K6T0yBrn2x4k8e-0kYA:9 a=M3yI97xlfcJq8iCF0f3vpds_FyYA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1300514419; Wed, 02 Sep 2009 08:42:06 +0200 From: Hans Petter Selasky To: "Bill Squire {billsf}" Date: Wed, 2 Sep 2009 08:42:26 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090901201346.GA2432@cuba.calyx.nl> <200909012341.08458.hselasky@c2i.net> <20090902013536.GA44206@cuba.calyx.nl> In-Reply-To: <20090902013536.GA44206@cuba.calyx.nl> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909020842.27496.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: My USB audio test setups and about FreeBSD and me X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 06:42:08 -0000 Hi, On Wednesday 02 September 2009 03:35:36 Bill Squire {billsf} wrote: >Litterly I've made millions of Euros with 'free' software. Every >bit gets committed except for unimportant parts. You know that the new USB stack in FreeBSD-8+9 also supports device side mode? So you could implement a complete USB audio device using a DAC+ADC+CPU and FreeBSD only. And if you want to have paid support transforming the USB stack into the kilobytes for small CPUs you can get that aswell. > Nice to have decent music again. So many thanks. > Sure. > Bill Squire > > The attachment is as labeled. If you use Windows you may still be taking a > chance as the camera is msdosfs based and there are 'chippers' out there. Looks fine over here ... Interesting project. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 07:00: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 D8A4B1065670; Wed, 2 Sep 2009 07:00:51 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 636948FC0C; Wed, 2 Sep 2009 07:00:51 +0000 (UTC) Received: from delta.allbsd.org (p4121-ipbf1805funabasi.chiba.ocn.ne.jp [114.146.83.121]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id n8270ZXt018655; Wed, 2 Sep 2009 16:00:45 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id n8270SpE073686; Wed, 2 Sep 2009 16:00:29 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 02 Sep 2009 15:59:58 +0900 (JST) Message-Id: <20090902.155958.08019398.hrs@allbsd.org> To: qing.li@bluecoat.com From: Hiroki Sato In-Reply-To: References: <20090830.024420.174808572.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Sep__2_15_59_58_2009_896)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.allbsd.org [133.31.130.32]); Wed, 02 Sep 2009 16:00:46 +0900 (JST) Cc: qingli@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: IPv6 regression on 8.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 07:00:51 -0000 ----Security_Multipart(Wed_Sep__2_15_59_58_2009_896)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Li, Qing" wrote in : qi> Hi Hiroki, qi> qi> > qi> > 2) Issue of subnet-router anycast address with a global address qi> > qi> > Thanks for the fixes! With the two patches 1) and 3) are gone, but qi> > 2) still remains. Is there something I can help to narrow down it? qi> > qi> qi> Hmm... I tried multiple test cases and all seem to work as expected. qi> I also tried the exact configuration sequence as you outlined in your qi> original bug report email, and that case worked, too. qi> qi> The only difference I can see from the given information, is I have qi> 3 em interfaces, whereas you have 2 em interfaces and 1 re, but I qi> don't see how that would make a difference. I think reproduction of the case 2) needs two boxes. One has two NICs and another has one NIC, and the three NICs are connected with a subnet independent from each other. Anyway, I will try the a-box-with-three-NICs case when I return home today. I didn't try it. qi> Would it be possible for you to email me your system configuration qi> produced from "ifconfig" and "netstat" privately ? Sure. I will send them to you later. -- Hiroki ----Security_Multipart(Wed_Sep__2_15_59_58_2009_896)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkqeF+4ACgkQTyzT2CeTzy0BAgCg2RR7Xmiweyt/lHnwT3Q3zQuk OBsAn0a4V/KdeinizFgCvUy3dJfVit4D =9jCd -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Sep__2_15_59_58_2009_896)---- From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 07:54: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 CFBBA106566B for ; Wed, 2 Sep 2009 07:54:49 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id 5BC7A8FC14 for ; Wed, 2 Sep 2009 07:54:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n827fUwm013242 for ; Wed, 2 Sep 2009 11:41:30 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 2 Sep 2009 11:41:30 +0400 (MSD) From: Dmitry Morozovsky To: current@FreeBSD.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Wed, 02 Sep 2009 11:41:30 +0400 (MSD) Cc: Subject: Dumb SVN question: update between branches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 07:54:49 -0000 Dear colleagues, I've found myself bumping against the wall with very stupid thing, quick googling did not help: what is SVN's analog of 'cvs update -r BRANCH' (in FreeBSD repo's case)? Example: in CVS case -- marck@revamp:/usr/src> cvs -R st Makefile =================================================================== File: Makefile Status: Up-to-date Working revision: 1.341.2.7 Thu Mar 19 20:48:18 2009 Repository revision: 1.341.2.7 /home/ncvs/src/Makefile,v Sticky Tag: RELENG_7 (branch: 1.341.2) Sticky Date: (none) Sticky Options: (none) marck@revamp:/usr/src> cvs -R up -r RELENG_8 [snip] marck@revamp:/usr/src> cvs -R st Makefile =================================================================== File: Makefile Status: Up-to-date Working revision: 1.358.2.1 Wed Sep 2 07:37:32 2009 Repository revision: 1.358.2.1 /home/ncvs/src/Makefile,v Sticky Tag: RELENG_8 (branch: 1.358.2) Sticky Date: (none) Sticky Options: (none) -- In SVN case I have: marck@hamster:/usr/src> svn info Path: . URL: file:///FreeBSD/svn/base/head Repository Root: file:///FreeBSD/svn/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 196740 Node Kind: directory Schedule: normal Last Changed Author: trasz Last Changed Rev: 196740 Last Changed Date: 2009-09-01 22:30:17 +0400 (Tue, 01 Sep 2009) what in this case I should do to have stable/8 (retaining my local changes, otherwise I'd just blow the whole tree up and re-checkout it). Sure I can store `svn diff' output, checkout fresh tree and try to apply diff there, but this way does not seem natural to me. Any hints? Thanks! -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 08:23:06 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 883B9106566C for ; Wed, 2 Sep 2009 08:23:06 +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 2B2468FC19 for ; Wed, 2 Sep 2009 08:23:06 +0000 (UTC) Received: from ip-149.ish.com.au ([203.29.62.149]:51008) by fish.ish.com.au with esmtpa (Exim 4.69) (envelope-from ) id 1Mim7v-0002yR-1V; Wed, 02 Sep 2009 19:27:39 +1000 Message-ID: <4A9E28BF.7080007@ish.com.au> Date: Wed, 02 Sep 2009 18:11:43 +1000 From: Aristedes Maniatis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3pre) Gecko/20090821 Shredder/3.0b4pre MIME-Version: 1.0 To: Dmitry Morozovsky References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: Dumb SVN question: update between branches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 08:23:06 -0000 On 2/09/09 5:41 PM, Dmitry Morozovsky wrote: > what in this case I should do to have stable/8 (retaining my local changes, > otherwise I'd just blow the whole tree up and re-checkout it). Sure I can store > `svn diff' output, checkout fresh tree and try to apply diff there, but this > way does not seem natural to me. "svn switch" will do what you want. I find it helpful to create a patch as backup first just in case something goes wrong. Ari --------------------------> 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 Wed Sep 2 08:41:23 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 4236B1065672 for ; Wed, 2 Sep 2009 08:41:23 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) by mx1.freebsd.org (Postfix) with ESMTP id BEA318FC0C for ; Wed, 2 Sep 2009 08:41:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.3/8.14.3) with ESMTP id n828fJCD029747; Wed, 2 Sep 2009 12:41:19 +0400 (MSD) (envelope-from marck@rinet.ru) Date: Wed, 2 Sep 2009 12:41:19 +0400 (MSD) From: Dmitry Morozovsky To: Aristedes Maniatis In-Reply-To: <4A9E28BF.7080007@ish.com.au> Message-ID: References: <4A9E28BF.7080007@ish.com.au> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (woozle.rinet.ru [0.0.0.0]); Wed, 02 Sep 2009 12:41:19 +0400 (MSD) Cc: current@freebsd.org Subject: Re: Dumb SVN question: update between branches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 08:41:23 -0000 On Wed, 2 Sep 2009, Aristedes Maniatis wrote: AM> On 2/09/09 5:41 PM, Dmitry Morozovsky wrote: AM> > what in this case I should do to have stable/8 (retaining my local AM> > changes, AM> > otherwise I'd just blow the whole tree up and re-checkout it). Sure I can AM> > store AM> > `svn diff' output, checkout fresh tree and try to apply diff there, but AM> > this AM> > way does not seem natural to me. AM> AM> "svn switch" will do what you want. I find it helpful to create a patch as AM> backup first just in case something goes wrong. Ah thanks a lot. I somehow overlooked this simple and straightforward way ;-) -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 05:47:06 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 8BEF8106566C for ; Wed, 2 Sep 2009 05:47:06 +0000 (UTC) (envelope-from ubm.freebsd@googlemail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id 0CD208FC1F for ; Wed, 2 Sep 2009 05:47:05 +0000 (UTC) Received: by bwz2 with SMTP id 2so481264bwz.43 for ; Tue, 01 Sep 2009 22:47:04 -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 :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=rCwFTcdpwIJ5Z0nq5zQfY3zIT3QgVVXoiRfIajYQ7ro=; b=mQcvzffhsPbvNl57gO77rRZ++yfdAJ3t781FC8tB6f7H92DJrHLwjzUCewmekDfkQ/ uk7a/3nda+qcV0t09b7J0dV/Q2wZtxCCGkmP1OsbyeIoJw4EO004nkEk5IQx4E8ZNXcr ei98TrEgg9ka1IvP0bUOxr73IpjbL5peE4Qrs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=r+dMR+7p4ArkJMW2Ib76exUkc/MHJyg+zETSUgznIMpF/WA7s7U0aJCajY7AiRK3pX ncBWMx2M9G39cL3mWOuuDqnlBpJQWUjmpSXZ53nJIBO7xV4hqhhEFuF6adqYg6vkx+lG n/vorPjbpHwypK3FAT0TWGjpo0KJiVjwE3jLU= Received: by 10.103.81.36 with SMTP id i36mr3378490mul.122.1251870424417; Tue, 01 Sep 2009 22:47:04 -0700 (PDT) Received: from ubm.mine.nu (e181050152.adsl.alicedsl.de [85.181.50.152]) by mx.google.com with ESMTPS id u26sm2894247mug.23.2009.09.01.22.47.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 01 Sep 2009 22:47:02 -0700 (PDT) Date: Wed, 2 Sep 2009 07:47:01 +0200 From: Marc UBM Bocklet To: current@freebsd.org Message-Id: <20090902074701.9a063349.ubm.freebsd@gmail.com> In-Reply-To: <200909010955.33747.jhb@freebsd.org> References: <20090822115958.f93fcf29.ubm.freebsd@gmail.com> <20090831222650.45b6c806.ubm@u-boot-man.de> <3bbf2fe10908311331k3e871898tc36a9846651cc53@mail.gmail.com> <200909010955.33747.jhb@freebsd.org> X-Mailer: Sylpheed 2.7.0 (GTK+ 2.16.4; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 02 Sep 2009 11:05:45 +0000 Cc: Subject: Re: panic: apic_free_vector: Thread already bound. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 05:47:06 -0000 On Tue, 1 Sep 2009 09:55:33 -0400 John Baldwin wrote: > > Maybe we can ship 8 with a printf() instrad than a panic()? > > Actually, it looks like 'rebooting' is what we want. Try this: > > --- //depot/vendor/freebsd/src/sys/amd64/amd64/local_apic.c > 2009/08/14 21:10:13 ++ > + //depot/user/jhb/acpipci/amd64/amd64/local_apic.c 2009/09/01 > 13:54:23 @@ -990,18 +990,21 @@ > * we don't lose an interrupt delivery race. > */ > td = curthread; > - thread_lock(td); > - if (sched_is_bound(td)) > - panic("apic_free_vector: Thread already bound.\n"); > - sched_bind(td, apic_cpuid(apic_id)); > - thread_unlock(td); > + if (!rebooting) { > + thread_lock(td); > + if (sched_is_bound(td)) > + panic("apic_free_vector: Thread already > bound.\n"); > + sched_bind(td, apic_cpuid(apic_id)); > + thread_unlock(td); > + } > mtx_lock_spin(&icu_lock); > lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] = -1; > mtx_unlock_spin(&icu_lock); > - thread_lock(td); > - sched_unbind(td); > - thread_unlock(td); > - > + if (!rebooting) { > + thread_lock(td); > + sched_unbind(td); > + thread_unlock(td); > + } > } > > /* Map an IDT vector (APIC) to an IRQ (interrupt source). */ > --- //depot/vendor/freebsd/src/sys/i386/i386/local_apic.c > 2009/08/14 21:10:13 ++ > + //depot/user/jhb/acpipci/i386/i386/local_apic.c 2009/09/01 > 13:53:14 @@ -994,18 +994,21 @@ > * we don't lose an interrupt delivery race. > */ > td = curthread; > - thread_lock(td); > - if (sched_is_bound(td)) > - panic("apic_free_vector: Thread already bound.\n"); > - sched_bind(td, apic_cpuid(apic_id)); > - thread_unlock(td); > + if (!rebooting) { > + thread_lock(td); > + if (sched_is_bound(td)) > + panic("apic_free_vector: Thread already > bound.\n"); > + sched_bind(td, apic_cpuid(apic_id)); > + thread_unlock(td); > + } > mtx_lock_spin(&icu_lock); > lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] = -1; > mtx_unlock_spin(&icu_lock); > - thread_lock(td); > - sched_unbind(td); > - thread_unlock(td); > - > + if (!rebooting) { > + thread_lock(td); > + sched_unbind(td); > + thread_unlock(td); > + } > } > > /* Map an IDT vector (APIC) to an IRQ (interrupt source). */ I can confirm that this fixes the issue for me. Thanks a lot! :-) Bye Marc From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 11:56: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 1ED801065702; Wed, 2 Sep 2009 11:56:07 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.193]) by mx1.freebsd.org (Postfix) with ESMTP id 96B838FC0A; Wed, 2 Sep 2009 11:56:06 +0000 (UTC) X-Envelope-To: freebsd-current@freebsd.org Received: from crumpet.foobar.org (twinkie.foobar.org [87.192.56.84]) (authenticated bits=0) by mail.acquirer.com (8.14.3/8.14.3) with ESMTP id n82BttUi047858 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 12:56:01 +0100 (IST) (envelope-from nick-lists@netability.ie) Message-ID: <4A9E5D4B.1020801@netability.ie> Date: Wed, 02 Sep 2009 12:55:55 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im> <200909011002.59592.jhb@freebsd.org> In-Reply-To: <200909011002.59592.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muffin.acquirer.com Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 11:56:07 -0000 On 01/09/2009 15:02, John Baldwin wrote: > Hmm, so an idea I had just now.. can you grab a dump of the PCI config space > for the disk controller in the MCFG vs non-MCFG cases? That is, find the > device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and then > run this command under both configurations and save the output: hmmm, the box won't boot when i use mcfg=1. I'll take a look at the console message tomorrow or friday. Nick From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 12:03: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 0EEFC1065679 for ; Wed, 2 Sep 2009 12:03:41 +0000 (UTC) (envelope-from 482254ac@razorfever.net) Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8B5F38FC12 for ; Wed, 2 Sep 2009 12:03:40 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQIAJf7nUpMCrCL/2dsb2JhbACBUxqKNsNiikeCNYFmBYFXhhk X-IronPort-AV: E=Sophos;i="4.44,318,1249272000"; d="txt'?scan'208";a="44956343" Received: from 76-10-176-139.dsl.teksavvy.com (HELO server.razorfever.net) ([76.10.176.139]) by ironport2-out.teksavvy.com with ESMTP; 02 Sep 2009 08:02:28 -0400 Received: from [192.168.0.197] ([192.168.0.197]) by server.razorfever.net (8.13.8/8.13.8) with ESMTP id n82C3M38016709 for ; Wed, 2 Sep 2009 08:03:22 -0400 (EDT) (envelope-from 482254ac@razorfever.net) Message-ID: <4A9E5F34.2090700@razorfever.net> Date: Wed, 02 Sep 2009 08:04:04 -0400 From: "Derek (freebsd lists)" <482254ac@razorfever.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------020900090803040701060404" X-Virus-Scanned: clamav-milter 0.95.2 at server.razorfever.net X-Virus-Status: Clean Subject: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 12:03:41 -0000 This is a multi-part message in MIME format. --------------020900090803040701060404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I've been testing the new siis driver, and I have found no appreciable performance change, using dd as a measure of "raw" performance. I get about 40MB/s read, and 30MB/s write. See attached bench-*.txt files. Am I expecting too much, or do I have something else going on here? (e.g. dd being a terrible benchmark of disk i/o) Is anyone else seeing better/worse/same numbers? Also I find it surprising that my gmirror read is only 40MB/s, and not 60-80MB/s, any thoughts on this? Thanks! - Derek --------------020900090803040701060404 Content-Type: text/plain; name="bench-nosiis.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bench-nosiis.txt" dd if=/dev/zero of=/dev/null bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 0.437049 secs (307099849 bytes/sec) dd if=/dev/zero of=/dev/ad4p2 bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 4.410338 secs (30432527 bytes/sec) dd if=/dev/zero of=/dev/ad6p2 bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 4.401181 secs (30495844 bytes/sec) dd if=/dev/ad6p2 of=/dev/null bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 3.234643 secs (41493831 bytes/sec) dd if=/dev/ad4p2 of=/dev/null bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 3.689668 secs (41385739 bytes/sec) gmirror label gm0p2 ad4p2 ad6p2 dd if=/dev/mirror/gm0p2 of=/dev/null bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 3.331307 secs (40289811 bytes/sec) dd if=/dev/zero of=/dev/mirror/gm0p2 bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 8.167607 secs (16432932 bytes/sec) --------------020900090803040701060404 Content-Type: text/plain; name="bench-siis.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bench-siis.txt" dd if=/dev/zero of=/dev/null bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 0.434279 secs (309058782 bytes/sec) dd if=/dev/zero of=/dev/ada0p2 bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 4.604623 secs (29148472 bytes/sec) dd if=/dev/zero of=/dev/ada1p2 bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 4.402896 secs (30483966 bytes/sec) dd if=/dev/ada1p2 of=/dev/null bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 3.203470 secs (41897607 bytes/sec) dd if=/dev/ada0p2 of=/dev/null bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 3.211751 secs (41789581 bytes/sec) gmirror label gm0p2 ada0p2 ada1p2 dd if=/dev/mirror/gm0p2 of=/dev/null bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 3.349089 secs (40075890 bytes/sec) dd if=/dev/zero of=/dev/mirror/gm0p2 bs=1M count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 8.121042 secs (16527156 bytes/sec) --------------020900090803040701060404 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-BETA3 #1: Tue Sep 1 15:24:09 EDT 2009 root@porter.razorfever.net:/usr/obj/usr/src/sys/ZFS-PROD Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) III CPU family 1400MHz (1399.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 Features=0x383fbff real memory = 2147483648 (2048 MB) avail memory = 2083577856 (1987 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 2 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 7fef0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0 pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 228M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x9000-0x90ff mem 0xfa000000-0xfaffffff,0xf9000000-0xf9000fff at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xa000-0xa00f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xa400-0xa41f irq 5 at device 7.2 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xa800-0xa81f irq 5 at device 7.3 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 pci0: at device 7.4 (no driver attached) siis0: port 0xb800-0xb80f mem 0xfc448000-0xfc44807f,0xfc440000-0xfc447fff irq 17 at device 8.0 on pci0 siis0: [ITHREAD] siisch0: at channel 0 on siis0 siisch0: [ITHREAD] siisch1: at channel 1 on siis0 siisch1: [ITHREAD] siisch2: at channel 2 on siis0 siisch2: [ITHREAD] siisch3: at channel 3 on siis0 siisch3: [ITHREAD] fxp0: port 0xbc00-0xbc3f mem 0xfc44a000-0xfc44afff,0xfc400000-0xfc41ffff irq 19 at device 10.0 on pci0 miibus0: on fxp0 inphy0: PHY 1 on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:31:f2:ec fxp0: [ITHREAD] fxp1: port 0xc000-0xc03f mem 0xfc449000-0xfc449fff,0xfc420000-0xfc43ffff irq 16 at device 11.0 on pci0 miibus1: on fxp1 inphy1: PHY 1 on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:02:b3:22:a9:ca fxp1: [ITHREAD] uhci2: port 0xc400-0xc41f irq 17 at device 12.0 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0xc800-0xc81f irq 18 at device 12.1 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xfc44b000-0xfc44b0ff irq 19 at device 12.2 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 fwohci0: port 0xcc00-0xcc7f mem 0xfc44c000-0xfc44c7ff irq 17 at device 12.3 on pci0 fwohci0: [ITHREAD] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:06:00:00:00:e3:32 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S100, max_rec 2 bytes. fwohci0: max_rec 2 -> 2048 firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x157c000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:06:00:e3:32 fwe0: Ethernet address: 02:11:06:00:e3:32 fwip0: on firewire0 fwip0: Firewire address: 00:11:06:00:00:00:e3:32 @ 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 atrtc0: port 0x70-0x73 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4 cpu0: on acpi0 cpu1: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcc7ff,0xcd000-0xce7ff,0xcf000-0xd07ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 WARNING: ZFS is considered to be an experimental feature in FreeBSD. ZFS NOTICE: prefetch is disabled by default on i386 - add enable to tunable to change. ZFS filesystem version 13 ZFS storage pool version 13 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 Waiting 5 seconds for SCSI devices to settle 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 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 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: 4 ports with 4 removable, self powered (aprobe0:siisch0:0:15:0): SIGNATURE: 0000 (aprobe0:siisch0:0:0:0): SIGNATURE: 0000 (aprobe1:siisch1:0:15:0): SIGNATURE: 0000 (aprobe0:siisch1:0:0:0): SIGNATURE: 0000 ada0 at siisch0 bus 0 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled ada1 at siisch1 bus 0 target 0 lun 0 ada1: ATA/ATAPI-8 SATA 2.x device ada1: 300.000MB/s transfers ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing enabled SMP: AP CPU #1 Launched! GEOM_MIRROR: Device mirror/gm0p2 launched (2/2). Trying to mount root from zfs:tank --------------020900090803040701060404 Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pciconf.txt" ostb0@pci0:0:0:0: class=0x060000 card=0x00000000 chip=0x06911106 rev=0xc4 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 card=0x00000000 chip=0x85981106 rev=0x00 hdr=0x01 isab0@pci0:0:7:0: class=0x060100 card=0x000010f1 chip=0x06861106 rev=0x40 hdr=0x00 atapci0@pci0:0:7:1: class=0x01018a card=0x05711106 chip=0x05711106 rev=0x06 hdr=0x00 uhci0@pci0:0:7:2: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x1a hdr=0x00 uhci1@pci0:0:7:3: class=0x0c0300 card=0x12340925 chip=0x30381106 rev=0x1a hdr=0x00 none0@pci0:0:7:4: class=0x068000 card=0x30571106 chip=0x30571106 rev=0x40 hdr=0x00 siis0@pci0:0:8:0: class=0x018000 card=0x31241095 chip=0x31241095 rev=0x02 hdr=0x00 fxp0@pci0:0:10:0: class=0x020000 card=0x00408086 chip=0x12298086 rev=0x0c hdr=0x00 fxp1@pci0:0:11:0: class=0x020000 card=0x00408086 chip=0x12298086 rev=0x0c hdr=0x00 uhci2@pci0:0:12:0: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x61 hdr=0x00 uhci3@pci0:0:12:1: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0x61 hdr=0x00 ehci0@pci0:0:12:2: class=0x0c0320 card=0x31041106 chip=0x31041106 rev=0x63 hdr=0x00 fwohci0@pci0:0:12:3: class=0x0c0010 card=0x30441106 chip=0x30441106 rev=0x46 hdr=0x00 vgapci0@pci0:1:0:0: class=0x030000 card=0x00840000 chip=0x47441002 rev=0x5c hdr=0x00 --------------020900090803040701060404-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 12:16: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 83117106566B for ; Wed, 2 Sep 2009 12:16: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 401BB8FC15 for ; Wed, 2 Sep 2009 12:16:56 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id A526F46B0D; Wed, 2 Sep 2009 08:16:55 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id F391D8A03E; Wed, 2 Sep 2009 08:16:54 -0400 (EDT) From: John Baldwin To: Rainer Hurling Date: Tue, 1 Sep 2009 17:17:56 -0400 User-Agent: KMail/1.9.7 References: <4A9BF23F.6070801@netability.ie> <200909011505.32243.jhb@freebsd.org> <4A9D86C9.1020603@gwdg.de> In-Reply-To: <4A9D86C9.1020603@gwdg.de> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200909011717.57386.jhb@freebsd.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 02 Sep 2009 08:16:55 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.0 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 12:16:56 -0000 On Tuesday 01 September 2009 4:40:41 pm Rainer Hurling wrote: > On 01.09.2009 21:05 (UTC+2), John Baldwin wrote: > > On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote: > >> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote: > >>> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote: > >>>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote: > >>>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote: > >>>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode > > (bios > >>>>>>> doesn't appear to give the option to use AHCI). On freebsd 7.x, all > >>>>>>> channels are detected. On freebsd8.0-beta3, the disks attached to the > >>>>>>> first two SATA ports are not detected, although it detects the ports > >>>>>>> themselves. > >>>>>>> > >>>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. > >>>>>>> > >>>>>>> Any ideas on what's going on here? This seems like a nasty > > regression. > >>>>>> There are 3 PRs about this problem: 128686, 132372, 137942. > >>>>>> > >>>>>> i386 version should recognize the disks. amd64 does when you set > >>>>>> hw.pci.mcfg=0 in loader.conf. > >>>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config > >>> space > >>>>> for the disk controller in the MCFG vs non-MCFG cases? That is, find > > the > >>>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and > >>> then > >>>>> run this command under both configurations and save the output: > >>>>> > >>>>> pciconf -r pci0:0:30:0 0:0xfc > >>>>> > >>>> I am not sure if your idea has something to do with my (and some other > >>>> users) problem. So excuse me, if this posting is wrong. > >>>> > >>>> For some month now I am only able to boot CURRENT under amd64 with > >>>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output > >>>> under i386 and under amd64. Perhaps you are able to get a hint? > >>> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using nfsroot > > or > >>> an mfsroot) and capture this output? The mcfg thing only affects access > > to > >>> PCI config space (what pciconf -r is displaying). I want to be able to > >>> compare the "broken" case (amd64 mcfg=1) with a working case. > >> My only amd64 system is at home. Sorry, but I have no idea how to start > >> this system using nfsroot oder mfsroot. > > > > Ok, I believe some of the other folks reporting an issue with this ATA > > controller had other disk controllers in the system so they may be able to do > > this. > > Thanks to Kostik Belousov, I tried his hint with live CD. Here it is, > only for amd64, with snapshot from todays CURRENT: > > #systctl hw.pci.mcfg > hw.pci.mcfg: 1 Hmm, this one is identical to the mcfg=0 one on amd64 (except for a few values that also differ between the working i386 and working amd64). So it doesn't seem that PCI config access is horribly broken. :( Perhaps someone can spend some time comparing what the driver does in the two cases with some printfs to see when it starts behaving differently during its attach routine to help narrow this down. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 12:25: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 5D6CD106566B for ; Wed, 2 Sep 2009 12:25:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 19B568FC14 for ; Wed, 2 Sep 2009 12:25:31 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n82CM8Q3020822; Wed, 2 Sep 2009 08:22:08 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200909021222.n82CM8Q3020822@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 Sep 2009 08:25:40 -0400 To: "Derek (freebsd lists)" <482254ac@razorfever.net>, freebsd-current@freebsd.org From: Mike Tancsa In-Reply-To: <4A9E5F34.2090700@razorfever.net> References: <4A9E5F34.2090700@razorfever.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 12:25:32 -0000 At 08:04 AM 9/2/2009, Derek (freebsd lists) wrote: >Hi, > >I've been testing the new siis driver, and I have found no >appreciable performance change, using dd as a measure of "raw" >performance. Dont know about raw, but I found some cases where it was faster, especially with random I/O. Havent tried with the recent commits however ---Mike >I get about 40MB/s read, and 30MB/s write. See attached >bench-*.txt files. > >Am I expecting too much, or do I have something else going on >here? (e.g. dd being a terrible benchmark of disk i/o) > >Is anyone else seeing better/worse/same numbers? > >Also I find it surprising that my gmirror read is only 40MB/s, >and not 60-80MB/s, any thoughts on this? > >Thanks! >- Derek > > > > > > >dd if=/dev/zero of=/dev/null bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 0.437049 secs (307099849 bytes/sec) > >dd if=/dev/zero of=/dev/ad4p2 bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 4.410338 secs (30432527 bytes/sec) > >dd if=/dev/zero of=/dev/ad6p2 bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 4.401181 secs (30495844 bytes/sec) > >dd if=/dev/ad6p2 of=/dev/null bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 3.234643 secs (41493831 bytes/sec) > >dd if=/dev/ad4p2 of=/dev/null bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 3.689668 secs (41385739 bytes/sec) > >gmirror label gm0p2 ad4p2 ad6p2 >dd if=/dev/mirror/gm0p2 of=/dev/null bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 3.331307 secs (40289811 bytes/sec) > >dd if=/dev/zero of=/dev/mirror/gm0p2 bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 8.167607 secs (16432932 bytes/sec) > > >dd if=/dev/zero of=/dev/null bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 0.434279 secs (309058782 bytes/sec) > >dd if=/dev/zero of=/dev/ada0p2 bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 4.604623 secs (29148472 bytes/sec) > >dd if=/dev/zero of=/dev/ada1p2 bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 4.402896 secs (30483966 bytes/sec) > >dd if=/dev/ada1p2 of=/dev/null bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 3.203470 secs (41897607 bytes/sec) > >dd if=/dev/ada0p2 of=/dev/null bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 3.211751 secs (41789581 bytes/sec) > >gmirror label gm0p2 ada0p2 ada1p2 >dd if=/dev/mirror/gm0p2 of=/dev/null bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 3.349089 secs (40075890 bytes/sec) > >dd if=/dev/zero of=/dev/mirror/gm0p2 bs=1M count=128 >128+0 records in >128+0 records out >134217728 bytes transferred in 8.121042 secs (16527156 bytes/sec) > > >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-BETA3 #1: Tue Sep 1 15:24:09 EDT 2009 > root@porter.razorfever.net:/usr/obj/usr/src/sys/ZFS-PROD >Timecounter "i8254" frequency 1193182 Hz quality 0 >CPU: Intel(R) Pentium(R) III CPU family 1400MHz (1399.54-MHz >686-class CPU) > Origin = "GenuineIntel" Id = 0x6b1 Stepping = 1 > >Features=0x383fbff >real memory = 2147483648 (2048 MB) >avail memory = 2083577856 (1987 MB) >ACPI APIC Table: >FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >FreeBSD/SMP: 2 package(s) x 1 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 >ioapic0 irqs 0-23 on motherboard >kbd1 at kbdmux0 >acpi0: on motherboard >acpi0: [ITHREAD] >acpi0: Power Button (fixed) >acpi0: reservation of 0, a0000 (3) failed >acpi0: reservation of 100000, 7fef0000 (3) failed >Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 >acpi_button0: on acpi0 >pcib0: port >0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0 >pci0: on pcib0 >agp0: on hostb0 >agp0: aperture size is 228M >pcib1: at device 1.0 on pci0 >pci1: on pcib1 >vgapci0: port 0x9000-0x90ff mem >0xfa000000-0xfaffffff,0xf9000000-0xf9000fff at device 0.0 on pci1 >isab0: at device 7.0 on pci0 >isa0: on isab0 >atapci0: port >0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xa000-0xa00f at device 7.1 on pci0 >ata0: on atapci0 >ata0: [ITHREAD] >ata1: on atapci0 >ata1: [ITHREAD] >uhci0: port 0xa400-0xa41f irq 5 at >device 7.2 on pci0 >uhci0: [ITHREAD] >usbus0: on uhci0 >uhci1: port 0xa800-0xa81f irq 5 at >device 7.3 on pci0 >uhci1: [ITHREAD] >usbus1: on uhci1 >pci0: at device 7.4 (no driver attached) >siis0: port 0xb800-0xb80f mem >0xfc448000-0xfc44807f,0xfc440000-0xfc447fff irq 17 at device 8.0 on pci0 >siis0: [ITHREAD] >siisch0: at channel 0 on siis0 >siisch0: [ITHREAD] >siisch1: at channel 1 on siis0 >siisch1: [ITHREAD] >siisch2: at channel 2 on siis0 >siisch2: [ITHREAD] >siisch3: at channel 3 on siis0 >siisch3: [ITHREAD] >fxp0: port 0xbc00-0xbc3f mem >0xfc44a000-0xfc44afff,0xfc400000-0xfc41ffff irq 19 at device 10.0 on pci0 >miibus0: on fxp0 >inphy0: PHY 1 on miibus0 >inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >fxp0: Ethernet address: 00:02:b3:31:f2:ec >fxp0: [ITHREAD] >fxp1: port 0xc000-0xc03f mem >0xfc449000-0xfc449fff,0xfc420000-0xfc43ffff irq 16 at device 11.0 on pci0 >miibus1: on fxp1 >inphy1: PHY 1 on miibus1 >inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >fxp1: Ethernet address: 00:02:b3:22:a9:ca >fxp1: [ITHREAD] >uhci2: port 0xc400-0xc41f irq 17 at >device 12.0 on pci0 >uhci2: [ITHREAD] >usbus2: on uhci2 >uhci3: port 0xc800-0xc81f irq 18 at >device 12.1 on pci0 >uhci3: [ITHREAD] >usbus3: on uhci3 >ehci0: mem 0xfc44b000-0xfc44b0ff irq >19 at device 12.2 on pci0 >ehci0: [ITHREAD] >usbus4: EHCI version 1.0 >usbus4: on ehci0 >fwohci0: port 0xcc00-0xcc7f mem >0xfc44c000-0xfc44c7ff irq 17 at device 12.3 on pci0 >fwohci0: [ITHREAD] >fwohci0: OHCI version 1.0 (ROM=1) >fwohci0: No. of Isochronous channels is 4. >fwohci0: EUI64 00:11:06:00:00:00:e3:32 >fwohci0: Phy 1394a available S400, 3 ports. >fwohci0: Link S100, max_rec 2 bytes. >fwohci0: max_rec 2 -> 2048 >firewire0: on fwohci0 >dcons_crom0: on firewire0 >dcons_crom0: bus_addr 0x157c000 >fwe0: on firewire0 >if_fwe0: Fake Ethernet address: 02:11:06:00:e3:32 >fwe0: Ethernet address: 02:11:06:00:e3:32 >fwip0: on firewire0 >fwip0: Firewire address: 00:11:06:00:00:00:e3:32 @ 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 >atrtc0: port 0x70-0x73 irq 8 on acpi0 >fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 >fdc0: [FILTER] >uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >uart0: [FILTER] >uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >uart1: [FILTER] >ppc0: port 0x378-0x37f irq 7 on acpi0 >ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode >ppc0: [ITHREAD] >ppbus0: on ppc0 >plip0: on ppbus0 >plip0: [ITHREAD] >lpt0: on ppbus0 >lpt0: [ITHREAD] >lpt0: Interrupt-driven port >ppi0: on ppbus0 >atkbdc0: port 0x60,0x64 irq 1 on acpi0 >atkbd0: irq 1 on atkbdc0 >kbd0 at atkbd0 >atkbd0: [GIANT-LOCKED] >atkbd0: [ITHREAD] >psm0: irq 12 on atkbdc0 >psm0: [GIANT-LOCKED] >psm0: [ITHREAD] >psm0: model IntelliMouse Explorer, device ID 4 >cpu0: on acpi0 >cpu1: on acpi0 >pmtimer0 on isa0 >orm0: at iomem >0xc0000-0xc7fff,0xc8000-0xcc7ff,0xcd000-0xce7ff,0xcf000-0xd07ff >pnpid ORM0000 on isa0 >sc0: at flags 0x100 on isa0 >sc0: VGA <16 virtual consoles, flags=0x300> >vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >WARNING: ZFS is considered to be an experimental feature in FreeBSD. >ZFS NOTICE: prefetch is disabled by default on i386 - add enable to >tunable to change. >ZFS filesystem version 13 >ZFS storage pool version 13 >Timecounters tick every 1.000 msec >firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) >firewire0: bus manager 0 >Waiting 5 seconds for SCSI devices to settle >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 >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 >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: 4 ports with 4 removable, self powered >(aprobe0:siisch0:0:15:0): SIGNATURE: 0000 >(aprobe0:siisch0:0:0:0): SIGNATURE: 0000 >(aprobe1:siisch1:0:15:0): SIGNATURE: 0000 >(aprobe0:siisch1:0:0:0): SIGNATURE: 0000 >ada0 at siisch0 bus 0 target 0 lun 0 >ada0: ATA/ATAPI-8 SATA 2.x device >ada0: 300.000MB/s transfers >ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) >ada0: Native Command Queueing enabled >ada1 at siisch1 bus 0 target 0 lun 0 >ada1: ATA/ATAPI-8 SATA 2.x device >ada1: 300.000MB/s transfers >ada1: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) >ada1: Native Command Queueing enabled >SMP: AP CPU #1 Launched! >GEOM_MIRROR: Device mirror/gm0p2 launched (2/2). >Trying to mount root from zfs:tank > > > >ostb0@pci0:0:0:0: class=0x060000 card=0x00000000 >chip=0x06911106 rev=0xc4 hdr=0x00 >pcib1@pci0:0:1:0: class=0x060400 card=0x00000000 >chip=0x85981106 rev=0x00 hdr=0x01 >isab0@pci0:0:7:0: class=0x060100 card=0x000010f1 >chip=0x06861106 rev=0x40 hdr=0x00 >atapci0@pci0:0:7:1: class=0x01018a card=0x05711106 >chip=0x05711106 rev=0x06 hdr=0x00 >uhci0@pci0:0:7:2: class=0x0c0300 card=0x12340925 >chip=0x30381106 rev=0x1a hdr=0x00 >uhci1@pci0:0:7:3: class=0x0c0300 card=0x12340925 >chip=0x30381106 rev=0x1a hdr=0x00 >none0@pci0:0:7:4: class=0x068000 card=0x30571106 >chip=0x30571106 rev=0x40 hdr=0x00 >siis0@pci0:0:8:0: class=0x018000 card=0x31241095 >chip=0x31241095 rev=0x02 hdr=0x00 >fxp0@pci0:0:10:0: class=0x020000 card=0x00408086 >chip=0x12298086 rev=0x0c hdr=0x00 >fxp1@pci0:0:11:0: class=0x020000 card=0x00408086 >chip=0x12298086 rev=0x0c hdr=0x00 >uhci2@pci0:0:12:0: class=0x0c0300 card=0x30381106 >chip=0x30381106 rev=0x61 hdr=0x00 >uhci3@pci0:0:12:1: class=0x0c0300 card=0x30381106 >chip=0x30381106 rev=0x61 hdr=0x00 >ehci0@pci0:0:12:2: class=0x0c0320 card=0x31041106 >chip=0x31041106 rev=0x63 hdr=0x00 >fwohci0@pci0:0:12:3: class=0x0c0010 card=0x30441106 >chip=0x30441106 rev=0x46 hdr=0x00 >vgapci0@pci0:1:0:0: class=0x030000 card=0x00840000 >chip=0x47441002 rev=0x5c hdr=0x00 > > >_______________________________________________ >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" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 12:38: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 F077A106568F for ; Wed, 2 Sep 2009 12:38:52 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (rrcs-24-73-246-106.sw.biz.rr.com [24.73.246.106]) by mx1.freebsd.org (Postfix) with ESMTP id B393B8FC21 for ; Wed, 2 Sep 2009 12:38:52 +0000 (UTC) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n82CcnmH038610; Wed, 2 Sep 2009 07:38:50 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=vEseTRK+GHpM7V2EKCVjpzELP6bnDkgO2AGb0TkwYXqO9NBTyJckOZ7akN40bvUSQ ZoYYMQJeRFZDgcRC4LRtsnxqzpeYeJ/qA9S8eBTynr25gmI26tsBqm+idM8TZuHFtdI fTaAbXHHhSG6uUO39gBdzQW/WcWKBYGv2+SucyI= Message-ID: <4A9E6759.7090700@jrv.org> Date: Wed, 02 Sep 2009 07:38:49 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Derek (freebsd lists)" <482254ac@razorfever.net> References: <4A9E5F34.2090700@razorfever.net> In-Reply-To: <4A9E5F34.2090700@razorfever.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 12:38:53 -0000 Derek (freebsd lists) wrote: > I get about 40MB/s read, and 30MB/s write. See attached > bench-*.txt files. That's too slow. As I posted on July 31 I got sustained read rates of 875 MB/s across ten disks, through two 3124 cards and four port multipliers. The system I tested was a dual processor Opteron 244 (1.8 GHz) running amd64. Perhaps more important, my disk controllers were on two different PCI-X buses with ample bandwidth (100 MHz 64-bit and 133 MHz 64-bit). Is your disk controller on a PCI bus, and is there any other PCI traffic at the time? From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 12:44: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 A4B071065676 for ; Wed, 2 Sep 2009 12:44:45 +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 774A18FC22 for ; Wed, 2 Sep 2009 12:44:45 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 26E8B46B3B; Wed, 2 Sep 2009 08:44:45 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 7751C8A043; Wed, 2 Sep 2009 08:44:44 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 2 Sep 2009 08:42:25 -0400 User-Agent: KMail/1.9.7 References: <20090901201346.GA2432@cuba.calyx.nl> In-Reply-To: <20090901201346.GA2432@cuba.calyx.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909020842.25447.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Wed, 02 Sep 2009 08:44:44 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.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: Bill Squire {billsf} Subject: Re: The only problems with v8.0 are: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 12:44:45 -0000 On Tuesday 01 September 2009 4:13:46 pm Bill Squire {billsf} wrote: > > These 'bug' me: > > 8.0 is ready. The '/boot/loader' has been a long time problem. If I'm the > only one that knows Forth (my first computer language) I probably can fix it. > However, a loader from v7 should do fine. What specifically is broken about /boot/loader in 8.0? > There appears to be a typo in one of the cddl 32bit Makefiles. It doesn't get > a certain header file into */obj/. That file is: '/usr/include/rpc/xdr.h'. Are you seeing a build failure? The tinderboxes are not broken so I believe world is building fine. If you are having problems building something else besides world can you provide more details? -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 12:58: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 BCF2D1065670 for ; Wed, 2 Sep 2009 12:58:56 +0000 (UTC) (envelope-from 482254ac@razorfever.net) Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7FDC88FC15 for ; Wed, 2 Sep 2009 12:58:56 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEALcInkpMCrCL/2dsb2JhbACBUxrZBYQbBYFXhhk X-IronPort-AV: E=Sophos;i="4.44,318,1249272000"; d="scan'208";a="44965587" Received: from 76-10-176-139.dsl.teksavvy.com (HELO server.razorfever.net) ([76.10.176.139]) by ironport2-out.teksavvy.com with ESMTP; 02 Sep 2009 08:57:45 -0400 Received: from [192.168.0.197] ([192.168.0.197]) by server.razorfever.net (8.13.8/8.13.8) with ESMTP id n82CwdeW016865; Wed, 2 Sep 2009 08:58:39 -0400 (EDT) (envelope-from 482254ac@razorfever.net) Message-ID: <4A9E6C2A.7090305@razorfever.net> Date: Wed, 02 Sep 2009 08:59:22 -0400 From: "Derek (freebsd lists)" <482254ac@razorfever.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "James R. Van Artsdalen" References: <4A9E5F34.2090700@razorfever.net> <4A9E6759.7090700@jrv.org> In-Reply-To: <4A9E6759.7090700@jrv.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at server.razorfever.net X-Virus-Status: Clean Cc: FreeBSD Current Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 12:58:56 -0000 James R. Van Artsdalen wrote: > Derek (freebsd lists) wrote: >> I get about 40MB/s read, and 30MB/s write. See attached >> bench-*.txt files. > > That's too slow. As I posted on July 31 I got sustained read rates of > 875 MB/s across ten disks, through two 3124 cards and four port multipliers. > Right, so directly to a single disks I see 40/30MB/s read/write respectively. "Benchmarks" on the Internet peg the i/o to be around 100/80MB/s average read on these disks. > The system I tested was a dual processor Opteron 244 (1.8 GHz) running > amd64. Perhaps more important, my disk controllers were on two > different PCI-X buses with ample bandwidth (100 MHz 64-bit and 133 MHz > 64-bit). From the dmesg, this is a dual 1.4Ghz P3, and the controller is standard 32-bit/33Mhz PCI. Mind you, I think even 80MB/s should not saturate the PCI bus, if there's nothing else going on. > Is your disk controller on a PCI bus, and is there any other PCI traffic > at the time? The only traffic would be a little ssh traffic on fxp0, but otherwise, I can't think of any other traffic that would be occurring. - Derek From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 14:03: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 16743106566B; Wed, 2 Sep 2009 14:03:51 +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 9AC948FC0A; Wed, 2 Sep 2009 14:03:49 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA06503; Wed, 02 Sep 2009 17:03:47 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A9E7B42.9070608@icyb.net.ua> Date: Wed, 02 Sep 2009 17:03:46 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: Robert Noland References: <4A9D7560.7060902@freebsd.org> <1251840705.1689.4440.camel@balrog.2hip.net> In-Reply-To: <1251840705.1689.4440.camel@balrog.2hip.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Rene Ladan , freebsd-current@FreeBSD.org, x11@FreeBSD.org Subject: Re: DRI initialiazation fails on 8.0-BETAx/M54 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 14:03:51 -0000 on 02/09/2009 00:31 Robert Noland said the following: > On Tue, 2009-09-01 at 21:26 +0200, Rene Ladan wrote: >> Hi, >> >> it looks like DRI initalization sometimes fails on my 8.0-BETA3/amd64 >> (official freebsd-update) laptop which has a ATI M54 card (radeonhd >> driver), reverting to software rendering for everything. The ports are >> up-to-date. >> >> From Xorg.0.log: >> (EE) RADEONHD(0): rhdAtomGetDDCIndex: GPIO_DDC Index 6 exceeds maximum 5 >> .. >> (EE) RADEONHD(0): [pci] Out of memory (-12) >> (EE) RADEONHD(0): [pci] PCI failed to initialize. Disabling the DRI. >> .. >> (II) RADEONHD(0): Using MMIO Command Submission for aceleration. >> ... >> >> Full xorg.conf and Xorg.0.log(.old) are at ftp://rene-ladan/pub/freebsd/ >> >> Any clues? Could it be related to hald giving timeouts on acd0 after which >> I just kill that hald subprocess and starting X after that? > > Is this happening when you start X after the system has been up for a > bit? I suspect that what is happening is that memory has become > fragmented and since bus_dma tries to allocate large chunks of > contiguous memory for drm, it has a tendency to fail after the system > has been running for a bit. This ultimately needs to be fixed in > bus_dma, but that hasn't happened yet. BTW, I have a different but potentially related problem - after running a head/current system for a while I am losing an ability to start VirtualBox. It complains about something "no memory" too. The system is amd64 with 4G of RAM with only a handful of processes started. Maybe we got some regression in memory area (e.g. pmap)? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 14:11: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 89EA61065693 for ; Wed, 2 Sep 2009 14:11: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 1C2038FC29 for ; Wed, 2 Sep 2009 14:11:41 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAGsYnkqWZZrw/2dsb2JhbACRf7cjkhGEGwWBVw X-IronPort-AV: E=Sophos;i="4.44,318,1249223400"; d="scan'208";a="29019909" Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail03.adl6.internode.on.net with ESMTP; 02 Sep 2009 23:41:39 +0930 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id 0360F5C80; Thu, 3 Sep 2009 00:11:39 +1000 (EST) Date: Thu, 3 Sep 2009 00:11:38 +1000 From: Emil Mikulic To: "Derek (freebsd lists)" <482254ac@razorfever.net> Message-ID: <20090902141138.GA15045@dmr.ath.cx> References: <4A9E5F34.2090700@razorfever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9E5F34.2090700@razorfever.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 14:11:42 -0000 On Wed, Sep 02, 2009 at 08:04:04AM -0400, Derek (freebsd lists) wrote: > Hi, > > I've been testing the new siis driver, and I have found no > appreciable performance change, using dd as a measure of "raw" > performance. > > I get about 40MB/s read, and 30MB/s write. See attached > bench-*.txt files. [...] > ada0: ATA/ATAPI-8 SATA 2.x device > ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) Huh, I have the same disk: # dmesg | grep ad4 ad4: 1430799MB at ata2-master SATA300 Sequential read on a disk this size should be around 120MB/sec at the outer tracks: # dd if=/dev/ad4 of=/dev/null bs=128k count=5000 655360000 bytes transferred in 5.171389 secs (126728039 bytes/sec) > Also I find it surprising that my gmirror read is only 40MB/s, > and not 60-80MB/s, any thoughts on this? Stripe will give you higher throughput. Mirror will give you more random seeks per second. --Emil From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 14: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 B89D61065670 for ; Wed, 2 Sep 2009 14:28:50 +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 D59588FC1A for ; Wed, 2 Sep 2009 14:28:49 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA07119; Wed, 02 Sep 2009 17:28:47 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A9E811E.7040107@freebsd.org> Date: Wed, 02 Sep 2009 17:28:46 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: Hans Petter Selasky References: <20090826080554.GA2664@beastie.smeiknet> <200908271913.13206.hselasky@c2i.net> <4A9BC919.1070305@freebsd.org> <200908311526.26074.hselasky@c2i.net> In-Reply-To: <200908311526.26074.hselasky@c2i.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 14:28:50 -0000 on 31/08/2009 16:26 Hans Petter Selasky said the following: > On Monday 31 August 2009 14:59:05 Andriy Gapon wrote: [snip] >> >> It's cf=255 that is different from all other hubs. > > Then: > > usbconfig -u 0 -a 1 set_config 0 OK, did this, the hub re-initialized and tried to attach the mouse, but failed again. BTW, I obtained some logs with hw.usb.debug=1. This is what I get when I plug the mouse and it doesn't get attached: Sep 2 11:51:57 trant kernel: usb_alloc_device:1449: parent_dev=0xffffff0004e64900, bus=0xffffff80002c4320, parent_hub=0xffffff00040d5800, depth=1, port_index=1, port_no=2, speed=1, usb_mode=0 Sep 2 11:51:57 trant kernel: usb_set_device_state:2444: udev 0xffffff00464fb800 state DETACHED -> POWERED Sep 2 11:51:57 trant kernel: usbd_do_request_callback:95: st=0 Sep 2 11:51:57 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148, endpoint=0xffffff00464fb8d8, nframes=1, dir=write Sep 2 11:51:57 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8 edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=0 bEndpointAddress=0x00 Sep 2 11:51:57 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer: Sep 2 11:51:57 trant kernel: usbd_transfer_submit:1416: open Sep 2 11:51:57 trant kernel: usbd_pipe_enter:1584: enter Sep 2 11:51:57 trant kernel: usbd_pipe_start:2416: start Sep 2 11:51:58 trant kernel: usbd_do_request_flags:327: Handle Request function is set Sep 2 11:51:58 trant last message repeated 11 times Sep 2 11:51:58 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT Sep 2 11:51:58 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION Sep 2 11:51:58 trant kernel: usbd_callback_wrapper_sub:2550: xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=8, afrm=0, nfrm=1 Sep 2 11:51:58 trant kernel: usbd_do_request_callback:95: st=2 Sep 2 11:51:58 trant kernel: usbd_transfer_stop:1691: close Sep 2 11:51:58 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED Sep 2 11:51:58 trant kernel: usbd_transfer_done:2192: not transferring Sep 2 11:51:58 trant kernel: usb_alloc_device:1586: set address 2 failed (USB_ERR_TIMEOUT, ignored) Sep 2 11:51:58 trant kernel: usb_set_device_state:2444: udev 0xffffff00464fb800 state POWERED -> ADDRESSED Sep 2 11:51:58 trant kernel: usbd_do_request_callback:95: st=0 Sep 2 11:51:58 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148, endpoint=0xffffff00464fb8d8, nframes=2, dir=write Sep 2 11:51:58 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8 edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00 Sep 2 11:51:58 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer: Sep 2 11:51:58 trant kernel: usbd_transfer_submit:1416: open Sep 2 11:51:58 trant kernel: usbd_pipe_enter:1584: enter Sep 2 11:51:58 trant kernel: usbd_pipe_start:2416: start Sep 2 11:51:59 trant kernel: usbd_do_reuqusebsdt__dfol_argesq:uest_flag3s2:7: Handl3e2 7R:e qHuaensdtl ef uRnecqtuieosn ti sf usnetction is set Sep 2 11:51:59 trant kernel: usbd_do_request_flags:327: Handle Request function is set Sep 2 11:51:59 trant last message repeated 7 times Sep 2 11:51:59 trant kernel: Sep 2 11:51:59 trant kernel: usbd_do_request_flags:327: Handle Request function is set Sep 2 11:51:59 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT Sep 2 11:51:59 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION Sep 2 11:51:59 trant kernel: usbd_callback_wrapper_sub:2550: xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=16, afrm=0, nfrm=2 Sep 2 11:51:59 trant kernel: usbd_do_request_callback:95: st=2 Sep 2 11:51:59 trant kernel: usbd_transfer_stop:1691: close Sep 2 11:51:59 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED Sep 2 11:51:59 trant kernel: usbd_transfer_done:2192: not transferring Sep 2 11:51:59 trant kernel: usb_alloc_device:1624: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! Sep 2 11:51:59 trant kernel: usbd_do_request_flags:327: Handle Request function is set Sep 2 11:51:59 trant last message repeated 2 times Sep 2 11:51:59 trant kernel: usbd_do_request_callback:95: st=0 Sep 2 11:51:59 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148, endpoint=0xffffff00464fb8d8, nframes=1, dir=write Sep 2 11:51:59 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8 edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00 Sep 2 11:51:59 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer: Sep 2 11:51:59 trant kernel: usbd_transfer_submit:1416: open Sep 2 11:51:59 trant kernel: usbd_pipe_enter:1584: enter Sep 2 11:51:59 trant kernel: usbd_pipe_start:2416: start Sep 2 11:52:00 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT Sep 2 11:52:00 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION Sep 2 11:52:00 trant kernel: usbd_callback_wrapper_sub:2550: xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=8, afrm=0, nfrm=1 Sep 2 11:52:00 trant kernel: usbd_do_request_callback:95: st=2 Sep 2 11:52:00 trant kernel: usbd_transfer_stop:1691: close Sep 2 11:52:00 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED Sep 2 11:52:00 trant kernel: usbd_transfer_done:2192: not transferring Sep 2 11:52:00 trant kernel: usbd_req_re_enumerate:1539: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Sep 2 11:52:00 trant kernel: usbd_do_request_callback:95: st=0 Sep 2 11:52:00 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148, endpoint=0xffffff00464fb8d8, nframes=2, dir=write Sep 2 11:52:00 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8 edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00 Sep 2 11:52:00 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer: Sep 2 11:52:00 trant kernel: usbd_transfer_submit:1416: open Sep 2 11:52:00 trant kernel: usbd_pipe_enter:1584: enter Sep 2 11:52:00 trant kernel: usbd_pipe_start:2416: start Sep 2 11:52:01 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT Sep 2 11:52:01 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION Sep 2 11:52:01 trant kernel: usbd_callback_wrapper_sub:2550: xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=16, afrm=0, nfrm=2 Sep 2 11:52:01 trant kernel: usbd_do_request_callback:95: st=2 Sep 2 11:52:01 trant kernel: usbd_transfer_stop:1691: close Sep 2 11:52:01 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED Sep 2 11:52:01 trant kernel: usbd_transfer_done:2192: not transferring Sep 2 11:52:01 trant kernel: usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! Sep 2 11:52:02 trant kernel: usbd_do_request_flags:327: Handle Request function is set Sep 2 11:52:02 trant last message repeated 9 times Sep 2 11:52:02 trant kernel: Sep 2 11:52:02 trant kernel: usbd_do_request_flags:327: Handle Request function is set Sep 2 11:52:02 trant last message repeated 4 times Sep 2 11:52:02 trant kernel: usbd_do_request_callback:95: st=0 Sep 2 11:52:02 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148, endpoint=0xffffff00464fb8d8, nframes=1, dir=write Sep 2 11:52:02 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8 edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00 Sep 2 11:52:02 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer: Sep 2 11:52:02 trant kernel: usbd_transfer_submit:1416: open Sep 2 11:52:02 trant kernel: usbd_pipe_enter:1584: enter Sep 2 11:52:02 trant kernel: usbd_pipe_start:2416: start Sep 2 11:52:03 trant kernel: usbd_do_request_flags:327: Handle Request fuunscbtdi_odno _irse qsueetst_flags:327: Handle Request function is set Sep 2 11:52:03 trant kernel: usbd_do_request_flags:327: Handle Request function is set Sep 2 11:52:03 trant last message repeated 7 times Sep 2 11:52:03 trant kernel: Sep 2 11:52:03 trant kernel: usbd_do_request_flags:327: Handle Request function is set Sep 2 11:52:03 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT Sep 2 11:52:03 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION Sep 2 11:52:03 trant kernel: usbd_callback_wrapper_sub:2550: xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=8, afrm=0, nfrm=1 Sep 2 11:52:03 trant kernel: usbd_do_request_callback:95: st=2 Sep 2 11:52:03 trant kernel: usbd_transfer_stop:1691: close Sep 2 11:52:03 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED Sep 2 11:52:03 trant kernel: usbd_transfer_done:2192: not transferring Sep 2 11:52:03 trant kernel: usbd_req_re_enumerate:1539: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) Sep 2 11:52:03 trant kernel: usbd_do_request_callback:95: st=0 Sep 2 11:52:03 trant kernel: usbd_transfer_submit:1397: xfer=0xffffff800882e148, endpoint=0xffffff00464fb8d8, nframes=2, dir=write Sep 2 11:52:03 trant kernel: usb_dump_endpoint: endpoint=0xffffff00464fb8d8 edesc=0xffffff00464fbde4 isoc_next=0 toggle_next=1 bEndpointAddress=0x00 Sep 2 11:52:03 trant kernel: usb_dump_queue: endpoint=0xffffff00464fb8d8 xfer: Sep 2 11:52:03 trant kernel: usbd_transfer_submit:1416: open Sep 2 11:52:03 trant kernel: usbd_pipe_enter:1584: enter Sep 2 11:52:03 trant kernel: usbd_pipe_start:2416: start Sep 2 11:52:04 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT Sep 2 11:52:04 trant kernel: usbd_transfer_done:2185: err=USB_ERR_NORMAL_COMPLETION Sep 2 11:52:04 trant kernel: usbd_callback_wrapper_sub:2550: xfer=0xffffff800882e148 endpoint=0xffffff00464fb8d8 sts=20 alen=0, slen=16, afrm=0, nfrm=2 Sep 2 11:52:04 trant kernel: usbd_do_request_callback:95: st=2 Sep 2 11:52:04 trant kernel: usbd_transfer_stop:1691: close Sep 2 11:52:04 trant kernel: usbd_transfer_done:2185: err=USB_ERR_CANCELLED Sep 2 11:52:04 trant kernel: usbd_transfer_done:2192: not transferring Sep 2 11:52:04 trant kernel: usbd_req_re_enumerate:1553: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT! Sep 2 11:52:04 trant kernel: usb_set_device_state:2444: udev 0xffffff00464fb800 state ADDRESSED -> DETACHED Sep 2 11:52:04 trant kernel: ugen0.2: <(null)> at usbus0 (disconnected) Sep 2 11:52:04 trant kernel: uhub_reattach_port:435: could not allocate new device! Sep 2 11:52:04 trant kernel: usbd_do_request_flags:327: Handle Request function is set Sep 2 11:52:06 trant last message repeated 19 times -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 14:36: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 6FC69106566C for ; Wed, 2 Sep 2009 14:36:31 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id E41398FC08 for ; Wed, 2 Sep 2009 14:36:30 +0000 (UTC) Received: by ewy4 with SMTP id 4so867037ewy.36 for ; Wed, 02 Sep 2009 07:36:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.20.210 with SMTP id p60mr216142wep.172.1251902189383; Wed, 02 Sep 2009 07:36:29 -0700 (PDT) In-Reply-To: <20090902141138.GA15045@dmr.ath.cx> References: <4A9E5F34.2090700@razorfever.net> <20090902141138.GA15045@dmr.ath.cx> Date: Wed, 2 Sep 2009 16:36:29 +0200 Message-ID: <367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com> From: Olivier Smedts To: Emil Mikulic Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Derek \(freebsd lists\)" <482254ac@razorfever.net>, freebsd-current@freebsd.org Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 14:36:31 -0000 2009/9/2 Emil Mikulic : > On Wed, Sep 02, 2009 at 08:04:04AM -0400, Derek (freebsd lists) wrote: >> Hi, >> >> I've been testing the new siis driver, and I have found no >> appreciable performance change, using dd as a measure of "raw" >> performance. >> >> I get about 40MB/s read, and 30MB/s write. =A0See attached >> bench-*.txt files. > > [...] > >> ada0: ATA/ATAPI-8 SATA 2.x device >> ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) > > Huh, I have the same disk: > > # dmesg | grep ad4 > ad4: 1430799MB at ata2-master SATA300 > > Sequential read on a disk this size should be around 120MB/sec at the > outer tracks: > > # dd if=3D/dev/ad4 of=3D/dev/null bs=3D128k count=3D5000 > 655360000 bytes transferred in 5.171389 secs (126728039 bytes/sec) > >> Also I find it surprising that my gmirror read is only 40MB/s, >> and not 60-80MB/s, any thoughts on this? > > Stripe will give you higher throughput. > Mirror will give you more random seeks per second. And higher read throughput. > > --Emil > _______________________________________________ > 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 Wed Sep 2 14:38: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 A65A910656AA; Wed, 2 Sep 2009 14:38:08 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.swipnet.se [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id 0103B8FC14; Wed, 2 Sep 2009 14:38:07 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=X34a_XabVTEAe1-7Y44A:9 a=6kgOV9agmkWpy0kkmSLoFOd61IgA:4 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe09.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 951922373; Wed, 02 Sep 2009 16:38:05 +0200 From: Hans Petter Selasky To: Andriy Gapon Date: Wed, 2 Sep 2009 16:38:23 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090826080554.GA2664@beastie.smeiknet> <200908311526.26074.hselasky@c2i.net> <4A9E811E.7040107@freebsd.org> In-Reply-To: <4A9E811E.7040107@freebsd.org> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpO< =?iso-8859-1?q?Q0yAl=7E=3F=60=27F=3FjDVb=5DE6TQ7=27=23h-VlLs=7Dk/=0A=09?=(yxg(p!IL.`#ng"%`BMrham7%UK,}VH\wUOm=^>wEEQ+KWt[{J#x6ow~JO:,zwp.(t; @ =?iso-8859-1?q?Aq=0A=09=3A4=3A=26nFCgDb8=5B3oIeTb=5E=27?=",; u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909021638.25183.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: Problems with mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 14:38:08 -0000 On Wednesday 02 September 2009 16:28:46 Andriy Gapon wrote: > Sep 2 11:51:58 trant kernel: usbd_transfer_done:2185: err=USB_ERR_TIMEOUT If your mouse hardware just times out like that, then its more likely that your USB device is bad :-( Have you tried other USB mice? --HPS From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 14:40: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 504F1106568B for ; Wed, 2 Sep 2009 14:40:21 +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 7C3528FC26 for ; Wed, 2 Sep 2009 14:40:20 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA07361; Wed, 02 Sep 2009 17:40:18 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4A9E83D1.900@freebsd.org> Date: Wed, 02 Sep 2009 17:40:17 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: Hans Petter Selasky References: <20090826080554.GA2664@beastie.smeiknet> <200908311526.26074.hselasky@c2i.net> <4A9E811E.7040107@freebsd.org> <200909021638.25183.hselasky@c2i.net> In-Reply-To: <200909021638.25183.hselasky@c2i.net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with mouse X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 14:40:21 -0000 on 02/09/2009 17:38 Hans Petter Selasky said the following: > On Wednesday 02 September 2009 16:28:46 Andriy Gapon wrote: >> Sep 2 11:51:58 trant kernel: usbd_transfer_done:2185: > err=USB_ERR_TIMEOUT > > If your mouse hardware just times out like that, then its > more likely that your USB device is bad :-( Have you tried > other USB mice? Can it be sometimes bad, sometimes good? Maybe timeout is too small for this particular mouse (or right on the edge)? I could try playing with it. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 14:51: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 467A61065672 for ; Wed, 2 Sep 2009 14:51:46 +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 BF0888FC17 for ; Wed, 2 Sep 2009 14:51:45 +0000 (UTC) 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 253258668; Wed, 02 Sep 2009 17:51:42 +0300 Message-ID: <4A9E8677.1020208@FreeBSD.org> Date: Wed, 02 Sep 2009 17:51:35 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: "Derek (freebsd lists)" <482254ac@razorfever.net> References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 14:51:46 -0000 Derek (freebsd lists) wrote: > I've been testing the new siis driver, and I have found no > appreciable performance change, using dd as a measure of "raw" > performance. On linear read/write, without port multipliers used, performance of siis driver is not so much differs from legacy driver. The most of it's benefits are NCQ, FIS-based switching and command queuing affect mostly highly parallel random workload. > I get about 40MB/s read, and 30MB/s write. See attached > bench-*.txt files. It's too small, indeed. Actually, there are two different kinds of siis compatible devices: SiI3124 and SiI3132/SiI3531. SiI3124 is more expensive PCI-X card, sometimes it goes with built-in PCIe x4 bridge. To operate effectively it needs effective bus. Inserting it to usual PCI or PCIe x1 slot kills any hope. SiI3132/SiI3531 same time are cheap PCIe x1 cards. Nobody have ever seen them giving more 130-150MB/s, even looking that PCIe x1 should give 2.5Gb/s. > Am I expecting too much, or do I have something else going on > here? (e.g. dd being a terrible benchmark of disk i/o) > > Is anyone else seeing better/worse/same numbers? I have posted my micro benchmarks here: http://docs.freebsd.org/cgi/mid.cgi?4A95A3CA.3060306 > Also I find it surprising that my gmirror read is only 40MB/s, > and not 60-80MB/s, any thoughts on this? To completely load gmirror on read operations, you may need to run two dd's same time. Also make sure, that your gmirror runs in round-robin mode. Default split mode, which should help with linear read, is IMHO ineffective, at least with default MAXPHYS and slice values. For maximum linear I/O performance you may want to build kernel with options MAXPHYS=(1024*1024) If you are doing many linear reads from file system, increase vfs.read_max sysctl. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 14:54: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 013A0106568F for ; Wed, 2 Sep 2009 14:54:29 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 887278FC28 for ; Wed, 2 Sep 2009 14:54:28 +0000 (UTC) Received: by ewy4 with SMTP id 4so886360ewy.36 for ; Wed, 02 Sep 2009 07:54: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=zu1mzaGMQmZ2oaefe9GYEiJ4QKhSPS4GeJabTGJ52qU=; b=YtQ17DE2E4zPWw261MIrS/79rIs8NdXsNdNiS0KxzPO00tDoSJl5cU89CRyU6aww1z X7o/gTmnvTa57PyDbjckPq37yauMdhJNv5z+07aJB7DC96ImeKwRpC2R6A97nu/gC0wb rx3GVmj5h/TugHL0VI7sm+TOsWc7rcZL8j1Sw= 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=p8Mn5mT6q1rcytlh8/RT8YWCxDAJs9BCgZlG8ye+Mofn2DG+7GYMsBg7fDF5dTeSPn n9oar4mReHP0YE+RLfyiMPp91tHt38Ck4W/HY2+n4OpKS+o4ebMxSXy8Xe1cIqiOOjXh uUeEkiGqqZhqOvuHvhGyPNI2VvR25j+nkW/9c= MIME-Version: 1.0 Sender: r.c.ladan@gmail.com Received: by 10.216.37.212 with SMTP id y62mr201073wea.5.1251901458711; Wed, 02 Sep 2009 07:24:18 -0700 (PDT) In-Reply-To: <4A9E7B42.9070608@icyb.net.ua> References: <4A9D7560.7060902@freebsd.org> <1251840705.1689.4440.camel@balrog.2hip.net> <4A9E7B42.9070608@icyb.net.ua> Date: Wed, 2 Sep 2009 16:24:18 +0200 X-Google-Sender-Auth: 7285796ea18383ce Message-ID: From: Rene Ladan To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, x11@freebsd.org, Robert Noland Subject: Re: DRI initialiazation fails on 8.0-BETAx/M54 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 14:54:29 -0000 2009/9/2 Andriy Gapon : > on 02/09/2009 00:31 Robert Noland said the following: >> On Tue, 2009-09-01 at 21:26 +0200, Rene Ladan wrote: >>> Hi, >>> >>> it looks like DRI initalization sometimes fails on my 8.0-BETA3/amd64 >>> (official freebsd-update) laptop which has a ATI M54 card (radeonhd >>> driver), reverting to software rendering for everything. The ports are >>> up-to-date. >>> >>> =A0From Xorg.0.log: >>> (EE) RADEONHD(0): rhdAtomGetDDCIndex: GPIO_DDC Index 6 exceeds maximum = 5 >>> .. >>> (EE) RADEONHD(0): [pci] Out of memory (-12) >>> (EE) RADEONHD(0): [pci] PCI failed to initialize. Disabling the DRI. >>> .. >>> (II) RADEONHD(0): Using MMIO Command Submission for aceleration. >>> ... >>> >>> Full xorg.conf and Xorg.0.log(.old) are at ftp://rene-ladan/pub/freebsd= / >>> >>> Any clues? =A0Could it be related to hald giving timeouts on acd0 after= which >>> I just kill that hald subprocess and starting X after that? >> >> Is this happening when you start X after the system has been up for a >> bit? =A0I suspect that what is happening is that memory has become >> fragmented and since bus_dma tries to allocate large chunks of >> contiguous memory for drm, it has a tendency to fail after the system >> has been running for a bit. =A0This ultimately needs to be fixed in >> bus_dma, but that hasn't happened yet. > > BTW, I have a different but potentially related problem - after running a > head/current system for a while I am losing an ability to start VirtualBo= x. It > complains about something "no memory" too. > The system is amd64 with 4G of RAM with only a handful of processes start= ed. > Maybe we got some regression in memory area (e.g. pmap)? > FWIW, my main memory size is 2GB. I haven't tried vbox (yet). More information at ftp://rene-ladan.nl/pub/freebsd/dmesg-80b3.txt Ren=E9 From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 15:00: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 32044106566B for ; Wed, 2 Sep 2009 15:00:25 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id CC2158FC13 for ; Wed, 2 Sep 2009 15:00:24 +0000 (UTC) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n82F0KTJ034364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Sep 2009 17:00:20 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n82F0Io9047260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 17:00:18 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n82F0Iq7067183; Wed, 2 Sep 2009 17:00:18 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n82F0HZ2067182; Wed, 2 Sep 2009 17:00:17 +0200 (CEST) (envelope-from ticso) Date: Wed, 2 Sep 2009 17:00:17 +0200 From: Bernd Walter To: Olivier Smedts Message-ID: <20090902150017.GU60240@cicely7.cicely.de> References: <4A9E5F34.2090700@razorfever.net> <20090902141138.GA15045@dmr.ath.cx> <367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, AWL=0.000, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: "Derek \(freebsd lists\)" <482254ac@razorfever.net>, Emil Mikulic , freebsd-current@freebsd.org Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 15:00:25 -0000 On Wed, Sep 02, 2009 at 04:36:29PM +0200, Olivier Smedts wrote: > 2009/9/2 Emil Mikulic : > > On Wed, Sep 02, 2009 at 08:04:04AM -0400, Derek (freebsd lists) wrote: > >> Hi, > >> > >> I've been testing the new siis driver, and I have found no > >> appreciable performance change, using dd as a measure of "raw" > >> performance. > >> > >> I get about 40MB/s read, and 30MB/s write.  See attached > >> bench-*.txt files. > > > > [...] > > > >> ada0: ATA/ATAPI-8 SATA 2.x device > >> ada0: 1430799MB (2930277168 512 byte sectors: 16H 63S/T 16383C) > > > > Huh, I have the same disk: > > > > # dmesg | grep ad4 > > ad4: 1430799MB at ata2-master SATA300 > > > > Sequential read on a disk this size should be around 120MB/sec at the > > outer tracks: > > > > # dd if=/dev/ad4 of=/dev/null bs=128k count=5000 > > 655360000 bytes transferred in 5.171389 secs (126728039 bytes/sec) > > > >> Also I find it surprising that my gmirror read is only 40MB/s, > >> and not 60-80MB/s, any thoughts on this? > > > > Stripe will give you higher throughput. > > Mirror will give you more random seeks per second. > > And higher read throughput. This is a myth and not true for linear access in the general case. A disk usually lays the track reversed order to increase read throughput. Once the head is positioned it reads data into cache until the asked block is reached, so it already has more or less of the following blocks in cache. If you need the following block you better ask the same disk, because at average it already has the half track in cache. If you ask another disk it has to do a physical read first. To really increase linear throughput you need to preread data at a large offset (knowing the physical layout of the drive), but since in real world this is usually data of a completely different file it doesn't make much sense. For short range switches you just ask two disks for different blocks, but require them to issue the same physical reads. Of course you can double the read throughput, but only tuned for contructed cases. Striping is different, because say first strip is accessed from disk 1 and second stripe from disk 2. This reduces performance, because unlike disk 1 disk 2 has the following block not in cache, but for upcoming blocks you win from the cummulative preread cache. But real world filesystem access rarely is that linear, so even then it mmight be better to increase the stripe size large enough to not take the linear win, but also not have the disk switch loss. In real world you usually can win performance from random access in both cases and random access is what you almost always really want to increase. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 15:25: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 5141F1065672; Wed, 2 Sep 2009 15:25:32 +0000 (UTC) (envelope-from 482254ac@razorfever.net) Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by mx1.freebsd.org (Postfix) with ESMTP id 01BBE8FC16; Wed, 2 Sep 2009 15:25:31 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAN8rnkpMCrCL/2dsb2JhbACBUxraMYJrgTAFgVeGGQ X-IronPort-AV: E=Sophos;i="4.44,318,1249272000"; d="scan'208";a="44994399" Received: from 76-10-176-139.dsl.teksavvy.com (HELO server.razorfever.net) ([76.10.176.139]) by ironport2-out.teksavvy.com with ESMTP; 02 Sep 2009 11:24:17 -0400 Received: from [192.168.0.197] ([192.168.0.197]) by server.razorfever.net (8.13.8/8.13.8) with ESMTP id n82FPAMF017373; Wed, 2 Sep 2009 11:25:10 -0400 (EDT) (envelope-from 482254ac@razorfever.net) Message-ID: <4A9E8E82.9050708@razorfever.net> Date: Wed, 02 Sep 2009 11:25:54 -0400 From: "Derek (freebsd lists)" <482254ac@razorfever.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexander Motin References: <4A9E8677.1020208@FreeBSD.org> In-Reply-To: <4A9E8677.1020208@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at server.razorfever.net X-Virus-Status: Clean Cc: FreeBSD-Current Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 15:25:32 -0000 Thank you for your informative response. Alexander Motin wrote: > Derek (freebsd lists) wrote: >> I've been testing the new siis driver, and I have found no >> appreciable performance change, using dd as a measure of "raw" >> performance. > > On linear read/write, without port multipliers used, performance of siis > driver is not so much differs from legacy driver. The most of it's > benefits are NCQ, FIS-based switching and command queuing affect mostly > highly parallel random workload. > That's good news, in that the behaviour is expected. >> I get about 40MB/s read, and 30MB/s write. See attached >> bench-*.txt files. > > It's too small, indeed. Actually, there are two different kinds of siis > compatible devices: SiI3124 and SiI3132/SiI3531. SiI3124 is more > expensive PCI-X card, sometimes it goes with built-in PCIe x4 bridge. To > operate effectively it needs effective bus. Inserting it to usual PCI or > PCIe x1 slot kills any hope. SiI3132/SiI3531 same time are cheap PCIe x1 > cards. Nobody have ever seen them giving more 130-150MB/s, even looking > that PCIe x1 should give 2.5Gb/s. > I've got the SiI3124, plugged into a PCI bus. While I know PCI is really slow by today's standards, I was hoping to see performance closer to the bus limits. My rates are 30% of the maximum "theoretical" bus utilization (33Mhz*32-bits). The figures you give for PCIe x1 are around 40% of maximum (on the low end of the figures) utilization, so we're in the same neighbourhood. > To completely load gmirror on read operations, you may need to run two > dd's same time. Also make sure, that your gmirror runs in round-robin > mode. Default split mode, which should help with linear read, is IMHO > ineffective, at least with default MAXPHYS and slice values. > ... I'll play around with this as well, I'm not too interested in tweaking stuff much in production, but it would be interesting to see just how this performs. In production, I plan to use the gmirror for swap, and zfs for everything else. It seems that for swap usage, linear read isn't a great model. Thanks again! - Derek From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 15:28: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 7008F106566C; Wed, 2 Sep 2009 15:28:25 +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 403E58FC12; Wed, 2 Sep 2009 15:28:25 +0000 (UTC) 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 052DC7E818; Wed, 2 Sep 2009 07:28:36 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Wed, 2 Sep 2009 17:28:21 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <4A9E8677.1020208@FreeBSD.org> In-Reply-To: <4A9E8677.1020208@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909021728.21566.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Alexander Motin , "Derek \(freebsd lists\)" <482254ac@razorfever.net> Subject: MAXPHYS and physical memory (Was: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 15:28:25 -0000 On Wednesday 02 September 2009 16:51:35 Alexander Motin wrote: > For maximum linear I/O performance you may want to build kernel with > options MAXPHYS=(1024*1024) I've found that just doubling the default MAXPHYS already panics-on-boot a 1.5GB i386 system. Is there any reasonable conversion table for MAXPHYS to physical memory, since various memory related kernel setups are derived from or calculated with MAXPHYS? -- Mel From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 15: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 1B2A6106566C for ; Wed, 2 Sep 2009 15:28:48 +0000 (UTC) (envelope-from 482254ac@razorfever.net) Received: from ironport2-out.teksavvy.com (ironport2-out.pppoe.ca [206.248.154.182]) by mx1.freebsd.org (Postfix) with ESMTP id D346F8FC14 for ; Wed, 2 Sep 2009 15:28:47 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAN8rnkpMCrCL/2dsb2JhbACBUxraMYQbBYFXhhk X-IronPort-AV: E=Sophos;i="4.44,318,1249272000"; d="scan'208";a="44994894" Received: from 76-10-176-139.dsl.teksavvy.com (HELO server.razorfever.net) ([76.10.176.139]) by ironport2-out.teksavvy.com with ESMTP; 02 Sep 2009 11:27:36 -0400 Received: from [192.168.0.197] ([192.168.0.197]) by server.razorfever.net (8.13.8/8.13.8) with ESMTP id n82FSUHX017396; Wed, 2 Sep 2009 11:28:30 -0400 (EDT) (envelope-from 482254ac@razorfever.net) Message-ID: <4A9E8F4A.7080409@razorfever.net> Date: Wed, 02 Sep 2009 11:29:14 -0400 From: "Derek (freebsd lists)" <482254ac@razorfever.net> User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Emil Mikulic References: <4A9E5F34.2090700@razorfever.net> <20090902141138.GA15045@dmr.ath.cx> In-Reply-To: <20090902141138.GA15045@dmr.ath.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at server.razorfever.net X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 15:28:48 -0000 Emil Mikulic wrote: > Huh, I have the same disk: > > # dmesg | grep ad4 > ad4: 1430799MB at ata2-master SATA300 > > Sequential read on a disk this size should be around 120MB/sec at the > outer tracks: > > # dd if=/dev/ad4 of=/dev/null bs=128k count=5000 > 655360000 bytes transferred in 5.171389 secs (126728039 bytes/sec) > Would you mind describing the controller/bus that you are using to get these speeds? Thanks! - Derek From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 15:30: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 7F639106566C; Wed, 2 Sep 2009 15:30:21 +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 3C3308FC13; Wed, 2 Sep 2009 15:30:20 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA08749; Wed, 02 Sep 2009 18:30:18 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A9E8F8A.1010004@icyb.net.ua> Date: Wed, 02 Sep 2009 18:30:18 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: FreeBSD current X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Alexander Motin Subject: ahci cd0 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, 02 Sep 2009 15:30:21 -0000 k3b did "something" to my cd0 while tasting it and after that IDE activity LED was constantly on and I got a never-ending stream of messages like the following: ahcich5: Timeout on slot 25 ahcich5: Timeout on slot 26 ahcich5: Timeout on slot 29 ahcich5: Timeout on slot 30 ahcich5: Timeout on slot 1 ahcich5: Timeout on slot 2 ahcich5: Timeout on slot 5 ahcich5: Timeout on slot 6 ahcich5: Timeout on slot 9 ahcich5: Timeout on slot 10 ... and so on. cd0 is on ahcich5. This is head r196558. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 15:47: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 DAC8A106566C for ; Wed, 2 Sep 2009 15:47:03 +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 5A7048FC15 for ; Wed, 2 Sep 2009 15:47:03 +0000 (UTC) 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 253265031; Wed, 02 Sep 2009 18:46:59 +0300 Message-ID: <4A9E9366.9050601@FreeBSD.org> Date: Wed, 02 Sep 2009 18:46:46 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Mel Flynn References: <4A9E8677.1020208@FreeBSD.org> <200909021728.21566.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200909021728.21566.mel.flynn+fbsd.current@mailing.thruhere.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Derek \(freebsd lists\)" <482254ac@razorfever.net>, freebsd-current@freebsd.org Subject: Re: MAXPHYS and physical memory (Was: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 15:47:03 -0000 Mel Flynn wrote: > On Wednesday 02 September 2009 16:51:35 Alexander Motin wrote: > >> For maximum linear I/O performance you may want to build kernel with >> options MAXPHYS=(1024*1024) > > I've found that just doubling the default MAXPHYS already panics-on-boot a > 1.5GB i386 system. Is there any reasonable conversion table for MAXPHYS to > physical memory, since various memory related kernel setups are derived from > or calculated with MAXPHYS? What especially your panic was about? It could be bug in ATA(4) or some other code, that does not handle MAXPHYS correctly. I don't think that you could reach memory limit during simple system boot because of that. I am successfully running my testing Pentium-75 with 64MB RAM with 1MB MAXPHYS. Could you show your panic message? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 16:47: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 A7A7F1065672 for ; Wed, 2 Sep 2009 16:47:07 +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 2D3558FC15 for ; Wed, 2 Sep 2009 16:47:06 +0000 (UTC) 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 253268778; Wed, 02 Sep 2009 19:47:03 +0300 Message-ID: <4A9EA17C.2020204@FreeBSD.org> Date: Wed, 02 Sep 2009 19:46:52 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Andriy Gapon References: <4A9E8F8A.1010004@icyb.net.ua> In-Reply-To: <4A9E8F8A.1010004@icyb.net.ua> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD current Subject: Re: ahci cd0 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, 02 Sep 2009 16:47:07 -0000 Andriy Gapon wrote: > k3b did "something" to my cd0 while tasting it and after that IDE activity LED was > constantly on and I got a never-ending stream of messages like the following: > > ahcich5: Timeout on slot 25 > ahcich5: Timeout on slot 26 > ahcich5: Timeout on slot 29 > ahcich5: Timeout on slot 30 > ahcich5: Timeout on slot 1 > ahcich5: Timeout on slot 2 > ahcich5: Timeout on slot 5 > ahcich5: Timeout on slot 6 > ahcich5: Timeout on slot 9 > ahcich5: Timeout on slot 10 > ... > and so on. > cd0 is on ahcich5. > > This is head r196558. I don't know what initially caused the problem, but new ATA-CAM infrastructure is still lacks of proper timeout error recovery. It is not easy part, but I am working on it. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 19: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 D1139106566B; Wed, 2 Sep 2009 19:41:05 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id AFF308FC14; Wed, 2 Sep 2009 19:41:04 +0000 (UTC) Received: from delta.allbsd.org (p4121-ipbf1805funabasi.chiba.ocn.ne.jp [114.146.83.121]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id n82JenRE032730; Thu, 3 Sep 2009 04:41:00 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id n82Jefhh074585; Thu, 3 Sep 2009 04:40:43 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 03 Sep 2009 04:38:40 +0900 (JST) Message-Id: <20090903.043840.213910223.hrs@allbsd.org> To: qing.li@bluecoat.com From: Hiroki Sato In-Reply-To: <20090902.155958.08019398.hrs@allbsd.org> References: <20090830.024420.174808572.hrs@allbsd.org> <20090902.155958.08019398.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2.51 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Sep__3_04_38_40_2009_684)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.allbsd.org [133.31.130.32]); Thu, 03 Sep 2009 04:41:00 +0900 (JST) Cc: qingli@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: IPv6 regression on 8.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 19:41:05 -0000 ----Security_Multipart(Thu_Sep__3_04_38_40_2009_684)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiroki Sato wrote in <20090902.155958.08019398.hrs@allbsd.org>: hr> Anyway, I will try the a-box-with-three-NICs case when I return home hr> today. I didn't try it. Okay, I tried the case of all of NICs on a host and confirmed it works fine. hr> hr> qi> Would it be possible for you to email me your system configuration hr> qi> produced from "ifconfig" and "netstat" privately ? hr> hr> Sure. I will send them to you later. The results of ifconfig and netstat are the following. These are by another configuration from one I sent in the previous email, but the symptom is still reproducible: box-A (RELENG_7): re0: flags=8843 metric 0 mtu 1500 ether 00:26:18:41:64:1a inet6 fe80::226:18ff:fe41:641a%re0 prefixlen 64 scopeid 0x2 inet6 2001:db8:1::6 prefixlen 64 Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default fe80::21a:6dff:feb9:fd1b%ng1 UGS ng1 ::1 ::1 UHL lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2001:db8:1:: 00:13:a9:ff:63:e6 UHLW re0 => 2001:db8:1::/64 link#2 UC re0 2001:db8:1::1 00:13:a9:ff:63:e6 UHLW re0 2001:db8:1::6 00:26:18:41:64:1a UHL lo0 box-B (CURRENT): msk0: flags=8843 metric 0 mtu 1500 ether 00:13:a9:ff:63:e6 inet6 fe80::213:a9ff:feff:63e6%msk0 prefixlen 64 scopeid 0x1 inet6 2001:db8:1:: prefixlen 64 anycast gif0: flags=8011 metric 0 mtu 1280 inet6 2001:db8:2::1 prefixlen 64 inet6 fe80::213:a9ff:feff:63e6%gif0 prefixlen 64 scopeid 0x7 Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default fe80::214:1bff:fe39:281a%msk0 UG msk0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2001:db8:1:: link#5 UHS lo0 => 2001:db8:1::/64 link#1 U msk0 2001:db8:2::/64 link#7 U gif0 2001:db8:2::1 link#5 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%msk0/64 link#1 U msk0 fe80::213:a9ff:feff:63e6%msk0 link#5 UHS lo0 fe80::%lo0/64 link#5 U lo0 fe80::%gif0/64 link#7 U gif0 fe80::213:a9ff:feff:63e6%gif0 link#5 UHS lo0 ff01:1::/32 fe80::213:a9ff:feff:63e6%msk0 U msk0 ff01:5::/32 ::1 U lo0 ff01:7::/32 2001:db8:2::1 U gif0 ff02::/16 ::1 UGRS lo0 ff02::%msk0/32 fe80::213:a9ff:feff:63e6%msk0 U msk0 ff02::%lo0/32 ::1 U lo0 ff02::%gif0/32 2001:db8:2::1 U gif0 When doing "ping6 2001:db8:1::" from box-A, the source address becomes 2001:db8:1::6 (this is correct) and a link-local address on msk0 on box-B replies. -- Hiroki ----Security_Multipart(Thu_Sep__3_04_38_40_2009_684)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkqeycAACgkQTyzT2CeTzy34JACfTvifjvsyaNPzSqPt+nHVznUh PSoAoIMNJge5B3+o0fIracP05n6ehWbu =ac7z -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Sep__3_04_38_40_2009_684)---- From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 20:22: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 DABA7106566B for ; Wed, 2 Sep 2009 20:22:24 +0000 (UTC) (envelope-from nick@van-laarhoven.org) Received: from baranao.anywi.com (baranao.anywi.com [213.207.101.176]) by mx1.freebsd.org (Postfix) with ESMTP id 93BFB8FC13 for ; Wed, 2 Sep 2009 20:22:24 +0000 (UTC) Received: from hind.van-laarhoven.org (ip51cfcfde.direct-adsl.nl [81.207.207.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by baranao.anywi.com (Postfix) with ESMTPSA id 0775C3F41C; Wed, 2 Sep 2009 22:22:21 +0200 (CEST) From: Nick Hibma To: Robert Noland Date: Wed, 2 Sep 2009 16:56:15 +0200 User-Agent: KMail/1.12.0 (FreeBSD/7.2-STABLE; KDE/4.3.0; i386; ; ) References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> In-Reply-To: <1251841416.1689.4458.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200909021656.15747.nick@van-laarhoven.org> X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DATE_IN_PAST_03_06, UNPARSEABLE_RELAY autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on baranao.anywi.com Cc: FreeBSD CURRENT Mailing List Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 20:22:24 -0000 > What is irrelevant is subjective... I mean does the average user really > need to see anything in dmesg? Please don't change agp_i810.c. A > verbose boot is incredibly noisy and rarely needed for debugging > anything except the most deep rooted of issues. Please state arguments instead of this 'I think it is useful'. That's not going to cut it. If you feel strongly about the info that is being produced, an option would be to produce a (tested!) patch that combines more information on one line as a compromise. FreeBSD has historically been producing very limited output on dmesg. Linux is very noisy (ever noticed the copyright notices right in the middle of your list of PCI devices?). Even they have decided that they should hide this behind coloured 'ok/failed' texts in some distributions. FreeBSD has slowly been producing more and more output (most notably the USB subsystem up to 7.x) and I am intending to remove that clutter again, or at least compress it. Being swamped with information reduces its value rather than increase it. Nick From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 21:01: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 A9667106566B; Wed, 2 Sep 2009 21:01:07 +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 779A28FC17; Wed, 2 Sep 2009 21:01:07 +0000 (UTC) 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 EF4C97E818; Wed, 2 Sep 2009 13:01:17 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Wed, 2 Sep 2009 23:01:03 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <200909021728.21566.mel.flynn+fbsd.current@mailing.thruhere.net> <4A9E9366.9050601@FreeBSD.org> In-Reply-To: <4A9E9366.9050601@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909022301.03825.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Alexander Motin Subject: Re: MAXPHYS and physical memory (Was: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 21:01:07 -0000 On Wednesday 02 September 2009 17:46:46 Alexander Motin wrote: > Mel Flynn wrote: > > On Wednesday 02 September 2009 16:51:35 Alexander Motin wrote: > >> For maximum linear I/O performance you may want to build kernel with > >> options MAXPHYS=(1024*1024) > > > > I've found that just doubling the default MAXPHYS already panics-on-boot > > a 1.5GB i386 system. Is there any reasonable conversion table for MAXPHYS > > to physical memory, since various memory related kernel setups are > > derived from or calculated with MAXPHYS? > > What especially your panic was about? It could be bug in ATA(4) or some > other code, that does not handle MAXPHYS correctly. I don't think that > you could reach memory limit during simple system boot because of that. > I am successfully running my testing Pentium-75 with 64MB RAM with 1MB > MAXPHYS. > > Could you show your panic message? It's been a while since I last tried, during 7.1-STABLE. Two different machines wouldn't boot, both 1.5G; loading kernel.old, then commenting the MAXPHYS change, rebuilding kernel made things work, so I stopped pursuing this at the time. I remember the panic message quite early page fault, one of the first drivers loaded (ahci or acpi). Since this is supposed to work, I'm going to pursue it further and see if I can still reproduce it. -- Mel From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 21:20: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 DAD5A106566C for ; Wed, 2 Sep 2009 21:20:53 +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 631AC8FC0A for ; Wed, 2 Sep 2009 21:20:53 +0000 (UTC) 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 253280285; Thu, 03 Sep 2009 00:20:49 +0300 Message-ID: <4A9EE1AB.3040307@FreeBSD.org> Date: Thu, 03 Sep 2009 00:20:43 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Mel Flynn References: <200909021728.21566.mel.flynn+fbsd.current@mailing.thruhere.net> <4A9E9366.9050601@FreeBSD.org> <200909022301.03825.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200909022301.03825.mel.flynn+fbsd.current@mailing.thruhere.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: MAXPHYS and physical memory (Was: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Sep 2009 21:20:53 -0000 Mel Flynn wrote: > On Wednesday 02 September 2009 17:46:46 Alexander Motin wrote: >> Mel Flynn wrote: >>> On Wednesday 02 September 2009 16:51:35 Alexander Motin wrote: >>>> For maximum linear I/O performance you may want to build kernel with >>>> options MAXPHYS=(1024*1024) >>> I've found that just doubling the default MAXPHYS already panics-on-boot >>> a 1.5GB i386 system. Is there any reasonable conversion table for MAXPHYS >>> to physical memory, since various memory related kernel setups are >>> derived from or calculated with MAXPHYS? >> What especially your panic was about? It could be bug in ATA(4) or some >> other code, that does not handle MAXPHYS correctly. I don't think that >> you could reach memory limit during simple system boot because of that. >> I am successfully running my testing Pentium-75 with 64MB RAM with 1MB >> MAXPHYS. >> >> Could you show your panic message? > > It's been a while since I last tried, during 7.1-STABLE. Two different > machines wouldn't boot, both 1.5G; loading kernel.old, then commenting the > MAXPHYS change, rebuilding kernel made things work, so I stopped pursuing this > at the time. > I remember the panic message quite early page fault, one of the first drivers > loaded (ahci or acpi). Since this is supposed to work, I'm going to pursue it > further and see if I can still reproduce it. I have fixed MAXPHYS issue in ata-ahci in RELENG_8, but I haven't merged it lower as code is quite different. So it would be nice if you can check it on 8.x. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Sep 2 21:24: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 803421065679 for ; Wed, 2 Sep 2009 21:24:04 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 641008FC13 for ; Wed, 2 Sep 2009 21:24:04 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1MixJD-0007YX-Vn for freebsd-current@freebsd.org; Wed, 02 Sep 2009 14:24:03 -0700 Message-ID: <25265998.post@talk.nabble.com> Date: Wed, 2 Sep 2009 14:24:03 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <4A9EA17C.2020204@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <4A9E8F8A.1010004@icyb.net.ua> <4A9EA17C.2020204@FreeBSD.org> Subject: Re: ahci cd0 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, 02 Sep 2009 21:24:04 -0000 Alexander Motin-3 wrote: > > Andriy Gapon wrote: >> k3b did "something" to my cd0 while tasting it and after that IDE >> activity LED was >> constantly on and I got a never-ending stream of messages like the >> following: >> >> ahcich5: Timeout on slot 25 >> ahcich5: Timeout on slot 26 >> ahcich5: Timeout on slot 29 >> ahcich5: Timeout on slot 30 >> ahcich5: Timeout on slot 1 >> ahcich5: Timeout on slot 2 >> ahcich5: Timeout on slot 5 >> ahcich5: Timeout on slot 6 >> ahcich5: Timeout on slot 9 >> ahcich5: Timeout on slot 10 >> ... >> and so on. >> cd0 is on ahcich5. >> >> This is head r196558. > > I don't know what initially caused the problem, but new ATA-CAM > infrastructure is still lacks of proper timeout error recovery. It is > not easy part, but I am working on it. > > -- > Alexander Motin > _______________________________________________ > 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" > > Hello. More or less, I've lost my sata dvd drive ;) (cd0: ) Although I can mount CDs, cdparanoia is not working, 003: CDROM reporting illegal number of tracks cdda2wav as well.. cdda2wav: Error 0. inquiry: scsi sendcmd: fatal error CDB: 12 E0 00 00 24 00 cmd finished after 0.000s timeout 60s Inquiry command failed. Aborting... cdcontrol play produces no sound.. (but it probably wasn't working with atacontrol either) mplayer stubbornly wants to play dvd:// as /dev/acd0 , using "mplayer /dev/cd0" plays first track of dvd, trying to play cd with this command leads to: Playing /dev/cd0. Seek failed I think that If mplayer would interpret dvd://(track) as /dev/cd0(track) original functionality should be restored. For now NCQ has stripped me of ability to watch DVDs and rip audiocds ;) Well, trade-off. -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/ahci-cd0-issue-tp25259873p25265998.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 00:11: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 C92DC1065676 for ; Thu, 3 Sep 2009 00:11:26 +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 5733C8FC17 for ; Thu, 3 Sep 2009 00:11:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAAulnkqWZZrw/2dsb2JhbACSAbhRkgCEGwWBVw X-IronPort-AV: E=Sophos;i="4.44,321,1249223400"; d="scan'208";a="29175156" Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail03.adl6.internode.on.net with ESMTP; 03 Sep 2009 09:41:23 +0930 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id 552875C6E; Thu, 3 Sep 2009 10:11:23 +1000 (EST) Date: Thu, 3 Sep 2009 10:11:23 +1000 From: Emil Mikulic To: "Derek (freebsd lists)" <482254ac@razorfever.net> Message-ID: <20090903001123.GA17538@dmr.ath.cx> References: <4A9E5F34.2090700@razorfever.net> <20090902141138.GA15045@dmr.ath.cx> <4A9E8F4A.7080409@razorfever.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9E8F4A.7080409@razorfever.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 00:11:26 -0000 On Wed, Sep 02, 2009 at 11:29:14AM -0400, Derek (freebsd lists) wrote: > Would you mind describing the controller/bus that you are using to > get these speeds? Bits of dmesg: atapci1: port 0xd480-0xd487,0xd400-0xd403,0xd080-0xd087,0xd000-0xd003,0xcc00-0xcc0f mem 0xfae7a000-0xfae7bfff irq 22 at device 9.0 on pci0 atapci1: [ITHREAD] atapci1: AHCI v1.20 controller with 6 3Gbps ports, PM supported ata2: on atapci1 ata2: [ITHREAD] ad4: 1430799MB at ata2-master SATA300 Also kenv: smbios.planar.product="M4N78 PRO" This system has a newer CPU than the one you were timing: CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2700.02-MHz K8-class CPU) Are you seeing a lot of system and/or interrupt time when you do your benchmarks? --Emil From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 00: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 DFB3F1065672 for ; Thu, 3 Sep 2009 00:17:34 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 3B49A8FC14 for ; Thu, 3 Sep 2009 00:17:33 +0000 (UTC) Received: by fxm6 with SMTP id 6so1171556fxm.43 for ; Wed, 02 Sep 2009 17:17:33 -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=WysTt7o8KGnnZqwq62SzEnAJUVHEeXKD27eSefouunU=; b=c5uEZM/jhwHK+EnVODHjxmUCwPiXhUlT0ShVBQo0Z1q7bKPAV4gSi1KiWHxmoDMWMp gYB9IqcpxUd+muYL4zbl1Eb0Dy/+ZwdErTqK2WZjXxSXtDMIDOOQ/q0UCeI8FfbSgYcp WaNtCXlp0hOiFMUckgDSI1esc4S2UUKy0sgrY= 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=Q+QD5kk2o4cHArBu4+o99LqgJyMzeG7WxlXij7HAkM603KexgfCiGepTpEfC5U8Hcy hBgNWBJvySSp5jl5J6Dj/CrBlJ6MS7ZsjqX+e3dhWOimh5n49dl1g7h3hiAiXGS/tYaL oK4WGxCCOk9d25Oo45OuVt05zIRten7XC271k= MIME-Version: 1.0 Received: by 10.223.2.200 with SMTP id 8mr3776992fak.60.1251935120136; Wed, 02 Sep 2009 16:45:20 -0700 (PDT) In-Reply-To: <200909021656.15747.nick@van-laarhoven.org> References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> Date: Wed, 2 Sep 2009 18:45:20 -0500 Message-ID: <2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com> From: Astrodog To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 00:17:35 -0000 On Wed, Sep 2, 2009 at 9:56 AM, Nick Hibma wrote: >> What is irrelevant is subjective... =A0I mean does the average user real= ly >> need to see anything in dmesg? =A0Please don't change agp_i810.c. =A0A >> verbose boot is incredibly noisy and rarely needed for debugging >> anything except the most deep rooted of issues. > > Please state arguments instead of this 'I think it is useful'. That's not > going to cut it. If you feel strongly about the info that is being produc= ed, > an option would be to produce a (tested!) patch that combines more > information on one line as a compromise. > > FreeBSD has historically been producing very limited output on dmesg. Lin= ux > is very noisy (ever noticed the copyright notices right in the middle of > your list of PCI devices?). Even they have decided that they should hide > this behind coloured 'ok/failed' texts in some distributions. > > FreeBSD has slowly been producing more and more output (most notably the = USB > subsystem up to 7.x) and I am intending to remove that clutter again, or = at > least compress it. > > Being swamped with information reduces its value rather than increase it. > > Nick I think this speaks more towards needing something between "Very Quiet" and "Give me everything every developer has ever wanted to know enough to include a print for it." --- Harrison From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 00:21: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 D6606106566B; Thu, 3 Sep 2009 00:21:10 +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 1D0FD8FC1B; Thu, 3 Sep 2009 00:21:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAI6onkqWZZrw/2dsb2JhbACSAbg/kgKEGwWBVw X-IronPort-AV: E=Sophos;i="4.44,321,1249223400"; d="scan'208";a="29179302" Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail03.adl6.internode.on.net with ESMTP; 03 Sep 2009 09:51:07 +0930 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id E8C605C6E; Thu, 3 Sep 2009 10:21:06 +1000 (EST) Date: Thu, 3 Sep 2009 10:21:06 +1000 From: Emil Mikulic To: Alexander Motin Message-ID: <20090903002106.GB17538@dmr.ath.cx> References: <4A9E8677.1020208@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9E8677.1020208@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Derek \(freebsd lists\)" <482254ac@razorfever.net>, FreeBSD-Current Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 00:21:10 -0000 On Wed, Sep 02, 2009 at 05:51:35PM +0300, Alexander Motin wrote: > To completely load gmirror on read operations, you may need to run > two dd's same time. Also make sure, that your gmirror runs in > round-robin mode. Default split mode, which should help with linear > read, is IMHO ineffective, at least with default MAXPHYS and slice > values. On that note, there is an excellent patch in this PR which improves the way gmirror schedules read requests to different disks: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/113885 Could someone please commit this? With this patch and a two-way mirror, I can run two linear scans of different files in parallel and get almost perfect scaling. (result: this approximately halves the wall-clock time it takes to do a backup of some fat VM images) IIRC, without the patch it's faster to run them sequentially. :( --Emil From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 00:28: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 29E42106568F for ; Thu, 3 Sep 2009 00:28:59 +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 ACE7C8FC0C for ; Thu, 3 Sep 2009 00:28:58 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAI6onkqWZZrw/2dsb2JhbACSAbg/kgKEGwWBVw X-IronPort-AV: E=Sophos;i="4.44,321,1249223400"; d="scan'208";a="29182893" Received: from ppp154-240.static.internode.on.net ([150.101.154.240]) by ipmail03.adl6.internode.on.net with ESMTP; 03 Sep 2009 09:58:57 +0930 Received: by ppp154-240.static.internode.on.net (Poo-fix, from userid 1001) id 859AE5C6E; Thu, 3 Sep 2009 10:28:56 +1000 (EST) Date: Thu, 3 Sep 2009 10:28:56 +1000 From: Emil Mikulic To: Olivier Smedts Message-ID: <20090903002856.GC17538@dmr.ath.cx> References: <4A9E5F34.2090700@razorfever.net> <20090902141138.GA15045@dmr.ath.cx> <367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <367b2c980909020736i60b64563xc4fec6d11e3dae2b@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "Derek \(freebsd lists\)" <482254ac@razorfever.net>, freebsd-current@freebsd.org Subject: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 00:28:59 -0000 On Wed, Sep 02, 2009 at 04:36:29PM +0200, Olivier Smedts wrote: > 2009/9/2 Emil Mikulic : > > Stripe will give you higher throughput. > > Mirror will give you more random seeks per second. > > And higher read throughput. If you've got two streaming reads in parallel, and get lucky with disk scheduling, you can get higher aggregate throughput. But for the single linear scan that Derek and I have been benchmarking, I don't see how mirror would give a higher read throughput. Both disks are spinning at the same speed and their heads are in the same positions. --Emil From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 01:03: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 5F9361065670; Thu, 3 Sep 2009 01:03:17 +0000 (UTC) (envelope-from sweetnavelorange@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id C0B5C8FC18; Thu, 3 Sep 2009 01:03:16 +0000 (UTC) Received: by ewy4 with SMTP id 4so1384052ewy.36 for ; Wed, 02 Sep 2009 18:03: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=K19tmjz/jFDx4iHbFz/v18U7JCOv+8rIDivmN/CdQDk=; b=ZpB4V0GBzqus1UPt5DXrjTFNrLLkte1C7iyOrOGGNbE4g2HUUwzBVzNiCaATF3XNun 1dPxET2Md2mCcjVo4Md81L1xd6iV1o1CPbiP/4B/uAmolwx8t+DNkz4IYFby+VbnwHjg aDB4v0oF7y/qaygB9Z2QCutzHsjAXlt8eD2pQ= 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=VBFsIVwU+oP01kk/aLDVgZbmoFsfuPbUgrIsIXJ2Oh1s3tzoGSiGEvGcBSFiImTOYj bo8XZfsz9g0EzFvYr8S3v0bGog61QHrdQ5j+3o4Qmpuv7PccXRE+3xeUNIRAWmCszWc7 ksYNeRF6L77N2rQPAQc3YQl+h0eRL6JvtONkA= MIME-Version: 1.0 Received: by 10.216.88.78 with SMTP id z56mr368577wee.37.1251938344289; Wed, 02 Sep 2009 17:39:04 -0700 (PDT) In-Reply-To: <200909021656.15747.nick@van-laarhoven.org> References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> Date: Thu, 3 Sep 2009 12:39:04 +1200 Message-ID: From: James Butler To: Nick Hibma Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD CURRENT Mailing List , Robert Noland Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 01:03:17 -0000 2009/9/3 Nick Hibma : >> What is irrelevant is subjective... =C2=A0I mean does the average user r= eally >> need to see anything in dmesg? =C2=A0Please don't change agp_i810.c. =C2= =A0A >> verbose boot is incredibly noisy and rarely needed for debugging >> anything except the most deep rooted of issues. > > Please state arguments instead of this 'I think it is useful'. That's not > going to cut it. If you feel strongly about the info that is being produc= ed, > an option would be to produce a (tested!) patch that combines more > information on one line as a compromise. > > FreeBSD has historically been producing very limited output on dmesg. Lin= ux > is very noisy (ever noticed the copyright notices right in the middle of > your list of PCI devices?). Even they have decided that they should hide > this behind coloured 'ok/failed' texts in some distributions. This seems like an important distinction - the information which needs to be available with dmesg and the information best shown to the user at startup are not necessarily the same. The hypothetical "average user" probably wouldn't care if there were *no* kernel messages shown on startup. The Xubuntu box I'm writing this from shows only GRUB messages before the login prompt on tty1, and only service startup messages on tty8 (not to suggest that FreeBSD ought to be more like Ubuntu...). IOW, why bother painting it at all? Plain galvanized steel is very durable, and quite attractive when kept clean ;-) -James Butler From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 01:14: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 514551065676 for ; Thu, 3 Sep 2009 01:14:33 +0000 (UTC) (envelope-from chmeeedalf@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 E4D678FC13 for ; Thu, 3 Sep 2009 01:14:32 +0000 (UTC) Received: by an-out-0708.google.com with SMTP id d14so545857and.13 for ; Wed, 02 Sep 2009 18:14:32 -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=UmMas+l+LYF7cZzZgcA/DVHdban9WyDir88L5v/U7K0=; b=p7X0YSKe6mBq20rKLUrsUz46jufZlyyFbcKYjmNh8my1aEscSmjCPIIwed4dw19s0J P5Jk5qSb+nb3GjBvg8oXLHYzU5ffjcvesW0lOhY72gIif3p4HVbyHsjh/CNb0U1G5o/D Yzprh9NE5eTjWusrUYryHNBfji56GT5JDvA5o= 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=RE9PeVvOxUlKO+5oQmmdkfy3sjhWY5BPawVbx6sH/koCKSfjR8JhEOUOCFJuL6+KMK xH/yb3ya43+c/QQWwoBsPz+9RvOY6RHVrF7FxQrAx8nJ4drma9ka78nqnDBMLTkYMJbQ feyDcsWxvEbIYx3FRBie2cQb72mYb+YTg9tf0= MIME-Version: 1.0 Sender: chmeeedalf@gmail.com Received: by 10.100.17.20 with SMTP id 20mr10096157anq.41.1251940472147; Wed, 02 Sep 2009 18:14:32 -0700 (PDT) In-Reply-To: References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> Date: Wed, 2 Sep 2009 21:14:32 -0400 X-Google-Sender-Auth: 60acffd507fa1fed Message-ID: From: Justin Hibbits To: James Butler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD CURRENT Mailing List , Nick Hibma , Robert Noland Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 01:14:33 -0000 On Wed, Sep 2, 2009 at 8:39 PM, James Butler wrote: > 2009/9/3 Nick Hibma : > >> What is irrelevant is subjective... I mean does the average user really > >> need to see anything in dmesg? Please don't change agp_i810.c. A > >> verbose boot is incredibly noisy and rarely needed for debugging > >> anything except the most deep rooted of issues. > > > > Please state arguments instead of this 'I think it is useful'. That's not > > going to cut it. If you feel strongly about the info that is being > produced, > > an option would be to produce a (tested!) patch that combines more > > information on one line as a compromise. > > > > FreeBSD has historically been producing very limited output on dmesg. > Linux > > is very noisy (ever noticed the copyright notices right in the middle of > > your list of PCI devices?). Even they have decided that they should hide > > this behind coloured 'ok/failed' texts in some distributions. > > This seems like an important distinction - the information which needs > to be available with dmesg and the information best shown to the user > at startup are not necessarily the same. The hypothetical "average > user" probably wouldn't care if there were *no* kernel messages shown > on startup. The Xubuntu box I'm writing this from shows only GRUB > messages before the login prompt on tty1, and only service startup > messages on tty8 (not to suggest that FreeBSD ought to be more like > Ubuntu...). > > IOW, why bother painting it at all? Plain galvanized steel is very > durable, and quite attractive when kept clean ;-) > > -James Butler > Doesn't the 'boot_mute' (loader) environment variable do just that? >From the man page: boot_mute All console output is suppressed when console is muted. In a running system, the state of console muting can be manipulated by the conscontrol(8) utility. - Justin From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 05:01: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 62A2C106568D for ; Thu, 3 Sep 2009 05:01:54 +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 36CA48FC14 for ; Thu, 3 Sep 2009 05:01:53 +0000 (UTC) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n8351ro5018309; Wed, 2 Sep 2009 22:01:53 -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 5fi5jnpa3jupnb2h3cwhvqpqma; Wed, 02 Sep 2009 22:01:53 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4A9F4DC1.4010002@freebsd.org> Date: Wed, 02 Sep 2009 22:01:53 -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: Astrodog References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> <2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com> In-Reply-To: <2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 05:01:54 -0000 >> FreeBSD has historically been producing very limited output on dmesg. Linux >> is very noisy (ever noticed the copyright notices right in the middle of >> your list of PCI devices?). Even they have decided that they should hide >> this behind coloured 'ok/failed' texts in some distributions. > > I think this speaks more towards needing something between "Very > Quiet" and "Give me everything every developer has ever wanted to know > enough to include a print for it." Other possibilities: * Provide a per-driver control to determine verbosity. That would make it easier for developers who really do want to see "everything there is to know in my part of the world". * Put more information into the kernel buffers (and from there into dmesg) and less on the screen. That would reduce visible boot verbosity while retaining the post-hoc debugging value of dmesg(1). Cheers, Tim From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 07:56: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 0D3E1106566B for ; Thu, 3 Sep 2009 07:56:44 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id DA1508FC18 for ; Thu, 3 Sep 2009 07:56:43 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Mj7BT-00034S-2F for freebsd-current@freebsd.org; Thu, 03 Sep 2009 00:56:43 -0700 Message-ID: <25271366.post@talk.nabble.com> Date: Thu, 3 Sep 2009 00:56:43 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <4A9EA17C.2020204@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <4A9E8F8A.1010004@icyb.net.ua> <4A9EA17C.2020204@FreeBSD.org> Subject: Re: ahci cd0 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: Thu, 03 Sep 2009 07:56:44 -0000 Alexander Motin-3 wrote: > > Andriy Gapon wrote: >> k3b did "something" to my cd0 while tasting it and after that IDE >> activity LED was >> constantly on and I got a never-ending stream of messages like the >> following: >> >> ahcich5: Timeout on slot 25 >> ahcich5: Timeout on slot 26 >> ahcich5: Timeout on slot 29 >> ahcich5: Timeout on slot 30 >> ahcich5: Timeout on slot 1 >> ahcich5: Timeout on slot 2 >> ahcich5: Timeout on slot 5 >> ahcich5: Timeout on slot 6 >> ahcich5: Timeout on slot 9 >> ahcich5: Timeout on slot 10 >> ... >> and so on. >> cd0 is on ahcich5. >> >> This is head r196558. > > I don't know what initially caused the problem, but new ATA-CAM > infrastructure is still lacks of proper timeout error recovery. It is > not easy part, but I am working on it. > > -- > Alexander Motin > _______________________________________________ > 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" > > Hello. One more thing, smartmontools also refuse to work. (non ATA/ATAPI device) All ports I mentioned were rebuilt. As it's WIP, I understand that this should be expected. -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/ahci-cd0-issue-tp25259873p25271366.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 09:03: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 36A9E106566B for ; Thu, 3 Sep 2009 09:03:53 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id 10B918FC13 for ; Thu, 3 Sep 2009 09:03:52 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1Mj8ES-0005ZU-6I for freebsd-current@freebsd.org; Thu, 03 Sep 2009 02:03:52 -0700 Message-ID: <25272244.post@talk.nabble.com> Date: Thu, 3 Sep 2009 02:03:52 -0700 (PDT) From: Jakub Lach To: freebsd-current@freebsd.org In-Reply-To: <25265998.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: jakub_lach@mailplus.pl References: <4A9E8F8A.1010004@icyb.net.ua> <4A9EA17C.2020204@FreeBSD.org> <25265998.post@talk.nabble.com> Subject: Re: ahci cd0 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: Thu, 03 Sep 2009 09:03:53 -0000 Jakub Lach wrote: > > > cdda2wav as well.. > > cdda2wav: Error 0. inquiry: scsi sendcmd: fatal error > CDB: 12 E0 00 00 24 00 > cmd finished after 0.000s timeout 60s > Inquiry command failed. Aborting... > My fault, cooked icotl is not working, with -D 1,0,0 cdda2wav works. -best regards, Jakub Lach -- View this message in context: http://www.nabble.com/ahci-cd0-issue-tp25259873p25272244.html Sent from the freebsd-current mailing list archive at Nabble.com. From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 09:30: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 8C716106566B; Thu, 3 Sep 2009 09:30:52 +0000 (UTC) (envelope-from nick-lists@netability.ie) Received: from mail.acquirer.com (mail.acquirer.com [87.198.142.193]) by mx1.freebsd.org (Postfix) with ESMTP id 128A28FC15; Thu, 3 Sep 2009 09:30:51 +0000 (UTC) X-Envelope-To: freebsd-current@freebsd.org Received: from cupcake.internal.acquirer.com (cupcake.internal.acquirer.com [10.228.100.105]) (authenticated bits=0) by mail.acquirer.com (8.14.3/8.14.3) with ESMTP id n839Ul5m023882 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 10:30:47 +0100 (IST) (envelope-from nick-lists@netability.ie) Message-ID: <4A9F8CC7.7020907@netability.ie> Date: Thu, 03 Sep 2009 10:30:47 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <4A9BF438.1000006@smeets.im> <200909011002.59592.jhb@freebsd.org> <4A9E5D4B.1020801@netability.ie> In-Reply-To: <4A9E5D4B.1020801@netability.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 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 muffin.acquirer.com Cc: freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 09:30:52 -0000 On 02/09/2009 12:55, Nick Hilliard wrote: > hmmm, the box won't boot when i use mcfg=1. I'll take a look at the > console message tomorrow or friday. meh, setting hw.pci.mcfg=1 on 7-stable changes the disk labels so that the machine crashes out into mountroot>. However it also kills the keyboard, meaning I can't manually mount the root fs. Nick From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 09:38: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 3B8C3106566C; Thu, 3 Sep 2009 09:38:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 136BA8FC12; Thu, 3 Sep 2009 09:38:21 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id B600B46B29; Thu, 3 Sep 2009 05:38:20 -0400 (EDT) Date: Thu, 3 Sep 2009 10:38:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Tim Kientzle In-Reply-To: <4A9F4DC1.4010002@freebsd.org> Message-ID: References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> <2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com> <4A9F4DC1.4010002@freebsd.org> 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@freebsd.org, Astrodog Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 09:38:21 -0000 On Wed, 2 Sep 2009, Tim Kientzle wrote: >>> FreeBSD has historically been producing very limited output on dmesg. >>> Linux is very noisy (ever noticed the copyright notices right in the >>> middle of your list of PCI devices?). Even they have decided that they >>> should hide this behind coloured 'ok/failed' texts in some distributions. >> >> I think this speaks more towards needing something between "Very Quiet" and >> "Give me everything every developer has ever wanted to know enough to >> include a print for it." > > Other possibilities: > > * Provide a per-driver control to determine verbosity. That would make it > easier for developers who really do want to see "everything there is to know > in my part of the world". > > * Put more information into the kernel buffers (and from there into dmesg) > and less on the screen. That would reduce visible boot verbosity while > retaining the post-hoc debugging value of dmesg(1). It's clear that part of the problem we're dealing with here is that dmesg remains the authoritative source for certain kinds of data that really should be in a machine-readable/reportable format. devinfo(8) captures some of this, but can't, for example, cleanly represent an IRQ being shared by multiple devices, and doesn't capture a lot of the device-driver specific data that appears in dmesg. dmesg is a useful log of events, and I'm not saying we should omit information there, but when inspecting the current state of the system, the kernel has a lot of information and it would be nice if more of it were accessible in userspace. To my mind, the main reason to look at dmesg should be to find out about *failed* device attaches, where there most likely won't be persisting state in the kernel, but the debugging information is invaluable. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 15:11: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 03C46106568D for ; Thu, 3 Sep 2009 15:11:24 +0000 (UTC) (envelope-from unixwind@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.freebsd.org (Postfix) with ESMTP id B96BD8FC13 for ; Thu, 3 Sep 2009 15:11:23 +0000 (UTC) Received: by an-out-0708.google.com with SMTP id d14so714067and.13 for ; Thu, 03 Sep 2009 08:11:22 -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; bh=X5Y3wsPy/4LihxUp6hjCJB/PtWbHWBJu8uo6m/WuuSo=; b=vdyUrEQWmVfehEMUUVFr6BJ+5E9+/V8wIvHmRzo9HDlVMxGwyyOOvfUPDpF0yn49C+ uNR8J6JGymmM5cHZoLfgdACQskcpieIrLD5dyiW3oHKVVrQi7Q48eAJrC746kyF9mATo MmCW6UqbnzyjRNMh0SN75uQcmRBo8hW4TpCHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=nuZ30gDzHJ21k6M8jlyX1HrsRbBEkoKMJJMv42W9DpVXTnsW7LfYhM5oZO26zQyo5I t61WM5eS/6AJwbbC7O7ory7q6W+chXLCqLDr2hcVwGFAKMwTNZP1wIewun7pRBIeZW79 msIN+IlGVHs4j42by3CxXehgLBE64B1W3Bxlk= MIME-Version: 1.0 Received: by 10.101.15.9 with SMTP id s9mr10936202ani.81.1251989310065; Thu, 03 Sep 2009 07:48:30 -0700 (PDT) Date: Thu, 3 Sep 2009 22:48:30 +0800 Message-ID: <260f7f810909030748q7cb0878bq6f1b3fb3fbae307a@mail.gmail.com> From: Felix Feng To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: WEP can not work on mwl 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: Thu, 03 Sep 2009 15:11:24 -0000 Hi, I'm trying mwl driver on FreeBSD current. But its WEP encryption does not work well. When I connect to a WEP AP, the driver can not get IP under DHCP and static IP does not work. Does anyone has the same issue as me? ------ Regards, Felix From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 15:25: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 AE702106568D for ; Thu, 3 Sep 2009 15:25:14 +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 57D2C8FC08 for ; Thu, 3 Sep 2009 15:25:13 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA04540; Thu, 03 Sep 2009 18:25:10 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A9FDFD6.2090305@icyb.net.ua> Date: Thu, 03 Sep 2009 18:25:10 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: Robert Watson References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> <2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com> <4A9F4DC1.4010002@freebsd.org> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Tim Kientzle , Astrodog Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 15:25:14 -0000 on 03/09/2009 12:38 Robert Watson said the following: [snip] > devinfo(8) > captures some of this, but can't, for example, cleanly represent an IRQ > being shared by multiple devices [snip] Minor technical nit - devinfo can actually do it (since r192379). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 15:46: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 14672106568D; Thu, 3 Sep 2009 15:46:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D4A1D8FC1A; Thu, 3 Sep 2009 15:46:58 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 8A93346B03; Thu, 3 Sep 2009 11:46:58 -0400 (EDT) Date: Thu, 3 Sep 2009 16:46:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andriy Gapon In-Reply-To: <4A9FDFD6.2090305@icyb.net.ua> Message-ID: References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> <2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com> <4A9F4DC1.4010002@freebsd.org> <4A9FDFD6.2090305@icyb.net.ua> 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@FreeBSD.org, Tim Kientzle , Astrodog Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 15:46:59 -0000 University of Cambridge On Thu, 3 Sep 2009, Andriy Gapon wrote: > on 03/09/2009 12:38 Robert Watson said the following: [snip] >> devinfo(8) captures some of this, but can't, for example, cleanly represent >> an IRQ being shared by multiple devices > [snip] > > Minor technical nit - devinfo can actually do it (since r192379). I stand pleasantly corrected :-). However, I think the point holds: we're relying on dmesg as the authoritative source of hardware discovery/probe information, and really, we should be using some more structured way of delivering that information, generic or device-specific. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 15:54: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 EC7F8106568D; Thu, 3 Sep 2009 15:54:20 +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 04F2A8FC08; Thu, 3 Sep 2009 15:54:19 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA04877; Thu, 03 Sep 2009 18:54:18 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4A9FE6A9.2070009@icyb.net.ua> Date: Thu, 03 Sep 2009 18:54:17 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.22 (X11/20090724) MIME-Version: 1.0 To: Robert Watson References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> <2fd864e0909021645p735e22b8id7d41f4b5a0ee89e@mail.gmail.com> <4A9F4DC1.4010002@freebsd.org> <4A9FDFD6.2090305@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 15:54:21 -0000 on 03/09/2009 18:46 Robert Watson said the following: > I stand pleasantly corrected :-). However, I think the point holds: > we're relying on dmesg as the authoritative source of hardware > discovery/probe information, and really, we should be using some more > structured way of delivering that information, generic or device-specific. Yes, I do agree. And - I can't explain why - this conversation reminded me of the sensors framework project. I expect a long discussion on the structure and access mechanism for such information. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 17:36: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 07A02106566B for ; Thu, 3 Sep 2009 17:36:50 +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 BC8828FC0C for ; Thu, 3 Sep 2009 17:36:49 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n83Ham84034494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 10:36:49 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A9FFEB0.4000201@errno.com> Date: Thu, 03 Sep 2009 10:36:48 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Felix Feng References: <260f7f810909030748q7cb0878bq6f1b3fb3fbae307a@mail.gmail.com> In-Reply-To: <260f7f810909030748q7cb0878bq6f1b3fb3fbae307a@mail.gmail.com> 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 Subject: Re: WEP can not work on mwl 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: Thu, 03 Sep 2009 17:36:50 -0000 Felix Feng wrote: > Hi, > > I'm trying mwl driver on FreeBSD current. But its WEP encryption does not > work well. When I connect to a WEP AP, the driver can not get IP under DHCP > and static IP does not work. Does anyone has the same issue as me? I doubt anyone else has a card. Please contact me off-line w/ the steps to reproduce the problem. There's also some tools in tools/tools/mwl that you might find useful in debugging. Sam From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 17:37: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 5BF42106568F; Thu, 3 Sep 2009 17:37:59 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id DE62B8FC17; Thu, 3 Sep 2009 17:37:58 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MjGFw-0006n2-TL; Thu, 03 Sep 2009 19:37:57 +0200 Message-ID: <4A9FFEF0.1000502@gwdg.de> Date: Thu, 03 Sep 2009 19:37:52 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <200909011505.32243.jhb@freebsd.org> <4A9D86C9.1020603@gwdg.de> <200909011717.57386.jhb@freebsd.org> In-Reply-To: <200909011717.57386.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 17:37:59 -0000 On 01.09.2009 23:17 (UTC+2), John Baldwin wrote: > On Tuesday 01 September 2009 4:40:41 pm Rainer Hurling wrote: >> On 01.09.2009 21:05 (UTC+2), John Baldwin wrote: >>> On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote: >>>> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote: >>>>> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote: >>>>>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote: >>>>>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote: >>>>>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode >>> (bios >>>>>>>>> doesn't appear to give the option to use AHCI). On freebsd 7.x, all >>>>>>>>> channels are detected. On freebsd8.0-beta3, the disks attached to > the >>>>>>>>> first two SATA ports are not detected, although it detects the ports >>>>>>>>> themselves. >>>>>>>>> >>>>>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. >>>>>>>>> >>>>>>>>> Any ideas on what's going on here? This seems like a nasty >>> regression. >>>>>>>> There are 3 PRs about this problem: 128686, 132372, 137942. >>>>>>>> >>>>>>>> i386 version should recognize the disks. amd64 does when you set >>>>>>>> hw.pci.mcfg=0 in loader.conf. >>>>>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config >>>>> space >>>>>>> for the disk controller in the MCFG vs non-MCFG cases? That is, find >>> the >>>>>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and >>>>> then >>>>>>> run this command under both configurations and save the output: >>>>>>> >>>>>>> pciconf -r pci0:0:30:0 0:0xfc >>>>>>> >>>>>> I am not sure if your idea has something to do with my (and some other >>>>>> users) problem. So excuse me, if this posting is wrong. >>>>>> >>>>>> For some month now I am only able to boot CURRENT under amd64 with >>>>>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output >>>>>> under i386 and under amd64. Perhaps you are able to get a hint? >>>>> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using > nfsroot >>> or >>>>> an mfsroot) and capture this output? The mcfg thing only affects access >>> to >>>>> PCI config space (what pciconf -r is displaying). I want to be able to >>>>> compare the "broken" case (amd64 mcfg=1) with a working case. >>>> My only amd64 system is at home. Sorry, but I have no idea how to start >>>> this system using nfsroot oder mfsroot. >>> Ok, I believe some of the other folks reporting an issue with this ATA >>> controller had other disk controllers in the system so they may be able to > do >>> this. >> Thanks to Kostik Belousov, I tried his hint with live CD. Here it is, >> only for amd64, with snapshot from todays CURRENT: >> >> #systctl hw.pci.mcfg >> hw.pci.mcfg: 1 > > Hmm, this one is identical to the mcfg=0 one on amd64 (except for a few values > that also differ between the working i386 and working amd64). So it doesn't > seem that PCI config access is horribly broken. :( Perhaps someone can spend > some time comparing what the driver does in the two cases with some printfs > to see when it starts behaving differently during its attach routine to help > narrow this down. > Is there any meaning in the differences of pciconf -lv output of i386 and amd64 (already shown in older postings)? ------------------------------------------- i386: atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA/RAID Controller (MCP55S)' class = mass storage subclass = ATA atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de rev=0xa2 hdr=0x00 vendor = 'Nvidia Corp' device = 'MCP55 SATA/RAID Controller (MCP55S)' class = mass storage subclass = ATA ------------------------------------------- amd64: atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de rev=0xa2 hdr=0x00 class = mass storage subclass = ATA atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de rev=0xa2 hdr=0x00 class = mass storage subclass = ATA ------------------------------------------- In the amd64 version there is no vendor and device string. Perhaps a problem of reading or interpreting? Rainer Hurling From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 18:01: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 854F61065679 for ; Thu, 3 Sep 2009 18:01:13 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: from n11b.bullet.mail.mud.yahoo.com (n11b.bullet.mail.mud.yahoo.com [209.191.125.178]) by mx1.freebsd.org (Postfix) with SMTP id 46F2F8FC17 for ; Thu, 3 Sep 2009 18:01:13 +0000 (UTC) Received: from [68.142.200.224] by n11.bullet.mail.mud.yahoo.com with NNFMP; 03 Sep 2009 17:47:22 -0000 Received: from [68.142.201.64] by t5.bullet.mud.yahoo.com with NNFMP; 03 Sep 2009 17:47:22 -0000 Received: from [127.0.0.1] by omp416.mail.mud.yahoo.com with NNFMP; 03 Sep 2009 17:47:22 -0000 X-Yahoo-Newman-Id: 426647.14493.bm@omp416.mail.mud.yahoo.com Received: (qmail 82029 invoked from network); 3 Sep 2009 17:47:22 -0000 Received: from unknown (HELO soul.local.inet) (webmaster@69.109.45.163 with plain) by smtp101.sbc.mail.sp1.yahoo.com with SMTP; 3 Sep 2009 17:47:21 -0000 X-YMail-OSG: 0Kgy8akVM1kbETtTyejLU4yPBkNupcaJHzuIQJoPXnzKPYtpZYM0UppUmhAI4Pb1.nxiZeymDiXfEz_3Cau_rNakuofa99pcNIqLwSwxWTTaZb_TKs36OFLB0xN028JobJXAN_CPMCIfo73mtN8O2yhj_a6Mt8ZFtPC1EoQXGYcEGGVYOGrwWbCvzWET._WO1cgKwS9J5DyamcXFSHxAm.xG0OQFJT0oWho- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AA00128.5030008@doghouserepair.com> Date: Thu, 03 Sep 2009 10:47:20 -0700 From: Ryan Rogers User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 18:01:13 -0000 I'm having a bit of a problem getting my DVD drive(s) to work correctly. I'm trying to transfer my DVD collection to my media server, but whenever I run vobcopy, /var/log/messages gets spammed with: acd0: FAILURE - non aligned DMA transfer attempted acd0: setting up DMA failed I added a bit more information to the first message to see if I could figure out what was actually going on. request->data was 0xd40e0c37, ch->dma.alignment was 2, and request->bytecount was 2048. My first guess was that my DVD drive was starting to flake out, so I bought another one in the hopes that it would fix it, but that wasn't the problem. The drives that I've tried are: DVDR at ata0-slave UDMA33 DVDR at ata6-master SATA150 The ata controllers are detected as: atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xec00-0xec0f at device 13.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd800-0xd80f mem 0xcfffd000-0xcfffdfff irq 20 at device 14.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc400-0xc40f mem 0xcfffc000-0xcfffcfff irq 21 at device 14.1 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] atapci3: port 0xc000-0xc007,0xbc00-0xbc03,0xb800-0xb807,0xb400-0xb403,0xb000-0xb00f mem 0xcfffb000-0xcfffbfff irq 20 at device 14.2 on pci0 atapci3: [ITHREAD] ata6: on atapci3 ata6: [ITHREAD] ata7: on atapci3 ata7: [ITHREAD] Setting hw.ata.ata_dma and hw.ata.atapi_dma to 0 doesn't help any. General drive usage (browsing through the contents of the DVD, watching a movie with VLC) doesn't give the DMA errors. I'm currently using 8.0-BETA3 r196774 i386. Any suggestions? Ryan From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 18:13: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 0AD131065672 for ; Thu, 3 Sep 2009 18:13:58 +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 856078FC18 for ; Thu, 3 Sep 2009 18:13:57 +0000 (UTC) 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 253380192; Thu, 03 Sep 2009 21:13:53 +0300 Message-ID: <4AA0075A.5010109@FreeBSD.org> Date: Thu, 03 Sep 2009 21:13:46 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Emil Mikulic References: <4A9E8677.1020208@FreeBSD.org> <20090903002106.GB17538@dmr.ath.cx> In-Reply-To: <20090903002106.GB17538@dmr.ath.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Derek \(freebsd lists\)" <482254ac@razorfever.net>, FreeBSD-Current Subject: gmirror 'load' algorithm (Was: Re: siis/atacam/ata/gmirror 8.0-BETA3 disk performance) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 18:13:58 -0000 Emil Mikulic wrote: > On Wed, Sep 02, 2009 at 05:51:35PM +0300, Alexander Motin wrote: >> To completely load gmirror on read operations, you may need to run >> two dd's same time. Also make sure, that your gmirror runs in >> round-robin mode. Default split mode, which should help with linear >> read, is IMHO ineffective, at least with default MAXPHYS and slice >> values. > > On that note, there is an excellent patch in this PR which improves > the way gmirror schedules read requests to different disks: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/113885 > > Could someone please commit this? > > With this patch and a two-way mirror, I can run two linear scans of > different files in parallel and get almost perfect scaling. (result: > this approximately halves the wall-clock time it takes to do a backup of > some fat VM images) > > IIRC, without the patch it's faster to run them sequentially. :( I have played a bit with this patch on 4-disk mirror. It works better then original algorithm, but still not perfect. 1. I have managed situation with 4 read streams when 3 drives were busy, while forth one was completely idle. gmirror prefer constantly seek one of drives on short distances, but not to use idle drive, because it's heads were few gigabytes away from that point. IMHO request locality priority should be made almost equal for any nonzero distances. As we can see with split mode, even small gaps between requests can significantly reduce drive performance. So I think it is not so important if data are 100MB or 500GB away from current head position. It is perfect case when requests are completely sequential. But everything beyond few megabytes from current position just won't fit drive cache. 2. IMHO it would be much better to use averaged request queue depth as load measure, instead of last request submit time. Request submit time works fine only for equal requests, equal drives and serialized load, but it is actually the case where complicated load balancing is just not needed. The fact that some drive just got request does not mean anything, if some another one got 50 requests one second ago and still processes them. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 18:38: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 5C6C4106566C for ; Thu, 3 Sep 2009 18:38:42 +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 2BF368FC0C for ; Thu, 3 Sep 2009 18:38:42 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id D261C46B03; Thu, 3 Sep 2009 14:38:41 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 004948A049; Thu, 3 Sep 2009 14:38:41 -0400 (EDT) From: John Baldwin To: Rainer Hurling Date: Thu, 3 Sep 2009 14:01:08 -0400 User-Agent: KMail/1.9.7 References: <4A9BF23F.6070801@netability.ie> <200909011717.57386.jhb@freebsd.org> <4A9FFEF0.1000502@gwdg.de> In-Reply-To: <4A9FFEF0.1000502@gwdg.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909031401.08825.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 03 Sep 2009 14:38:41 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.6 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: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 18:38:42 -0000 On Thursday 03 September 2009 1:37:52 pm Rainer Hurling wrote: > On 01.09.2009 23:17 (UTC+2), John Baldwin wrote: > > On Tuesday 01 September 2009 4:40:41 pm Rainer Hurling wrote: > >> On 01.09.2009 21:05 (UTC+2), John Baldwin wrote: > >>> On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote: > >>>> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote: > >>>>> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote: > >>>>>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote: > >>>>>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote: > >>>>>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode > >>> (bios > >>>>>>>>> doesn't appear to give the option to use AHCI). On freebsd 7.x, all > >>>>>>>>> channels are detected. On freebsd8.0-beta3, the disks attached to > > the > >>>>>>>>> first two SATA ports are not detected, although it detects the ports > >>>>>>>>> themselves. > >>>>>>>>> > >>>>>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. > >>>>>>>>> > >>>>>>>>> Any ideas on what's going on here? This seems like a nasty > >>> regression. > >>>>>>>> There are 3 PRs about this problem: 128686, 132372, 137942. > >>>>>>>> > >>>>>>>> i386 version should recognize the disks. amd64 does when you set > >>>>>>>> hw.pci.mcfg=0 in loader.conf. > >>>>>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI config > >>>>> space > >>>>>>> for the disk controller in the MCFG vs non-MCFG cases? That is, find > >>> the > >>>>>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) and > >>>>> then > >>>>>>> run this command under both configurations and save the output: > >>>>>>> > >>>>>>> pciconf -r pci0:0:30:0 0:0xfc > >>>>>>> > >>>>>> I am not sure if your idea has something to do with my (and some other > >>>>>> users) problem. So excuse me, if this posting is wrong. > >>>>>> > >>>>>> For some month now I am only able to boot CURRENT under amd64 with > >>>>>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed output > >>>>>> under i386 and under amd64. Perhaps you are able to get a hint? > >>>>> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using > > nfsroot > >>> or > >>>>> an mfsroot) and capture this output? The mcfg thing only affects access > >>> to > >>>>> PCI config space (what pciconf -r is displaying). I want to be able to > >>>>> compare the "broken" case (amd64 mcfg=1) with a working case. > >>>> My only amd64 system is at home. Sorry, but I have no idea how to start > >>>> this system using nfsroot oder mfsroot. > >>> Ok, I believe some of the other folks reporting an issue with this ATA > >>> controller had other disk controllers in the system so they may be able to > > do > >>> this. > >> Thanks to Kostik Belousov, I tried his hint with live CD. Here it is, > >> only for amd64, with snapshot from todays CURRENT: > >> > >> #systctl hw.pci.mcfg > >> hw.pci.mcfg: 1 > > > > Hmm, this one is identical to the mcfg=0 one on amd64 (except for a few values > > that also differ between the working i386 and working amd64). So it doesn't > > seem that PCI config access is horribly broken. :( Perhaps someone can spend > > some time comparing what the driver does in the two cases with some printfs > > to see when it starts behaving differently during its attach routine to help > > narrow this down. > > > > Is there any meaning in the differences of pciconf -lv output of i386 > and amd64 (already shown in older postings)? > > ------------------------------------------- > i386: > atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA/RAID Controller (MCP55S)' > class = mass storage > subclass = ATA > atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de > rev=0xa2 hdr=0x00 > vendor = 'Nvidia Corp' > device = 'MCP55 SATA/RAID Controller (MCP55S)' > class = mass storage > subclass = ATA > ------------------------------------------- > amd64: > atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de > rev=0xa2 hdr=0x00 > class = mass storage > subclass = ATA > atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de > rev=0xa2 hdr=0x00 > class = mass storage > subclass = ATA > ------------------------------------------- > > In the amd64 version there is no vendor and device string. Perhaps a > problem of reading or interpreting? No, the strings are pulled out of /usr/share/misc/pci_vendors based on the value in 'chip='. Since the 'chip=' values are identical it's probably just a matter of having different versions of the pci_vendors file. The only thing MCFG affects is how you read the 'chip=' number which are identical in the two cases. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 19:37: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 89CB3106568F for ; Thu, 3 Sep 2009 19:37:21 +0000 (UTC) (envelope-from lapo@lapo.it) Received: from mail.lapo.it (motoko.lapo.it [88.198.0.105]) by mx1.freebsd.org (Postfix) with ESMTP id E08E68FC12 for ; Thu, 3 Sep 2009 19:37:20 +0000 (UTC) Received: (qmail 68441 invoked by uid 89); 3 Sep 2009 19:10:39 -0000 Received: from host71-40-static.74-81-b.business.telecomitalia.it (HELO ?10.0.0.1?) (lapo@lapo.it@81.74.40.71) by 0 with ESMTPA; 3 Sep 2009 19:10:39 -0000 Message-ID: <4AA0149E.30209@lapo.it> Date: Thu, 03 Sep 2009 21:10:22 +0200 From: Lapo Luchini User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Martin Wilke References: <20090527134343.GB1104@bsdcrew.de> <85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com> <20090527163952.GI1104@bsdcrew.de> In-Reply-To: <20090527163952.GI1104@bsdcrew.de> X-Enigmail-Version: 0.96.0 OpenPGP: id=C8F252FB; url=http://www.lapo.it/pgpkey.txt Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigABD3E114924551AF40FD267C" Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, "M. Vale" Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 19:37:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigABD3E114924551AF40FD267C Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin Wilke wrote: >> /usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild/footer.kmk:2304: *= ** >> target file `virtualbox' has both : and :: entries. >> Stop . >> kmk: Leaving directory `/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1' >> gmake: *** >> [/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/out/freebsd.amd64/releas= e/bootstrap/ts-stage2-build] >> Error 2 >> ./kBuild/env.sh: info: rc=3D2: gmake -f bootstrap.gmk >> *** Error code 2 >=20 >> Stop in /usr/ports/devel/kBuild. >> " > > Please update to 7.2 or higher Errr, and what if I have that in a FreeBSD 7.2-STABLE? Any other ideas? (both on my i386 laptop and amd64 home-server) Strangely I can find nothing on Google for that, which seems to indicate very little people is trying VirtualBox on FreeBSD or both my unrelated and different boxes have got a "rare" bug =3D) (but of course they got more or less the same mix of ports installed, so they're not really unrelated one another) --=20 Lapo Luchini - http://lapo.it/ =E2=80=9C=E2=80=A6one of the main causes of the fall of the Roman Empire = was that, lacking zero, they had no way to indicate successful termination of their C programs.=E2=80=9D (Robert Firth) --------------enigABD3E114924551AF40FD267C 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 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJKoBSlAAoJELBiMTth2oCDWxcQAKGqt9y08atiOR389PqjDqoj PiXH4uR1/KNe3Y5PCMG26I91mpSPCSZVkV4C7iFWJ4QEgE9ygDRz0/zGCcjvBrI6 yMv5ZZBh0aro93O55Vp9GS5oVVn9D6sKoOHLw2bdnccU4/wO9X06BgUzh9QpFrbK 9I4mE0tK/JY944R7TEssth71BS6ligp/7jw5foHlD41qmg9ZYFudmrkQWhXFb9B3 MfjURuIBcNsaN9pOjniRVkjURPzV/zFJOYrml2DOxaJkPL3+uKFGidVLyvjvLsdy q1UzZGnZxVnF4TQROoGTmUUTvdc9saMjVI+uoaJ/o6U4Ox1I7wDbS0WiSlzajfL4 tkccU/wgNWD2u+Sqb54FCscGpTnHY9Vj251KWHuZ+XEAro9zqDHbjJM89d0pdtvN 00CkUP2GkcCV3p5u2XFk2qmS25nX508GwvPWMD179hyqOq5nZdloJcxnMyxKkaZM Jxa6Lzu6E0q/CZS03H1YHlyTrjvhLnsNXGDcQ4BppmvAZ/mlgAf6cWwJt/jIkKNC 4NuCry6hO1fHLpT1ERW8+AJmhw0q1r1cfKPrUVi+iQG8dTy0rbFcU+Wv8aF80bsh fdQh+H1UyTy3c0URCVwbjWbNamqVNMxkE5xs4NohWQ9Sc6G6xoKD0TgVGEHfZbgp 0uJ9fgxXvh69zZd6iNZl =05kV -----END PGP SIGNATURE----- --------------enigABD3E114924551AF40FD267C-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 19:40: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 9A8CA1065670; Thu, 3 Sep 2009 19:40:12 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 251FF8FC14; Thu, 3 Sep 2009 19:40:12 +0000 (UTC) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MjIAE-0007n9-3W; Thu, 03 Sep 2009 21:40:10 +0200 Message-ID: <4AA01B94.8000309@gwdg.de> Date: Thu, 03 Sep 2009 21:40:04 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: John Baldwin References: <4A9BF23F.6070801@netability.ie> <200909011717.57386.jhb@freebsd.org> <4A9FFEF0.1000502@gwdg.de> <200909031401.08825.jhb@freebsd.org> In-Reply-To: <200909031401.08825.jhb@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: 8.0-beta3 does not detect several ata channels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 19:40:12 -0000 On 03.09.2009 20:01 (UTC+2), John Baldwin wrote: > On Thursday 03 September 2009 1:37:52 pm Rainer Hurling wrote: >> On 01.09.2009 23:17 (UTC+2), John Baldwin wrote: >>> On Tuesday 01 September 2009 4:40:41 pm Rainer Hurling wrote: >>>> On 01.09.2009 21:05 (UTC+2), John Baldwin wrote: >>>>> On Tuesday 01 September 2009 2:49:09 pm Rainer Hurling wrote: >>>>>> On 01.09.2009 19:41 (UTC+2), John Baldwin wrote: >>>>>>> On Tuesday 01 September 2009 12:47:50 pm Rainer Hurling wrote: >>>>>>>> On 01.09.2009 16:02 (UTC+2), John Baldwin wrote: >>>>>>>>> On Monday 31 August 2009 12:03:04 pm Florian Smeets wrote: >>>>>>>>>> On 8/31/09 5:54 PM, Nick Hilliard wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I have a hp proliant ML115 with 6 sata ports which run in ATA mode >>>>> (bios >>>>>>>>>>> doesn't appear to give the option to use AHCI). On freebsd 7.x, > all >>>>>>>>>>> channels are detected. On freebsd8.0-beta3, the disks attached to >>> the >>>>>>>>>>> first two SATA ports are not detected, although it detects the > ports >>>>>>>>>>> themselves. >>>>>>>>>>> >>>>>>>>>>> I've attached a verbose dmesg from freebsd 7.1 and 8.0-beta3. >>>>>>>>>>> >>>>>>>>>>> Any ideas on what's going on here? This seems like a nasty >>>>> regression. >>>>>>>>>> There are 3 PRs about this problem: 128686, 132372, 137942. >>>>>>>>>> >>>>>>>>>> i386 version should recognize the disks. amd64 does when you set >>>>>>>>>> hw.pci.mcfg=0 in loader.conf. >>>>>>>>> Hmm, so an idea I had just now.. can you grab a dump of the PCI > config >>>>>>> space >>>>>>>>> for the disk controller in the MCFG vs non-MCFG cases? That is, > find >>>>> the >>>>>>>>> device's address using pciconf -lv (e.g. pci0:0:30:0 or some such) > and >>>>>>> then >>>>>>>>> run this command under both configurations and save the output: >>>>>>>>> >>>>>>>>> pciconf -r pci0:0:30:0 0:0xfc >>>>>>>>> >>>>>>>> I am not sure if your idea has something to do with my (and some > other >>>>>>>> users) problem. So excuse me, if this posting is wrong. >>>>>>>> >>>>>>>> For some month now I am only able to boot CURRENT under amd64 with >>>>>>>> setting hw.pci.mcfg=0. Under i386 all works fine. Below I listed > output >>>>>>>> under i386 and under amd64. Perhaps you are able to get a hint? >>>>>>> Hmm, would you be able to boot with mcfg=1 on amd64 (perhaps using >>> nfsroot >>>>> or >>>>>>> an mfsroot) and capture this output? The mcfg thing only affects > access >>>>> to >>>>>>> PCI config space (what pciconf -r is displaying). I want to be able > to >>>>>>> compare the "broken" case (amd64 mcfg=1) with a working case. >>>>>> My only amd64 system is at home. Sorry, but I have no idea how to start >>>>>> this system using nfsroot oder mfsroot. >>>>> Ok, I believe some of the other folks reporting an issue with this ATA >>>>> controller had other disk controllers in the system so they may be able > to >>> do >>>>> this. >>>> Thanks to Kostik Belousov, I tried his hint with live CD. Here it is, >>>> only for amd64, with snapshot from todays CURRENT: >>>> >>>> #systctl hw.pci.mcfg >>>> hw.pci.mcfg: 1 >>> Hmm, this one is identical to the mcfg=0 one on amd64 (except for a few > values >>> that also differ between the working i386 and working amd64). So it > doesn't >>> seem that PCI config access is horribly broken. :( Perhaps someone can > spend >>> some time comparing what the driver does in the two cases with some > printfs >>> to see when it starts behaving differently during its attach routine to > help >>> narrow this down. >>> >> Is there any meaning in the differences of pciconf -lv output of i386 >> and amd64 (already shown in older postings)? >> >> ------------------------------------------- >> i386: >> atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de >> rev=0xa2 hdr=0x00 >> vendor = 'Nvidia Corp' >> device = 'MCP55 SATA/RAID Controller (MCP55S)' >> class = mass storage >> subclass = ATA >> atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de >> rev=0xa2 hdr=0x00 >> vendor = 'Nvidia Corp' >> device = 'MCP55 SATA/RAID Controller (MCP55S)' >> class = mass storage >> subclass = ATA >> ------------------------------------------- >> amd64: >> atapci1@pci0:0:5:0: class=0x010185 card=0x72601462 chip=0x037f10de >> rev=0xa2 hdr=0x00 >> class = mass storage >> subclass = ATA >> atapci2@pci0:0:5:1: class=0x010185 card=0x72601462 chip=0x037f10de >> rev=0xa2 hdr=0x00 >> class = mass storage >> subclass = ATA >> ------------------------------------------- >> >> In the amd64 version there is no vendor and device string. Perhaps a >> problem of reading or interpreting? > > No, the strings are pulled out of /usr/share/misc/pci_vendors based on the > value in 'chip='. Since the 'chip=' values are identical it's probably just > a matter of having different versions of the pci_vendors file. The only > thing MCFG affects is how you read the 'chip=' number which are identical in > the two cases. > OK, I see. But on my system there are absolutely no differences between /usr/share/misc/pci_vendors of i386 and amd64. From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 20: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 55C331065672; Thu, 3 Sep 2009 20:14:48 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by mx1.freebsd.org (Postfix) with ESMTP id CD2A98FC1B; Thu, 3 Sep 2009 20:14:47 +0000 (UTC) Received: by vws27 with SMTP id 27so257336vws.3 for ; Thu, 03 Sep 2009 13: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; bh=fnq7WyorOcz6KP0dAAgj9hCIG6sO87qNDPbSfh7G4ZU=; b=YtCAv/q0mrLLU0HWOVshJoTS9df8tisIZwEWeqnQj8jrLr+mEvCBPZuP1jdkTujGo2 akFxNH5h4s6eWIvqvdRKzxfK2a8gtzoFMVZhvCQFuxv995JfMCnTuGwsYq80clEY2gkh EkjmNGrIdQ/jygaM2TSHr8Xc7W9GrVMP9By7o= 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=jV5fDgOTeiyhOy8in9A7Jmh6U7wew8J5PEn7WBffJBwZeLRpiKxfV2zKzAdIJa+VsZ XuhfXDt6KlcSDOWPkcS8pJYEVP6p4KIef4nTc9i+YYBJf+5qLOlGvgAxaJCrysebpXxE ZshOBynlZwevrtWiv3ncGYQJMTCE0l1rYXtyg= MIME-Version: 1.0 Received: by 10.150.132.19 with SMTP id f19mr16909243ybd.83.1252007566848; Thu, 03 Sep 2009 12:52:46 -0700 (PDT) In-Reply-To: <4AA0149E.30209@lapo.it> References: <20090527134343.GB1104@bsdcrew.de> <85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com> <20090527163952.GI1104@bsdcrew.de> <4AA0149E.30209@lapo.it> Date: Thu, 3 Sep 2009 14:52:46 -0500 Message-ID: <6201873e0909031252r41bced2eqe1784a17214f1cd1@mail.gmail.com> From: Adam Vande More To: Lapo Luchini Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, "M. Vale" , Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 20:14:48 -0000 On Thu, Sep 3, 2009 at 2:10 PM, Lapo Luchini wrote: > Martin Wilke wrote: > >> /usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild/footer.kmk:2304: *= ** > >> target file `virtualbox' has both : and :: entries. > >> Stop . > >> kmk: Leaving directory `/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1' > >> gmake: *** > >> > [/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/out/freebsd.amd64/release/b= ootstrap/ts-stage2-build] > >> Error 2 > >> ./kBuild/env.sh: info: rc=3D2: gmake -f bootstrap.gmk > >> *** Error code 2 > > > >> Stop in /usr/ports/devel/kBuild. > >> " > > > > Please update to 7.2 or higher > > Errr, and what if I have that in a FreeBSD 7.2-STABLE? > Any other ideas? (both on my i386 laptop and amd64 home-server) > > Strangely I can find nothing on Google for that, which seems to indicate > very little people is trying VirtualBox on FreeBSD or both my unrelated > and different boxes have got a "rare" bug =3D) > > (but of course they got more or less the same mix of ports installed, so > they're not really unrelated one another) > > -- > Lapo Luchini - http://lapo.it/ > > =93=85one of the main causes of the fall of the Roman Empire was that, > lacking zero, they had no way to indicate successful termination of > their C programs.=94 (Robert Firth) > > Are you using portmaster to build virtualbox? --=20 Adam Vande More From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 21:21: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 B1963106566B for ; Thu, 3 Sep 2009 21:21:20 +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 3D2538FC14 for ; Thu, 3 Sep 2009 21:21:19 +0000 (UTC) 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 253385679; Fri, 04 Sep 2009 00:21:17 +0300 Message-ID: <4AA03346.5010608@FreeBSD.org> Date: Fri, 04 Sep 2009 00:21:10 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Ryan Rogers , current@FreeBSD.org References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 21:21:20 -0000 Ryan Rogers wrote: > I'm having a bit of a problem getting my DVD drive(s) to work correctly. > I'm trying to transfer my DVD collection to my media server, but > whenever I run vobcopy, /var/log/messages gets spammed with: > > acd0: FAILURE - non aligned DMA transfer attempted > acd0: setting up DMA failed > > I added a bit more information to the first message to see if I could > figure out what was actually going on. request->data was 0xd40e0c37, > ch->dma.alignment was 2, and request->bytecount was 2048. Actually I don't understand what for this check was made there. It is busdma infrastructure business to implement buffer bouncing to manage requested alignment. But this check enforces application level to bother with this. Usually it works fine, as memory often allocated aligned. But probably here is some specifics in your application. Could you try to just to comment-out that request->data check? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 22:20:46 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 BB3871065670 for ; Thu, 3 Sep 2009 22:20:46 +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 9451C8FC18 for ; Thu, 3 Sep 2009 22:20:46 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n83MA6NO059074; Thu, 3 Sep 2009 15:10:07 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n83MA67F059073; Thu, 3 Sep 2009 15:10:06 -0700 (PDT) Date: Thu, 3 Sep 2009 15:10:06 -0700 (PDT) From: Matthew Dillon Message-Id: <200909032210.n83MA67F059073@apollo.backplane.com> To: Alexander Motin References: <4AA03346.5010608@FreeBSD.org> Cc: Ryan Rogers , current@freebsd.org Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 22:20:46 -0000 This is a known problem with physio and/or the ATA driver, depending on your viewpoint. See kern/kern_physio.c. The physio code directly maps the userland buffer via vmapbuf() and supplies it as a BIO to the device. The ATA driver does not use BUSDMA (and never has)... it assumes BIOs are minimally aligned. But BIOs generated from kern_physio.c use user addresses directly and thus might only be byte-aligned. The CAM pass-through device has the same problem. The problem occurs most often when running a cd/dvd player or burner which declares operational structures it intends to read() or write() on the stack, sometimes even with char[] arrays. The solution I came up for with DFly was to implement bounce buffers manually in kern_physio.c and the CAM pass-through device for any user data that was not 16-byte aligned. I considered implementing bounce buffers in all the disk drivers that were missing it but there are other serious problems trying to bounce dma buffers that deep in the device hierarchy... you can hit low-memory deadlocks if the driver isn't written carefully enough (and most aren't). The BUSDMA API has never been easy to work with for anyone trying to use the async data buffer bouncing load feature... most drivers just force it to run synchronously and thus hit the deadlock issues. I seem to recall that the same issue popped up a few months ago on these lists, too. -Matt From owner-freebsd-current@FreeBSD.ORG Thu Sep 3 22:35: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 6DB52106566C; Thu, 3 Sep 2009 22:35:45 +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 16AD28FC18; Thu, 3 Sep 2009 22:35:44 +0000 (UTC) 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 92B907E853; Thu, 3 Sep 2009 14:35:55 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Fri, 4 Sep 2009 00:35:41 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA3; KDE/4.2.4; i386; ; ) References: <4AA03346.5010608@FreeBSD.org> In-Reply-To: <4AA03346.5010608@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909040035.41840.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Ryan Rogers , Alexander Motin Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Sep 2009 22:35:45 -0000 On Thursday 03 September 2009 23:21:10 Alexander Motin wrote: > Ryan Rogers wrote: > > I'm having a bit of a problem getting my DVD drive(s) to work correctly. > > I'm trying to transfer my DVD collection to my media server, but > > whenever I run vobcopy, /var/log/messages gets spammed with: > > > > acd0: FAILURE - non aligned DMA transfer attempted > > acd0: setting up DMA failed > > > > I added a bit more information to the first message to see if I could > > figure out what was actually going on. request->data was 0xd40e0c37, > > ch->dma.alignment was 2, and request->bytecount was 2048. > > Actually I don't understand what for this check was made there. It is > busdma infrastructure business to implement buffer bouncing to manage > requested alignment. But this check enforces application level to bother > with this. Usually it works fine, as memory often allocated aligned. But > probably here is some specifics in your application. Could you try to > just to comment-out that request->data check? +1 on 7.2-STABLE machine, using cam layer. multimedia/handbrake is the offending app, that then keeps going into a loop requesting "title one of 8". If suspended, the app is not killable and reboot does not shut down the machine. Hard power off is needed. Preceding the spam is: kernel: (cd0:ata1:0:0:0): Media region code is mismatched to logical unit region I've been assured there's no media region code mismatch (US DVD with US DVD- ROM). Just reproduced with mplayer: $ mplayer -vo null dvd://1 MPlayer 1.0rc2-4.2.1 (C) 2000-2007 MPlayer Team CPU: AMD Athlon(tm) XP 3000+ (Family: 6, Model: 10, Stepping: 0) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 0 Compiled with runtime CPU detection. Playing dvd://1. There are 8 titles on this DVD. There are 31 chapters in this DVD title. There are 1 angles in this DVD title. audio stream: 0 format: ac3 (5.1) language: en aid: 128. audio stream: 1 format: ac3 (5.1) language: fr aid: 129. audio stream: 2 format: ac3 (5.1) language: es aid: 130. number of audio channels on disk: 3. subtitle ( sid ): 0 language: en subtitle ( sid ): 1 language: fr subtitle ( sid ): 2 language: es subtitle ( sid ): 3 language: en subtitle ( sid ): 4 language: fr subtitle ( sid ): 5 language: es number of subtitles on disk: 6 kernel: unknown: FAILURE - REPORT_KEY ILLEGAL REQUEST asc=0x6f ascq=0x04 kernel: (cd0:ata1:0:0:0): REPORT KEY. CDB: a4 0 0 0 12 ac 0 0 0 c 4 0 kernel: (cd0:ata1:0:0:0): CAM Status: SCSI Status Error kernel: (cd0:ata1:0:0:0): SCSI Status: Check Condition kernel: (cd0:ata1:0:0:0): ILLEGAL REQUEST asc:6f,4 kernel: (cd0:ata1:0:0:0): Media region code is mismatched to logical unit region kernel: (cd0:ata1:0:0:0): Retrying Command (per Sense Data) kernel: unknown: FAILURE - REPORT_KEY ILLEGAL REQUEST asc=0x6f ascq=0x04 kernel: (cd0:ata1:0:0:0): REPORT KEY. CDB: a4 0 0 0 12 ac 0 0 0 c 4 0 kernel: (cd0:ata1:0:0:0): CAM Status: SCSI Status Error kernel: (cd0:ata1:0:0:0): SCSI Status: Check Condition kernel: (cd0:ata1:0:0:0): ILLEGAL REQUEST asc:6f,4 kernel: (cd0:ata1:0:0:0): Media region code is mismatched to logical unit region kernel: (cd0:ata1:0:0:0): Retries Exhausted kernel: ata1: FAILURE - non aligned DMA transfer attempted kernel: unknown: setting up DMA failed The above system is a desktop with: at scbus3 target 0 lun 0 (probe0,pass4,cd0) If needed, I can upgrade this system to stable/8, rather not upgrade it to head. -- Mel From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 01:00: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 D0B2D106566C for ; Fri, 4 Sep 2009 01:00:39 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp02.lnh.mail.rcn.net (smtp02.lnh.mail.rcn.net [207.172.157.102]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2538FC19 for ; Fri, 4 Sep 2009 01:00:39 +0000 (UTC) Received: from mr02.lnh.mail.rcn.net ([207.172.157.22]) by smtp02.lnh.mail.rcn.net with ESMTP; 03 Sep 2009 21:00:39 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr02.lnh.mail.rcn.net (MOS 3.10.7-GA) with ESMTP id QDS24501; Thu, 3 Sep 2009 21:00:37 -0400 (EDT) Received: from 209-6-22-227.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com (HELO jerusalem.litteratus.org.litteratus.org) ([209.6.22.227]) by smtp01.lnh.mail.rcn.net with ESMTP; 03 Sep 2009 21:00:38 -0400 From: Robert Huff MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19104.26293.468518.603685@jerusalem.litteratus.org> Date: Thu, 3 Sep 2009 21:00:37 -0400 To: Robert Huff In-Reply-To: <4A9C2A0E.4010203@rcn.com> References: <4A9C2A0E.4010203@rcn.com> X-Mailer: VM 7.17 under 21.5 (beta28) "fuki" XEmacs Lucid X-Junkmail-Whitelist: YES (by domain whitelist at mr02.lnh.mail.rcn.net) Cc: current@freebsd.org Subject: FIXED: HEAD newfs/sysinstall issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 01:00:39 -0000 Me: > About two weeks ago we had a discussion about my inability to > complete an install because the partition/label part of sysinstall > was getting confused. I found a work-around: when down with the label phase, instead of hotting 'q', hit 'w' (which isn't listed as an option). This will create the slices and partitions, and further steps will work fine. Robert Huff From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 04: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 6478F1065670 for ; Fri, 4 Sep 2009 04:14:22 +0000 (UTC) (envelope-from lapo@lapo.it) Received: from mail.lapo.it (motoko.lapo.it [88.198.0.105]) by mx1.freebsd.org (Postfix) with ESMTP id BCA478FC15 for ; Fri, 4 Sep 2009 04:14:21 +0000 (UTC) Received: (qmail 47004 invoked by uid 89); 4 Sep 2009 04:14:20 -0000 Received: from host71-40-static.74-81-b.business.telecomitalia.it (HELO ?10.0.0.1?) (lapo@lapo.it@81.74.40.71) by 0 with ESMTPA; 4 Sep 2009 04:14:20 -0000 Message-ID: <4AA09410.8020302@lapo.it> Date: Fri, 04 Sep 2009 06:14:08 +0200 From: Lapo Luchini User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Adam Vande More References: <20090527134343.GB1104@bsdcrew.de> <85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com> <20090527163952.GI1104@bsdcrew.de> <4AA0149E.30209@lapo.it> <6201873e0909031252r41bced2eqe1784a17214f1cd1@mail.gmail.com> In-Reply-To: <6201873e0909031252r41bced2eqe1784a17214f1cd1@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=C8F252FB Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enig364510BCBF0FC7948039456A" Cc: Doug Barton , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, "M. Vale" , Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 04:14:22 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig364510BCBF0FC7948039456A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Adam Vande More wrote: >>>/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild/footer.kmk:2304: *= ** >>> target file `virtualbox' has both : and :: entries. >>> >>> Please update to 7.2 or higher >>=20 >> Errr, and what if I have that in a FreeBSD 7.2-STABLE? >=20 > Are you using portmaster to build virtualbox? Yes indeed... and now that you say it, I tried a simple "cd emulators/virtualbox ; make install" and it worked! I wonder what does portmaster different to break only that specific port.= =2E. --=20 Lapo Luchini - http://lapo.it/ =E2=80=9CAny sufficiently advanced technology is indistinguishable from m= agic.=E2=80=9D (Arthur C. Clarke) --------------enig364510BCBF0FC7948039456A 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 (Cygwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJKoJQWAAoJELBiMTth2oCDJrkP/i8HEydXOiy4W+c1FYwtMvdl suJsLLlvAlV0UloIzrjDKL916qxzCiJOWfXuzzXtHBWIAw5ICLSQruXFcZ5FF3Tl PqmQ73g5imoZELvkOupQtTZA2/VICKIJCSbJbfTinU1IcNXiFQkChs0h0Sfnpe7Z aZ1Hz7AvGyk+u6YUm6AB5qzS23Y/g1cyfwzyPij1hSC07bMEMuV/qcXXtZW3LbbQ 0pWg6RahxdLbwFfSf1oy32OHZHYDxT13VMGbInPVJDZZsHVl5N22jDd8WaCBE4TT aE+5dbm1SB1MPj/W+3dj3EWRgqLADF1zPOscBfGcFsLqPZYm2lRGxEnq9Lfui+Al 4r1zkiSgBBtQUvq6bDsMFQFyFD/rVlD4TVdPDYWMEq2KFTIl6HdeMhngckWh7AFb 8qC/t9UkDcrOuQGj2oXJyOcRcuvV5c5Ua+DfJ5gXJIKbVGG/Vcj7vDjb2ADQEtMY r+MXYFxMMnu+MBRqveTmXmMp/zaIGyklnhznfRyzYolFZ9FDvJMkeXW+FLcEWw6I PHgVKa1WbyUrzwrUvP8mrOx0lpmLq5ScgMGw4w5lwg5dt5/V0yBp/3V15XOvemZd g1TDID4YKIsh8aqDAe2Ix2m5NtudUN3Zji1WeTzpiyPkVBgkP+5xmNlRPSvo1WT3 Q+JcpzrCPlHNNhOdKbp5 =LljS -----END PGP SIGNATURE----- --------------enig364510BCBF0FC7948039456A-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 05:04: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 AB3481065676 for ; Fri, 4 Sep 2009 05:04:34 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: from n13.bullet.mail.mud.yahoo.com (n13.bullet.mail.mud.yahoo.com [68.142.206.40]) by mx1.freebsd.org (Postfix) with SMTP id 6C00B8FC15 for ; Fri, 4 Sep 2009 05:04:34 +0000 (UTC) Received: from [68.142.200.221] by n13.bullet.mail.mud.yahoo.com with NNFMP; 04 Sep 2009 05:04:33 -0000 Received: from [68.142.201.246] by t9.bullet.mud.yahoo.com with NNFMP; 04 Sep 2009 05:04:33 -0000 Received: from [127.0.0.1] by omp407.mail.mud.yahoo.com with NNFMP; 04 Sep 2009 05:04:33 -0000 X-Yahoo-Newman-Id: 716422.58819.bm@omp407.mail.mud.yahoo.com Received: (qmail 97292 invoked from network); 4 Sep 2009 05:04:33 -0000 Received: from unknown (HELO soul.local.inet) (webmaster@69.109.45.163 with plain) by smtp108.sbc.mail.sp1.yahoo.com with SMTP; 4 Sep 2009 05:04:33 -0000 X-YMail-OSG: kDiv7egVM1k7zv46eQqCG4pI3QiychZ6FA25SLYmiEp61BTPF8rRlTWGd8Ob89f8QJDUOEVtxy9UsICYxyvNfDPjZwG8wJ5f1g6V.JwnHdmBjAgzXRuRJY_b5qlfq4Az8HQSA3gYgawvaR80uyRyrIAvA4tg870N5f_WscXq4jBI1FRuhjY- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AA09FDF.2010307@doghouserepair.com> Date: Thu, 03 Sep 2009 22:04:31 -0700 From: Ryan Rogers User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Alexander Motin , freebsd-current@freebsd.org References: <4AA03346.5010608@FreeBSD.org> In-Reply-To: <4AA03346.5010608@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 05:04:34 -0000 Alexander Motin wrote: > Ryan Rogers wrote: >> I'm having a bit of a problem getting my DVD drive(s) to work >> correctly. I'm trying to transfer my DVD collection to my media >> server, but whenever I run vobcopy, /var/log/messages gets spammed with: >> >> acd0: FAILURE - non aligned DMA transfer attempted >> acd0: setting up DMA failed >> >> I added a bit more information to the first message to see if I could >> figure out what was actually going on. request->data was 0xd40e0c37, >> ch->dma.alignment was 2, and request->bytecount was 2048. > > Actually I don't understand what for this check was made there. It is > busdma infrastructure business to implement buffer bouncing to manage > requested alignment. But this check enforces application level to bother > with this. Usually it works fine, as memory often allocated aligned. But > probably here is some specifics in your application. Could you try to > just to comment-out that request->data check? > I commented out that part of the check, and it worked in the sense that it didn't spit out any errors at me, but I'm not 100% certain that the data isn't getting corrupted. I tried ripping two discs. The first is completely corrupted, the second appears to be fine on first glance. I'm going to try a couple more discs to see if maybe the first one was just bad. Also, one other thing that I noticed that seems odd is this: acd0: DVDR at ata6-master SATA150 .... cd0: Removable CD-ROM SCSI-0 device cd0: 3.300MB/s transfers I timed how long the first disc took to rip, and it seems to match that reported speed. "Working but slow" is certainly better than "not working", but my speeds in Windows using DVD Decrypter on the same disk are at least 3 times faster, bursting up to about 5 times faster. Ryan From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 05:31:19 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 07686106566C; Fri, 4 Sep 2009 05:31:19 +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 AF6C58FC12; Fri, 4 Sep 2009 05:31:18 +0000 (UTC) Received: from [IPv6:::1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n845V7xU092195; Thu, 3 Sep 2009 23:31:07 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Scott Long In-Reply-To: <200909032210.n83MA67F059073@apollo.backplane.com> Date: Thu, 3 Sep 2009 23:31:07 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <4AA03346.5010608@FreeBSD.org> <200909032210.n83MA67F059073@apollo.backplane.com> To: Matthew Dillon X-Mailer: Apple Mail (2.1075.2) X-Spam-Status: No, score=-2.2 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Ryan Rogers , Alexander Motin , current@freebsd.org Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 05:31:19 -0000 On Sep 3, 2009, at 4:10 PM, Matthew Dillon wrote: > This is a known problem with physio and/or the ATA driver, > depending > on your viewpoint. See kern/kern_physio.c. > > The physio code directly maps the userland buffer via vmapbuf() and > supplies it as a BIO to the device. The ATA driver does not use > BUSDMA (and never has)... it assumes BIOs are minimally aligned. > Wrong. > But BIOs generated from kern_physio.c use user addresses directly > and > thus might only be byte-aligned. > > The CAM pass-through device has the same problem. > Huh? Are you confused by the physaddr interface of CAM? > The problem occurs most often when running a cd/dvd player or > burner > which declares operational structures it intends to read() or > write() > on the stack, sometimes even with char[] arrays. > > The solution I came up for with DFly was to implement bounce > buffers > manually in kern_physio.c and the CAM pass-through device for any > user data that was not 16-byte aligned. I considered implementing > bounce buffers in all the disk drivers that were missing it but > there are other serious problems trying to bounce dma buffers > that deep > in the device hierarchy... you can hit low-memory deadlocks if the > driver isn't written carefully enough (and most aren't). The > BUSDMA > API has never been easy to work with for anyone trying to use the > async data buffer bouncing load feature... most drivers just > force it > to run synchronously and thus hit the deadlock issues. > Wrong. Scott From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 05:56: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 02C1F106566C for ; Fri, 4 Sep 2009 05:56:13 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 52CFA8FC1D for ; Fri, 4 Sep 2009 05:56:11 +0000 (UTC) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id n845uAnC089234; Fri, 4 Sep 2009 09:56:10 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1252043770; bh=DOs4Jgz7kN1cbtkdhOPcepgm2OvOS8xorjiU7HHFgmk=; l=476; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=Xm50KuyR0MwCVIIryF197DbZj/O5kGOiQ/TTwvj8dMJhF2jasSyapMy7BkXEHDk6u ysFHXLH7s5R6+A9KPmxa0NLWIfN7CI/hOe6Uyjb9Pwp5+dT4nK032ARLIl96ZsDN4U q4in1ndGIMObyTSHB3/zxavirn/3V7tk933a5hmI= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id n845u8Gn089233; Fri, 4 Sep 2009 09:56:09 +0400 (MSD) (envelope-from ache) Date: Fri, 4 Sep 2009 09:56:07 +0400 From: Andrey Chernov To: current@freebsd.org, lev@freebsd.org Message-ID: <20090904055607.GA89117@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org, lev@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: 'svn add' does not add 'svn:keywords', but 'svn ci' ask for it X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 05:56:13 -0000 1) svn add some_file 2) svn ci some_file svn: Commit blocked by pre-commit hook (exit code 1) with output: Path ".../some_file" is missing the svn:keywords property (or an fbsd:nokeywords override) I manage it adding by hand: 3) svn propset svn:keywords 'FreeBSD:%H' some_file It isn't convenient. Why 'svn add' can't do it automatically for me using the same detection method as 'svn ci'? P.S. I use subversion-freebsd-1.6.5 port. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 06:28: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 F2C55106568D; Fri, 4 Sep 2009 06:28:54 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 5E90C8FC18; Fri, 4 Sep 2009 06:28:54 +0000 (UTC) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id n846SrBR089731; Fri, 4 Sep 2009 10:28:53 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1252045733; bh=QFIS+hpGa/om0Vsk9TnCAMr8Zkd39NGq0jM1Ctmiu+M=; l=199; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=NwoWH7Xzt90Wdk225T+hp9sAAJ/70Om6jhZUJHDupZ7ev+qHPK9/QaREahJlycGe7 rTuEPCd1iD5zrcEpiAsyX6LIeaf3qnXZ5cDOH0TmRjqKFPuGdu0dJFX3P9sRi7tZZB zQGYh90ukkjqEs2K9xizmGruxAZ+twBwUjMYtWyU= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id n846Sqo0089730; Fri, 4 Sep 2009 10:28:52 +0400 (MSD) (envelope-from ache) Date: Fri, 4 Sep 2009 10:28:51 +0400 From: Andrey Chernov To: current@freebsd.org, lev@freebsd.org Message-ID: <20090904062851.GA89703@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , current@freebsd.org, lev@freebsd.org References: <20090904055607.GA89117@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090904055607.GA89117@nagual.pp.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Re: 'svn add' does not add 'svn:keywords', but 'svn ci' ask for it X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 06:28:55 -0000 On Fri, Sep 04, 2009 at 09:56:07AM +0400, Andrey Chernov wrote: > I manage it adding by hand: > 3) svn propset svn:keywords 'FreeBSD:%H' some_file Typo, 'FreeBSD=%H' -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 06:29:29 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 8060F1065693; Fri, 4 Sep 2009 06:29:29 +0000 (UTC) (envelope-from devin@spamcop.net) Received: from mail.distalzou.net (203.141.139.231.static.zoot.jp [203.141.139.231]) by mx1.freebsd.org (Postfix) with ESMTP id 490618FC29; Fri, 4 Sep 2009 06:29:28 +0000 (UTC) Received: from plexi.pun-pun.prv ([192.168.7.29]) by mail.distalzou.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MjRvq-000INF-Qz; Fri, 04 Sep 2009 15:05:58 +0900 Date: Fri, 4 Sep 2009 15:05:58 +0900 (JST) From: Tod McQuillin X-X-Sender: devin@plexi.pun-pun.prv To: Andrey Chernov In-Reply-To: <20090904055607.GA89117@nagual.pp.ru> Message-ID: <20090904150520.L1222@plexi.pun-pun.prv> References: <20090904055607.GA89117@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: lev@freebsd.org, current@freebsd.org Subject: Re: 'svn add' does not add 'svn:keywords', but 'svn ci' ask for it X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 06:29:29 -0000 On Fri, 4 Sep 2009, Andrey Chernov wrote: > 1) svn add some_file > 2) svn ci some_file > svn: Commit blocked by pre-commit hook (exit code 1) with output: > Path ".../some_file" is missing the > svn:keywords property (or an fbsd:nokeywords override) > > I manage it adding by hand: > 3) svn propset svn:keywords 'FreeBSD:%H' some_file Have a look at http://people.freebsd.org/~peter/auto-props.txt -- Tod From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 06:40:32 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 B9D021065670; Fri, 4 Sep 2009 06:40:32 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 1C9AC8FC13; Fri, 4 Sep 2009 06:40:31 +0000 (UTC) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.14.3/8.14.3) with ESMTP id n846eU7c089885; Fri, 4 Sep 2009 10:40:30 +0400 (MSD) (envelope-from ache@nagual.pp.ru) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nagual.pp.ru; s=default; t=1252046430; bh=+4ULgbymFpdlAm3Mv/04G1PhNjSzpY5GsRYyPLC+u0A=; l=660; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=WTTtI+ybEh1Qy9wbZ/n1iAMOJH8E/SoAae2EOblxJosIJWokpawfffpxzMuJXrdhz HVHObFf75pBHTqL2BN+KaHyqR9fufOGYf6cBeuOlgzObIf42vkBj7lqDZ+gjWRlA07 AE/VkWU98IvVsZ63dCEzBPUU2bcWWUdL+S8ryr8U= Received: (from ache@localhost) by nagual.pp.ru (8.14.3/8.14.3/Submit) id n846eUsR089884; Fri, 4 Sep 2009 10:40:30 +0400 (MSD) (envelope-from ache) Date: Fri, 4 Sep 2009 10:40:29 +0400 From: Andrey Chernov To: Tod McQuillin Message-ID: <20090904064028.GA89820@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Tod McQuillin , current@freebsd.org, lev@freebsd.org References: <20090904055607.GA89117@nagual.pp.ru> <20090904150520.L1222@plexi.pun-pun.prv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090904150520.L1222@plexi.pun-pun.prv> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: lev@freebsd.org, current@freebsd.org Subject: Re: 'svn add' does not add 'svn:keywords', but 'svn ci' ask for it X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 06:40:32 -0000 On Fri, Sep 04, 2009 at 03:05:58PM +0900, Tod McQuillin wrote: > On Fri, 4 Sep 2009, Andrey Chernov wrote: > > > 1) svn add some_file > > 2) svn ci some_file > > svn: Commit blocked by pre-commit hook (exit code 1) with output: > > Path ".../some_file" is missing the > > svn:keywords property (or an fbsd:nokeywords override) > > > > I manage it adding by hand: > > 3) svn propset svn:keywords 'FreeBSD:%H' some_file > > Have a look at http://people.freebsd.org/~peter/auto-props.txt Thanx, I already have ~/.subversion/config, but .src extention I use not listed there. Strange I don't hit this problem before. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 06:50: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 D33CF1065670 for ; Fri, 4 Sep 2009 06:50:51 +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 53F298FC13 for ; Fri, 4 Sep 2009 06:50:50 +0000 (UTC) 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 253408613; Fri, 04 Sep 2009 09:50:47 +0300 Message-ID: <4AA0B8C0.90604@FreeBSD.org> Date: Fri, 04 Sep 2009 09:50:40 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Ryan Rogers References: <4AA03346.5010608@FreeBSD.org> <4AA09FDF.2010307@doghouserepair.com> In-Reply-To: <4AA09FDF.2010307@doghouserepair.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 06:50:51 -0000 Ryan Rogers wrote: > Alexander Motin wrote: >> Ryan Rogers wrote: >>> I'm having a bit of a problem getting my DVD drive(s) to work >>> correctly. I'm trying to transfer my DVD collection to my media >>> server, but whenever I run vobcopy, /var/log/messages gets spammed with: >>> >>> acd0: FAILURE - non aligned DMA transfer attempted >>> acd0: setting up DMA failed >>> >>> I added a bit more information to the first message to see if I could >>> figure out what was actually going on. request->data was 0xd40e0c37, >>> ch->dma.alignment was 2, and request->bytecount was 2048. >> >> Actually I don't understand what for this check was made there. It is >> busdma infrastructure business to implement buffer bouncing to manage >> requested alignment. But this check enforces application level to >> bother with this. Usually it works fine, as memory often allocated >> aligned. But probably here is some specifics in your application. >> Could you try to just to comment-out that request->data check? > > I commented out that part of the check, and it worked in the sense that > it didn't spit out any errors at me, but I'm not 100% certain that the > data isn't getting corrupted. I tried ripping two discs. The first is > completely corrupted, the second appears to be fine on first glance. I'm > going to try a couple more discs to see if maybe the first one was just > bad. Please. > Also, one other thing that I noticed that seems odd is this: > > acd0: DVDR at ata6-master SATA150 > .... > cd0: Removable CD-ROM SCSI-0 device > cd0: 3.300MB/s transfers > > I timed how long the first disc took to rip, and it seems to match that > reported speed. "Working but slow" is certainly better than "not > working", but my speeds in Windows using DVD Decrypter on the same disk > are at least 3 times faster, bursting up to about 5 times faster. It's just a small atapicam misfeature. It doesn't translates SATA modes to CAM speeds. It's only cosmetics, it shouldn't be important. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 10:08: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 DE180106566B for ; Fri, 4 Sep 2009 10:08:50 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by mx1.freebsd.org (Postfix) with ESMTP id 6F3E88FC15 for ; Fri, 4 Sep 2009 10:08:50 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-217-45.belrs3.nsw.optusnet.com.au [122.106.217.45]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n84A8lXT026958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Sep 2009 20:08:48 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n84A8lwG013343 for ; Fri, 4 Sep 2009 20:08:47 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n84A8l8p013342 for freebsd-current@freebsd.org; Fri, 4 Sep 2009 20:08:47 +1000 (EST) (envelope-from peter) Date: Fri, 4 Sep 2009 20:08:47 +1000 From: peterjeremy@acm.org To: FreeBSD CURRENT Mailing List Message-ID: <20090904100847.GA13167@server.vk2pj.dyndns.org> References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 10:08:50 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Sep-03 12:39:04 +1200, James Butler wr= ote: >This seems like an important distinction - the information which needs >to be available with dmesg and the information best shown to the user >at startup are not necessarily the same. Agreed. And some rc.d scripts are also overly verbose - starting a system with 150 virtual interfaces takes a significant amount of time via a serial console. > The hypothetical "average >user" probably wouldn't care if there were *no* kernel messages shown >on startup. Whilst they mightn't care about the current probe/attach messages, it is very reassuring for the kernel to show that it is actually doing something. > The Xubuntu box I'm writing this from shows only GRUB >messages before the login prompt on tty1, and only service startup >messages on tty8 Solaris is similar - leading to some nailchewing when rebooting after a change: Does nothing being reported on the console for 2 minutes mean that the kernel has gone off into limbo or it is just slowly grinding through *something*? Whilst SIGINFO helps once userland starts, I would not be comfortable with a system that reported nothing between the boot loader and login prompts. --=20 Peter Jeremy --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqg5y8ACgkQ/opHv/APuIfr1QCbB1yDVhegaHupo3j9G0duznHR /uoAoIJKvXnuBtwXW0R5kFoT9dOSRMxV =SL8P -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 10:16: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 4322A1065672 for ; Fri, 4 Sep 2009 10:16:39 +0000 (UTC) (envelope-from akm@theinternet.com.au) Received: from mail06.syd.optusnet.com.au (mail06.syd.optusnet.com.au [211.29.132.187]) by mx1.freebsd.org (Postfix) with ESMTP id B8DEF8FC17 for ; Fri, 4 Sep 2009 10:16:38 +0000 (UTC) Received: from camelot.theinternet.com.au (110.32.226.197.optusnet.com.au [110.32.226.197] (may be forged)) by mail06.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n84AGUf7009312; Fri, 4 Sep 2009 20:16:31 +1000 Received: by camelot.theinternet.com.au (Postfix, from userid 1000) id 45C9717031; Fri, 4 Sep 2009 20:16:30 +1000 (EST) Date: Fri, 4 Sep 2009 20:16:30 +1000 From: Andrew Milton To: peterjeremy@acm.org Message-ID: <20090904101630.GA17207@camelot.theinternet.com.au> Mail-Followup-To: Andrew Milton , peterjeremy@acm.org, FreeBSD CURRENT Mailing List References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> <20090904100847.GA13167@server.vk2pj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090904100847.GA13167@server.vk2pj.dyndns.org> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD CURRENT Mailing List Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 10:16:39 -0000 +-------[ peterjeremy@acm.org ]---------------------- | | Whilst SIGINFO helps once userland starts, I would not be comfortable | with a system that reported nothing between the boot loader and login | prompts. Agreed. Especially after installs on new hardware, or after an upgrade / kernel rebuild. We already have -m and -q bootflags... -- Andrew Milton akm@theinternet.com.au From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 11:24: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 00C271065692 for ; Fri, 4 Sep 2009 11:24:50 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7FAD18FC1D for ; Fri, 4 Sep 2009 11:24:48 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n84BOlgd078139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Sep 2009 13:24:47 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4AA0F8FE.6050908@omnilan.de> Date: Fri, 04 Sep 2009 13:24:46 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.22 (X11/20090815) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA61E7099A9086D98D1482361" Subject: xorg running > 48h starts consuming CPU cycles with BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 11:24:50 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA61E7099A9086D98D1482361 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I have one problem with xorg running on BETA3. Repeatably, after more than 48hour uptime, my workstation showes=20 increased load. The longer the uptime, the more cpu cycles xorg consumes.= It's absolutely application independent. After 3 or 4 days, almost one=20 complete CPU is occupied by xorg, but I have no idea what xorg is doing. Is there any way to "look inside" xorg to see where the CPU cycles vanish= ? With uptimes shorter than 2 days I can't see xorg consuming any=20 remarkable CPU cycles. Xorg is 1.6.1, compiled on BETA3: 1157 root 1 53 0 828M 234M select 1 40:04 15.38% Xorg Thanks, -Harry --------------enigA61E7099A9086D98D1482361 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqg+P8ACgkQLDqVQ9VXb8iE2ACcChXhKwXLXKJizfhHB21F7Dwx xXIAnRKEEo13MYtlTTOLQKLg5n4zwtkE =BUhJ -----END PGP SIGNATURE----- --------------enigA61E7099A9086D98D1482361-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 12:36: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 1C3C1106568B; Fri, 4 Sep 2009 12:36:50 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-yw0-f187.google.com (mail-yw0-f187.google.com [209.85.211.187]) by mx1.freebsd.org (Postfix) with ESMTP id 728178FC28; Fri, 4 Sep 2009 12:36:49 +0000 (UTC) Received: by ywh17 with SMTP id 17so1394233ywh.3 for ; Fri, 04 Sep 2009 05:36:48 -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=KUxl8ddq0JOIsZgs81l2QhgrfGZHmtodQhA8iQicPww=; b=ZG8fEgSsJ7IxTEGIdoN71m5BaE0Nq4hOE28QYMP6GVmVCP/k3vumfU79C2GIyZZEPa B/MbyIHHJmKLKaNq4ogxhwDxHL55NvmGDco4nrrm0xllWK+4CRBMHv87vxpZ+M+HlTAw xlAwENbaO6P30XlpbKOsL+FmjmUVSXyu5KbkI= 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=oCY34nE4SyCHA707nco4RL/Au2sXMrwzmsl97ZXRIEPTld1gXpn6XccSMeRdTFnfDl fkamYHq6WpQ0FmmzxFkvjyOWJ+zT7H3hHRmmsvSFtFfOJFdfpRlB6qShf9Zg1Ct2W0bj dgVe2NyW8j/rOnio3fKYyKinJrgcw4XsiWdgo= MIME-Version: 1.0 Received: by 10.150.238.1 with SMTP id l1mr18502393ybh.68.1252067808244; Fri, 04 Sep 2009 05:36:48 -0700 (PDT) In-Reply-To: <4AA09410.8020302@lapo.it> References: <20090527134343.GB1104@bsdcrew.de> <85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com> <20090527163952.GI1104@bsdcrew.de> <4AA0149E.30209@lapo.it> <6201873e0909031252r41bced2eqe1784a17214f1cd1@mail.gmail.com> <4AA09410.8020302@lapo.it> Date: Fri, 4 Sep 2009 07:36:48 -0500 Message-ID: <6201873e0909040536y2a2c7a22t30247d61adc26318@mail.gmail.com> From: Adam Vande More To: Lapo Luchini Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Doug Barton , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, "M. Vale" , Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 12:36:50 -0000 On Thu, Sep 3, 2009 at 11:14 PM, Lapo Luchini wrote: > Adam Vande More wrote: > >>>/usr/ports/devel/kBuild/work/kBuild-0.1.5-p1/kBuild/footer.kmk:2304: *= ** > >>> target file `virtualbox' has both : and :: entries. > >>> > >>> Please update to 7.2 or higher > >> > >> Errr, and what if I have that in a FreeBSD 7.2-STABLE? > > > > Are you using portmaster to build virtualbox? > > Yes indeed... and now that you say it, I tried a simple > "cd emulators/virtualbox ; make install" > and it worked! > > I wonder what does portmaster different to break only that specific port.= .. > > -- > Lapo Luchini - http://lapo.it/ > > =93Any sufficiently advanced technology is indistinguishable from magic.= =94 > (Arthur C. Clarke) > > I believe portmaster uses a lot environmental variables, and kBuild does something funky with them. So technically, the issue lies w/ kBuild, not portmaster. At least that's what I read. --=20 Adam Vande More From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 14:26:01 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 1563D1065679; Fri, 4 Sep 2009 14:26:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B8EBE8FC0A; Fri, 4 Sep 2009 14:26:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id n84EPxFe018021; Fri, 4 Sep 2009 10:25:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id n84EPx4P018005; Fri, 4 Sep 2009 14:25:59 GMT (envelope-from tinderbox@freebsd.org) Date: Fri, 4 Sep 2009 14:25:59 GMT Message-Id: <200909041425.n84EPx4P018005@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 14:26:01 -0000 TB --- 2009-09-04 12:25:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-09-04 12:25:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-09-04 12:25:00 - cleaning the object tree TB --- 2009-09-04 12:25:56 - cvsupping the source tree TB --- 2009-09-04 12:25:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-09-04 12:27:17 - building world TB --- 2009-09-04 12:27:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-04 12:27:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-04 12:27:17 - TARGET=i386 TB --- 2009-09-04 12:27:17 - TARGET_ARCH=i386 TB --- 2009-09-04 12:27:17 - TZ=UTC TB --- 2009-09-04 12:27:17 - __MAKE_CONF=/dev/null TB --- 2009-09-04 12:27:17 - cd /src TB --- 2009-09-04 12:27:17 - /usr/bin/make -B buildworld >>> World build started on Fri Sep 4 12:27:17 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Sep 4 13:32:29 UTC 2009 TB --- 2009-09-04 13:32:29 - generating LINT kernel config TB --- 2009-09-04 13:32:29 - cd /src/sys/i386/conf TB --- 2009-09-04 13:32:29 - /usr/bin/make -B LINT TB --- 2009-09-04 13:32:29 - building LINT kernel TB --- 2009-09-04 13:32:29 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-04 13:32:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-04 13:32:29 - TARGET=i386 TB --- 2009-09-04 13:32:29 - TARGET_ARCH=i386 TB --- 2009-09-04 13:32:29 - TZ=UTC TB --- 2009-09-04 13:32:29 - __MAKE_CONF=/dev/null TB --- 2009-09-04 13:32:29 - cd /src TB --- 2009-09-04 13:32:29 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 4 13:32:30 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Sep 4 13:58:08 UTC 2009 TB --- 2009-09-04 13:58:08 - building GENERIC kernel TB --- 2009-09-04 13:58:08 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-04 13:58:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-04 13:58:08 - TARGET=i386 TB --- 2009-09-04 13:58:08 - TARGET_ARCH=i386 TB --- 2009-09-04 13:58:08 - TZ=UTC TB --- 2009-09-04 13:58:08 - __MAKE_CONF=/dev/null TB --- 2009-09-04 13:58:08 - cd /src TB --- 2009-09-04 13:58:08 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 4 13:58:08 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Sep 4 14:18:31 UTC 2009 TB --- 2009-09-04 14:18:31 - building PAE kernel TB --- 2009-09-04 14:18:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-04 14:18:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-04 14:18:31 - TARGET=i386 TB --- 2009-09-04 14:18:31 - TARGET_ARCH=i386 TB --- 2009-09-04 14:18:31 - TZ=UTC TB --- 2009-09-04 14:18:31 - __MAKE_CONF=/dev/null TB --- 2009-09-04 14:18:31 - cd /src TB --- 2009-09-04 14:18:31 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Fri Sep 4 14:18:31 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Fri Sep 4 14:23:35 UTC 2009 TB --- 2009-09-04 14:23:35 - building XEN kernel TB --- 2009-09-04 14:23:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-09-04 14:23:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-09-04 14:23:35 - TARGET=i386 TB --- 2009-09-04 14:23:35 - TARGET_ARCH=i386 TB --- 2009-09-04 14:23:35 - TZ=UTC TB --- 2009-09-04 14:23:35 - __MAKE_CONF=/dev/null TB --- 2009-09-04 14:23:35 - cd /src TB --- 2009-09-04 14:23:35 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Fri Sep 4 14:23:35 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/intr_machdep.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/io.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/io_apic.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/k6_mem.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/local_apic.c cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /src/sys/i386/i386/machdep.c /src/sys/i386/i386/machdep.c: In function 'init386': /src/sys/i386/i386/machdep.c:2574: error: expected ';' before 'do' *** Error code 1 Stop in /obj/i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-09-04 14:25:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-09-04 14:25:59 - ERROR: failed to build XEN kernel TB --- 2009-09-04 14:25:59 - 5086.95 user 704.03 system 7259.30 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 13:52: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 74E28106568D for ; Fri, 4 Sep 2009 13:52:53 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 54A868FC16 for ; Fri, 4 Sep 2009 13:52:53 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id B4C188C080; Fri, 4 Sep 2009 08:52:52 -0500 (CDT) Date: Fri, 4 Sep 2009 08:52:52 -0500 From: Mark Linimon To: Andrew Milton , peterjeremy@acm.org, FreeBSD CURRENT Mailing List Message-ID: <20090904135252.GA23438@lonesome.com> References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> <20090904100847.GA13167@server.vk2pj.dyndns.org> <20090904101630.GA17207@camelot.theinternet.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090904101630.GA17207@camelot.theinternet.com.au> User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Fri, 04 Sep 2009 15:25:05 +0000 Cc: Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 13:52:53 -0000 No one has mentioned the other reason to leave in verbosity: so that users who are having problems can file more useful PRs. This is particularly true of video cards (which, as one might recall, is where this thread started.) In some cases it can save a whole round-trip of "please reboot with another flag set and provide the following information ..." mcl From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 15:34: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 F118F1065676 for ; Fri, 4 Sep 2009 15:34:53 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 837FF8FC1C for ; Fri, 4 Sep 2009 15:34:53 +0000 (UTC) Received: by fxm6 with SMTP id 6so743883fxm.43 for ; Fri, 04 Sep 2009 08:34: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; bh=6uNudfdD4x6Wr58t/M6h/VJpdJmbrl8hhw6JykV+9RM=; b=q4hXdRZRurhjnNvPWo1Ejwecgakua9oyIL6fmXQnqHhk5wOTdt7brDC9rKx3bwR+2F VeUgBy6Hu3ybr3e5O91L4e52Dt5x2w+nWnI5cEOk1V1d0egWli90VYPjcJD1DH6dzV4H 5iUOpemanxoRGznUHiL8yjAvg40WMuQw4NkrU= 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=PD9RIuB/2J2EJFAuM1/LlKYm+L2PnTmuj+8dBYiZBqB1barTtlvQ0g2PDvaPV9B4S2 Q2MKeBQiBWEu2fJBvWcoxV1pLuQNqn1bEAbLkYBr1ejzK9fPNwRuqPfeWKSkx8DbWP3c eCP6fvN2gGDgqv6uQhaQK25Y+daUljwICKbcM= MIME-Version: 1.0 Received: by 10.103.80.25 with SMTP id h25mr4832188mul.15.1252078492273; Fri, 04 Sep 2009 08:34:52 -0700 (PDT) In-Reply-To: <4AA0F8FE.6050908@omnilan.de> References: <4AA0F8FE.6050908@omnilan.de> Date: Fri, 4 Sep 2009 15:34:52 +0000 Message-ID: <3a142e750909040834g2465d932t4b65ff02727761bf@mail.gmail.com> From: "Paul B. Mahol" To: Harald Schmalzbauer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: xorg running > 48h starts consuming CPU cycles with BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 15:34:54 -0000 On 9/4/09, Harald Schmalzbauer wrote: > Hello, > > I have one problem with xorg running on BETA3. > Repeatably, after more than 48hour uptime, my workstation showes > increased load. The longer the uptime, the more cpu cycles xorg consumes. > It's absolutely application independent. After 3 or 4 days, almost one > complete CPU is occupied by xorg, but I have no idea what xorg is doing. > Is there any way to "look inside" xorg to see where the CPU cycles vanish? > With uptimes shorter than 2 days I can't see xorg consuming any > remarkable CPU cycles. > Xorg is 1.6.1, compiled on BETA3: > 1157 root 1 53 0 828M 234M select 1 40:04 15.38% Xorg What video driver Xorg is using? -- Paul From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 17:16: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 00C27106566B for ; Fri, 4 Sep 2009 17:16:49 +0000 (UTC) (envelope-from lists@rhavenn.net) Received: from smtp144.dfw.emailsrvr.com (smtp144.dfw.emailsrvr.com [67.192.241.144]) by mx1.freebsd.org (Postfix) with ESMTP id D5E0F8FC1C for ; Fri, 4 Sep 2009 17:16:48 +0000 (UTC) Received: from relay4.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay4.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 89F7710CBF52 for ; Fri, 4 Sep 2009 12:59:32 -0400 (EDT) Received: by relay4.relay.dfw.mlsrvr.com (Authenticated sender: rhavenn-AT-rhavenn.net) with ESMTPSA id 6E81E10CBE72 for ; Fri, 4 Sep 2009 12:59:32 -0400 (EDT) Received: by alucard.int.rhavenn.net (Postfix, from userid 1000) id 0863B11428D; Fri, 4 Sep 2009 08:59:30 -0800 (AKDT) Date: Fri, 4 Sep 2009 08:59:30 -0800 From: Henrik Hudson To: freebsd-current@freebsd.org Message-ID: <20090904165930.GA4160@alucard.int.rhavenn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: PF rules not loading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 17:16:49 -0000 Hey List, I just finishing supping to 8-BETA3 and after a reboot I noticed that my PF rules weren't loading and hence NAT wasn't working for internal clients, not to mention no firewall :) This might not be specific to BETA3, but it's the first time I noticed it concretely. I did have a power outage last week where after a poweron I had to run pfctl -f /etc/pf.conf to get NAT working again. This was under BETA2. uname: FreeBSD cerberus.domain.local 8.0-BETA3 FreeBSD 8.0-BETA3 #1: Fri Sep 4 02:35:38 AKDT 2009 root@cerberus.domain.local:/usr/obj/usr/src/sys/CERBERUS amd64 The kernel is 99% stock with the only changes being the IDENT and adding PF and ALTQ specific items. rc.conf: #firewall -pf pf_enable="YES" # Set to YES to enable packet filter (pf) pf_rules="/etc/pf.conf" # rules definition file for pf pf_program="/sbin/pfctl" # where the pfctl program lives pf_flags="" # additional flags for pfctl pflog_enable="YES" # Set to YES to enable packet filter logging pflog_logfile="/var/log/pflog" # where pflogd should store the logfile pflog_program="/sbin/pflogd" # where the pflogd program lives pflog_flags="" # additional flags for pflogd pfsync_enable="NO" # Expose pf state to other hosts for syncing pfsync_syncdev="" # Interface for pfsync to work through pfsync_ifconfig="" # Additional options to ifconfig(8) for pfsync Manually running /etc/rc.d/pf start works fine and doesn't show any errors. Any further steps to troubleshoot this / check this? hardware is a atom based mobo with the onboad re0 and then a xl0 PCI card. re0 is internal facing and the xl0 is a DHCP external from my ISP. Henrik -- Henrik Hudson lists@rhavenn.net ----------------------------------------- "God, root, what is difference?" Pitr; UF From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 17:34: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 0A2C11065697 for ; Fri, 4 Sep 2009 17:34:29 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout030.mac.com (asmtpout030.mac.com [17.148.16.105]) by mx1.freebsd.org (Postfix) with ESMTP id E5EC58FC13 for ; Fri, 4 Sep 2009 17:34:28 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp030.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KPG00HV4JH99750@asmtp030.mac.com> for freebsd-current@freebsd.org; Fri, 04 Sep 2009 10:34:25 -0700 (PDT) From: Marcel Moolenaar In-reply-to: <20090904135252.GA23438@lonesome.com> Date: Fri, 04 Sep 2009 10:34:21 -0700 Message-id: <642B63E0-0F75-45FD-9E8D-58D990F7C8EB@mac.com> References: <200909010931.16880.nick@van-laarhoven.org> <1251841416.1689.4458.camel@balrog.2hip.net> <200909021656.15747.nick@van-laarhoven.org> <20090904100847.GA13167@server.vk2pj.dyndns.org> <20090904101630.GA17207@camelot.theinternet.com.au> <20090904135252.GA23438@lonesome.com> To: Mark Linimon X-Mailer: Apple Mail (2.1075.2) Cc: FreeBSD CURRENT Mailing List , peterjeremy@acm.org Subject: Re: Reducing noise in dmesg output X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 17:34:29 -0000 On Sep 4, 2009, at 6:52 AM, Mark Linimon wrote: > No one has mentioned the other reason to leave in verbosity: so that > users > who are having problems can file more useful PRs. This is > particularly > true of video cards (which, as one might recall, is where this thread > started.) This has always been an interesting fault-line. Yes, if you print or log "everything" then there's bound to be useful information somewhere that can be used to analyze problems. Approaching this from the glass half-empty angle, I can see why people value verbosity. It's an easy case to state: without it we don't know what went wrong. There's a flip-side and it's one that's much harder to argue for. Arguments against verbosity include such things as: 1. The signal/noise ratio is worse which means that it's easier to miss the information that is truly important. 2. You present the user with output that's not even directed towards the user -- it's an aesthetic bug. 3. It introduces performance problems, especially on slow consoles. 4. If it works, it works and the verbosity is unnecessary. Much more subjective... As long as we depend on verbosity to provide us with the information we need to solve a problem, it's really hard to convince people that we should make it more user-oriented and print only things that are of value to the user. Which means that unless developers value the user perspective and are willing to put in the effort to allow for another way of obtaining the information, verbosity is hard to reduce. It's not in the developer's interest. That is, unless the problem reporting is actually much better if done differently. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 18:15: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 A4F8B106568D; Fri, 4 Sep 2009 18:15:54 +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 8B56C8FC15; Fri, 4 Sep 2009 18:15:54 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n84IFrhJ016825; Fri, 4 Sep 2009 11:15:54 -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: Fri, 4 Sep 2009 11:15:18 -0700 Message-ID: In-Reply-To: <20090904173716.GA2278@mr-happy.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-BETA3/IPv6: route: bad keyword: cloning Thread-Index: AcothpUh13HV8f/6S8q5q0b1qQIRBQAP5OsQ References: <20090904173716.GA2278@mr-happy.com> From: "Li, Qing" To: "Jeff Blank" , Cc: FreeBSD Current Subject: RE: 8.0-BETA3/IPv6: route: bad keyword: cloning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 18:15:54 -0000 >=20 > Upon booting an 8.0-BETA3 system with IPv6 enabled, I saw this in the > console boot output: >=20 > route: bad keyword: cloning > usage: route [-dnqtv] command [[modifiers] args] >=20 > This looks like it's from line 1062/1063 of /etc/network.subr > v1.195.2.4. >=20 > This system is not an IPv6 router, so do I particularly need > $ipv6_default_interface set in rc.conf? >=20 > Is there a situation where -cloning (still referenced in the man page) > is a valid option to route (in inet6 context at least)? If no, should > I file a PR? (I searched GNATS but didn't find anything matching > this.) >=20 Route cloning is obsolete. Please report issues concerning 8.0 to freebsd-current@freebsd.org. Thanks, -- Qing From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 18:41: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 440D9106566B for ; Fri, 4 Sep 2009 18:41:52 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id C07178FC0A for ; Fri, 4 Sep 2009 18:41:51 +0000 (UTC) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n84Ifn7a083500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Sep 2009 20:41:50 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4AA15F66.9070907@omnilan.de> Date: Fri, 04 Sep 2009 20:41:42 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.22 (X11/20090815) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4AA0F8FE.6050908@omnilan.de> <3a142e750909040834g2465d932t4b65ff02727761bf@mail.gmail.com> In-Reply-To: <3a142e750909040834g2465d932t4b65ff02727761bf@mail.gmail.com> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA5C71BF8CAC487D0CA682933" Subject: Re: xorg running > 48h starts consuming CPU cycles with BETA3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 18:41:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA5C71BF8CAC487D0CA682933 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Paul B. Mahol schrieb am 04.09.2009 17:34 (localtime): > On 9/4/09, Harald Schmalzbauer wrote: >> Hello, >> >> I have one problem with xorg running on BETA3. >> Repeatably, after more than 48hour uptime, my workstation showes >> increased load. The longer the uptime, the more cpu cycles xorg consum= es. >> It's absolutely application independent. After 3 or 4 days, almost one= >> complete CPU is occupied by xorg, but I have no idea what xorg is doin= g. >> Is there any way to "look inside" xorg to see where the CPU cycles van= ish? >> With uptimes shorter than 2 days I can't see xorg consuming any >> remarkable CPU cycles. >> Xorg is 1.6.1, compiled on BETA3: >> 1157 root 1 53 0 828M 234M select 1 40:04 15.38% Xo= rg >=20 > What video driver Xorg is using? nvidia (not nv) Thanks, -Harry --------------enigA5C71BF8CAC487D0CA682933 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkqhX20ACgkQLDqVQ9VXb8i/JgCfcLx4pUdsPskdeDj5LuWAQlu1 dBkAn3CsMkzkVnEC/1cucWfbPYAmm+JI =HqiV -----END PGP SIGNATURE----- --------------enigA5C71BF8CAC487D0CA682933-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 18:57: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 D36A3106566C; Fri, 4 Sep 2009 18:57:20 +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 84E028FC14; Fri, 4 Sep 2009 18:57:20 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n84IvJ8q022650; Fri, 4 Sep 2009 11:57:20 -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: Fri, 4 Sep 2009 11:56:58 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 8.0-BETA3/IPv6: route: bad keyword: cloning Thread-Index: AcothpUh13HV8f/6S8q5q0b1qQIRBQAP5OsQAA15B5A= References: <20090904173716.GA2278@mr-happy.com> From: "Li, Qing" To: "Jeff Blank" , Cc: qingli@freebsd.org, FreeBSD Current Subject: RE: 8.0-BETA3/IPv6: route: bad keyword: cloning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 18:57:20 -0000 Regarding the man page issue, after a quick investigation, and to=20 make a long story short, Kip Macy and I spent a bunch of time testing=20 and fixing a few last minute bugs before my big commit last December.=20 Kip actually took care of this man page and one other issue in "ndp" command.=20 Somehow these two last minute changes fell through the cracks and did not make it into r186119. Kip will fix it again. Thank you for catching the bug. -- Qing =09 > -----Original Message----- > From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd- > stable@freebsd.org] On Behalf Of Li, Qing > Sent: Friday, September 04, 2009 11:15 AM > To: Jeff Blank; freebsd-stable@freebsd.org > Cc: FreeBSD Current > Subject: RE: 8.0-BETA3/IPv6: route: bad keyword: cloning >=20 > > > > Upon booting an 8.0-BETA3 system with IPv6 enabled, I saw this in the > > console boot output: > > > > route: bad keyword: cloning > > usage: route [-dnqtv] command [[modifiers] args] > > > > This looks like it's from line 1062/1063 of /etc/network.subr > > v1.195.2.4. > > > > This system is not an IPv6 router, so do I particularly need > > $ipv6_default_interface set in rc.conf? > > > > Is there a situation where -cloning (still referenced in the man page) > > is a valid option to route (in inet6 context at least)? If no, > should > > I file a PR? (I searched GNATS but didn't find anything matching > > this.) > > >=20 > Route cloning is obsolete. Please report issues concerning > 8.0 to freebsd-current@freebsd.org. >=20 > Thanks, >=20 > -- Qing >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 19:04: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 C30271065672 for ; Fri, 4 Sep 2009 19:04:29 +0000 (UTC) (envelope-from webmaster@doghouserepair.com) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by mx1.freebsd.org (Postfix) with SMTP id 866828FC1F for ; Fri, 4 Sep 2009 19:04:29 +0000 (UTC) Received: (qmail 11158 invoked from network); 4 Sep 2009 19:04:28 -0000 Received: from unknown (HELO soul.local.inet) (webmaster@69.109.45.163 with plain) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 4 Sep 2009 19:04:28 -0000 X-YMail-OSG: sNCwFA0VM1kuE44YsNThAXZq9HoQ4Pg1YH8V.EledKRABSK.vH7Dv7CoGMCzQuv4NaFAdawz_Qe7Y9UC9uV3BqFwXEeZjO407HmDOCUjXZ0misXUxSSpd.zupuuw6ZrHkg5yvtmGWnGWiFRyPbkzBB2nsOqOPdxslR6.XO8.VSqC8wcZM0NlS47ICpdaXm_qpuox6iVdgG5fIQzXZp3iQ4kyJASlIkT.vArPgDjLFeGF59jkDemMctq74G02eOUhp2S0ECo9xbEWt6zApaVj5ACfV7O8nvXRMWdNWuzLvbTsr1Qp1P8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4AA164B9.6030806@doghouserepair.com> Date: Fri, 04 Sep 2009 12:04:25 -0700 From: Ryan Rogers User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Alexander Motin , freebsd-current@freebsd.org References: <4AA03346.5010608@FreeBSD.org> <4AA09FDF.2010307@doghouserepair.com> <4AA0B8C0.90604@FreeBSD.org> In-Reply-To: <4AA0B8C0.90604@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 19:04:29 -0000 Alexander Motin wrote: > Ryan Rogers wrote: >> Alexander Motin wrote: >>> Ryan Rogers wrote: >>>> I'm having a bit of a problem getting my DVD drive(s) to work >>>> correctly. I'm trying to transfer my DVD collection to my media >>>> server, but whenever I run vobcopy, /var/log/messages gets spammed >>>> with: >>>> >>>> acd0: FAILURE - non aligned DMA transfer attempted >>>> acd0: setting up DMA failed >>>> >>>> I added a bit more information to the first message to see if I >>>> could figure out what was actually going on. request->data was >>>> 0xd40e0c37, ch->dma.alignment was 2, and request->bytecount was 2048. >>> >>> Actually I don't understand what for this check was made there. It is >>> busdma infrastructure business to implement buffer bouncing to manage >>> requested alignment. But this check enforces application level to >>> bother with this. Usually it works fine, as memory often allocated >>> aligned. But probably here is some specifics in your application. >>> Could you try to just to comment-out that request->data check? >> >> I commented out that part of the check, and it worked in the sense >> that it didn't spit out any errors at me, but I'm not 100% certain >> that the data isn't getting corrupted. I tried ripping two discs. >> The first is completely corrupted, the second appears to be fine on >> first glance. I'm going to try a couple more discs to see if maybe the >> first one was just bad. > > Please. > >> Also, one other thing that I noticed that seems odd is this: >> >> acd0: DVDR at ata6-master SATA150 >> .... >> cd0: Removable CD-ROM SCSI-0 device >> cd0: 3.300MB/s transfers >> >> I timed how long the first disc took to rip, and it seems to match >> that reported speed. "Working but slow" is certainly better than "not >> working", but my speeds in Windows using DVD Decrypter on the same >> disk are at least 3 times faster, bursting up to about 5 times faster. > > It's just a small atapicam misfeature. It doesn't translates SATA modes > to CAM speeds. It's only cosmetics, it shouldn't be important. > I've ripped a handful of DVDs since my last post, and I haven't had any error messages, and the output appears to be correct. I even re-ripped the one that had originally been corrupted, and it appears to be fine as well. So, it appears removing that part of the check fixed the issue for me. Ryan From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 20:08: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 73B391065670 for ; Fri, 4 Sep 2009 20:08:56 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 0778E8FC08 for ; Fri, 4 Sep 2009 20:08:55 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id DF415730DA; Fri, 4 Sep 2009 21:57:18 +0200 (CEST) Date: Fri, 4 Sep 2009 21:57:18 +0200 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20090904195718.GA69566@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: what clock is used by select()/HZ ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 20:08:56 -0000 Hi, I am running a kernel (8.0) with HZ=5000 trying to generate packets which are apart from each other by something that is not an exact multiple of 1ms . I have a modified ping version which essentially accepts a microsecond spec, loops around select() and tries to send a packet at precise intervals (taking care not to accumulate errors). running it with ./ping -i 0.050200 some.host and looking at the tcpdump output captured on the same host, i see that packets get out of the system at intervals that (according to the tcpdump timestamps are .050121 (60% of them) or .050322 (40% of them) seconds apart (values are scattered within 10us of each of the two values). Overall the average delta is correct, but individual samples are not. The system reports the following values: kern.timecounter.choice: TSC(-100) HPET(900) ACPI-safe(850) i8254(0) dummy(-1000000) kern.timecounter.hardware: HPET kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.HPET.frequency: 25000000 kern.timecounter.tc.ACPI-safe.frequency: 3579545 kern.timecounter.tc.TSC.frequency: 2314976129 kern.timecounter.tick: 5 # (not sure what this means) The only way i can explain the differences in the delays is that the internal value of HZ is slightly different than the correct value (50121/50200 or 50322/50200 times 5000) due to some approximation in the divider used to generate the peridic interrupt, whereas gettimeofday() is reasonably correct and prevents the accumulation of errors. However, HPET (which seems to be the one used) is a multiple of 5000 so the divider should be correct, and i cannot figure out what other clock source could cause, due to a rounding error in the divisor, such a large difference (50121/50200 or 50322/50200) Any ideas ? cheers luigi From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 20:11: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 473BC106568D for ; Fri, 4 Sep 2009 20:11:33 +0000 (UTC) (envelope-from cjk@home.kreklow.us) Received: from srv.home.kreklow.us (cjkreklow-1-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:59f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 243A58FC19 for ; Fri, 4 Sep 2009 20:11:33 +0000 (UTC) Received: by srv.home.kreklow.us (Postfix, from userid 1000) id 4B5492D1468E; Fri, 4 Sep 2009 15:11:32 -0500 (CDT) Date: Fri, 4 Sep 2009 15:11:32 -0500 From: Collin Kreklow To: freebsd-current@freebsd.org Message-ID: <20090904201132.GA17378@srv.home.kreklow.us> References: <20090904165930.GA4160@alucard.int.rhavenn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090904165930.GA4160@alucard.int.rhavenn.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: PF rules not loading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 20:11:33 -0000 On Fri, Sep 04, 2009 at 08:59:30AM -0800, Henrik Hudson wrote: > Hey List, > > I just finishing supping to 8-BETA3 and after a reboot I noticed > that my PF rules weren't loading and hence NAT wasn't working for > internal clients, not to mention no firewall :) > > This might not be specific to BETA3, but it's the first time I > noticed it concretely. I did have a power outage last week where > after a poweron I had to run pfctl -f /etc/pf.conf to get NAT working > again. This was under BETA2. At the time when the pf script runs during boot, all the network interfaces may not be fully configured. It is likely that your pf.conf includes rules that pf can't calculate because one or more network interfaces are not yet configured. I had to change my pf.conf to hard-code the IP ranges instead of using :network to get my rules to load on boot. Also make sure your script is using (xl0) where appropriate. - Collin From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 20:34: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 0EA40106566C for ; Fri, 4 Sep 2009 20:34:47 +0000 (UTC) (envelope-from lists@rhavenn.net) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by mx1.freebsd.org (Postfix) with ESMTP id E04C48FC13 for ; Fri, 4 Sep 2009 20:34:46 +0000 (UTC) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 98E3A13D338A for ; Fri, 4 Sep 2009 16:34:46 -0400 (EDT) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: rhavenn-AT-rhavenn.net) with ESMTPSA id 7DEE913D3385 for ; Fri, 4 Sep 2009 16:34:41 -0400 (EDT) Received: by alucard.int.rhavenn.net (Postfix, from userid 1000) id EE31111428D; Fri, 4 Sep 2009 12:34:39 -0800 (AKDT) Date: Fri, 4 Sep 2009 12:34:39 -0800 From: Henrik Hudson To: freebsd-current@freebsd.org Message-ID: <20090904203439.GA6431@alucard.int.rhavenn.net> References: <20090904165930.GA4160@alucard.int.rhavenn.net> <20090904201132.GA17378@srv.home.kreklow.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090904201132.GA17378@srv.home.kreklow.us> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: PF rules not loading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 20:34:47 -0000 On Fri, 04 Sep 2009, Collin Kreklow wrote: > On Fri, Sep 04, 2009 at 08:59:30AM -0800, Henrik Hudson wrote: > > Hey List, > > > > I just finishing supping to 8-BETA3 and after a reboot I noticed > > that my PF rules weren't loading and hence NAT wasn't working for > > internal clients, not to mention no firewall :) > > > > This might not be specific to BETA3, but it's the first time I > > noticed it concretely. I did have a power outage last week where > > after a poweron I had to run pfctl -f /etc/pf.conf to get NAT working > > again. This was under BETA2. > > At the time when the pf script runs during boot, all the network > interfaces may not be fully configured. It is likely that your pf.conf > includes rules that pf can't calculate because one or more network > interfaces are not yet configured. I had to change my pf.conf to > hard-code the IP ranges instead of using :network to get my rules to > load on boot. Also make sure your script is using (xl0) where > appropriate. It's possible. However, I'm pretty sure the ruleset worked correctly on the initial install and it's a ruleset I've used on plenty of different gateway servers with a similar hardware setup. However, I did just finish building another 8-BETA3 x64 box and it works fine, so maybe something fluky is going on with the server crash due to the power outage. I will investiage further. Thanks. Henrik -- Henrik Hudson lists@rhavenn.net ----------------------------------------- "God, root, what is difference?" Pitr; UF From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 20: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 AD39D1065670 for ; Fri, 4 Sep 2009 20:52:22 +0000 (UTC) (envelope-from lists@rhavenn.net) Received: from smtp194.dfw.emailsrvr.com (smtp194.dfw.emailsrvr.com [67.192.241.194]) by mx1.freebsd.org (Postfix) with ESMTP id 7D9938FC08 for ; Fri, 4 Sep 2009 20:52:22 +0000 (UTC) Received: from relay9.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay9.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id 187DA13D331A for ; Fri, 4 Sep 2009 16:52:22 -0400 (EDT) Received: by relay9.relay.dfw.mlsrvr.com (Authenticated sender: rhavenn-AT-rhavenn.net) with ESMTPSA id F139113D32C1 for ; Fri, 4 Sep 2009 16:52:21 -0400 (EDT) Received: by alucard.int.rhavenn.net (Postfix, from userid 1000) id BB81511428D; Fri, 4 Sep 2009 12:52:20 -0800 (AKDT) Date: Fri, 4 Sep 2009 12:52:20 -0800 From: Henrik Hudson To: freebsd-current@freebsd.org Message-ID: <20090904205220.GA6647@alucard.int.rhavenn.net> References: <20090904165930.GA4160@alucard.int.rhavenn.net> <20090904201132.GA17378@srv.home.kreklow.us> <20090904203439.GA6431@alucard.int.rhavenn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090904203439.GA6431@alucard.int.rhavenn.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: PF rules not loading X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 20:52:22 -0000 On Fri, 04 Sep 2009, Henrik Hudson wrote: > On Fri, 04 Sep 2009, Collin Kreklow wrote: > > > On Fri, Sep 04, 2009 at 08:59:30AM -0800, Henrik Hudson wrote: > > > Hey List, > > > > > > I just finishing supping to 8-BETA3 and after a reboot I noticed > > > that my PF rules weren't loading and hence NAT wasn't working for > > > internal clients, not to mention no firewall :) > > > > > > This might not be specific to BETA3, but it's the first time I > > > noticed it concretely. I did have a power outage last week where > > > after a poweron I had to run pfctl -f /etc/pf.conf to get NAT working > > > again. This was under BETA2. > > > > At the time when the pf script runs during boot, all the network > > interfaces may not be fully configured. It is likely that your pf.conf > > includes rules that pf can't calculate because one or more network > > interfaces are not yet configured. I had to change my pf.conf to > > hard-code the IP ranges instead of using :network to get my rules to > > load on boot. Also make sure your script is using (xl0) where > > appropriate. > > It's possible. However, I'm pretty sure the ruleset worked correctly > on the initial install and it's a ruleset I've used on plenty of > different gateway servers with a similar hardware setup. > > However, I did just finish building another 8-BETA3 x64 box and it > works fine, so maybe something fluky is going on with the server > crash due to the power outage. > > I will investiage further. Thanks. *ding* *ding* we have a winner. I had added a rule which required a DNS lookup for port forwarding in torrent traffic to an internal host. Thanks. Henrik -- Henrik Hudson lists@rhavenn.net ----------------------------------------- "God, root, what is difference?" Pitr; UF From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 21:57: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 1FA6E1065693 for ; Fri, 4 Sep 2009 21:57:53 +0000 (UTC) (envelope-from boris.hollas@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 6C5728FC1E for ; Fri, 4 Sep 2009 21:57:52 +0000 (UTC) Received: (qmail invoked by alias); 04 Sep 2009 21:31:11 -0000 Received: from p54A232FC.dip0.t-ipconnect.de (EHLO lifebook) [84.162.50.252] by mail.gmx.net (mp026) with SMTP; 04 Sep 2009 23:31:11 +0200 X-Authenticated: #34156689 X-Provags-ID: V01U2FsdGVkX1+WDMxuynSWhEJAv6c6R+AFv7RiH0iumCvpZrgL9s pbMD+ENy7weH34 Date: Fri, 04 Sep 2009 23:30:47 +0200 To: freebsd-current@freebsd.org From: "Boris Hollas" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.64 (Linux) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 Subject: 8.0-BETA3: ACPI resume fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 21:57:53 -0000 I've installed 8.0-BETA3 without X on a Fuji-Siemens Lifebook E8110. I observed the following while testing sleep mode: 1) Test 1 - I invoked # zzz - Screen and HD were switched off. - I pressed "On". - HD was switched on, but screen remained blank. The system didn't react to typing "reboot". 2) Test 2 I loaded acpi_fujitsu and repeated test 1 with the same result. 3) Test 3 I compiled a kernel without firewire support and excluded many unnecessary drivers. I repeated test 1 with the same result. 4) Test 4 With the kernel from 3), I entered # sysctrl acpi.hw.reset_video=1 and repeated test 1 with the same result. Sleep mode works with Debian Lenny. Resume also failed with both 7.2-R and 8.0-BETA3 on an old Thinkpad A30p. From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 23:10: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 1D0161065672 for ; Fri, 4 Sep 2009 23:10:43 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by mx1.freebsd.org (Postfix) with ESMTP id A2A328FC1A for ; Fri, 4 Sep 2009 23:10:42 +0000 (UTC) Received: by bwz2 with SMTP id 2so941443bwz.43 for ; Fri, 04 Sep 2009 16:10:41 -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=oXqJscPS4GZqknpoHngv5AWVKwrZqmW/amd4kxExtjs=; b=aKk5J+oD88EmIXmfuasKzGP6Ei8mNkqpgrJiobv/wvg8yehTKsKls8G5GKxaaMbYyB xahJC74YYpuRUpNH1zhsT2x2yKDBPZilKFRHlIylO1CeFv03Plkg2tTxyIdK0xId+Zfd xPI+BTWr6alrSujDFxtCx1NbiHrLtqhS8VnCI= 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=C6BoZwZ2b7uMFZjPU3B0o2SxauNJARcF6eOgMiyh+C2EY/q2rcimcjW3tjmx7FBqIK LvRKUj0KaP6z2d6dxauBhz17ymwqxEnTGnatoEUWBH+abdEMso2P29IChq8PyEJBMco5 8BX89bmn0t+11E3ypqeVAnrrG1Lj82Cist7oo= MIME-Version: 1.0 Received: by 10.103.78.35 with SMTP id f35mr5005883mul.89.1252105841458; Fri, 04 Sep 2009 16:10:41 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Sep 2009 23:10:41 +0000 Message-ID: <3a142e750909041610w6d1249cch6eb8164e7230b749@mail.gmail.com> From: "Paul B. Mahol" To: Boris Hollas Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: 8.0-BETA3: ACPI resume fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 23:10:43 -0000 On 9/4/09, Boris Hollas wrote: > I've installed 8.0-BETA3 without X on a Fuji-Siemens Lifebook E8110. > > I observed the following while testing sleep mode: > > 1) Test 1 > - I invoked > # zzz > - Screen and HD were switched off. > - I pressed "On". > - HD was switched on, but screen remained blank. The system didn't react > to typing "reboot". > > 2) Test 2 > I loaded acpi_fujitsu and repeated test 1 with the same result. > > 3) Test 3 > I compiled a kernel without firewire support and excluded many unnecessary > drivers. I repeated test 1 with the same result. > > 4) Test 4 > With the kernel from 3), I entered > # sysctrl acpi.hw.reset_video=1 > and repeated test 1 with the same result. > > > Sleep mode works with Debian Lenny. > > Resume also failed with both 7.2-R and 8.0-BETA3 on an old Thinkpad A30p. Resume in general currently doesnt work with SMP kernel on SMP systems on i386, (missing some code) amd64 should work. -- Paul From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 23:14: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 84BE2106575E; Fri, 4 Sep 2009 23:14:24 +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 8D15F8FC0A; Fri, 4 Sep 2009 23:14:24 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n84NENsB072080; Fri, 4 Sep 2009 16:14:23 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n84NEMAS072077; Fri, 4 Sep 2009 16:14:22 -0700 (PDT) Date: Fri, 4 Sep 2009 16:14:22 -0700 (PDT) From: Matthew Dillon Message-Id: <200909042314.n84NEMAS072077@apollo.backplane.com> To: Scott Long References: <4AA03346.5010608@FreeBSD.org> <200909032210.n83MA67F059073@apollo.backplane.com> Cc: Ryan Rogers , Alexander Motin , current@freebsd.org Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 23:14:28 -0000 :> The physio code directly maps the userland buffer via vmapbuf() and :> supplies it as a BIO to the device. The ATA driver does not use :> BUSDMA (and never has)... it assumes BIOs are minimally aligned. :> : :Wrong. By the way Scott, do you honestly believe that idiotic one-line answers just as a means to try to screw over my postings are appropriate for someone of your standing in the FreeBSD community? In anycase, this is what was causing the problem in DragonFly and the code is nearly identicial to FreeBSD. Adding the bounce buffers in physio and cam's pass-through fixed the problem in DragonFly... that is, the programs that we got bug reports about non-aligned DMA transfers started working again after I made those changes. Yes, removing the check might work in some cases, particularly with newer chipsets, since even BUSDMA alignment tends to be conservative for reverse-engineered chipsets, but I've seen userland pass byte-aligned buffers through CAM and physio on numerous occassions and if you actually want it to work reliably you have to enforce at least a base alignment... which BUSDMA can do if the driver uses BUSDMA (except it does it way too deep in the driver stack IMHO). All my points stand. Bounce buffers have created issues both positive and negative from the day they were introduced to this very day. I was very happy to be able to wash my hands of the majority of those problems by enforcing a base alignment closer to the userland boundary, and I would heartily recommend the same approach to any OS project. So, again, if you have a more detailed response that gets at the heart of the problem, I'm sure the original posters are eagerly waiting your next posting. But hey, if you think your type of answer is completely appropriate then maybe I should start following your lead and not bother to supply any detail in my own. Hey, you're wrong! Oh, by the way, I'm not going to bother to say why. Sheesh. You guys are just too full of yourselves these days. -Matt From owner-freebsd-current@FreeBSD.ORG Fri Sep 4 23:15: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 9FFE31065679 for ; Fri, 4 Sep 2009 23:15:53 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-ew0-f208.google.com (mail-ew0-f208.google.com [209.85.219.208]) by mx1.freebsd.org (Postfix) with ESMTP id 00D618FC0C for ; Fri, 4 Sep 2009 23:15:52 +0000 (UTC) Received: by ewy4 with SMTP id 4so1321346ewy.36 for ; Fri, 04 Sep 2009 16:15: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=lQBh8rqjd64SjZY9A+18X8xX+CGnsyVTohVmfatOYEo=; b=go4Zr7D4z4KdYoH3j86B5UoCS0RHm3zo3angeTWfjEXuBIxV/zIFobUsjZ2Qyh4rLe V4MVc3UlpDnMh2ONuV/NAOFzqjAc5MZWOt9wx690kHTXh/24ylYf6DERzY+O1h90DeNB p0RvBW5ROaEuIUhBdxYDBuIHhgSLo/eVbqi5s= 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=X60Wstrs2n+ZV8lDowTQa7YpX1SPTAL9UHS0eYT9yQ5klkuT6gZTCFaeY//E1cGALb 6YqIQ5vi4Yh7GfugcNkd8bi91RtQk3YCQ79jk7iNmPEpU54jE4dQ5EYHF59xY78hgkfL uXS2N74B7Juh32hWB6i2t130uB4YFMkwVll4Q= MIME-Version: 1.0 Received: by 10.211.143.14 with SMTP id v14mr1040111ebn.99.1252106152068; Fri, 04 Sep 2009 16:15:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Sep 2009 18:15:52 -0500 Message-ID: <179b97fb0909041615qa3f4a80ld669663769df5b62@mail.gmail.com> From: Brandon Gooch To: Boris Hollas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: 8.0-BETA3: ACPI resume fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 04 Sep 2009 23:15:53 -0000 On Fri, Sep 4, 2009 at 4:30 PM, Boris Hollas wrote: > I've installed 8.0-BETA3 without X on a Fuji-Siemens Lifebook E8110. > > I observed the following while testing sleep mode: > > 1) Test 1 > - I invoked > =A0# zzz > - Screen and HD were switched off. > - I pressed "On". > - HD was switched on, but screen remained blank. The system didn't react = to > typing "reboot". > > 2) Test 2 > I loaded acpi_fujitsu and repeated test 1 with the same result. > > 3) Test 3 > I compiled a kernel without firewire support and excluded many unnecessar= y > drivers. I repeated test 1 with the same result. > > 4) Test 4 > With the kernel from 3), I entered > # sysctrl acpi.hw.reset_video=3D1 > and repeated test 1 with the same result. > > > Sleep mode works with Debian Lenny. > > Resume also failed with both 7.2-R and 8.0-BETA3 on an old Thinkpad A30p. > _______________________________________________ > 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= " > On my ThinkPad X300 (with Intel GM965 SVGA Controller), I have to load i915.ko from /boot/loader.conf or via kldload(8) to suspend/resume from console. Otherwise, I run X.org and use the /etc/rc.suspend and /etc/rc.resume scripts to invoke vidcontrol(1), switching to ttyv1 before suspend, and switching back to ttyv9 (X.org) after resume. This is the only way I can "reliably" use suspend/resume. >From /etc/rc.suspend: ... /usr/sbin/vidcontrol -s 1 < /dev/console ... >From /etc/rc.resume: ... /usr/sbin/vidcontrol -s 9 < /dev/console -Brandon From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 00:45:51 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 92125106568B for ; Sat, 5 Sep 2009 00:45:51 +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 681298FC12 for ; Sat, 5 Sep 2009 00:45:51 +0000 (UTC) Received: (from root@localhost) by kientzle.com (8.14.3/8.14.3) id n850jnVY044355; Fri, 4 Sep 2009 17:45:49 -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 gqxsjcr77kamdec85h2n9hab72; Fri, 04 Sep 2009 17:45:48 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <4AA1B4BC.2080306@freebsd.org> Date: Fri, 04 Sep 2009 17:45:48 -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: Andrey Chernov , current@freebsd.org, lev@freebsd.org References: <20090904055607.GA89117@nagual.pp.ru> In-Reply-To: <20090904055607.GA89117@nagual.pp.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: 'svn add' does not add 'svn:keywords', but 'svn ci' ask for it X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 00:45:51 -0000 Andrey Chernov wrote: > 1) svn add some_file > 2) svn ci some_file > svn: Commit blocked by pre-commit hook (exit code 1) with output: > Path ".../some_file" is missing the > svn:keywords property (or an fbsd:nokeywords override) > > I manage it adding by hand: > 3) svn propset svn:keywords 'FreeBSD:%H' some_file > > It isn't convenient. Why 'svn add' can't do it automatically for > me using the same detection method as 'svn ci'? The "svn ci" check is done on the server, and subversion does not allow the server checks to change the commit in any way. The server-side hooks can only inspect the commit and choose whether or not to permit it. The "svn add" command doesn't talk to the server at all; it only modifies the pending update on the local client. As I think others have pointed out, the standard "svn" command-line tool does have an option to automatically set certain properties depending on the file type. I believe this check is only done for "svn add." Tim From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 05:42:41 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 52E74106566C for ; Sat, 5 Sep 2009 05:42:41 +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 D0AA28FC0C for ; Sat, 5 Sep 2009 05:42:40 +0000 (UTC) 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 253495155; Sat, 05 Sep 2009 08:42:37 +0300 Message-ID: <4AA1FA41.1030804@FreeBSD.org> Date: Sat, 05 Sep 2009 08:42:25 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20090901) MIME-Version: 1.0 To: Matthew Dillon References: <4AA03346.5010608@FreeBSD.org> <200909032210.n83MA67F059073@apollo.backplane.com> <200909042314.n84NEMAS072077@apollo.backplane.com> In-Reply-To: <200909042314.n84NEMAS072077@apollo.backplane.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Ryan Rogers , current@freebsd.org Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 05:42:41 -0000 Matthew Dillon wrote: > :> The physio code directly maps the userland buffer via vmapbuf() and > :> supplies it as a BIO to the device. The ATA driver does not use > :> BUSDMA (and never has)... it assumes BIOs are minimally aligned. > : > :Wrong. > > By the way Scott, do you honestly believe that idiotic one-line > answers just as a means to try to screw over my postings are > appropriate for someone of your standing in the FreeBSD community? His answer is short, but correct, because all ATA drivers do use BUSDMA. And as I have already said, BUSDMA manages proper alignment there, by implementing bounce buffers. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 07:12: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 C65161065670; Sat, 5 Sep 2009 07:12:00 +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 3F7C88FC17; Sat, 5 Sep 2009 07:12:00 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n857BwmK076833; Sat, 5 Sep 2009 00:11:58 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n857Btwx076830; Sat, 5 Sep 2009 00:11:55 -0700 (PDT) Date: Sat, 5 Sep 2009 00:11:55 -0700 (PDT) From: Matthew Dillon Message-Id: <200909050711.n857Btwx076830@apollo.backplane.com> To: Alexander Motin References: <4AA03346.5010608@FreeBSD.org> <200909032210.n83MA67F059073@apollo.backplane.com> <200909042314.n84NEMAS072077@apollo.backplane.com> <4AA1FA41.1030804@FreeBSD.org> Cc: Ryan Rogers , current@FreeBSD.org Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 07:12:00 -0000 :> :> By the way Scott, do you honestly believe that idiotic one-line :> answers just as a means to try to screw over my postings are :> appropriate for someone of your standing in the FreeBSD community? : :His answer is short, but correct, because all ATA drivers do use BUSDMA. :And as I have already said, BUSDMA manages proper alignment there, by :implementing bounce buffers. : :-- :Alexander Motin Perhaps, but it is hardly a civilized conversation. If he is going to act like an asshole on the lists, then he can stew in his own juices for all I care, or not post at all. But acting in such an infantile manner is something I will not tolerate. I really don't care if he maps me out of his mail server or not, but playing the 'last word' game is something only a 5-year-old would do and he's a lot older then 5 years old. I do see the FBsd ATA driver is using busdma, so I was incorrect there. It is also preallocating bounce buffers on a per-slot basis, so you shouldn't get allocation failures later on at load-time (though it's a bit unclear if the bounce zone limitations can cause a later bus dma load to fail if insufficient bounce buffers are available, and allocating bounce buffers per slot can lead to a large multiplication of wired memory reserved). I guess it will work even if it isn't pretty. I think there was another issue with ATAPI transfers... something related to the DMA having to be in multiples of 16 bytes (on older chipsets anyway), but SCSI has no such restriction so pass-through commands would not always be properly encapsulated into an ATAPI transfer. I can't find a code reference for it but I remember there being some sort of related issue. In anycase, the bounce zone mess was why I eventually started doing at least a minimal alignment closer to the user<->kernel interface, where the kernel could safely allocated memory M_WAITOK. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 08:34: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 B9844106568D for ; Sat, 5 Sep 2009 08:34:13 +0000 (UTC) (envelope-from michel.junger@gmail.com) Received: from smtp19.orange.fr (smtp19.orange.fr [80.12.242.17]) by mx1.freebsd.org (Postfix) with ESMTP id 53E8A8FC19 for ; Sat, 5 Sep 2009 08:34:13 +0000 (UTC) Received: from smtp19.orange.fr (mwinf1929 [172.22.129.129]) by mwinf1915.orange.fr (SMTP Server) with ESMTP id 7E2DF1C021B4 for ; Sat, 5 Sep 2009 09:14:14 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1929.orange.fr (SMTP Server) with ESMTP id 1562D20000AC for ; Sat, 5 Sep 2009 09:14:13 +0200 (CEST) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1929.orange.fr (SMTP Server) with ESMTP id 0805D20000B1 for ; Sat, 5 Sep 2009 09:14:13 +0200 (CEST) Received: from gmail.com (ADijon-551-1-18-231.w86-204.abo.wanadoo.fr [86.204.25.231]) by mwinf1929.orange.fr (SMTP Server) with SMTP id 153E120000AC for ; Sat, 5 Sep 2009 09:14:10 +0200 (CEST) X-ME-UUID: 20090905071410870.153E120000AC@mwinf1929.orange.fr Received: by gmail.com (nbSMTP-1.00) for uid 1001 michel.junger@gmail.com; Sat, 5 Sep 2009 09:12:51 +0200 (CEST) Date: Sat, 5 Sep 2009 09:12:51 +0200 From: michel Junger To: freebsd-current@freebsd.org Message-ID: <20090905071250.GA9367@mua.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: 8.0BETA3 on eee1005ha-h, hardware & acpi issues. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 08:34:13 -0000 Hello, I'm trying to install freebsd on an asus eee1005ha-h. I made the installation using 8.0BETA3 with an usb stick. Some things don't work as expected or don't work at all. And more disturbing, some things work but I don't understand why !? Here is a list of what is already done with questions for points that are unclear to me. == things ok without doing anything == - The ethernet network adapter use the alc driver, no problem. - Function keys : backlight control buttons ( fn + f5, f6 ) . - The sleep button ( fn+f1 ) works too, but you need to make some configuration to have a working sleep mode. == Trouble with ACPI & S3 mode == It was more difficult to get S3 mode working correctly, apparently freebsd and acpi on this machine don't work well together. - In /boot/loader.conf, the line with hint.apic.0.disabled is the most important. - I put hw.pci.do_power_nodriver and kern.hz because I read about those variables in the eee wiki page but I don't know why are they usefull. It seems that several values are possible for do_power_nodriver, maybe 2 or 3 unfortunately I don't know which one is the best ? The same for kern.hz, why 100 ? Maybe there's a better value than 100 ? it would be nice if someone can give me some clue. hint.apic.0.disabled="1" hw.pci.do_power_nodriver=1 kern.hz=100 - The handbook explains how to disassemble the acpi instructions. In the generated code several window versions are listed, linux is also present but no *bsd ... What a surprise! As said in the handbook I put an osname compatible with the acpi code. hw.acpi.osname="Windows 2001" - I also had this line. It's necessary to still have the mouse when resuming from S3 mode. hint.psm.0.flags="0x3000" When S3 sleep is ok ( tested with sync & acpiconf -s S3, be prepare to violent reboot ), I put the following two lines in /etc/sysctl.conf. This done, typing fn+f1 or closing the lid is equivalent to "Enter S3 mode now". hw.acpi.sleep_button_state=S3 hw.acpi.lid_switch_state=S3 == Things that don't work correctly == - I put hw.acpi.reset_video=1 in /etc/sysctl.conf but during few seconds after waking up from S3 sleep the display is full of "garbage". - Sound works with snd_hda.ko module. But if you go in S3 mode, even if you have unload snd_hda before, when the system wake up and you reload the snd_hda module, the sound card is well recognized but it doesn't work (no sound) at all. Is there a "trick" to completely re-init sound card ? - xorg works ( Driver "intel"), but when you're under X11 if you decide to return to a text console, the screen is suddenly filled with horizontal green and black stripes. After that you're just able to properly reboot with ctrl+alt+suppr. It looks like the operating system is running with a video console broken. On the other hand switching to S3 mode while in X11 works fine. Things I didn't try to setup : bluetooth / webcam / wifi . Now I need to setup powerd, build a custom kernel, any url, advice is welcome. For example I don't which CPUTYPE to use for Atom N280 processor ? I was helped by the freebsd eee wiki page and the handbook. The acpi chapter in the handbook is a must-read. As explained by the handbook I've put result of "boot -v", "acpidump -dt" and "sysctl hw.acpi." in files donwloaded at : http://mjunger.atspace.com/fbsd/ If some "acpi guru" can see obvious mistakes, it'll be great. Michel. From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 14:59: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 46654106566B for ; Sat, 5 Sep 2009 14:59:42 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 929D28FC08 for ; Sat, 5 Sep 2009 14:59:41 +0000 (UTC) Received: (qmail invoked by alias); 05 Sep 2009 14:32:58 -0000 Received: from 85-127-83-116.dynamic.xdsl-line.inode.at (EHLO taxman.pepperland) [85.127.83.116] by mail.gmx.net (mp010) with SMTP; 05 Sep 2009 16:32:58 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX18tLLVGwRotpOn138Jt9pPKDUffIVabPy6Dzigu0d D12ihECXXRxklw From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Sat, 5 Sep 2009 16:32:55 +0200 User-Agent: KMail/1.12.1 (FreeBSD/8.0-BETA4; KDE/4.3.1; i386; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200909051632.55580.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Subject: ukbd: short freeze when activating LEDs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 14:59:42 -0000 I recently switched from a PS/2 keyboard to USB. Whenever I press capslock/numlock, the system shortly (< 0.5 ms) freezes. The LEDs are switched on/off after that short delay. This also happens when I switch between virtual consoles using ALT+F[0-9]. Using a USB->PS/2 adapter, the keyboard doesn't show that behavior. Otherwise it is working fine. ukbd0: on usbus0 kbd2 at ukbd0 This is on 8.0-BETA4/i386. From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 15:05: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 32681106566B for ; Sat, 5 Sep 2009 15:05:39 +0000 (UTC) (envelope-from billsf@cuba.calyx.nl) Received: from cuba.calyx.nl (cuba.calyx.nl [213.130.163.36]) by mx1.freebsd.org (Postfix) with ESMTP id F1D238FC12 for ; Sat, 5 Sep 2009 15:05:38 +0000 (UTC) Received: by cuba.calyx.nl (Postfix, from userid 1000) id 07CC8197BE34; Sat, 5 Sep 2009 17:05:38 +0200 (CEST) Date: Sat, 5 Sep 2009 17:05:37 +0200 From: Bill Squire {billsf} To: freebsd-current@freebsd.org Message-ID: <20090905150537.GA78983@cuba.calyx.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: v9.0 treating me very well X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 15:05:39 -0000 Hi current-users, Surely we want v8.0 to work right, but many of the complaints I see have already been fixed in v9.0 Its not my call (no way will use a Generic kernel) but please consider your configurations carefully. If you want to do both you need a separate base install and a /var. I put multiple base-installs on flash ROM drives. Be sure they don't 'require MSDOSFS' to work, but be prepared to put it back and take it back. (see the ports or emulate, also in the ports) Hint: 2GiB drives made by a manufacturer I've taken many larger ones back so I refuse to advertise then, particularly since they have discontinued that model. Hint: Its a place close to namesake of this server I'm using. PS: The low-cost (and best sounding) USB chips work out of the box, now on v9.0 so if you have these try it out. I use balanced audio and have really decent speakers -- You know if you read my previous posts. Bill Squire From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 15:56: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 869211065670; Sat, 5 Sep 2009 15:56:59 +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 5D0618FC17; Sat, 5 Sep 2009 15:56:59 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n85Futln080959; Sat, 5 Sep 2009 08:56:55 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n85Futap080958; Sat, 5 Sep 2009 08:56:55 -0700 (PDT) Date: Sat, 5 Sep 2009 08:56:55 -0700 (PDT) From: Matthew Dillon Message-Id: <200909051556.n85Futap080958@apollo.backplane.com> To: Alexander Motin , Scott Long , Ryan Rogers , current@FreeBSD.org References: <4AA03346.5010608@FreeBSD.org> <200909032210.n83MA67F059073@apollo.backplane.com> <200909042314.n84NEMAS072077@apollo.backplane.com> <4AA1FA41.1030804@FreeBSD.org> Cc: Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 15:56:59 -0000 Ah, I found the code reference. This is something I had to throw into DFly's version of the ATA driver: /* * Don't allow DMA for requests with length not multiple of 16 bytes. * Some ATAPI devices don't like it. */ if ((softc->atadev[tid]->mode >= ATA_DMA) && len > 0 && !(len & 15)) request_flags |= ATA_R_DMA; It turns out that for non-SATA (older) chipsets ATAPI command DMA is speced to only run in multiples of 16 bytes. If an ATAPI request buffer is not a multiple of 16 bytes the two choices are to either (1) PAD the request buffer to 16 bytes or (2) Not use a DMA transfer mode. I eventually chose (2). The issue with (1) is that the busdma subsystem doesn't really have a way to specify a length alignment requirement, only a base offset alignment requirement, and buffer passed from userland might be declared on the stack so unlike buffers passed by the kernel there may not be any extra play in the buffer which allows one to simply DMA a little bit more into it. I'm fairly sure that SATA chipsets don't care, this seems to be an issue with pre-SATA chipsets. -Matt From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 16:02:15 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 416661065694 for ; Sat, 5 Sep 2009 16:02:15 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id CB00D8FC13 for ; Sat, 5 Sep 2009 16:02:14 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=HZ8Y2r5GBf4A:10 a=hlIU1J3LQChSjWV/CGRL5g==:17 a=yk3i9zUPt_rtMNkf-DQA:9 a=e61jST9r6rGHg91t4eMxtMME2SYA:4 Received: from [193.217.167.6] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1316094060; Sat, 05 Sep 2009 18:02:12 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 5 Sep 2009 18:02:37 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200909051632.55580.shoesoft@gmx.net> In-Reply-To: <200909051632.55580.shoesoft@gmx.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909051802.37902.hselasky@c2i.net> Cc: Stefan Ehmann Subject: Re: ukbd: short freeze when activating LEDs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 16:02:15 -0000 On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote: > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) freezes. How did you measure this? Are you able to figure out why it is hanging? Has this got anything to do with BIOS or microcode running on the CPU? USB keyboard LEDs are set asynchronously. It should not block like you explain. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 16:05: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 F2FDB106566B for ; Sat, 5 Sep 2009 16:05:43 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 89C268FC14 for ; Sat, 5 Sep 2009 16:05:43 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=HZ8Y2r5GBf4A:10 a=hlIU1J3LQChSjWV/CGRL5g==:17 a=M7SfUVd05sFvxA9UuTUA:9 a=Uv-fEwQ5J54KeR-v_3B0VqT8aQcA:4 Received: from [193.217.167.6] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1316094424; Sat, 05 Sep 2009 18:05:42 +0200 To: freebsd-current@freebsd.org Content-Disposition: inline From: Hans Petter Selasky X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpO< =?iso-8859-1?q?Q0yAl=7E=3F=60=27F=3FjDVb=5DE6TQ7=27=23h-VlLs=7Dk/=0A=09?=(yxg(p!IL.`#ng"%`BMrham7%UK,}VH\wUOm=^>wEEQ+KWt[{J#x6ow~JO:,zwp.(t; @ =?iso-8859-1?q?Aq=0A=09=3A4=3A=26nFCgDb8=5B3oIeTb=5E=27?=",; u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv Date: Sat, 5 Sep 2009 18:06:06 +0200 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909051806.07692.hselasky@c2i.net> Cc: Stefan Ehmann Subject: Re: ukbd: short freeze when activating LEDs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 16:05:44 -0000 On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote: > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) freezes. It might also be because the USB keyboard driver is using Giant, which can be congested. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 16:47: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 88EF2106566C for ; Sat, 5 Sep 2009 16:47:38 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 9D5028FC13 for ; Sat, 5 Sep 2009 16:47:37 +0000 (UTC) Received: (qmail invoked by alias); 05 Sep 2009 16:47:35 -0000 Received: from 85-127-83-116.dynamic.xdsl-line.inode.at (EHLO taxman.pepperland) [85.127.83.116] by mail.gmx.net (mp062) with SMTP; 05 Sep 2009 18:47:35 +0200 X-Authenticated: #16703784 X-Provags-ID: V01U2FsdGVkX19HN0YicvVHo0uViwkm6hMOepsB4SQV0sMtHaPvqQ iJC8/vKE0qMCKj From: Stefan Ehmann To: Hans Petter Selasky Date: Sat, 5 Sep 2009 18:47:32 +0200 User-Agent: KMail/1.12.1 (FreeBSD/8.0-BETA4; KDE/4.3.1; i386; ; ) References: <200909051632.55580.shoesoft@gmx.net> <200909051802.37902.hselasky@c2i.net> In-Reply-To: <200909051802.37902.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200909051847.32946.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.53 Cc: freebsd-current@freebsd.org Subject: Re: ukbd: short freeze when activating LEDs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 16:47:38 -0000 On Saturday 05 September 2009 18:02:37 you wrote: > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote: > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) freezes. > > How did you measure this? The mouse is not responding and sound also stops during that period. It's probably much shorter, more likely 0.1-0.2ms. > Are you able to figure out why it is hanging? > > Has this got anything to do with BIOS or microcode running on the CPU? No idea. top shows > 95% interrupt if I'm on the console, in xorg the cpu goes to system. Interestingly, the number of interrupts displayed by systat is very moderate (if I just move the mouse, it's much higher) > USB keyboard LEDs are set asynchronously. It should not block like you > explain. The keyboard works fine on my notebook. I think the problem is the USB controller on my PC, not the keyboard driver. dmesg reports it as uhci0: port 0xb400-0xb41f at device 16.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x003a usbus0: on uhci0 Historically, I've always had lots of trouble with USB on this particular PC. With the old USB code, I've got lots of issues. scanner didn't work at all, sometimes even problems with basic things like umass. With new USB things are much better, but not always perfect. If there's no easy way to debug, it's probably not worth the hassle. The PC is nearing the end of its life-time anyway. -- Thanks, Stefan From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 17:17: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 8743A1065672 for ; Sat, 5 Sep 2009 17:17:58 +0000 (UTC) (envelope-from bw@exodus.desync.com) Received: from exodus.desync.com (exodus.desync.com [IPv6:2607:f178::164]) by mx1.freebsd.org (Postfix) with ESMTP id 35C188FC0A for ; Sat, 5 Sep 2009 17:17:57 +0000 (UTC) Received: from exodus.desync.com (localhost [127.0.0.1]) by exodus.desync.com (8.14.3/8.14.3) with ESMTP id n85HHuR6069830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 5 Sep 2009 13:17:56 -0400 (EDT) (envelope-from bw@exodus.desync.com) Received: (from bw@localhost) by exodus.desync.com (8.14.3/8.14.2/Submit) id n85HHuV0069829 for freebsd-current@freebsd.org; Sat, 5 Sep 2009 13:17:56 -0400 (EDT) (envelope-from bw) Date: Sat, 5 Sep 2009 13:17:56 -0400 From: ben wilber To: FreeBSD CURRENT Mailing List Message-ID: <20090905171756.GA2827@exodus.desync.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Angst-Level: High User-Agent: Mutt/1.5.20 (2009-06-14) Subject: ipv6 addresses on loopback 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: Sat, 05 Sep 2009 17:17:58 -0000 Hello, It looks like IPv6 addresses bound to loopback interfaces no longer work. % ifconfig lo0 lo0: flags=8049 metric 0 mtu 16384 options=3 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5 inet6 2607:f178:0:3::12 prefixlen 128 % route -n get -inet6 2607:f178:0:3::12 route to: 2607:f178:0:3::12 destination: :: mask: default gateway: 2607:f178::1 interface: mxge0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 % uname -a FreeBSD exodus 9.0-CURRENT FreeBSD 9.0-CURRENT #8: Sat Sep 5 10:23:33 EDT 2009 bw@exodus:/usr/obj/usr/src/sys/COMRADE amd64 bw. From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 17:40: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 9E5E71065698 for ; Sat, 5 Sep 2009 17:40:42 +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 066328FC1A for ; Sat, 5 Sep 2009 17:40:41 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=HZ8Y2r5GBf4A:10 a=hlIU1J3LQChSjWV/CGRL5g==:17 a=Xr4jvITCnfzBP_cAE6QA:9 a=8ALqLP3ezsgIOR3OBISrpix9TGQA:4 a=4EdWEy84jLFuwBtr:21 a=P3xhUJKicS87pXW9:21 Received: from [193.217.167.6] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1202895591; Sat, 05 Sep 2009 19:40:40 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 5 Sep 2009 19:41:02 +0200 User-Agent: KMail/1.11.4 (FreeBSD/9.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200909051632.55580.shoesoft@gmx.net> <200909051802.37902.hselasky@c2i.net> <200909051847.32946.shoesoft@gmx.net> In-Reply-To: <200909051847.32946.shoesoft@gmx.net> X-Face: (%:6u[ldzJ`0qjD7sCkfdMmD*RxpOwEEQ+KWt[{J#x6ow~JO:,zwp.(t; @Aq :4:&nFCgDb8[3oIeTb^'",;u{5{}C9>"PuY\)!=#\u9SSM-nz8+SR~B\!qBv MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909051941.03766.hselasky@c2i.net> Cc: Stefan Ehmann Subject: Re: ukbd: short freeze when activating LEDs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 17:40:42 -0000 On Saturday 05 September 2009 18:47:32 Stefan Ehmann wrote: > On Saturday 05 September 2009 18:02:37 you wrote: > > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote: > > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) > > > freezes. > > > > How did you measure this? > > The mouse is not responding and sound also stops during that period. > It's probably much shorter, more likely 0.1-0.2ms. > > > Are you able to figure out why it is hanging? > > > > Has this got anything to do with BIOS or microcode running on the CPU? > > No idea. top shows > 95% interrupt if I'm on the console, in xorg the cpu > goes to system. Interestingly, the number of interrupts displayed by systat > is very moderate (if I just move the mouse, it's much higher) > > > USB keyboard LEDs are set asynchronously. It should not block like you > > explain. > > The keyboard works fine on my notebook. I think the problem is the USB > controller on my PC, not the keyboard driver. dmesg reports it as > uhci0: port 0xb400-0xb41f at device 16.0 on > pci0 uhci0: [ITHREAD] > uhci0: LegSup = 0x003a > usbus0: on uhci0 > > Historically, I've always had lots of trouble with USB on this particular > PC. With the old USB code, I've got lots of issues. scanner didn't work at > all, sometimes even problems with basic things like umass. > > With new USB things are much better, but not always perfect. > > If there's no easy way to debug, it's probably not worth the hassle. The PC > is nearing the end of its life-time anyway. I see. Your observation is interesting and valuable. It might look like some piece of hardware is excessively using the RAM. Maybe an USB recording off the USB cable will give the final answer. There are some relatively cheap USB analyzers from Beagle which you can buy. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 18:20: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 271351065697 for ; Sat, 5 Sep 2009 18:20:34 +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 EBDD28FC18 for ; Sat, 5 Sep 2009 18:20:33 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id n85IKReq013128; Sat, 5 Sep 2009 11:20:28 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 5 Sep 2009 11:11:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ipv6 addresses on loopback broken Thread-Index: AcouTOSJ6PFuDHGNSjaOh0CKrxaNEAAB1krZ References: <20090905171756.GA2827@exodus.desync.com> From: "Li, Qing" To: "ben wilber" , "FreeBSD CURRENT Mailing List" Cc: Subject: RE: ipv6 addresses on loopback 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: Sat, 05 Sep 2009 18:20:34 -0000 > > It looks like IPv6 addresses bound to loopback interfaces no longer > work. > Please apply patch http://people.freebsd.org/~qingli/qing-ipv6-patch-9-5-1100.diff and let me how it works. In the meantime, I will do more testing on it. Thanks, -- Qing From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 18:29: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 D66541065670 for ; Sat, 5 Sep 2009 18:29:30 +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 7B3AF8FC0C for ; Sat, 5 Sep 2009 18:29:30 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 97AD91CE90; Sat, 5 Sep 2009 20:29:29 +0200 (CEST) Date: Sat, 5 Sep 2009 20:29:29 +0200 From: Ed Schouten To: Hans Petter Selasky Message-ID: <20090905182929.GB2829@hoeg.nl> References: <200909051806.07692.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LF/YhktBJmDzOfS4" Content-Disposition: inline In-Reply-To: <200909051806.07692.hselasky@c2i.net> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, Stefan Ehmann Subject: Re: ukbd: short freeze when activating LEDs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 18:29:30 -0000 --LF/YhktBJmDzOfS4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Hans Petter Selasky wrote: > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote: > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) freeze= s. >=20 > It might also be because the USB keyboard driver is using Giant, which ca= n be=20 > congested. For half a second? I experience the same issue. I also have the same issue with the Syscons VGA driver when switching windows. Some time ago I talked about this with some other people and it may be possible it has something to do with SMIs. Not sure... --=20 Ed Schouten WWW: http://80386.nl/ --LF/YhktBJmDzOfS4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkqirgkACgkQ52SDGA2eCwVwbACaAxBHc13JxBcGgNP+H1vDGix7 mD0An3JV7dPq+oJMyeb02xM/QfahPEmb =gVqn -----END PGP SIGNATURE----- --LF/YhktBJmDzOfS4-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 18:59: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 47EC11065670 for ; Sat, 5 Sep 2009 18:59:18 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id 23EFE8FC19 for ; Sat, 5 Sep 2009 18:59:18 +0000 (UTC) Received: from unknown (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id E46368471; Sat, 5 Sep 2009 18:59:16 +0000 (UTC) Date: Sat, 5 Sep 2009 19:59:13 +0100 From: Bruce Cran To: current@freebsd.org, bzeeb+freebsd+lor@zabbadoz.net Message-ID: <20090905195913.0000358e@unknown> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: LOR: kern_exec.c and vfs_cache.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: Sat, 05 Sep 2009 18:59:18 -0000 I got this LOR on 8.0-BETA3 when running pmcstat: lock order reversal: 1st 0xc55716a0 ufs (ufs) @ /usr/src/sys/kern/kern_exec.c:570 2nd 0xc98f5a2c filedesc structure (filedesc structure) @ /usr/src/sys/kern/vfs_cache.c:999 KDB: stack backtrace: db_trace_self_wrapper(c0c6be4a,e6b5494c,c08bd7f5,c08ae67b,c0c6ed1d,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08ae67b,c0c6ed1d,c452f500,c452c1d0,e6b549a8,...) at kdb_backtrace+0x29 _witness_debugger(c0c6ed1d,c98f5a2c,c0c638c6,c452c1d0,c0c74e88,...) at _witness_debugger+0x25 witness_checkorder(c98f5a2c,1,c0c74e88,3e7,0,...) at witness_checkorder+0x839 _sx_slock(c98f5a2c,0,c0c74e88,3e7,c497a6c0,...) at _sx_slock+0x85 vn_fullpath(c497a6c0,c5571648,e6b54aa4,e6b54aa0,0,...) at vn_fullpath+0x74 pmc_getfilename(c0c60fc0,3,c497a6c0,e6b54a60,246,...) at pmc_getfilename+0x2e pmc_hook_handler(c497a6c0,1,e6b54c1c,318,c0c90edb,...) at pmc_hook_handler+0x279 kern_execve(c497a6c0,e6b54c58,0,283052a8,28305348,e164d000,e164d000,e164d020,e164d485,e168d000,3fb7b,3,24,0) at kern_execve+0xe1c execve(c497a6c0,e6b54cfc,c,c497a6c0,c0d4e474,...) at execve+0x4c syscall(e6b54d38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (59, FreeBSD ELF32, execve), eip = 0x28173eaf, esp = 0xbfbfe34c, ebp = 0xbfbfe378 --- -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 19:06: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 95DCB106566B for ; Sat, 5 Sep 2009 19:06:47 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (muon.cran.org.uk [66.246.138.153]) by mx1.freebsd.org (Postfix) with ESMTP id 707618FC1A for ; Sat, 5 Sep 2009 19:06:47 +0000 (UTC) Received: from unknown (87-194-158-129.bethere.co.uk [87.194.158.129]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA id 64BDD8479; Sat, 5 Sep 2009 19:06:46 +0000 (UTC) Date: Sat, 5 Sep 2009 20:06:53 +0100 From: Bruce Cran To: Ed Schouten Message-ID: <20090905200653.000057c8@unknown> In-Reply-To: <20090905182929.GB2829@hoeg.nl> References: <200909051806.07692.hselasky@c2i.net> <20090905182929.GB2829@hoeg.nl> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.0; i586-pc-mingw32msvc) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Stefan Ehmann , Hans Petter Selasky Subject: Re: ukbd: short freeze when activating LEDs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 19:06:47 -0000 On Sat, 5 Sep 2009 20:29:29 +0200 Ed Schouten wrote: > * Hans Petter Selasky wrote: > > On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote: > > > Whenever I press capslock/numlock, the system shortly (< 0.5 ms) > > > freezes. > > > > It might also be because the USB keyboard driver is using Giant, > > which can be congested. > > For half a second? I experience the same issue. I also have the same > issue with the Syscons VGA driver when switching windows. Some time > ago I talked about this with some other people and it may be possible > it has something to do with SMIs. Not sure... > Half a millisecond or, as reported in another message, 100us :) I suspect the OP probably did mean 0.5s, a pause which someone can both see and hear. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 19:33: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 955C6106566B; Sat, 5 Sep 2009 19:33:18 +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 4247C8FC12; Sat, 5 Sep 2009 19:33:18 +0000 (UTC) Received: from [IPv6:::1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n85JVvGg011353; Sat, 5 Sep 2009 13:31:57 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Scott Long In-Reply-To: <4AA1FA41.1030804@FreeBSD.org> Date: Sat, 5 Sep 2009 13:31:56 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <4AA03346.5010608@FreeBSD.org> <200909032210.n83MA67F059073@apollo.backplane.com> <200909042314.n84NEMAS072077@apollo.backplane.com> <4AA1FA41.1030804@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1075.2) X-Spam-Status: No, score=-2.6 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Ryan Rogers , current@freebsd.org Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 19:33:18 -0000 On Sep 4, 2009, at 11:42 PM, Alexander Motin wrote: > Matthew Dillon wrote: >> :> The physio code directly maps the userland buffer via vmapbuf >> () and >> :> supplies it as a BIO to the device. The ATA driver does not >> use >> :> BUSDMA (and never has)... it assumes BIOs are minimally >> aligned. >> : >> :Wrong. >> >> By the way Scott, do you honestly believe that idiotic one-line >> answers just as a means to try to screw over my postings are >> appropriate for someone of your standing in the FreeBSD community? > > His answer is short, but correct, because all ATA drivers do use > BUSDMA. > And as I have already said, BUSDMA manages proper alignment there, by > implementing bounce buffers. > Matt typically doesn't listen to what others have to say in disagreement anyways, so I didn't see a whole lot of value in wasting my time with long answers with him. However, others have asked me for more thorough explanations in private, and I'll attempt to provide them here: 1. Alexander is correct, ata has used busdma for many years. This may be different in DillonBSD, but we're talking about FreeBSD here. As such, it was hard to engage further in the conversation given the basic disconnect in understanding. 2. The CAM passthrough doesn't care a whole lot about alignment because alignment is the concern of the SIMs in conjunction with busdma, not the periph and transport layers of CAM. There is one exception to this, which is the physaddr data transfer mode in CAM. busdma doesn't understand this mode. However, nothing in FreeBSD uses this mode; it's a legacy remnant from many years ago. Most SIMs choose to ignore this interface anyways (recall that SIMs are responsible for alignment, not the rest of CAM), so it's not an issue except on a small selection of hardware, using custom software (i.e. close source large appliance software not found in the ports tree) that deliberately selects the interface. 3. Adding alignment bouncing logic to every driver in the tree is silly when it already exists in busdma. Granted, I didn't implement this feature very well originally, so there were bugs that made it less useful. However, I think that most of those bugs have been fixed, and any that remain can and should be fixed. 4. The vast majority of the storage drivers in the tree use busdma and use it correctly for deferred loads. This wasn't the case many years ago, and may not be the case in DillonBSD, but again, we're talking about FreeBSD here. There might be a few drivers left that don't fully conform to the API (ATA was a big one, which is one of the many reasons that the new generation of SATA drivers was written), and I'm happy to help others fix any drivers that remain and are causing problems. Again, I'm happy to discuss this further. I apologize for the terse answers to the community, and I hope this has cleared up the problem. Scott From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 19:41:51 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 7FE681065670 for ; Sat, 5 Sep 2009 19:41:51 +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 180E98FC0A for ; Sat, 5 Sep 2009 19:41:50 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n85Jfhr5014189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Sep 2009 22:41:43 +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 n85JfhaP000786; Sat, 5 Sep 2009 22:41:43 +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 n85JfhcM000785; Sat, 5 Sep 2009 22:41:43 +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: Sat, 5 Sep 2009 22:41:43 +0300 From: Kostik Belousov To: Bruce Cran Message-ID: <20090905194142.GE47688@deviant.kiev.zoral.com.ua> References: <20090905195913.0000358e@unknown> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZRyEpB+iJ+qUx0kp" Content-Disposition: inline In-Reply-To: <20090905195913.0000358e@unknown> 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: bzeeb+freebsd+lor@zabbadoz.net, current@freebsd.org Subject: Re: LOR: kern_exec.c and vfs_cache.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: Sat, 05 Sep 2009 19:41:51 -0000 --ZRyEpB+iJ+qUx0kp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 05, 2009 at 07:59:13PM +0100, Bruce Cran wrote: > I got this LOR on 8.0-BETA3 when running pmcstat: >=20 > lock order reversal: > 1st 0xc55716a0 ufs (ufs) @ /usr/src/sys/kern/kern_exec.c:570 > 2nd 0xc98f5a2c filedesc structure (filedesc structure) > @ /usr/src/sys/kern/vfs_cache.c:999 KDB: stack backtrace: > db_trace_self_wrapper(c0c6be4a,e6b5494c,c08bd7f5,c08ae67b,c0c6ed1d,...) > at db_trace_self_wrapper+0x26 > kdb_backtrace(c08ae67b,c0c6ed1d,c452f500,c452c1d0,e6b549a8,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c6ed1d,c98f5a2c,c0c638c6,c452c1d0,c0c74e88,...) at > _witness_debugger+0x25 > witness_checkorder(c98f5a2c,1,c0c74e88,3e7,0,...) at > witness_checkorder+0x839 > _sx_slock(c98f5a2c,0,c0c74e88,3e7,c497a6c0,...) at _sx_slock+0x85 > vn_fullpath(c497a6c0,c5571648,e6b54aa4,e6b54aa0,0,...) at > vn_fullpath+0x74 pmc_getfilename(c0c60fc0,3,c497a6c0,e6b54a60,246,...) > at pmc_getfilename+0x2e > pmc_hook_handler(c497a6c0,1,e6b54c1c,318,c0c90edb,...) at > pmc_hook_handler+0x279 > kern_execve(c497a6c0,e6b54c58,0,283052a8,28305348,e164d000,e164d000,e164d= 020,e164d485,e168d000,3fb7b,3,24,0) > at kern_execve+0xe1c execve(c497a6c0,e6b54cfc,c,c497a6c0,c0d4e474,...) > at execve+0x4c syscall(e6b54d38) at syscall+0x2a3 Xint0x80_syscall() at > Xint0x80_syscall+0x20 --- syscall (59, FreeBSD ELF32, execve), eip =3D > 0x28173eaf, esp =3D 0xbfbfe34c, ebp =3D 0xbfbfe378 --- The following should fix the LOR and make vfs_mark_atime more resistent to the supplied doomed vnode. diff --git a/sys/kern/kern_exec.c b/sys/kern/kern_exec.c index e770d07..a90968f 100644 --- a/sys/kern/kern_exec.c +++ b/sys/kern/kern_exec.c @@ -786,10 +786,12 @@ interpret: */ if (PMC_SYSTEM_SAMPLING_ACTIVE() || PMC_PROC_IS_USING_PMCS(p)) { PROC_UNLOCK(p); + VOP_UNLOCK(imgp->vp, 0); pe.pm_credentialschanged =3D credential_changing; pe.pm_entryaddr =3D imgp->entry_addr; =20 PMC_CALL_HOOK_X(td, PMC_FN_PROCESS_EXEC, (void *) &pe); + vn_lock(imgp->vp, LK_EXCLUSIVE | LK_RETRY); } else PROC_UNLOCK(p); #else /* !HWPMC_HOOKS */ diff --git a/sys/kern/vfs_subr.c b/sys/kern/vfs_subr.c index 3beb881..f3ec565 100644 --- a/sys/kern/vfs_subr.c +++ b/sys/kern/vfs_subr.c @@ -4269,8 +4269,12 @@ vfs_read_dirent(struct vop_readdir_args *ap, struct = dirent *dp, off_t off) void vfs_mark_atime(struct vnode *vp, struct ucred *cred) { + struct mount *mp; =20 - if ((vp->v_mount->mnt_flag & (MNT_NOATIME | MNT_RDONLY)) =3D=3D 0) + mp =3D vp->v_mount; + VFS_ASSERT_GIANT(mp); + ASSERT_VOP_LOCKED(vp, "vfs_mark_atime"); + if (mp !=3D NULL && (mp->mnt_flag & (MNT_NOATIME | MNT_RDONLY)) =3D=3D 0) (void)VOP_MARKATIME(vp); } =20 --ZRyEpB+iJ+qUx0kp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkqivvUACgkQC3+MBN1Mb4gBDACggJevpaxLVWcwmCzono0FYd3H GEUAn3jOvxujCLQ9F+wFAqtvbCluP7+O =9i/D -----END PGP SIGNATURE----- --ZRyEpB+iJ+qUx0kp-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 19:57: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 9B753106566B for ; Sat, 5 Sep 2009 19:57:59 +0000 (UTC) (envelope-from bw@exodus.desync.com) Received: from exodus.desync.com (exodus.desync.com [IPv6:2607:f178::164]) by mx1.freebsd.org (Postfix) with ESMTP id 480138FC18 for ; Sat, 5 Sep 2009 19:57:59 +0000 (UTC) Received: from exodus.desync.com (localhost [127.0.0.1]) by exodus.desync.com (8.14.3/8.14.3) with ESMTP id n85Jvt7N002639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 5 Sep 2009 15:57:55 -0400 (EDT) (envelope-from bw@exodus.desync.com) Received: (from bw@localhost) by exodus.desync.com (8.14.3/8.14.2/Submit) id n85Jvrs4002637; Sat, 5 Sep 2009 15:57:53 -0400 (EDT) (envelope-from bw) Date: Sat, 5 Sep 2009 15:57:53 -0400 From: ben wilber To: "Li, Qing" Message-ID: <20090905195753.GA2581@exodus.desync.com> References: <20090905171756.GA2827@exodus.desync.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Angst-Level: High User-Agent: Mutt/1.5.20 (2009-06-14) Cc: FreeBSD CURRENT Mailing List Subject: Re: ipv6 addresses on loopback 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: Sat, 05 Sep 2009 19:57:59 -0000 On Sat, Sep 05, 2009 at 11:11:08AM -0700, Li, Qing wrote: > > > > It looks like IPv6 addresses bound to loopback interfaces no longer > > work. > > > > Please apply patch > > http://people.freebsd.org/~qingli/qing-ipv6-patch-9-5-1100.diff > > and let me how it works. In the meantime, I will do more testing > on it. Applied to r196870, problem gone. Thanks, bw. From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 20:04: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 CFABE1065698; Sat, 5 Sep 2009 20:04:54 +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 A7E1C8FC12; Sat, 5 Sep 2009 20:04:54 +0000 (UTC) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n85K4pVn083477; Sat, 5 Sep 2009 13:04:53 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n85K4pvP083476; Sat, 5 Sep 2009 13:04:51 -0700 (PDT) Date: Sat, 5 Sep 2009 13:04:51 -0700 (PDT) From: Matthew Dillon Message-Id: <200909052004.n85K4pvP083476@apollo.backplane.com> To: Scott Long References: <4AA03346.5010608@FreeBSD.org> <200909032210.n83MA67F059073@apollo.backplane.com> <200909042314.n84NEMAS072077@apollo.backplane.com> <4AA1FA41.1030804@FreeBSD.org> Cc: Ryan Rogers , Alexander Motin , current@FreeBSD.org Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 20:04:54 -0000 It's really unfortunate that after all these years you don't seem to know the name of our project. Insofar as listening to people go... I certainly do, as long as they are courteous. But, unfortunately, numerous FreeBSD people, some all the way back to the very day I first became a committer all those years ago, seem to have severe problems interacting with their peers on any level. I guess those people are all running the show now. If this was an attempt at diplomacy, Scott, you could have removed the veiled insults... and it probably would have worked. -Matt From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 20:13: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 475D31065670 for ; Sat, 5 Sep 2009 20:13:27 +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 C77618FC08 for ; Sat, 5 Sep 2009 20:13:26 +0000 (UTC) Received: (qmail 29734 invoked by uid 399); 5 Sep 2009 20:13:19 -0000 Received: from localhost (HELO ?10.9.1.119?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 5 Sep 2009 20:13:19 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4AA2C659.8050800@FreeBSD.org> Date: Sat, 05 Sep 2009 13:13:13 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Vande More References: <20090527134343.GB1104@bsdcrew.de> <85d001330905270909jde4d723s65e8708a8b498c29@mail.gmail.com> <20090527163952.GI1104@bsdcrew.de> <4AA0149E.30209@lapo.it> <6201873e0909031252r41bced2eqe1784a17214f1cd1@mail.gmail.com> <4AA09410.8020302@lapo.it> <6201873e0909040536y2a2c7a22t30247d61adc26318@mail.gmail.com> In-Reply-To: <6201873e0909040536y2a2c7a22t30247d61adc26318@mail.gmail.com> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, "M. Vale" , Lapo Luchini , Martin Wilke Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 20:13:27 -0000 Adam Vande More wrote: > I believe portmaster uses a lot environmental variables, and kBuild does > something funky with them. So technically, the issue lies w/ kBuild, not > portmaster. At least that's what I read. Yes, that's correct. Doug From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 20:20: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 52C90106568D for ; Sat, 5 Sep 2009 20:20:59 +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 E58C78FC16 for ; Sat, 5 Sep 2009 20:20:58 +0000 (UTC) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n85KKu5B015171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 5 Sep 2009 22:20:56 +0200 (CEST) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: From: Stefan Bethke To: Hans Petter Selasky In-Reply-To: <200909012357.42238.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 v936) Date: Sat, 5 Sep 2009 22:20:55 +0200 References: <15577E21-9A9B-45CA-BC56-D1AB1FF6A5A9@lassitu.de> <200909012250.48439.hselasky@c2i.net> <200909012357.42238.hselasky@c2i.net> X-Mailer: Apple Mail (2.936) Cc: freebsd-current@freebsd.org Subject: Re: Elsa MicroLink 56k USB is not picked up by umodem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 05 Sep 2009 20:20:59 -0000 Am 01.09.2009 um 23:57 schrieb Hans Petter Selasky: >> # usbconfig -u 0 -a 3 set_config 1 >> umodem0: > addr >> 3> on usbus0 >> umodem0: data interface 1, has CM over data, has break >> >> Checking quickly with cu, I can make it dial out. > > kldload usb_quirk > > usbconfig dump_quirk_names > > And then run something like: > > usbconfig add_dev_quirk_vplh 0x??? 0x??? 0x0000 0xFFFF UQ_CFG_INDEX_1 > > Will make the quirk permanent. > > If you make a patch for usbdevs and the usb_quirk.c in /sys/dev/usb/ > quirk/ > then I can commit that. Index: usb_quirk.c =================================================================== --- usb_quirk.c (revision 196650) +++ usb_quirk.c (working copy) @@ -94,6 +94,7 @@ {USB_QUIRK_ENTRY(USB_VENDOR_TELEX, USB_PRODUCT_TELEX_MIC1, 0x009, 0x009, UQ_AU_NO_FRAC, UQ_NONE)}, {USB_QUIRK_ENTRY(USB_VENDOR_SILICONPORTALS, USB_PRODUCT_SILICONPORTALS_YAPPHONE, 0x100, 0x100, UQ_AU_INP_ASYNC, UQ_NONE)}, {USB_QUIRK_ENTRY(USB_VENDOR_LOGITECH, USB_PRODUCT_LOGITECH_UN53B, 0x0000, 0xFFFF, UQ_NO_STRINGS, UQ_NONE)}, + {USB_QUIRK_ENTRY(USB_VENDOR_ELSA, USB_PRODUCT_ELSA_MODEM1, 0x0000, 0xFFFF, UQ_CFG_INDEX_1, UQ_NONE)}, /* * XXX The following quirks should have a more specific revision Thanks, Stefan -- Stefan Bethke Fon +49 151 14070811