From owner-freebsd-arch@FreeBSD.ORG Sun May 11 07:51:20 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D9591065677 for ; Sun, 11 May 2008 07:51:20 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by mx1.freebsd.org (Postfix) with ESMTP id 6D3CA8FC18 for ; Sun, 11 May 2008 07:51:20 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wf-out-1314.google.com with SMTP id 28so1762779wfa.7 for ; Sun, 11 May 2008 00:51:20 -0700 (PDT) Received: by 10.142.154.20 with SMTP id b20mr2735136wfe.166.1210492279959; Sun, 11 May 2008 00:51:19 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id 30sm14736630wfa.17.2008.05.11.00.51.17 (version=SSLv3 cipher=RC4-MD5); Sun, 11 May 2008 00:51:18 -0700 (PDT) Date: Sat, 10 May 2008 21:53:12 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Kostik Belousov In-Reply-To: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> Message-ID: <20080510214812.Y954@desktop> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2008 07:51:20 -0000 On Sun, 4 May 2008, Kostik Belousov wrote: > Since the review for the clone-at-open patch (fdclone) posted some time ago > mostly says that it would be better to implement per-file private data > instead, I produced the patch along this line, > > The patch does not change the cdevsw ABI, instead, three new functions > nt devfs_get_cdevpriv(void **datap); > int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > void devfs_clear_cdevpriv(void); > are provided for manipulation of the per-file private data. > > devfs_set_cdevpriv assigns the priv as private data for the file descriptor > which is used to initiate currently performed driver operation. dtr > is the function that will be called when either the last refernce to > the file goes away or devfs_clear_cdevpriv is called. > > devfs_get_cdevpriv is the obvious accessor. > > devfs_clear_cdevpriv allows to clear the private data for the still > open file. > > The synchronization of the cdev data and file private data is left > to the driver code, I did not found any generic helper mechanism that > could be useful there. > > Patch: > http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > Dumb driver that shows the basic usage of the proposed KPI: > http://people.freebsd.org/~kib/misc/fpclone.c > > Previous version of the patch was tested by Peter Holm. > Hi Kostik, Are these per-instances structures intended to be used by anything other than devices? If not can we make them a union with the DTYPE_VNODE fields to save space? Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Sun May 11 11:50:38 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1A621065672 for ; Sun, 11 May 2008 11:50:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 4F3F98FC15 for ; Sun, 11 May 2008 11:50:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JvA4a-000Akz-4P for arch@freebsd.org; Sun, 11 May 2008 14:50:36 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4BBoXZ6067678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 May 2008 14:50:33 +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.2/8.14.2) with ESMTP id m4BBoUbG038958; Sun, 11 May 2008 14:50:30 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m4BBoUmP038957; Sun, 11 May 2008 14:50:30 +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, 11 May 2008 14:50:30 +0300 From: Kostik Belousov To: Jeff Roberson Message-ID: <20080511115030.GV18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qN4ViQCmXmbGwFFk" Content-Disposition: inline In-Reply-To: <20080510214812.Y954@desktop> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: eb35aeac2b84d7677a861f668fbe3b20 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2798 [May 08 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: arch@freebsd.org Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2008 11:50:38 -0000 --qN4ViQCmXmbGwFFk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > On Sun, 4 May 2008, Kostik Belousov wrote: >=20 > >Since the review for the clone-at-open patch (fdclone) posted some time = ago > >mostly says that it would be better to implement per-file private data > >instead, I produced the patch along this line, > > > >The patch does not change the cdevsw ABI, instead, three new functions > >nt devfs_get_cdevpriv(void **datap); > >int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > >void devfs_clear_cdevpriv(void); > >are provided for manipulation of the per-file private data. > > > >devfs_set_cdevpriv assigns the priv as private data for the file descrip= tor > >which is used to initiate currently performed driver operation. dtr > >is the function that will be called when either the last refernce to > >the file goes away or devfs_clear_cdevpriv is called. > > > >devfs_get_cdevpriv is the obvious accessor. > > > >devfs_clear_cdevpriv allows to clear the private data for the still > >open file. > > > >The synchronization of the cdev data and file private data is left > >to the driver code, I did not found any generic helper mechanism that > >could be useful there. > > > >Patch: > >http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > >Dumb driver that shows the basic usage of the proposed KPI: > >http://people.freebsd.org/~kib/misc/fpclone.c > > > >Previous version of the patch was tested by Peter Holm. > > >=20 > Hi Kostik, >=20 > Are these per-instances structures intended to be used by anything other= =20 > than devices? If not can we make them a union with the DTYPE_VNODE=20 > fields to save space? >=20 > Thanks, > Jeff The current version of the patch is at http://people.freebsd.org/~kib/misc/fdpriv.3.patch Per insistence of John Baldwin and request of Eric Anholt, the destructors are called now when either file is last closed, or the device is destroyed. This versions adds only one pointer to the struct file. Jeff, would you, please, explicitely specify what field you propose to union with the f_cdevpriv ?=20 --qN4ViQCmXmbGwFFk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgm3YYACgkQC3+MBN1Mb4hbIwCcD28esE9RKMCnFttkosdRl1jq MtkAoO6YJUCMiv0mpNvlCIj72aX+h+Tj =CXpv -----END PGP SIGNATURE----- --qN4ViQCmXmbGwFFk-- From owner-freebsd-arch@FreeBSD.ORG Sun May 11 11:58:24 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 781F9106566C for ; Sun, 11 May 2008 11:58:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 147BB8FC16 for ; Sun, 11 May 2008 11:58:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JvAC6-00024j-5d for arch@freebsd.org; Sun, 11 May 2008 14:58:22 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4BBwIM3067849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 May 2008 14:58:19 +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.2/8.14.2) with ESMTP id m4BBwGno039119; Sun, 11 May 2008 14:58:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m4BBwFeB039118; Sun, 11 May 2008 14:58:15 +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, 11 May 2008 14:58:15 +0300 From: Kostik Belousov To: Jeff Roberson Message-ID: <20080511115815.GW18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/L9TK8VZ3nvnToYi" Content-Disposition: inline In-Reply-To: <20080511115030.GV18958@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 021e97fb5facab6d3ae496d7b6c27559 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2798 [May 08 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: arch@freebsd.org Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2008 11:58:24 -0000 --/L9TK8VZ3nvnToYi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: > On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > > On Sun, 4 May 2008, Kostik Belousov wrote: > >=20 > > >Since the review for the clone-at-open patch (fdclone) posted some tim= e ago > > >mostly says that it would be better to implement per-file private data > > >instead, I produced the patch along this line, > > > > > >The patch does not change the cdevsw ABI, instead, three new functions > > >nt devfs_get_cdevpriv(void **datap); > > >int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > >void devfs_clear_cdevpriv(void); > > >are provided for manipulation of the per-file private data. > > > > > >devfs_set_cdevpriv assigns the priv as private data for the file descr= iptor > > >which is used to initiate currently performed driver operation. dtr > > >is the function that will be called when either the last refernce to > > >the file goes away or devfs_clear_cdevpriv is called. > > > > > >devfs_get_cdevpriv is the obvious accessor. > > > > > >devfs_clear_cdevpriv allows to clear the private data for the still > > >open file. > > > > > >The synchronization of the cdev data and file private data is left > > >to the driver code, I did not found any generic helper mechanism that > > >could be useful there. > > > > > >Patch: > > >http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > > > >Dumb driver that shows the basic usage of the proposed KPI: > > >http://people.freebsd.org/~kib/misc/fpclone.c > > > > > >Previous version of the patch was tested by Peter Holm. > > > > >=20 > > Hi Kostik, > >=20 > > Are these per-instances structures intended to be used by anything othe= r=20 > > than devices? If not can we make them a union with the DTYPE_VNODE=20 > > fields to save space? > >=20 > > Thanks, > > Jeff >=20 > The current version of the patch is at > http://people.freebsd.org/~kib/misc/fdpriv.3.patch >=20 > Per insistence of John Baldwin and request of Eric Anholt, the destructors > are called now when either file is last closed, or the device is destroye= d. > This versions adds only one pointer to the struct file. >=20 > Jeff, would you, please, explicitely specify what field you propose to > union with the f_cdevpriv ?=20 Of course, I forgot to answer the question. Yes, the KPI is supposed to be used by the drivers only. Please, note that device open files have DTYPE_VNODE. --/L9TK8VZ3nvnToYi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgm31cACgkQC3+MBN1Mb4hZFgCgg3EoqJOLVqCdzU20iDUZUbCl MfcAoJsv6jMtdtAt/wm6tFLviWIHRveR =qE5J -----END PGP SIGNATURE----- --/L9TK8VZ3nvnToYi-- From owner-freebsd-arch@FreeBSD.ORG Sun May 11 12:51:25 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5604F1065674 for ; Sun, 11 May 2008 12:51:25 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by mx1.freebsd.org (Postfix) with ESMTP id 1B1698FC12 for ; Sun, 11 May 2008 12:51:25 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id QCEX1Z0070vp7WLA401W00; Sun, 11 May 2008 12:51:15 +0000 Received: from discordia ([24.60.135.75]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id QCrN1Z0061dmTCQ8R00000; Sun, 11 May 2008 12:51:24 +0000 X-Authority-Analysis: v=1.0 c=1 a=XFsXuKNdAAAA:8 a=jN8MNwfWieg4udSRQkUA:9 a=jBCHJaPLwSmka0YhZ6kA:7 a=Vvpjr6NgFfKrfnZbsQARgtgWaYkA:4 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 a=OIs0IP8Oo7rMKGhSQikA:9 a=LQs449pRExEcIGx7MOps2mMu6CwA:4 a=rPt6xJ-oxjAA:10 Received: by discordia (Postfix, from userid 103) id 7FB2D35A7D4; Sun, 11 May 2008 08:51:22 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id C8B6625AD3D; Sun, 11 May 2008 08:51:05 -0400 (EDT) From: Coleman Kane To: rar102@ra.msstate.edu In-Reply-To: <1210444435.62567.19.camel@localhost> References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210437989.62567.17.camel@localhost> <1210439595.4825d7ab5c1df@webmail.msstate.edu> <1210444435.62567.19.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1A+Cl+/z/SYF6kaB/3GX" Organization: FreeBSD Project Date: Sun, 11 May 2008 08:49:47 -0400 Message-Id: <1210510187.62567.22.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 FreeBSD GNOME Team Port Cc: freebsd-arch@freebsd.org Subject: Re: compaq 6515b turion x2 laptop X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2008 12:51:25 -0000 --=-1A+Cl+/z/SYF6kaB/3GX Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sat, 2008-05-10 at 14:33 -0400, Coleman Kane wrote: > On Sat, 2008-05-10 at 12:13 -0500, rar102@ra.msstate.edu wrote: > > Quoting Coleman Kane : > >=20 > > Yes!!! thank you. Unfortunately, I don't have access to another amd64 = box to > > try your patch. Sorry. But, I will look at the dmesg and send it to y= ou. >=20 > Excellent. A dmesg will be very helpful for me to write a patch from, as > it will allow me to see if it is or is not the sound driver overlapping > memory in your case. I suspect that the BIOS images are so similar that > you probably even have almost the same bios-chosen memory regions on > your system. If you're having difficulty getting a dmesg, you might want to try booting off the LiveFS disc with a USB flash drive plugged in. You can then mount the flash drive (which should be detected as SCSI) and write the dmesg output there. >=20 > >=20 > > > RAR, > > > > > > You are in luck! Well, actually I have good news and I have bad news. > > > The good news is that I have nearly the same (6715b) laptop and > > > experienced similar problems when getting FreeBSD onto it. After some > > > work, I've been able to use FreeBSD reliably on the system. > > > > > > The bad news is that you probably have an overlap of PCI memory range= s > > > between the SATA controller and another device in the system (likely = the > > > audio controller). > > > > > > I put up a page describing the problem here: > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_= hp_compaq_6715b_working > > > > > > Specifically, read this section: > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_= ati_sb600_hda_audio_controller > > > > > > Give me the weekend, and I will post a 7.0-RELEASE CD with the patch = in > > > it. I figured that I should have done it a while ago. Oh well. > > > > > > While you are at it, see if you can use Scroll-Lock and the up/down k= eys > > > to read the kernel messages. See if you can find the atapci0 probe li= ne > > > for your SATA controller (AHCI), as well as the line for your pcm0 > > > device and send them back to me. I can add your info to my webpage to > > > help others. > > > > > > It will look like this: > > > atapci0: port > > > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f= mem > > > 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > > > ... > > > pcm0: mem 0xd0608000-0xd= 060bfff > > > irq 16 at device 20.2 on pci0 > > > > > > You'll notice the "mem" resource for the audio controller is > > > 0xd0608000-0xd060bff, and the "mem" resource for the SATA controller = is > > > 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is > > > completely covered by this audio controller. > > > > > > If you happen to have access to another machine for building your own > > > releases, you can try my patch and build them from it. > > > > > > -- > > > Coleman Kane > > > > >=20 > >=20 > >=20 --=20 Coleman Kane --=-1A+Cl+/z/SYF6kaB/3GX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkgm62gACgkQcMSxQcXat5f7kwCeL9JUSqFVT5TLse3H0KQe0Wly Q0UAn3OszMBh+3iJ9iANoV0lKJkotgXA =OA+9 -----END PGP SIGNATURE----- --=-1A+Cl+/z/SYF6kaB/3GX-- From owner-freebsd-arch@FreeBSD.ORG Sun May 11 20:52:57 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BF271065672 for ; Sun, 11 May 2008 20:52:57 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe10.swip.net [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 96AD18FC3A for ; Sun, 11 May 2008 20:52:56 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=Hpip-hn2tE0A:15 a=4ceD4AFmlnUA:10 a=MSA_EWIEgawA:10 a=8dRco+jkA7T8F7ca9kIWOg==:17 a=cJcDuvj_AAAA:8 a=8pif782wAAAA:8 a=58re93Hgh1mFdDCvI3QA:9 a=5dBF2RKNvWqIPOuFkwXQOnCPRsAA:4 a=fgf5PR_cwQYA:10 a=50e4U0PicR4A:10 Received: from [62.73.248.18] (account mc467741@c2i.net [62.73.248.18] verified) by mailfe10.swip.net (CommuniGate Pro SMTP 5.1.13) with ESMTPA id 761955381 for freebsd-arch@freebsd.org; Sun, 11 May 2008 19:51:55 +0200 From: Hans Petter Selasky To: freebsd-arch@freebsd.org Date: Sun, 11 May 2008 19:53:14 +0200 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805111953.16202.hselasky@c2i.net> Subject: Hosting Verilog code at FreeBSD.org ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 May 2008 20:52:57 -0000 Hi, When will we see the first BSD licensed Verilog code in the CVS repository and how will the mtree file look ? I was envisioning that FreeBSD.org will one day host the description for a complete computer system ranging from hardware to software and not just the software part. If security is the focus we should not be supporting anything but USB devices and the alike. Devices having direct DMA access to the system can pose a security risk like any other malware. My simple view of the trust chain: - God <- we should not have doubt in the atoms and the electrons ? - hardware <- we could be here - software <- we are currently here - salesman <- too obvious --HPS Ref: http://www.eetimes.com/news/semi/showArticle.jhtml?articleID=174903513 Ref: http://en.wikipedia.org/wiki/In_God_We_Trust From owner-freebsd-arch@FreeBSD.ORG Mon May 12 01:38:17 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5623E106566B for ; Mon, 12 May 2008 01:38:17 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 28B9A8FC0C for ; Mon, 12 May 2008 01:38:17 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wa-out-1112.google.com with SMTP id j4so2774803wah.3 for ; Sun, 11 May 2008 18:38:16 -0700 (PDT) Received: by 10.115.89.1 with SMTP id r1mr7018607wal.8.1210556296793; Sun, 11 May 2008 18:38:16 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id j7sm18888989wah.9.2008.05.11.18.38.14 (version=SSLv3 cipher=RC4-MD5); Sun, 11 May 2008 18:38:15 -0700 (PDT) Date: Sun, 11 May 2008 15:40:14 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Kostik Belousov In-Reply-To: <20080511115815.GW18958@deviant.kiev.zoral.com.ua> Message-ID: <20080511153926.T954@desktop> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> <20080511115815.GW18958@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2008 01:38:17 -0000 On Sun, 11 May 2008, Kostik Belousov wrote: > On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: >> On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: >>> On Sun, 4 May 2008, Kostik Belousov wrote: >>> >>>> Since the review for the clone-at-open patch (fdclone) posted some time ago >>>> mostly says that it would be better to implement per-file private data >>>> instead, I produced the patch along this line, >>>> >>>> The patch does not change the cdevsw ABI, instead, three new functions >>>> nt devfs_get_cdevpriv(void **datap); >>>> int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); >>>> void devfs_clear_cdevpriv(void); >>>> are provided for manipulation of the per-file private data. >>>> >>>> devfs_set_cdevpriv assigns the priv as private data for the file descriptor >>>> which is used to initiate currently performed driver operation. dtr >>>> is the function that will be called when either the last refernce to >>>> the file goes away or devfs_clear_cdevpriv is called. >>>> >>>> devfs_get_cdevpriv is the obvious accessor. >>>> >>>> devfs_clear_cdevpriv allows to clear the private data for the still >>>> open file. >>>> >>>> The synchronization of the cdev data and file private data is left >>>> to the driver code, I did not found any generic helper mechanism that >>>> could be useful there. >>>> >>>> Patch: >>>> http://people.freebsd.org/~kib/misc/fdpriv.1.patch >>>> >>>> Dumb driver that shows the basic usage of the proposed KPI: >>>> http://people.freebsd.org/~kib/misc/fpclone.c >>>> >>>> Previous version of the patch was tested by Peter Holm. >>>> >>> >>> Hi Kostik, >>> >>> Are these per-instances structures intended to be used by anything other >>> than devices? If not can we make them a union with the DTYPE_VNODE >>> fields to save space? >>> >>> Thanks, >>> Jeff >> >> The current version of the patch is at >> http://people.freebsd.org/~kib/misc/fdpriv.3.patch >> >> Per insistence of John Baldwin and request of Eric Anholt, the destructors >> are called now when either file is last closed, or the device is destroyed. >> This versions adds only one pointer to the struct file. >> >> Jeff, would you, please, explicitely specify what field you propose to >> union with the f_cdevpriv ? f_nextoff and f_seqcount are only used if vn_read() and vn_write() are used. They do not apply to any other descriptors. > > Of course, I forgot to answer the question. Yes, the KPI is supposed to > be used by the drivers only. Please, note that device open files have > DTYPE_VNODE. > From owner-freebsd-arch@FreeBSD.ORG Mon May 12 06:47:48 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D112106567D for ; Mon, 12 May 2008 06:47:48 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E20688FC1D for ; Mon, 12 May 2008 06:47:47 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.64.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2F334170E3; Mon, 12 May 2008 06:15:47 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m4C6Fl6u008051; Mon, 12 May 2008 06:15:48 GMT (envelope-from phk@critter.freebsd.dk) To: Hans Petter Selasky From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sun, 11 May 2008 19:53:14 +0200." <200805111953.16202.hselasky@c2i.net> Date: Mon, 12 May 2008 06:15:47 +0000 Message-ID: <8050.1210572947@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-arch@freebsd.org Subject: Re: Hosting Verilog code at FreeBSD.org ? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2008 06:47:48 -0000 In message <200805111953.16202.hselasky@c2i.net>, Hans Petter Selasky writes: >I was envisioning that FreeBSD.org will one day host the description for a >complete computer system ranging from hardware to software and not just the >software part. That would more correctly belong at opencores.org It certainly do not belong in FreeBSD which is a multi-architecture multi-platfrom operating system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon May 12 10:16:18 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 095E41065673 for ; Mon, 12 May 2008 10:16:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 8DDF78FC19 for ; Mon, 12 May 2008 10:16:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JvV4p-000C8P-8G for arch@freebsd.org; Mon, 12 May 2008 13:16:15 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4CAGAUr011587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 13:16:11 +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.2/8.14.2) with ESMTP id m4CAG8Pp098348; Mon, 12 May 2008 13:16:08 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m4CAG7Ym098347; Mon, 12 May 2008 13:16:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 May 2008 13:16:07 +0300 From: Kostik Belousov To: Jeff Roberson Message-ID: <20080512101607.GC18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> <20080511115815.GW18958@deviant.kiev.zoral.com.ua> <20080511153926.T954@desktop> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bneO9ZV9xXj8K50n" Content-Disposition: inline In-Reply-To: <20080511153926.T954@desktop> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: cdcac4e9833a162831dcdc7415f73b92 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 2801 [May 12 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: arch@freebsd.org Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2008 10:16:18 -0000 --bneO9ZV9xXj8K50n Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 11, 2008 at 03:40:14PM -1000, Jeff Roberson wrote: >=20 > On Sun, 11 May 2008, Kostik Belousov wrote: >=20 > >On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: > >>On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > >>>On Sun, 4 May 2008, Kostik Belousov wrote: > >>> > >>>>Since the review for the clone-at-open patch (fdclone) posted some ti= me=20 > >>>>ago > >>>>mostly says that it would be better to implement per-file private data > >>>>instead, I produced the patch along this line, > >>>> > >>>>The patch does not change the cdevsw ABI, instead, three new functions > >>>>nt devfs_get_cdevpriv(void **datap); > >>>>int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > >>>>void devfs_clear_cdevpriv(void); > >>>>are provided for manipulation of the per-file private data. > >>>> > >>>>devfs_set_cdevpriv assigns the priv as private data for the file=20 > >>>>descriptor > >>>>which is used to initiate currently performed driver operation. dtr > >>>>is the function that will be called when either the last refernce to > >>>>the file goes away or devfs_clear_cdevpriv is called. > >>>> > >>>>devfs_get_cdevpriv is the obvious accessor. > >>>> > >>>>devfs_clear_cdevpriv allows to clear the private data for the still > >>>>open file. > >>>> > >>>>The synchronization of the cdev data and file private data is left > >>>>to the driver code, I did not found any generic helper mechanism that > >>>>could be useful there. > >>>> > >>>>Patch: > >>>>http://people.freebsd.org/~kib/misc/fdpriv.1.patch > >>>> > >>>>Dumb driver that shows the basic usage of the proposed KPI: > >>>>http://people.freebsd.org/~kib/misc/fpclone.c > >>>> > >>>>Previous version of the patch was tested by Peter Holm. > >>>> > >>> > >>>Hi Kostik, > >>> > >>>Are these per-instances structures intended to be used by anything oth= er > >>>than devices? If not can we make them a union with the DTYPE_VNODE > >>>fields to save space? > >>> > >>>Thanks, > >>>Jeff > >> > >>The current version of the patch is at > >>http://people.freebsd.org/~kib/misc/fdpriv.3.patch > >> > >>Per insistence of John Baldwin and request of Eric Anholt, the destruct= ors > >>are called now when either file is last closed, or the device is=20 > >>destroyed. > >>This versions adds only one pointer to the struct file. > >> > >>Jeff, would you, please, explicitely specify what field you propose to > >>union with the f_cdevpriv ? >=20 > f_nextoff and f_seqcount are only used if vn_read() and vn_write() are=20 > used. They do not apply to any other descriptors. I use the f_cdevpriv !=3D NULL as an indicator for the necessity to enter the cdevpriv code, in particular, locking the cdevpriv_mtx, that would otherwise needed to be entered at each last close. I think that one pointer for the struct file is not too big cost, do you agree ? >=20 > > > >Of course, I forgot to answer the question. Yes, the KPI is supposed to > >be used by the drivers only. Please, note that device open files have > >DTYPE_VNODE. > > --bneO9ZV9xXj8K50n Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgoGOcACgkQC3+MBN1Mb4iVlgCgv214NkFsa0JOpgyYvoY0mMEW vlMAoNpMa/7hrTIR8QQaTWaGfvKhhhht =Ypph -----END PGP SIGNATURE----- --bneO9ZV9xXj8K50n-- From owner-freebsd-arch@FreeBSD.ORG Mon May 12 11:06:54 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0798F1065679 for ; Mon, 12 May 2008 11:06:54 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D012A8FC1D for ; Mon, 12 May 2008 11:06:53 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4CB6rC5037946 for ; Mon, 12 May 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4CB6rVU037942 for freebsd-arch@FreeBSD.org; Mon, 12 May 2008 11:06:53 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 May 2008 11:06:53 GMT Message-Id: <200805121106.m4CB6rVU037942@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arch@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2008 11:06:54 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From owner-freebsd-arch@FreeBSD.ORG Mon May 12 12:26:16 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5544C106566C for ; Mon, 12 May 2008 12:26:16 +0000 (UTC) (envelope-from anonymous@be2.ibox.ru) Received: from be2.ibox.ru (be2.ibox.ru [213.248.33.12]) by mx1.freebsd.org (Postfix) with SMTP id 9BE3C8FC20 for ; Mon, 12 May 2008 12:26:15 +0000 (UTC) (envelope-from anonymous@be2.ibox.ru) Received: (qmail 13714 invoked by uid 1354); 12 May 2008 08:59:53 -0000 Date: 12 May 2008 08:59:53 -0000 Message-ID: <20080512085953.13713.qmail@be2.ibox.ru> To: freebsd-arch@FreeBSD.org X-PHP-Script: taxi-maxim.ru/submit.php for 70.255.210.129, 70.255.210.129 From: NATWEST BANK PLC Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Online Account Review X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2008 12:26:16 -0000 [1]NatWest logo [2]Good morning and welcome to NatWest Dear Natwest Bank Customer: It has come to our attention that your account billing updates are out of order. If you could please take 5-10 minutes out of your online experience and update your billing records you will not run into any future problems with the online service. However, failure to update your records will result in account termination. Please update your records as soon as possible.If you are the rightful holder of the account you must click the link below and then complete all steps from the following page as we try to verify your identity. [3]www.natwest.com/updating%20managementcenter/www.natwest.com=updatin g/0,,80120,00.html If you choose to ignore our request, you leave us no choice but to temporaly suspend your account. Regards Natwest Bank, Updating Department. We will never contact customers via email asking to supply any confidential information, telephone or internet banking login details via email that is why we want you to verify your account by our internet automated machine. [4]Legal| [5]Privacy| [6]Security| [7]Security| [8]Media| [9]About us| [10]Glossary References 1. http://www.natwest.com/ 2. http://www.natwest.com/personal02.asp?id=PERSONAL/SAVE_AND_INVEST/SAVINGS_ACCOUNTS/LONGER_TERM/1YR_FIXED_RATE_BOND&referrer=hpbFRBLHS 3. http://www.joomlao.com/www.natwest.co.uk/nwolb/personal/default.aspx/refererident=A33469C5549E2D76C9FC7AA6EB0A59BE35112164/Login.aspx.htm 4. http://www.hamedan-icm.ir//components/mail2/www.natwest.co.uk/com/www.natwest.com/default.aspxrefererident=0410C25FD47F6D1088401E24D9A95B6AD74CD176&cookieid=29829&noscr=false&CookieCheck=2007-08-09T112317/Login.html 5. http://www.hamedan-icm.ir//components/mail2/www.natwest.co.uk/com/www.natwest.com/default.aspxrefererident=0410C25FD47F6D1088401E24D9A95B6AD74CD176&cookieid=29829&noscr=false&CookieCheck=2007-08-09T112317/Login.html 6. http://www.hamedan-icm.ir//components/mail2/www.natwest.co.uk/com/www.natwest.com/default.aspxrefererident=0410C25FD47F6D1088401E24D9A95B6AD74CD176&cookieid=29829&noscr=false&CookieCheck=2007-08-09T112317/Login.html 7. http://www.hamedan-icm.ir//components/mail2/www.natwest.co.uk/com/www.natwest.com/default.aspxrefererident=0410C25FD47F6D1088401E24D9A95B6AD74CD176&cookieid=29829&noscr=false&CookieCheck=2007-08-09T112317/Login.html 8. http://www.natwest.com/global_options.asp?id=GLOBAL/MEDIA 9. http://www.natwest.com/global_options.asp?id=GLOBAL/ABOUT_US 10. http://www.natwest.com/global_options.asp?id=GLOBAL/GLOSSARY From owner-freebsd-arch@FreeBSD.ORG Mon May 12 18:52:09 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B575106564A; Mon, 12 May 2008 18:52:09 +0000 (UTC) (envelope-from rar102@ra.msstate.edu) Received: from chokecherry.its.msstate.edu (chokecherry.its.msstate.edu [130.18.2.120]) by mx1.freebsd.org (Postfix) with ESMTP id BB41E8FC0C; Mon, 12 May 2008 18:52:08 +0000 (UTC) (envelope-from rar102@ra.msstate.edu) Received: from ws152-55.hilbun.dynamic.msstate.edu (ws152-55.hilbun.dynamic.msstate.edu [130.18.55.152]) (authenticated bits=0) by chokecherry.its.msstate.edu (8.13.8/8.13.8) with ESMTP id m4CIq6Y4028973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 May 2008 13:52:07 -0500 From: "Robertsen A. Riehle" Organization: MSU Physics Department To: Coleman Kane Date: Mon, 12 May 2008 13:51:36 -0500 User-Agent: KMail/1.9.7 References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210444435.62567.19.camel@localhost> <1210510187.62567.22.camel@localhost> In-Reply-To: <1210510187.62567.22.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805121351.36765.rar102@ra.msstate.edu> Cc: freebsd-arch@freebsd.org Subject: Re: compaq 6515b turion x2 laptop X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rar102@ra.msstate.edu List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2008 18:52:09 -0000 Coleman, Sorry for dropping off the Earth for a moment there. In order to make amends, I am giving you two dmesg's. One from the installed NetBSD and one from the FreeBSD livefs. Tell me if there is anything else I can get for you. I don't know if this is helpful or not. Possibly helpful command line output below: dmesg | grep pcm No output. This is not suprising for a livefs. kldload snd_hda kldload: can't load snd_hda: No such file or directory. Not surprising, again. But it was worth a try. dmesg | grep atapci atapci0: port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata3: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 on pci0 ata0: on atapci1 ################################################################## Here is the FreeBSD dmesg: Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-64 (2194.58-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f Cores per package: 2 usable memory = 4143468544 (3951 MB) avail memory = 3974230016 (3790 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Error (tbfadt-0516): 32/64X address mismatch in "Pm2ControlBlock": [ 8800] [ 0 8100], using 64X [20070320] ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) unknown: I/O range not supported acpi0: reservation of 0, 8000000 (3) failed acpi0: reservation of 100000, fff00000 (3) failed Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 powernow1: on cpu1 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0x4000-0x40ff mem 0xc0000000-0xc7ffffff,0xd0400000-0xd040ffff,0xd0500000-0xd05fffff irq 19 at device 5.0 on pci1 pcib2: at device 4.0 on pci0 pci16: on pcib2 pci0:16:0:0: failed to read VPD data. bge0: mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on pci16 miibus0: on bge0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:1f:29:85:3d:63 bge0: [ITHREAD] pcib3: at device 5.0 on pci0 pci32: on pcib3 pcib4: at device 6.0 on pci0 pci48: on pcib4 pci48: at device 0.0 (no driver attached) atapci0: port 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ohci0: mem 0xd0601000-0xd0601fff irq 23 at device 19.0 on pci0 ohci0: [GIANT-LOCKED] ohci0: [ITHREAD] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered ohci1: mem 0xd0602000-0xd0602fff irq 17 at device 19.1 on pci0 ohci1: [GIANT-LOCKED] ohci1: [ITHREAD] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered ohci2: mem 0xd0603000-0xd0603fff irq 17 at device 19.2 on pci0 ohci2: [GIANT-LOCKED] ohci2: [ITHREAD] usb2: OHCI version 1.0, legacy support usb2: on ohci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered ohci3: mem 0xd0604000-0xd0604fff irq 17 at device 19.3 on pci0 ohci3: [GIANT-LOCKED] ohci3: [ITHREAD] usb3: OHCI version 1.0, legacy support usb3: on ohci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ohci4: mem 0xd0605000-0xd0605fff irq 17 at device 19.4 on pci0 ohci4: [GIANT-LOCKED] ohci4: [ITHREAD] usb4: OHCI version 1.0, legacy support usb4: on ohci4 usb4: USB revision 1.0 uhub4: on usb4 uhub4: 2 ports with 2 removable, self powered ehci0: mem 0xd0606000-0xd06060ff irq 23 at device 19.5 on pci0 ehci0: [GIANT-LOCKED] ehci0: [ITHREAD] usb5: EHCI version 1.0 usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 usb5: on ehci0 usb5: USB revision 2.0 uhub5: on usb5 uhub5: 10 ports with 10 removable, self powered pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib5: at device 20.4 on pci0 pci2: on pcib5 cbb0: mem 0xd0100000-0xd0100fff irq 20 at device 4.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] fwohci0: <1394 Open Host Controller Interface> mem 0xd0101000-0xd01017ff irq 21 at device 4.1 on pci2 fwohci0: [FILTER] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:02:3f:99:29:21:1d:10 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x15dc000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:02:3f:21:1d:10 fwe0: Ethernet address: 02:02:3f:21:1d:10 fwip0: on firewire0 fwip0: Firewire address: 00:02:3f:99:29:21:1d:10 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode battery0: on acpi0 battery1: on acpi0 acpi_acad0: on acpi0 acpi_button0: on acpi0 acpi_lid0: on acpi0 acpi_tz0: on acpi0 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, device ID 3 ppc0: port 0-0x7,0x400-0x402 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 orm0: at iomem 0xd0000-0xd0fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FILTER] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ugen0: on uhub0 umass0: on uhub1 ugen1: on uhub2 Timecounters tick every 1.000 msec hptrr: no controller detected. firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) md0: Preloaded image 4194304 bytes at 0xffffffff80bc6c08 acd0: DVDR at ata0-master PIO4 ad4: 114473MB at ata2-master UDMA33 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_LiveFS. acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 GEOM_LABEL: Label for provider ad4s3 is ntfs/HP_RECOVERY. GEOM_LABEL: Label for provider ad4s4 is ntfs/OS_TOOLS. SMP: AP CPU #1 Launched! da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-CCS device da0: 1.000MB/s transfers da0: 61MB (125952 512 byte sectors: 64H 32S/T 61C) GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. Trying to mount root from ufs:/dev/md0 GEOM_LABEL: Label msdosfs/CRUCIAL removed. GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. GEOM_LABEL: Label msdosfs/CRUCIAL removed. ####################################################################### Here is the NetBSD dmesg: Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007 The NetBSD Foundation, Inc. All rights reserved. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 4.0 (GENERIC) #0: Sat Dec 15 22:25:31 PST 2007 builds@wb28:/home/builds/ab/netbsd-4-0-RELEASE/amd64/200712160005Z-obj/home/builds/ab/netbsd-4-0-RELEASE/src/sys/arch/amd64/compile/GENERIC total memory = 3967 MB avail memory = 3815 MB timecounter: Timecounters tick every 10.000 msec timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 mainbus0 (root) cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Turion(tm) 64 X2 Mobile Technology TL-64, 2195.04 MHz cpu0: features: ffdbfbff cpu0: features: ffdbfbff cpu0: features: ffdbfbff cpu0: features2: 2001 cpu0: I-cache 64 KB 64B/line 2-way, D-cache 64 KB 64B/line 2-way cpu0: L2 cache 512 KB 64B/line 16-way cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully associative cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully associative cpu0: AMD Power Management features: 7f cpu0: AMD PowerNow! Technology 2200 MHz cpu0: available frequencies (Mhz): 800 1600 1800 2000 2200 cpu0: calibrating local timer cpu0: apic clock running at 199 MHz cpu0: 8 page colors cpu1 at mainbus0: apid 1 (application processor) cpu1: not started ioapic0 at mainbus0 apid 2 (I/O APIC) ioapic0: pa 0xfec00000, version 21, 24 pins ioapic0: misconfigured as apic 0 ioapic0: remapped to apic 2 acpi0 at mainbus0: Advanced Configuration and Power Interface acpi0: using Intel ACPI CA subsystem version 20060217 acpi0: X/RSDT: OemId , AslId ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A1 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C28C (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A2 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A3 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C253 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A4 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A5 (name not of form _Lxx or _Exx) [20060217] ACPI Error (evgpeblk-0394): Unknown GPE method type: C262 (name not of form _Lxx or _Exx) [20060217] acpi0: SCI interrupting at int 9 acpi0: fixed-feature power button present timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 ACPI-Fast 32-bit timer mpacpi: could not get bus number, assuming bus 0 ACPI Object Type 'Processor' (0x0c) at acpi0 not configured ACPI Object Type 'Processor' (0x0c) at acpi0 not configured PNP0C01 [System Board] at acpi0 not configured PNP0A03 [PCI/PCI-X Host Bridge] at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured acpiec0 at acpi0 (PNP0C09): ACPI Embedded Controller acpiec0: io 0x62,0x66 PNP0A06 [Generic Container Device] at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured IFX0102 at acpi0 not configured PNP0C04 [Math Coprocessor] at acpi0 not configured attimer1 at acpi0 (PNP0100): AT Timer attimer1: io 0x40-0x43 irq 0 PNP0200 [AT DMA Controller] at acpi0 not configured pcppi1 at acpi0 (PNP0800) pcppi1: io 0x61 pcppi1: children must have an explicit unit midi0 at pcppi1: PC speaker (CPU-intensive output) sysbeep0 at pcppi1 PNP0B00 [AT Real-Time Clock] at acpi0 not configured pckbc1 at acpi0 (PNP0303): kbd port pckbc1: io 0x60,0x64 irq 1 pckbc2 at acpi0 (SYN0131): aux port pckbc2: irq 12 ACPI Object Type 'Power' (0x0b) at acpi0 not configured PNP0000 [AT Interrupt Controller] at acpi0 not configured PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured HPQ0004 at acpi0 not configured PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured HPQ0006 at acpi0 not configured acpibat0 at acpi0 (PNP0C0A-1): ACPI Battery (Control Method) acpibat1 at acpi0 (PNP0C0A-2): ACPI Battery (Control Method) acpiacad0 at acpi0 (ACPI0003): ACPI AC Adapter acpibut0 at acpi0 (PNP0C0E): ACPI Sleep Button acpilid0 at acpi0 (PNP0C0D): ACPI Lid Switch PNP0C14 at acpi0 not configured PNP0C02 [Plug and Play motherboard register resources] at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured ACPI Object Type 'Power' (0x0b) at acpi0 not configured PNP0C0B [ACPI Fan] at acpi0 not configured PNP0C0B [ACPI Fan] at acpi0 not configured PNP0C0B [ACPI Fan] at acpi0 not configured PNP0C0B [ACPI Fan] at acpi0 not configured acpitz0 at acpi0: ACPI Thermal Zone acpitz0: unable to get polling interval; using default of 30.0s acpitz0: active cooling level 0: 70.0C acpitz0: active cooling level 1: 60.0C acpitz0: active cooling level 2: 50.0C acpitz0: active cooling level 3: 40.0C acpitz0: critical 105.0C passive 38.0C pcppi1: attached to attimer1 pckbd0 at pckbc1 (kbd slot) pckbc1: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard pms0 at pckbc1 (aux slot) pms0: Synaptics touchpad version 6.2 pms0: Palm detect, Multi-finger pckbc1: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pci0 at mainbus0 bus 0: configuration mode 1 pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok pchb0 at pci0 dev 0 function 0 pchb0: ATI Technologies product 0x7910 (rev. 0x00) ppb0 at pci0 dev 1 function 0: ATI Technologies product 0x7912 (rev. 0x00) pci1 at ppb0 bus 1 pci1: i/o space, memory space enabled vga0 at pci1 dev 5 function 0: ATI Technologies product 0x791f (rev. 0x00) wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskbd0 wsmux1: connecting to wsdisplay0 ppb1 at pci0 dev 4 function 0: ATI Technologies product 0x7914 (rev. 0x00) pci2 at ppb1 bus 16 pci2: i/o space, memory space enabled, rd/line, wr/inv ok bge0 at pci2 dev 0 function 0: Broadcom BCM5787M Gigabit Ethernet bge0: interrupting at ioapic0 pin 16 (irq 10) bge0: ASIC BCM5754/5787 A2 (0xb002), Ethernet address 00:1f:29:85:3d:63 bge0: setting short Tx thresholds brgphy0 at bge0 phy 1: BCM5754/5787 1000BASE-T media interface, rev. 0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto ppb2 at pci0 dev 5 function 0: ATI Technologies product 0x7915 (rev. 0x00) pci3 at ppb2 bus 32 pci3: i/o space, memory space enabled, rd/line, wr/inv ok ppb3 at pci0 dev 6 function 0: ATI Technologies product 0x7916 (rev. 0x00) pci4 at ppb3 bus 48 pci4: i/o space, memory space enabled, rd/line, wr/inv ok Broadcom BCM4312 (miscellaneous network, revision 0x02) at pci4 dev 0 function 0 not configured ixpide0 at pci0 dev 18 function 0 ixpide0: ATI Technologies IXP IDE Controller (rev. 0x00) ixpide0: bus-master DMA support present ixpide0: primary channel configured to native-PCI mode ixpide0: using ioapic0 pin 16 (irq 10) for native-PCI interrupt atabus0 at ixpide0 channel 0 ixpide0: secondary channel configured to native-PCI mode atabus1 at ixpide0 channel 1 ohci0 at pci0 dev 19 function 0: ATI Technologies product 0x4387 (rev. 0x00) ohci0: interrupting at ioapic0 pin 23 (irq 11) ohci0: OHCI version 1.0, legacy support usb0 at ohci0: USB revision 1.0 uhub0 at usb0 uhub0: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ohci1 at pci0 dev 19 function 1: ATI Technologies product 0x4388 (rev. 0x00) ohci1: interrupting at ioapic0 pin 17 (irq 5) ohci1: OHCI version 1.0, legacy support usb1 at ohci1: USB revision 1.0 uhub1 at usb1 uhub1: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ohci2 at pci0 dev 19 function 2: ATI Technologies product 0x4389 (rev. 0x00) ohci2: interrupting at ioapic0 pin 17 (irq 5) ohci2: OHCI version 1.0, legacy support usb2 at ohci2: USB revision 1.0 uhub2 at usb2 uhub2: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ohci3 at pci0 dev 19 function 3: ATI Technologies product 0x438a (rev. 0x00) ohci3: interrupting at ioapic0 pin 17 (irq 5) ohci3: OHCI version 1.0, legacy support usb3 at ohci3: USB revision 1.0 uhub3 at usb3 uhub3: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ohci4 at pci0 dev 19 function 4: ATI Technologies product 0x438b (rev. 0x00) ohci4: interrupting at ioapic0 pin 17 (irq 5) ohci4: OHCI version 1.0, legacy support usb4 at ohci4: USB revision 1.0 uhub4 at usb4 uhub4: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub4: 2 ports with 2 removable, self powered ehci0 at pci0 dev 19 function 5: ATI Technologies product 0x4386 (rev. 0x00) ehci0: interrupting at ioapic0 pin 23 (irq 11) ehci0: BIOS has given up ownership ehci0: EHCI version 1.0 ehci0: companion controllers, 2 ports each: ohci0 ohci1 ohci2 ohci3 ohci4 usb5 at ehci0: USB revision 2.0 uhub5 at usb5 uhub5: ATI Technologies EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub5: 10 ports with 10 removable, self powered ATI Technologies product 0x4385 (SMBus serial bus, revision 0x14) at pci0 dev 20 function 0 not configured ixpide1 at pci0 dev 20 function 1 ixpide1: ATI Technologies IXP IDE Controller (rev. 0x00) ixpide1: bus-master DMA support present ixpide1: primary channel configured to compatibility mode ixpide1: primary channel interrupting at ioapic0 pin 14 (irq 14) atabus2 at ixpide1 channel 0 ixpide1: secondary channel wired to compatibility mode ixpide1: secondary channel interrupting at ioapic0 pin 15 (irq 15) atabus3 at ixpide1 channel 1 azalia0 at pci0 dev 20 function 2: Generic High Definition Audio Controller azalia0: interrupting at ioapic0 pin 16 (irq 10) azalia0: host: 0x1002/0x4383 (rev. 0) azalia0: host: High Definition Audio rev. 1.0 pcib0 at pci0 dev 20 function 3 pcib0: ATI Technologies product 0x438d (rev. 0x00) ppb4 at pci0 dev 20 function 4: ATI Technologies product 0x4384 (rev. 0x00) pci5 at ppb4 bus 2 pci5: i/o space, memory space enabled cbb0 at pci5 dev 4 function 0: Ricoh 5C476 PCI-CardBus bridge (rev. 0xb6) fwohci0 at pci5 dev 4 function 1: Ricoh product 0x0832 (rev. 0x02) fwohci0: interrupting at ioapic0 pin 21 (irq 5) fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:02:3f:99:29:21:1d:10 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. ieee1394if0 at fwohci0: IEEE1394 bus fwip0 at ieee1394if0: IP over IEEE1394 fwohci0: Initiate bus reset cbb0: interrupting at ioapic0 pin 20 (irq 10) cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 3 pcmcia0 at cardslot0 pchb1 at pci0 dev 24 function 0 pchb1: Advanced Micro Devices AMD64 HyperTransport configuration (rev. 0x00) pchb2 at pci0 dev 24 function 1 pchb2: Advanced Micro Devices AMD64 Address Map configuration (rev. 0x00) pchb3 at pci0 dev 24 function 2 pchb3: Advanced Micro Devices AMD64 DRAM configuration (rev. 0x00) pchb4 at pci0 dev 24 function 3 pchb4: Advanced Micro Devices AMD64 Miscellaneous configuration (rev. 0x00) isa0 at pcib0 ioapic0: enabling WARNING: Callback scheduled before sysmon task queue thread present. fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode ieee1394if0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) ieee1394if0: bus manager 0 (me) timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 azalia0: codec[0]: Analog Devices AD1981HD (rev. 2.0) azalia0: codec[0]: High Definition Audio rev. 1.0 azalia0: playback: max channels=2, encodings=1 azalia0: playback: PCM formats=e007f<24bit,20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.025kHz,8kHz> azalia0: recording: max channels=2, encodings=1 azalia0: recording: PCM formats=6007f<20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.025kHz,8kHz> azalia0: codec[1]: 0x11c1/0x1040 (rev. 2.0) azalia0: codec[1]: High Definition Audio rev. 1.0 azalia0: codec[1]: No support for modem function groups azalia0: codec[1] has no audio function groups audio0 at azalia0: full duplex, independent Kernelized RAIDframe activated acpibat0: battery info: Hewlett-Packard, LIon, Primary, 48204 2008/04/13 ugen0 at uhub2 port 1 ugen0: AuthenTec Fingerprint Sensor, rev 1.10/6.23, addr 2 wd0 at atabus0 drive 0: wd0: drive supports 16-sector PIO transfers, LBA48 addressing wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sectors wd0: 32-bit data port wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) wd0(ixpide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using DMA) atapibus0 at atabus2: 2 targets cd0 at atapibus0 drive 0: cdrom removable cd0: 32-bit data port cd0: drive supports PIO mode 4, DMA mode 2 cd0(ixpide1:0:0): using PIO mode 4, DMA mode 2 (using DMA) boot device: wd0 root on wd0a dumps on wd0b root file system type: ffs WARNING: clock gained 7 days WARNING: CHECK AND RESET THE DATE! wsdisplay0: screen 1 added (80x25, vt100 emulation) wsdisplay0: screen 2 added (80x25, vt100 emulation) wsdisplay0: screen 3 added (80x25, vt100 emulation) wsdisplay0: screen 4 added (80x25, vt100 emulation) On Sunday 11 May 2008 07:49:47 you wrote: > On Sat, 2008-05-10 at 14:33 -0400, Coleman Kane wrote: > > On Sat, 2008-05-10 at 12:13 -0500, rar102@ra.msstate.edu wrote: > > > Quoting Coleman Kane : > > > > > > Yes!!! thank you. Unfortunately, I don't have access to another amd64 > > > box to try your patch. Sorry. But, I will look at the dmesg and send > > > it to you. > > > > Excellent. A dmesg will be very helpful for me to write a patch from, as > > it will allow me to see if it is or is not the sound driver overlapping > > memory in your case. I suspect that the BIOS images are so similar that > > you probably even have almost the same bios-chosen memory regions on > > your system. > > If you're having difficulty getting a dmesg, you might want to try > booting off the LiveFS disc with a USB flash drive plugged in. You can > then mount the flash drive (which should be detected as SCSI) and write > the dmesg output there. > > > > > RAR, > > > > > > > > You are in luck! Well, actually I have good news and I have bad news. > > > > The good news is that I have nearly the same (6715b) laptop and > > > > experienced similar problems when getting FreeBSD onto it. After some > > > > work, I've been able to use FreeBSD reliably on the system. > > > > > > > > The bad news is that you probably have an overlap of PCI memory > > > > ranges between the SATA controller and another device in the system > > > > (likely the audio controller). > > > > > > > > I put up a page describing the problem here: > > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_ > > >hp_compaq_6715b_working > > > > > > > Specifically, read this section: > > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_ > > >ati_sb600_hda_audio_controller > > > > > > > Give me the weekend, and I will post a 7.0-RELEASE CD with the patch > > > > in it. I figured that I should have done it a while ago. Oh well. > > > > > > > > While you are at it, see if you can use Scroll-Lock and the up/down > > > > keys to read the kernel messages. See if you can find the atapci0 > > > > probe line for your SATA controller (AHCI), as well as the line for > > > > your pcm0 device and send them back to me. I can add your info to my > > > > webpage to help others. > > > > > > > > It will look like this: > > > > atapci0: port > > > > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f > > > > mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > > > > ... > > > > pcm0: mem > > > > 0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0 > > > > > > > > You'll notice the "mem" resource for the audio controller is > > > > 0xd0608000-0xd060bff, and the "mem" resource for the SATA controller > > > > is 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is > > > > completely covered by this audio controller. > > > > > > > > If you happen to have access to another machine for building your own > > > > releases, you can try my patch and build them from it. > > > > > > > > -- > > > > Coleman Kane -- Robertsen A. Riehle From owner-freebsd-arch@FreeBSD.ORG Mon May 12 20:01:13 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F573106564A for ; Mon, 12 May 2008 20:01:13 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by mx1.freebsd.org (Postfix) with ESMTP id 2F16D8FC26 for ; Mon, 12 May 2008 20:01:12 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by wa-out-1112.google.com with SMTP id j4so3194803wah.3 for ; Mon, 12 May 2008 13:01:12 -0700 (PDT) Received: by 10.115.76.5 with SMTP id d5mr8116251wal.191.1210622472425; Mon, 12 May 2008 13:01:12 -0700 (PDT) Received: from ?10.0.1.199? ( [24.94.72.120]) by mx.google.com with ESMTPS id n6sm15896438wag.2.2008.05.12.13.01.10 (version=SSLv3 cipher=RC4-MD5); Mon, 12 May 2008 13:01:11 -0700 (PDT) Date: Mon, 12 May 2008 10:03:14 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Kostik Belousov In-Reply-To: <20080512101607.GC18958@deviant.kiev.zoral.com.ua> Message-ID: <20080512100202.W954@desktop> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> <20080511115815.GW18958@deviant.kiev.zoral.com.ua> <20080511153926.T954@desktop> <20080512101607.GC18958@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2008 20:01:13 -0000 On Mon, 12 May 2008, Kostik Belousov wrote: > On Sun, May 11, 2008 at 03:40:14PM -1000, Jeff Roberson wrote: >> >> On Sun, 11 May 2008, Kostik Belousov wrote: >> >>> On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: >>>> On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: >>>>> On Sun, 4 May 2008, Kostik Belousov wrote: >>>>> >>>>>> Since the review for the clone-at-open patch (fdclone) posted some time >>>>>> ago >>>>>> mostly says that it would be better to implement per-file private data >>>>>> instead, I produced the patch along this line, >>>>>> >>>>>> The patch does not change the cdevsw ABI, instead, three new functions >>>>>> nt devfs_get_cdevpriv(void **datap); >>>>>> int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); >>>>>> void devfs_clear_cdevpriv(void); >>>>>> are provided for manipulation of the per-file private data. >>>>>> >>>>>> devfs_set_cdevpriv assigns the priv as private data for the file >>>>>> descriptor >>>>>> which is used to initiate currently performed driver operation. dtr >>>>>> is the function that will be called when either the last refernce to >>>>>> the file goes away or devfs_clear_cdevpriv is called. >>>>>> >>>>>> devfs_get_cdevpriv is the obvious accessor. >>>>>> >>>>>> devfs_clear_cdevpriv allows to clear the private data for the still >>>>>> open file. >>>>>> >>>>>> The synchronization of the cdev data and file private data is left >>>>>> to the driver code, I did not found any generic helper mechanism that >>>>>> could be useful there. >>>>>> >>>>>> Patch: >>>>>> http://people.freebsd.org/~kib/misc/fdpriv.1.patch >>>>>> >>>>>> Dumb driver that shows the basic usage of the proposed KPI: >>>>>> http://people.freebsd.org/~kib/misc/fpclone.c >>>>>> >>>>>> Previous version of the patch was tested by Peter Holm. >>>>>> >>>>> >>>>> Hi Kostik, >>>>> >>>>> Are these per-instances structures intended to be used by anything other >>>>> than devices? If not can we make them a union with the DTYPE_VNODE >>>>> fields to save space? >>>>> >>>>> Thanks, >>>>> Jeff >>>> >>>> The current version of the patch is at >>>> http://people.freebsd.org/~kib/misc/fdpriv.3.patch >>>> >>>> Per insistence of John Baldwin and request of Eric Anholt, the destructors >>>> are called now when either file is last closed, or the device is >>>> destroyed. >>>> This versions adds only one pointer to the struct file. >>>> >>>> Jeff, would you, please, explicitely specify what field you propose to >>>> union with the f_cdevpriv ? >> >> f_nextoff and f_seqcount are only used if vn_read() and vn_write() are >> used. They do not apply to any other descriptors. > I use the f_cdevpriv != NULL as an indicator for the necessity to enter > the cdevpriv code, in particular, locking the cdevpriv_mtx, that would > otherwise needed to be entered at each last close. I think that one > pointer for the struct file is not too big cost, do you agree ? No, it's not a big cost, however if it is possible to avoid that is best. Can you not check the type before checking f_cdevpriv? Should we not only be checking cdevpriv in contexts where we know that it is not a vnode? > >> >>> >>> Of course, I forgot to answer the question. Yes, the KPI is supposed to >>> be used by the drivers only. Please, note that device open files have >>> DTYPE_VNODE. >>> > From owner-freebsd-arch@FreeBSD.ORG Tue May 13 01:05:02 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8545B1065671 for ; Tue, 13 May 2008 01:05:02 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by mx1.freebsd.org (Postfix) with ESMTP id 5AE848FC13 for ; Tue, 13 May 2008 01:05:02 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id Qo2N1Z0210x6nqcA703d00; Tue, 13 May 2008 01:04:37 +0000 Received: from discordia ([24.60.135.75]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id Qp4Z1Z0051dmTCQ8Y00000; Tue, 13 May 2008 01:04:35 +0000 X-Authority-Analysis: v=1.0 c=1 a=XFsXuKNdAAAA:8 a=YYlrVdjIwXE4X1UhW4UA:9 a=n_a-xRBQRTmYWXk0ZesA:7 a=7_uE0MA1-kuosAwiDocbrL7KABoA:4 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 a=MFU2FdmMXE0KYg_U_V0A:9 a=R9vp_NQhu9kG9gQE0TL1Xmdc9usA:4 a=rPt6xJ-oxjAA:10 Received: by discordia (Postfix, from userid 103) id EE39616B55D; Mon, 12 May 2008 21:04:32 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id 3846316B55B; Mon, 12 May 2008 21:04:15 -0400 (EDT) From: Coleman Kane To: rar102@ra.msstate.edu In-Reply-To: <200805121351.36765.rar102@ra.msstate.edu> References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210444435.62567.19.camel@localhost> <1210510187.62567.22.camel@localhost> <200805121351.36765.rar102@ra.msstate.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Wz8T+DHAVrkQngfaSPiP" Organization: FreeBSD Project Date: Mon, 12 May 2008 21:02:34 -0400 Message-Id: <1210640554.1439.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1.1 FreeBSD GNOME Team Port Cc: freebsd-arch@freebsd.org Subject: Re: compaq 6515b turion x2 laptop X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2008 01:05:02 -0000 --=-Wz8T+DHAVrkQngfaSPiP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2008-05-12 at 13:51 -0500, Robertsen A. Riehle wrote: > Coleman, >=20 > Sorry for dropping off the Earth for a moment there. In order to make am= ends,=20 > I am giving you two dmesg's. One from the installed NetBSD and one from = the=20 > FreeBSD livefs. Tell me if there is anything else I can get for you. I=20 > don't know if this is helpful or not. Possibly helpful command line outp= ut=20 > below: >=20 > dmesg | grep pcm=20 > No output. This is not suprising for a livefs. >=20 > kldload snd_hda > kldload: can't load snd_hda: No such file or directory. Not surprising= ,=20 > again. But it was worth a try. >=20 > dmesg | grep atapci > atapci0: port > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem= =20 > 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata3: on atapci0 > atapci1: port=20 > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 o= n=20 > pci0 > ata0: on atapci1 >=20 It looks to me that you have almost the identical system to what I have from HP. The SATA controller is definitely the same exact memory mapping. So, I've got two projects for you: 1) See if you can boot off the LiveFS again, and give me the output of "devinfo -u -v" 2) Visit the following page: http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp_c= ompaq_6715b_working Follow the directions that point you to where to find the good ISO images, and use them to boot the system. When you get to the boot menu, choose option #6 that will take you to the loader console. Then enter the following at the=20 loader prompt: set hw.pci.hp6715b_membase_for_hda_audio=3D"0xd0614000" Then enter (to start the system): boot See if that does anything for you better. If you still have problems, then it is likely you'll need a different membase. I hopefully will be able to give you a good mem-base depending upon the output of #1, above. The purpose of setting that loader variable is discussed further down the document on my site, under the HDA Audio device discussion. You can safely add that loader setting to /boot/loader.conf so that it is automatically set after you get your system installed. I'd like to get a copy of your new dmesg (using my images) after you boot up as well. --=20 Coleman Kane Rest of the blob copied below: > ################################################################## > Here is the FreeBSD dmesg: > Copyright (c) 1992-2008 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 > root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-64 (2194.58-MHz K8-class C= PU) > Origin =3D "AuthenticAMD" Id =3D 0x60f82 Stepping =3D 2 > =20 > Features=3D0x178bfbff > Features2=3D0x2001 > AMD Features=3D0xea500800 > AMD Features2=3D0x11f > Cores per package: 2 > usable memory =3D 4143468544 (3951 MB) > avail memory =3D 3974230016 (3790 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ACPI Error (tbfadt-0516): 32/64X address mismatch in "Pm2ControlBlock": [= =20 > 8800] [ 0 8100], using 64X [20070320] > ioapic0: Changing APIC ID to 2 > ioapic0 irqs 0-23 on motherboard > kbd1 at kbdmux0 > ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413= ) > hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > unknown: I/O range not supported > acpi0: reservation of 0, 8000000 (3) failed > acpi0: reservation of 100000, fff00000 (3) failed > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > cpu0: on acpi0 > acpi_throttle0: on cpu0 > powernow0: on cpu0 > cpu1: on acpi0 > acpi_throttle1: on cpu1 > acpi_throttle1: failed to attach P_CNT > device_attach: acpi_throttle1 attach returned 6 > powernow1: on cpu1 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > vgapci0: port 0x4000-0x40ff mem=20 > 0xc0000000-0xc7ffffff,0xd0400000-0xd040ffff,0xd0500000-0xd05fffff irq 19 = at=20 > device 5.0 on pci1 > pcib2: at device 4.0 on pci0 > pci16: on pcib2 > pci0:16:0:0: failed to read VPD data. > bge0: mem 0xd0000000-0xd000f= fff=20 > irq 16 at device 0.0 on pci16 > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,=20 > 1000baseT-FDX, auto > bge0: Ethernet address: 00:1f:29:85:3d:63 > bge0: [ITHREAD] > pcib3: at device 5.0 on pci0 > pci32: on pcib3 > pcib4: at device 6.0 on pci0 > pci48: on pcib4 > pci48: at device 0.0 (no driver attached) > atapci0: port=20 > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem= =20 > 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > atapci0: [ITHREAD] > ata2: on atapci0 > ata2: [ITHREAD] > ata3: on atapci0 > ata3: [ITHREAD] > ohci0: mem 0xd0601000-0xd0601fff irq 23 a= t=20 > device 19.0 on pci0 > ohci0: [GIANT-LOCKED] > ohci0: [ITHREAD] > usb0: OHCI version 1.0, legacy support > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: on usb0 > uhub0: 2 ports with 2 removable, self powered > ohci1: mem 0xd0602000-0xd0602fff irq 17 a= t=20 > device 19.1 on pci0 > ohci1: [GIANT-LOCKED] > ohci1: [ITHREAD] > usb1: OHCI version 1.0, legacy support > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: on usb1 > uhub1: 2 ports with 2 removable, self powered > ohci2: mem 0xd0603000-0xd0603fff irq 17 a= t=20 > device 19.2 on pci0 > ohci2: [GIANT-LOCKED] > ohci2: [ITHREAD] > usb2: OHCI version 1.0, legacy support > usb2: on ohci2 > usb2: USB revision 1.0 > uhub2: on usb2 > uhub2: 2 ports with 2 removable, self powered > ohci3: mem 0xd0604000-0xd0604fff irq 17 a= t=20 > device 19.3 on pci0 > ohci3: [GIANT-LOCKED] > ohci3: [ITHREAD] > usb3: OHCI version 1.0, legacy support > usb3: on ohci3 > usb3: USB revision 1.0 > uhub3: on usb3 > uhub3: 2 ports with 2 removable, self powered > ohci4: mem 0xd0605000-0xd0605fff irq 17 a= t=20 > device 19.4 on pci0 > ohci4: [GIANT-LOCKED] > ohci4: [ITHREAD] > usb4: OHCI version 1.0, legacy support > usb4: on ohci4 > usb4: USB revision 1.0 > uhub4: on usb4 > uhub4: 2 ports with 2 removable, self powered > ehci0: mem 0xd0606000-0xd06060ff irq = 23 at=20 > device 19.5 on pci0 > ehci0: [GIANT-LOCKED] > ehci0: [ITHREAD] > usb5: EHCI version 1.0 > usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 > usb5: on ehci0 > usb5: USB revision 2.0 > uhub5: on usb5 > uhub5: 10 ports with 10 removable, self powered > pci0: at device 20.0 (no driver attached) > atapci1: port=20 > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 o= n=20 > pci0 > ata0: on atapci1 > ata0: [ITHREAD] > pci0: at device 20.2 (no driver attached) > isab0: at device 20.3 on pci0 > isa0: on isab0 > pcib5: at device 20.4 on pci0 > pci2: on pcib5 > cbb0: mem 0xd0100000-0xd0100fff irq 20 at de= vice=20 > 4.0 on pci2 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [ITHREAD] > fwohci0: <1394 Open Host Controller Interface> mem 0xd0101000-0xd01017ff = irq=20 > 21 at device 4.1 on pci2 > fwohci0: [FILTER] > fwohci0: OHCI version 1.10 (ROM=3D0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:02:3f:99:29:21:1d:10 > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > dcons_crom0: on firewire0 > dcons_crom0: bus_addr 0x15dc000 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:02:3f:21:1d:10 > fwe0: Ethernet address: 02:02:3f:21:1d:10 > fwip0: on firewire0 > fwip0: Firewire address: 00:02:3f:99:29:21:1d:10 @ 0xfffe00000000, S400,=20 > maxrec 2048 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: BUS reset > fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode > battery0: on acpi0 > battery1: on acpi0 > acpi_acad0: on acpi0 > acpi_button0: on acpi0 > acpi_lid0: on acpi0 > acpi_tz0: on acpi0 > 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, device ID 3 > ppc0: port 0-0x7,0x400-0x402 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Polled port > ppi0: on ppbus0 > orm0: at iomem 0xd0000-0xd0fff on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=3D0x300> > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 8250 or not responding > sio0: [FILTER] > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > ugen0: 2> on uhub0 > umass0: on uhub1 > ugen1: 2> on uhub2 > Timecounters tick every 1.000 msec > hptrr: no controller detected. > firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) > firewire0: bus manager 0 (me) > md0: Preloaded image 4194304 bytes at 0xffffffff80bc6c08 > acd0: DVDR at ata0-master PIO4 > ad4: 114473MB at ata2-master UDMA33 > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=3D0x64 ascq=3D0x00=20 > GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_LiveFS. > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=3D0x64 ascq=3D0x00=20 > GEOM_LABEL: Label for provider ad4s3 is ntfs/HP_RECOVERY. > GEOM_LABEL: Label for provider ad4s4 is ntfs/OS_TOOLS. > SMP: AP CPU #1 Launched! > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-CCS device=20 > da0: 1.000MB/s transfers > da0: 61MB (125952 512 byte sectors: 64H 32S/T 61C) > GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. > Trying to mount root from ufs:/dev/md0 > GEOM_LABEL: Label msdosfs/CRUCIAL removed. > GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. > GEOM_LABEL: Label msdosfs/CRUCIAL removed. >=20 > ####################################################################### > Here is the NetBSD dmesg: >=20 > Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, > 2006, 2007 > The NetBSD Foundation, Inc. All rights reserved. > Copyright (c) 1982, 1986, 1989, 1991, 1993 > The Regents of the University of California. All rights reserved. >=20 > NetBSD 4.0 (GENERIC) #0: Sat Dec 15 22:25:31 PST 2007 > =09 > builds@wb28:/home/builds/ab/netbsd-4-0-RELEASE/amd64/200712160005Z-obj/ho= me/builds/ab/netbsd-4-0-RELEASE/src/sys/arch/amd64/compile/GENERIC > total memory =3D 3967 MB > avail memory =3D 3815 MB > timecounter: Timecounters tick every 10.000 msec > timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 > mainbus0 (root) > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Turion(tm) 64 X2 Mobile Technology TL-64, 2195.04 MHz > cpu0: features: ffdbfbff > cpu0: features: ffdbfbff > cpu0: features: ffdbfbff > cpu0: features2: 2001 > cpu0: I-cache 64 KB 64B/line 2-way, D-cache 64 KB 64B/line 2-way > cpu0: L2 cache 512 KB 64B/line 16-way > cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully associ= ative > cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully associ= ative > cpu0: AMD Power Management features: 7f > cpu0: AMD PowerNow! Technology 2200 MHz > cpu0: available frequencies (Mhz): 800 1600 1800 2000 2200 > cpu0: calibrating local timer > cpu0: apic clock running at 199 MHz > cpu0: 8 page colors > cpu1 at mainbus0: apid 1 (application processor) > cpu1: not started > ioapic0 at mainbus0 apid 2 (I/O APIC) > ioapic0: pa 0xfec00000, version 21, 24 pins > ioapic0: misconfigured as apic 0 > ioapic0: remapped to apic 2 > acpi0 at mainbus0: Advanced Configuration and Power Interface > acpi0: using Intel ACPI CA subsystem version 20060217 > acpi0: X/RSDT: OemId , AslId > ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A1 (name not of fo= rm=20 > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C28C (name not of fo= rm=20 > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A2 (name not of fo= rm=20 > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A3 (name not of fo= rm=20 > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C253 (name not of fo= rm=20 > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A4 (name not of fo= rm=20 > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A5 (name not of fo= rm=20 > _Lxx or _Exx) [20060217] > ACPI Error (evgpeblk-0394): Unknown GPE method type: C262 (name not of fo= rm=20 > _Lxx or _Exx) [20060217] > acpi0: SCI interrupting at int 9 > acpi0: fixed-feature power button present > timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 > ACPI-Fast 32-bit timer > mpacpi: could not get bus number, assuming bus 0 > ACPI Object Type 'Processor' (0x0c) at acpi0 not configured > ACPI Object Type 'Processor' (0x0c) at acpi0 not configured > PNP0C01 [System Board] at acpi0 not configured > PNP0A03 [PCI/PCI-X Host Bridge] at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > acpiec0 at acpi0 (PNP0C09): ACPI Embedded Controller > acpiec0: io 0x62,0x66 > PNP0A06 [Generic Container Device] at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > IFX0102 at acpi0 not configured > PNP0C04 [Math Coprocessor] at acpi0 not configured > attimer1 at acpi0 (PNP0100): AT Timer > attimer1: io 0x40-0x43 irq 0 > PNP0200 [AT DMA Controller] at acpi0 not configured > pcppi1 at acpi0 (PNP0800) > pcppi1: io 0x61 > pcppi1: children must have an explicit unit > midi0 at pcppi1: PC speaker (CPU-intensive output) > sysbeep0 at pcppi1 > PNP0B00 [AT Real-Time Clock] at acpi0 not configured > pckbc1 at acpi0 (PNP0303): kbd port > pckbc1: io 0x60,0x64 irq 1 > pckbc2 at acpi0 (SYN0131): aux port > pckbc2: irq 12 > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > PNP0000 [AT Interrupt Controller] at acpi0 not configured > PNP0C02 [Plug and Play motherboard register resources] at acpi0 not confi= gured > HPQ0004 at acpi0 not configured > PNP0C02 [Plug and Play motherboard register resources] at acpi0 not confi= gured > HPQ0006 at acpi0 not configured > acpibat0 at acpi0 (PNP0C0A-1): ACPI Battery (Control Method) > acpibat1 at acpi0 (PNP0C0A-2): ACPI Battery (Control Method) > acpiacad0 at acpi0 (ACPI0003): ACPI AC Adapter > acpibut0 at acpi0 (PNP0C0E): ACPI Sleep Button > acpilid0 at acpi0 (PNP0C0D): ACPI Lid Switch > PNP0C14 at acpi0 not configured > PNP0C02 [Plug and Play motherboard register resources] at acpi0 not confi= gured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > ACPI Object Type 'Power' (0x0b) at acpi0 not configured > PNP0C0B [ACPI Fan] at acpi0 not configured > PNP0C0B [ACPI Fan] at acpi0 not configured > PNP0C0B [ACPI Fan] at acpi0 not configured > PNP0C0B [ACPI Fan] at acpi0 not configured > acpitz0 at acpi0: ACPI Thermal Zone > acpitz0: unable to get polling interval; using default of 30.0s > acpitz0: active cooling level 0: 70.0C > acpitz0: active cooling level 1: 60.0C > acpitz0: active cooling level 2: 50.0C > acpitz0: active cooling level 3: 40.0C > acpitz0: critical 105.0C passive 38.0C > pcppi1: attached to attimer1 > pckbd0 at pckbc1 (kbd slot) > pckbc1: using irq 1 for kbd slot > wskbd0 at pckbd0: console keyboard > pms0 at pckbc1 (aux slot) > pms0: Synaptics touchpad version 6.2 > pms0: Palm detect, Multi-finger > pckbc1: using irq 12 for aux slot > wsmouse0 at pms0 mux 0 > pci0 at mainbus0 bus 0: configuration mode 1 > pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok > pchb0 at pci0 dev 0 function 0 > pchb0: ATI Technologies product 0x7910 (rev. 0x00) > ppb0 at pci0 dev 1 function 0: ATI Technologies product 0x7912 (rev. 0x00= ) > pci1 at ppb0 bus 1 > pci1: i/o space, memory space enabled > vga0 at pci1 dev 5 function 0: ATI Technologies product 0x791f (rev. 0x00= ) > wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using wskb= d0 > wsmux1: connecting to wsdisplay0 > ppb1 at pci0 dev 4 function 0: ATI Technologies product 0x7914 (rev. 0x00= ) > pci2 at ppb1 bus 16 > pci2: i/o space, memory space enabled, rd/line, wr/inv ok > bge0 at pci2 dev 0 function 0: Broadcom BCM5787M Gigabit Ethernet > bge0: interrupting at ioapic0 pin 16 (irq 10) > bge0: ASIC BCM5754/5787 A2 (0xb002), Ethernet address 00:1f:29:85:3d:63 > bge0: setting short Tx thresholds > brgphy0 at bge0 phy 1: BCM5754/5787 1000BASE-T media interface, rev. 0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT,=20 > 1000baseT-FDX, auto > ppb2 at pci0 dev 5 function 0: ATI Technologies product 0x7915 (rev. 0x00= ) > pci3 at ppb2 bus 32 > pci3: i/o space, memory space enabled, rd/line, wr/inv ok > ppb3 at pci0 dev 6 function 0: ATI Technologies product 0x7916 (rev. 0x00= ) > pci4 at ppb3 bus 48 > pci4: i/o space, memory space enabled, rd/line, wr/inv ok > Broadcom BCM4312 (miscellaneous network, revision 0x02) at pci4 dev 0 fun= ction=20 > 0 not configured > ixpide0 at pci0 dev 18 function 0 > ixpide0: ATI Technologies IXP IDE Controller (rev. 0x00) > ixpide0: bus-master DMA support present > ixpide0: primary channel configured to native-PCI mode > ixpide0: using ioapic0 pin 16 (irq 10) for native-PCI interrupt > atabus0 at ixpide0 channel 0 > ixpide0: secondary channel configured to native-PCI mode > atabus1 at ixpide0 channel 1 > ohci0 at pci0 dev 19 function 0: ATI Technologies product 0x4387 (rev. 0x= 00) > ohci0: interrupting at ioapic0 pin 23 (irq 11) > ohci0: OHCI version 1.0, legacy support > usb0 at ohci0: USB revision 1.0 > uhub0 at usb0 > uhub0: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > ohci1 at pci0 dev 19 function 1: ATI Technologies product 0x4388 (rev. 0x= 00) > ohci1: interrupting at ioapic0 pin 17 (irq 5) > ohci1: OHCI version 1.0, legacy support > usb1 at ohci1: USB revision 1.0 > uhub1 at usb1 > uhub1: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 2 ports with 2 removable, self powered > ohci2 at pci0 dev 19 function 2: ATI Technologies product 0x4389 (rev. 0x= 00) > ohci2: interrupting at ioapic0 pin 17 (irq 5) > ohci2: OHCI version 1.0, legacy support > usb2 at ohci2: USB revision 1.0 > uhub2 at usb2 > uhub2: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub2: 2 ports with 2 removable, self powered > ohci3 at pci0 dev 19 function 3: ATI Technologies product 0x438a (rev. 0x= 00) > ohci3: interrupting at ioapic0 pin 17 (irq 5) > ohci3: OHCI version 1.0, legacy support > usb3 at ohci3: USB revision 1.0 > uhub3 at usb3 > uhub3: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub3: 2 ports with 2 removable, self powered > ohci4 at pci0 dev 19 function 4: ATI Technologies product 0x438b (rev. 0x= 00) > ohci4: interrupting at ioapic0 pin 17 (irq 5) > ohci4: OHCI version 1.0, legacy support > usb4 at ohci4: USB revision 1.0 > uhub4 at usb4 > uhub4: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub4: 2 ports with 2 removable, self powered > ehci0 at pci0 dev 19 function 5: ATI Technologies product 0x4386 (rev. 0x= 00) > ehci0: interrupting at ioapic0 pin 23 (irq 11) > ehci0: BIOS has given up ownership > ehci0: EHCI version 1.0 > ehci0: companion controllers, 2 ports each: ohci0 ohci1 ohci2 ohci3 ohci4 > usb5 at ehci0: USB revision 2.0 > uhub5 at usb5 > uhub5: ATI Technologies EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 > uhub5: 10 ports with 10 removable, self powered > ATI Technologies product 0x4385 (SMBus serial bus, revision 0x14) at pci0= dev=20 > 20 function 0 not configured > ixpide1 at pci0 dev 20 function 1 > ixpide1: ATI Technologies IXP IDE Controller (rev. 0x00) > ixpide1: bus-master DMA support present > ixpide1: primary channel configured to compatibility mode > ixpide1: primary channel interrupting at ioapic0 pin 14 (irq 14) > atabus2 at ixpide1 channel 0 > ixpide1: secondary channel wired to compatibility mode > ixpide1: secondary channel interrupting at ioapic0 pin 15 (irq 15) > atabus3 at ixpide1 channel 1 > azalia0 at pci0 dev 20 function 2: Generic High Definition Audio Controll= er > azalia0: interrupting at ioapic0 pin 16 (irq 10) > azalia0: host: 0x1002/0x4383 (rev. 0) > azalia0: host: High Definition Audio rev. 1.0 > pcib0 at pci0 dev 20 function 3 > pcib0: ATI Technologies product 0x438d (rev. 0x00) > ppb4 at pci0 dev 20 function 4: ATI Technologies product 0x4384 (rev. 0x0= 0) > pci5 at ppb4 bus 2 > pci5: i/o space, memory space enabled > cbb0 at pci5 dev 4 function 0: Ricoh 5C476 PCI-CardBus bridge (rev. 0xb6) > fwohci0 at pci5 dev 4 function 1: Ricoh product 0x0832 (rev. 0x02) > fwohci0: interrupting at ioapic0 pin 21 (irq 5) > fwohci0: OHCI version 1.10 (ROM=3D0) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:02:3f:99:29:21:1d:10 > fwohci0: Phy 1394a available S400, 1 ports. > fwohci0: Link S400, max_rec 2048 bytes. > ieee1394if0 at fwohci0: IEEE1394 bus > fwip0 at ieee1394if0: IP over IEEE1394 > fwohci0: Initiate bus reset > cbb0: interrupting at ioapic0 pin 20 (irq 10) > cardslot0 at cbb0 slot 0 flags 0 > cardbus0 at cardslot0: bus 3 > pcmcia0 at cardslot0 > pchb1 at pci0 dev 24 function 0 > pchb1: Advanced Micro Devices AMD64 HyperTransport configuration (rev. 0x= 00) > pchb2 at pci0 dev 24 function 1 > pchb2: Advanced Micro Devices AMD64 Address Map configuration (rev. 0x00) > pchb3 at pci0 dev 24 function 2 > pchb3: Advanced Micro Devices AMD64 DRAM configuration (rev. 0x00) > pchb4 at pci0 dev 24 function 3 > pchb4: Advanced Micro Devices AMD64 Miscellaneous configuration (rev. 0x0= 0) > isa0 at pcib0 > ioapic0: enabling > WARNING: Callback scheduled before sysmon task queue thread present. > fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode > ieee1394if0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) > ieee1394if0: bus manager 0 (me) > timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 > azalia0: codec[0]: Analog Devices AD1981HD (rev. 2.0) > azalia0: codec[0]: High Definition Audio rev. 1.0 > azalia0: playback: max channels=3D2, encodings=3D1 > azalia0: playback: PCM=20 > formats=3De007f<24bit,20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.0= 25kHz,8kHz> > azalia0: recording: max channels=3D2, encodings=3D1 > azalia0: recording: PCM=20 > formats=3D6007f<20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.025kHz,= 8kHz> > azalia0: codec[1]: 0x11c1/0x1040 (rev. 2.0) > azalia0: codec[1]: High Definition Audio rev. 1.0 > azalia0: codec[1]: No support for modem function groups > azalia0: codec[1] has no audio function groups > audio0 at azalia0: full duplex, independent > Kernelized RAIDframe activated > acpibat0: battery info: Hewlett-Packard, LIon, Primary, 48204 2008/04/13 > ugen0 at uhub2 port 1 > ugen0: AuthenTec Fingerprint Sensor, rev 1.10/6.23, addr 2 > wd0 at atabus0 drive 0: > wd0: drive supports 16-sector PIO transfers, LBA48 addressing > wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 sect= ors > wd0: 32-bit data port > wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) > wd0(ixpide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using D= MA) > atapibus0 at atabus2: 2 targets > cd0 at atapibus0 drive 0: c= drom=20 > removable > cd0: 32-bit data port > cd0: drive supports PIO mode 4, DMA mode 2 > cd0(ixpide1:0:0): using PIO mode 4, DMA mode 2 (using DMA) > boot device: wd0 > root on wd0a dumps on wd0b > root file system type: ffs > WARNING: clock gained 7 days > WARNING: CHECK AND RESET THE DATE! > wsdisplay0: screen 1 added (80x25, vt100 emulation) > wsdisplay0: screen 2 added (80x25, vt100 emulation) > wsdisplay0: screen 3 added (80x25, vt100 emulation) > wsdisplay0: screen 4 added (80x25, vt100 emulation) >=20 >=20 >=20 >=20 >=20 >=20 > On Sunday 11 May 2008 07:49:47 you wrote: > > On Sat, 2008-05-10 at 14:33 -0400, Coleman Kane wrote: > > > On Sat, 2008-05-10 at 12:13 -0500, rar102@ra.msstate.edu wrote: > > > > Quoting Coleman Kane : > > > > > > > > Yes!!! thank you. Unfortunately, I don't have access to another am= d64 > > > > box to try your patch. Sorry. But, I will look at the dmesg and s= end > > > > it to you. > > > > > > Excellent. A dmesg will be very helpful for me to write a patch from,= as > > > it will allow me to see if it is or is not the sound driver overlappi= ng > > > memory in your case. I suspect that the BIOS images are so similar th= at > > > you probably even have almost the same bios-chosen memory regions on > > > your system. > > > > If you're having difficulty getting a dmesg, you might want to try > > booting off the LiveFS disc with a USB flash drive plugged in. You can > > then mount the flash drive (which should be detected as SCSI) and write > > the dmesg output there. > > > > > > > RAR, > > > > > > > > > > You are in luck! Well, actually I have good news and I have bad n= ews. > > > > > The good news is that I have nearly the same (6715b) laptop and > > > > > experienced similar problems when getting FreeBSD onto it. After = some > > > > > work, I've been able to use FreeBSD reliably on the system. > > > > > > > > > > The bad news is that you probably have an overlap of PCI memory > > > > > ranges between the SATA controller and another device in the syst= em > > > > > (likely the audio controller). > > > > > > > > > > I put up a page describing the problem here: > > > > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_= the_ > > > >hp_compaq_6715b_working > > > > > > > > > Specifically, read this section: > > > > > > > > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onbo= ard_ > > > >ati_sb600_hda_audio_controller > > > > > > > > > Give me the weekend, and I will post a 7.0-RELEASE CD with the pa= tch > > > > > in it. I figured that I should have done it a while ago. Oh well. > > > > > > > > > > While you are at it, see if you can use Scroll-Lock and the up/do= wn > > > > > keys to read the kernel messages. See if you can find the atapci0 > > > > > probe line for your SATA controller (AHCI), as well as the line f= or > > > > > your pcm0 device and send them back to me. I can add your info to= my > > > > > webpage to help others. > > > > > > > > > > It will look like this: > > > > > atapci0: port > > > > > 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x= 502f > > > > > mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 > > > > > ... > > > > > pcm0: mem > > > > > 0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0 > > > > > > > > > > You'll notice the "mem" resource for the audio controller is > > > > > 0xd0608000-0xd060bff, and the "mem" resource for the SATA control= ler > > > > > is 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is > > > > > completely covered by this audio controller. > > > > > > > > > > If you happen to have access to another machine for building your= own > > > > > releases, you can try my patch and build them from it. > > > > > > > > > > -- > > > > > Coleman Kane --=-Wz8T+DHAVrkQngfaSPiP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkgo6KUACgkQcMSxQcXat5co8ACfdxzMMAKHwUZmYS3gY59p7F99 GS8An0xu3HIij6x4Kd8qRZ2duiYEDzN1 =RkWC -----END PGP SIGNATURE----- --=-Wz8T+DHAVrkQngfaSPiP-- From owner-freebsd-arch@FreeBSD.ORG Tue May 13 09:37:49 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8470F1065766 for ; Tue, 13 May 2008 09:37:49 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay03.kiev.sovam.com (relay03.kiev.sovam.com [62.64.120.201]) by mx1.freebsd.org (Postfix) with ESMTP id 493B38FC25 for ; Tue, 13 May 2008 09:37:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay03.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Jvqx5-0008XO-0o for arch@freebsd.org; Tue, 13 May 2008 12:37:43 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4D9bbCW063879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 12:37:38 +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.2/8.14.2) with ESMTP id m4D9bZnO065057; Tue, 13 May 2008 12:37:35 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m4D9bYfq065055; Tue, 13 May 2008 12:37:34 +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, 13 May 2008 12:37:34 +0300 From: Kostik Belousov To: Jeff Roberson Message-ID: <20080513093734.GF18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> <20080511115815.GW18958@deviant.kiev.zoral.com.ua> <20080511153926.T954@desktop> <20080512101607.GC18958@deviant.kiev.zoral.com.ua> <20080512100202.W954@desktop> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7yq/Cf0cB4WNollR" Content-Disposition: inline In-Reply-To: <20080512100202.W954@desktop> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: 3c73e585e5c021cb3ff5f493c210d5be X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2807 [May 12 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: arch@freebsd.org Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2008 09:37:49 -0000 --7yq/Cf0cB4WNollR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 12, 2008 at 10:03:14AM -1000, Jeff Roberson wrote: >=20 > On Mon, 12 May 2008, Kostik Belousov wrote: >=20 > >On Sun, May 11, 2008 at 03:40:14PM -1000, Jeff Roberson wrote: > >> > >>On Sun, 11 May 2008, Kostik Belousov wrote: > >> > >>>On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: > >>>>On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > >>>>>On Sun, 4 May 2008, Kostik Belousov wrote: > >>>>> > >>>>>>Since the review for the clone-at-open patch (fdclone) posted some= =20 > >>>>>>time > >>>>>>ago > >>>>>>mostly says that it would be better to implement per-file private d= ata > >>>>>>instead, I produced the patch along this line, > >>>>>> > >>>>>>The patch does not change the cdevsw ABI, instead, three new functi= ons > >>>>>>nt devfs_get_cdevpriv(void **datap); > >>>>>>int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > >>>>>>void devfs_clear_cdevpriv(void); > >>>>>>are provided for manipulation of the per-file private data. > >>>>>> > >>>>>>devfs_set_cdevpriv assigns the priv as private data for the file > >>>>>>descriptor > >>>>>>which is used to initiate currently performed driver operation. dtr > >>>>>>is the function that will be called when either the last refernce to > >>>>>>the file goes away or devfs_clear_cdevpriv is called. > >>>>>> > >>>>>>devfs_get_cdevpriv is the obvious accessor. > >>>>>> > >>>>>>devfs_clear_cdevpriv allows to clear the private data for the still > >>>>>>open file. > >>>>>> > >>>>>>The synchronization of the cdev data and file private data is left > >>>>>>to the driver code, I did not found any generic helper mechanism th= at > >>>>>>could be useful there. > >>>>>> > >>>>>>Patch: > >>>>>>http://people.freebsd.org/~kib/misc/fdpriv.1.patch > >>>>>> > >>>>>>Dumb driver that shows the basic usage of the proposed KPI: > >>>>>>http://people.freebsd.org/~kib/misc/fpclone.c > >>>>>> > >>>>>>Previous version of the patch was tested by Peter Holm. > >>>>>> > >>>>> > >>>>>Hi Kostik, > >>>>> > >>>>>Are these per-instances structures intended to be used by anything= =20 > >>>>>other > >>>>>than devices? If not can we make them a union with the DTYPE_VNODE > >>>>>fields to save space? > >>>>> > >>>>>Thanks, > >>>>>Jeff > >>>> > >>>>The current version of the patch is at > >>>>http://people.freebsd.org/~kib/misc/fdpriv.3.patch > >>>> > >>>>Per insistence of John Baldwin and request of Eric Anholt, the=20 > >>>>destructors > >>>>are called now when either file is last closed, or the device is > >>>>destroyed. > >>>>This versions adds only one pointer to the struct file. > >>>> > >>>>Jeff, would you, please, explicitely specify what field you propose to > >>>>union with the f_cdevpriv ? > >> > >>f_nextoff and f_seqcount are only used if vn_read() and vn_write() are > >>used. They do not apply to any other descriptors. > >I use the f_cdevpriv !=3D NULL as an indicator for the necessity to enter > >the cdevpriv code, in particular, locking the cdevpriv_mtx, that would > >otherwise needed to be entered at each last close. I think that one > >pointer for the struct file is not too big cost, do you agree ? >=20 > No, it's not a big cost, however if it is possible to avoid that is best. >=20 > Can you not check the type before checking f_cdevpriv? Should we not onl= y=20 > be checking cdevpriv in contexts where we know that it is not a vnode? I am sorry, my english may be not enough, so I may interpret your proposal mistakenly. I read it as a suggestion to check the file type before accessing the f_cdevpriv. The problem with the f_cdevpriv exists only at the _fdrop(). There, we have a file of f_type =3D=3D DTYPE_VNODE both for devfs and normal files. I cannot check the f_vnode since the vnode may be reclaimed. The only differentiator is the f_ops, that is devfs_ops_f for devfs file, and vnops for the normal file during the file lifetime. Unfortunately, f_ops is reset to the badfileops by vn_closefile before the _fdrop() is getting called. Reserving the flag in the f_flag looks not good due to interaction with the userspace. I do not want the callback to be called before the d_close() driver method gets a chance to clean the data. >=20 > > > >> > >>> > >>>Of course, I forgot to answer the question. Yes, the KPI is supposed to > >>>be used by the drivers only. Please, note that device open files have > >>>DTYPE_VNODE. > >>> > > --7yq/Cf0cB4WNollR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgpYV0ACgkQC3+MBN1Mb4iY0ACgvoYMcS9XS3/a9Uae1motcOiG z6AAoMWSpiZuO1wV/CtT1t2IQvydAO6w =lpEc -----END PGP SIGNATURE----- --7yq/Cf0cB4WNollR-- From owner-freebsd-arch@FreeBSD.ORG Wed May 14 09:13:58 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79EFD1065677 for ; Wed, 14 May 2008 09:13:58 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by mx1.freebsd.org (Postfix) with ESMTP id 174138FC12 for ; Wed, 14 May 2008 09:13:57 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp5-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp5-g19.free.fr (Postfix) with ESMTP id 4B70F3F6289; Wed, 14 May 2008 11:13:56 +0200 (CEST) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp5-g19.free.fr (Postfix) with ESMTP id 3018B3F6284; Wed, 14 May 2008 11:13:56 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 77C4C9D6EF; Wed, 14 May 2008 09:11:08 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 677944089; Wed, 14 May 2008 11:11:08 +0200 (CEST) Date: Wed, 14 May 2008 11:11:08 +0200 From: Jeremie Le Hen To: Marcel Moolenaar Message-ID: <20080514091108.GD70896@obiwan.tataz.chchile.org> References: <20080502070147.GE74500@obiwan.tataz.chchile.org> <8ED24288-618C-4B55-A27E-C5FAB2E046E8@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8ED24288-618C-4B55-A27E-C5FAB2E046E8@mac.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-arch@FreeBSD.org Subject: Re: Integration of ProPolice in FreeBSD X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2008 09:13:58 -0000 Hi Marcel, Thank you for your comments. On Fri, May 02, 2008 at 08:52:37AM -0700, Marcel Moolenaar wrote: > Index: share/mk/bsd.sys.mk > =================================================================== > RCS file: /mnt/octobre/space/freebsd-cvs/src/share/mk/bsd.sys.mk,v > retrieving revision 1.44 > diff -u -p -r1.44 bsd.sys.mk > --- share/mk/bsd.sys.mk 22 Nov 2007 23:21:12 -0000 1.44 > +++ share/mk/bsd.sys.mk 29 Mar 2008 23:13:06 -0000 > @@ -74,5 +74,10 @@ CWARNFLAGS += -Werror > CWARNFLAGS += -Wno-unknown-pragmas > .endif > > +.if ${MK_SSP} != "no" && ${CC} != "icc" > +CFLAGS += -fstack-protector > +# Don't use -Wstack-protector as it breaks world with -Werror. > +.endif > + > # Allow user-specified additional warning flags > CFLAGS += ${CWARNFLAGS} > > > I may be better to explicitly test for GCC. I would not assume > that GCC and ICC are the only options, even if they are now. > There's a second place as well... I would make sense to test for GCC indeed but in the same file there is a number of explicit tests for ICC. Thus I prefer to keep to the current "style" at the expense of a little more work for those who will try to compile with another compiler. > Index: sys/boot/i386/Makefile.inc > =================================================================== > RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/i386/Makefile.inc,v > retrieving revision 1.12 > diff -u -p -r1.12 Makefile.inc > --- sys/boot/i386/Makefile.inc 28 Sep 2006 10:02:04 -0000 1.12 > +++ sys/boot/i386/Makefile.inc 28 Mar 2008 07:41:32 -0000 > @@ -24,3 +24,5 @@ BTXDIR= ${.CURDIR}/../btx > BTXLDR= ${BTXDIR}/btxldr/btxldr > BTXKERN= ${BTXDIR}/btx/btx > BTXCRT= ${BTXDIR}/lib/crt0.o > + > +.include "../Makefile.inc" > Index: sys/boot/i386/loader/Makefile > =================================================================== > RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/i386/loader/Makefile,v > retrieving revision 1.85 > diff -u -p -r1.85 Makefile > --- sys/boot/i386/loader/Makefile 29 May 2007 14:35:57 -0000 1.85 > +++ sys/boot/i386/loader/Makefile 16 Apr 2008 09:14:10 -0000 > @@ -1,5 +1,7 @@ > # $FreeBSD: src/sys/boot/i386/loader/Makefile,v 1.85 2007/05/29 14:35:57 > simokawa Exp $ > > +WITHOUT_SSP= > + > .include > > PROG= loader.sym > > Maybe second and third level makefiles should include > ../../Makefile.inc and ../../../Makefile.inc resp. > If, for arguments sake, we want to enable SSP in boot, > then it's best if that only requires a single knob to > be changed. This may not be a strong argument for SSP, > but with Makefile.inc in place, I don't see a possible > future in which another knob is added that controls > overall behavior (e.g. something like the Watcom option > to use argument passing in registers instead of on the > stack for i386 -- you definitely want to have that apply > to all code or none). For now, I prefer leaving it as is and let anyone else make this change. While I agree with your argument, I'm not sure this benefit is worth the complexity it adds for now, given that the only knob is WITHOUT_SSP and it would require more than a simple switch to use SSP for /boot (import SSP symbols). > Also, please make sure MK_SSP defaults to "no" on ia64. Ok, done. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-arch@FreeBSD.ORG Wed May 14 09:32:56 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEBD1106566B for ; Wed, 14 May 2008 09:32:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from anti-4.kiev.sovam.com (anti-4.kiev.sovam.com [62.64.120.202]) by mx1.freebsd.org (Postfix) with ESMTP id 7432A8FC19 for ; Wed, 14 May 2008 09:32:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by anti-4.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JwDLY-000DAK-Vc for arch@freebsd.org; Wed, 14 May 2008 12:32:54 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4E9WQ9P017779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 May 2008 12:32:26 +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.2/8.14.2) with ESMTP id m4E9WNCC043603; Wed, 14 May 2008 12:32:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m4E9WNW0043602; Wed, 14 May 2008 12:32:23 +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: Wed, 14 May 2008 12:32:23 +0300 From: Kostik Belousov To: Jeff Roberson Message-ID: <20080514093223.GN18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080510214812.Y954@desktop> <20080511115030.GV18958@deviant.kiev.zoral.com.ua> <20080511115815.GW18958@deviant.kiev.zoral.com.ua> <20080511153926.T954@desktop> <20080512101607.GC18958@deviant.kiev.zoral.com.ua> <20080512100202.W954@desktop> <20080513093734.GF18958@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5glgGqCv79Y86mRH" Content-Disposition: inline In-Reply-To: <20080513093734.GF18958@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: e3b942a55251a77f49093e43cd2f7d51 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2811 [May 13 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: arch@freebsd.org Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2008 09:32:56 -0000 --5glgGqCv79Y86mRH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, May 13, 2008 at 12:37:34PM +0300, Kostik Belousov wrote: > On Mon, May 12, 2008 at 10:03:14AM -1000, Jeff Roberson wrote: > >=20 > > On Mon, 12 May 2008, Kostik Belousov wrote: > >=20 > > >On Sun, May 11, 2008 at 03:40:14PM -1000, Jeff Roberson wrote: > > >> > > >>On Sun, 11 May 2008, Kostik Belousov wrote: > > >> > > >>>On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: > > >>>>On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > > >>>>>On Sun, 4 May 2008, Kostik Belousov wrote: > > >>>>> > > >>>>>>Since the review for the clone-at-open patch (fdclone) posted som= e=20 > > >>>>>>time > > >>>>>>ago > > >>>>>>mostly says that it would be better to implement per-file private= data > > >>>>>>instead, I produced the patch along this line, > > >>>>>> > > >>>>>>The patch does not change the cdevsw ABI, instead, three new func= tions > > >>>>>>nt devfs_get_cdevpriv(void **datap); > > >>>>>>int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > >>>>>>void devfs_clear_cdevpriv(void); > > >>>>>>are provided for manipulation of the per-file private data. > > >>>>>> > > >>>>>>devfs_set_cdevpriv assigns the priv as private data for the file > > >>>>>>descriptor > > >>>>>>which is used to initiate currently performed driver operation. d= tr > > >>>>>>is the function that will be called when either the last refernce= to > > >>>>>>the file goes away or devfs_clear_cdevpriv is called. > > >>>>>> > > >>>>>>devfs_get_cdevpriv is the obvious accessor. > > >>>>>> > > >>>>>>devfs_clear_cdevpriv allows to clear the private data for the sti= ll > > >>>>>>open file. > > >>>>>> > > >>>>>>The synchronization of the cdev data and file private data is left > > >>>>>>to the driver code, I did not found any generic helper mechanism = that > > >>>>>>could be useful there. > > >>>>>> > > >>>>>>Patch: > > >>>>>>http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > >>>>>> > > >>>>>>Dumb driver that shows the basic usage of the proposed KPI: > > >>>>>>http://people.freebsd.org/~kib/misc/fpclone.c > > >>>>>> > > >>>>>>Previous version of the patch was tested by Peter Holm. > > >>>>>> > > >>>>> > > >>>>>Hi Kostik, > > >>>>> > > >>>>>Are these per-instances structures intended to be used by anything= =20 > > >>>>>other > > >>>>>than devices? If not can we make them a union with the DTYPE_VNODE > > >>>>>fields to save space? > > >>>>> > > >>>>>Thanks, > > >>>>>Jeff > > >>>> > > >>>>The current version of the patch is at > > >>>>http://people.freebsd.org/~kib/misc/fdpriv.3.patch > > >>>> > > >>>>Per insistence of John Baldwin and request of Eric Anholt, the=20 > > >>>>destructors > > >>>>are called now when either file is last closed, or the device is > > >>>>destroyed. > > >>>>This versions adds only one pointer to the struct file. > > >>>> > > >>>>Jeff, would you, please, explicitely specify what field you propose= to > > >>>>union with the f_cdevpriv ? > > >> > > >>f_nextoff and f_seqcount are only used if vn_read() and vn_write() are > > >>used. They do not apply to any other descriptors. > > >I use the f_cdevpriv !=3D NULL as an indicator for the necessity to en= ter > > >the cdevpriv code, in particular, locking the cdevpriv_mtx, that would > > >otherwise needed to be entered at each last close. I think that one > > >pointer for the struct file is not too big cost, do you agree ? > >=20 > > No, it's not a big cost, however if it is possible to avoid that is bes= t. > >=20 > > Can you not check the type before checking f_cdevpriv? Should we not o= nly=20 > > be checking cdevpriv in contexts where we know that it is not a vnode? >=20 > I am sorry, my english may be not enough, so I may interpret your > proposal mistakenly. I read it as a suggestion to check the file type > before accessing the f_cdevpriv. >=20 > The problem with the f_cdevpriv exists only at the _fdrop(). There, we > have a file of f_type =3D=3D DTYPE_VNODE both for devfs and normal files. > I cannot check the f_vnode since the vnode may be reclaimed. The only > differentiator is the f_ops, that is devfs_ops_f for devfs file, and > vnops for the normal file during the file lifetime. Unfortunately, > f_ops is reset to the badfileops by vn_closefile before the _fdrop() is > getting called. >=20 > Reserving the flag in the f_flag looks not good due to interaction with > the userspace. >=20 > I do not want the callback to be called before the d_close() driver method > gets a chance to clean the data. So, I cannot implement overlay of the cdevpriv over the seqaccess data=20 without some additional flag. On the other hand, use of 2 bytes for the f_type is overkill when the range of the types is [1,8]. I divided it to two one-byte fields, and new field is used for filetype-specific flags. http://people.freebsd.org/~kib/misc/fdpriv.4.patch shall give the same size of the struct file while not causing unconditional acquire of the cdevpriv_mtx on the last file close. Jeff, do you agree with the proposed vivisection of the f_type ? I will ask Peter to retest the patch then. --5glgGqCv79Y86mRH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgqsaYACgkQC3+MBN1Mb4hPJQCgnwivOryzU6WwVdASNvY0MNXb UT8AoOL6Cg7J3i0Ro3xNTMYtszAVFpvd =AbHK -----END PGP SIGNATURE----- --5glgGqCv79Y86mRH-- From owner-freebsd-arch@FreeBSD.ORG Wed May 14 22:50:30 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E21B1065671 for ; Wed, 14 May 2008 22:50:30 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by mx1.freebsd.org (Postfix) with ESMTP id 08BF68FC1D for ; Wed, 14 May 2008 22:50:29 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from mail.cokane.org ([71.168.87.213]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K0V00AXVOI6OIU0@vms173003.mailsrvcs.net> for arch@FreeBSD.org; Wed, 14 May 2008 16:46:55 -0500 (CDT) Received: by mail.cokane.org (Postfix, from userid 103) id 8318B25AD3C; Wed, 14 May 2008 17:49:45 -0400 (EDT) Received: from [172.20.1.3] (erwin.int.cokane.org [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cokane.org (Postfix) with ESMTP id 3EC721DB2F9; Wed, 14 May 2008 17:49:37 -0400 (EDT) Date: Wed, 14 May 2008 17:49:33 -0400 From: Coleman Kane In-reply-to: <1210352688.2152.78.camel@localhost> To: Eric Anholt Message-id: <1210801773.2466.12.camel@localhost> Organization: FreeBSD Project MIME-version: 1.0 X-Mailer: Evolution 2.22.1.1 FreeBSD GNOME Team Port Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-yBBmb6AbjuCblXyHzTIP" X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia References: <1210352688.2152.78.camel@localhost> X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8-gr1 X-Spam-Level: Cc: arch@FreeBSD.org Subject: Re: Feature requests for open-source graphics X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 May 2008 22:50:30 -0000 --=-yBBmb6AbjuCblXyHzTIP Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 2008-05-09 at 10:04 -0700, Eric Anholt wrote: > (Re-sent after I dragged a discussion of NVIDIA on FreeBSD off-topic on > developers@) >=20 > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > >=20 > > > Quite, and this has been covered several times already. In fact, =20 > > > they engage > > > in several hacks to support Linux. Other OS's such as Solaris and =20 > > > OS X have > > > cleaner interfaces for many of the things they wish to do. > >=20 > > I think this is where I normally say that we need kernel drivers > > for graphics hardware. I'm not going to do that anymore; I've been > > stating the obvious too often already... >=20 > It's OK, we're finally listening. By the end of the year, major Linux > distributions should be shipping "DRM modesetting" -- the DRM device > takes over your graphics card and manages memory, execution, and > suspend/resume. Your kernel console and X Server then sit on top of > that, submitting video mode setting and command execution requests to > the DRM. The chips I would expect to be supported by then are all > Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. >=20 > What FreeBSD needs to do to keep up is implement the memory manager > part. I think I've got a reasonable design going that should take about > a month of reimplementing for the FreeBSD kernel. If someone wanted to > get us closer to doing that, >=20 > git clone anongit.freedesktop.org:/git/mesa/drm=20 >=20 > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines) > work on -current. >=20 > To see what we're working on for what we're calling the "graphics > execution manager" now (memory management plus caching management plus > plans for execution scheduling), >=20 > git-remote add anholt people.freedesktop.org:~anholt/drm > git-fetch anholt > git-checkout anholt/drm-gem >=20 > The interesting things we're needing from the kernel: > - Private storage associated with file descriptors > - Callback to driver on destruction of file descriptor > - Ability to allocate a swap-backed pile of memory > - Ability to pin pages from that object and get addresses for them to > stuff into the GTT. > - Ability to map pages in the kernel with the uncached bits set > (non-intel) > - Ability to map pages to userland with the uncached bits set > (non-intel, likely not required, but may come at a performance > cost). >=20 > Interesting things we're likely going to need from the kernel: > - Ability to create fds above 1024 from our driver, associated with our > own set of file operations (read/write/mmap/ioctl/close). > - Ability to look up those fds and get our private storage associated > with them. >=20 > If above goes through, then another likely adventure: > - Creating a filesystem exposing those objects we've been making fds > for. >=20 > email message attachment, "Forwarded message - Re: Forward: Updated > FreeBSD kernel feature requests (NVIDIA graphics)" > > -------- Forwarded Message -------- > > From: Eric Anholt > > To: Marcel Moolenaar > > Cc: John Baldwin , Coleman Kane > > , Dag-Erling Sm=C3=B8rgrav , Martin > > Cracauer , gnn@freebsd.org, > > developers@freebsd.org > > Subject: Re: Forward: Updated FreeBSD kernel feature requests > > (NVIDIA graphics) > > Date: Thu, 08 May 2008 15:54:17 -0700 > > Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port > >=20 > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > > >=20 > > > > Quite, and this has been covered several times already. In fact, =20 > > > > they engage > > > > in several hacks to support Linux. Other OS's such as Solaris and = =20 > > > > OS X have > > > > cleaner interfaces for many of the things they wish to do. > > >=20 > > > I think this is where I normally say that we need kernel drivers > > > for graphics hardware. I'm not going to do that anymore; I've been > > > stating the obvious too often already... > >=20 > > It's OK, we're finally listening. By the end of the year, major Linux > > distributions should be shipping "DRM modesetting" -- the DRM device > > takes over your graphics card and manages memory, execution, and > > suspend/resume. Your kernel console and X Server then sit on top of > > that, submitting video mode setting and command execution requests to > > the DRM. The chips I would expect to be supported by then are all > > Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. > >=20 > > What FreeBSD needs to do to keep up is implement the memory manager > > part. I think I've got a reasonable design going that should take abou= t > > a month of reimplementing for the FreeBSD kernel. If someone wanted to > > get us closer to doing that, > >=20 > > git clone anongit.freedesktop.org:/git/mesa/drm=20 > >=20 > > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defines= ) > > work on -current. > >=20 > > To see what we're working on for what we're calling the "graphics > > execution manager" now (memory management plus caching management plus > > plans for execution scheduling), > >=20 > > git-remote add anholt people.freedesktop.org:~anholt/drm > > git-fetch anholt > > git-checkout anholt/drm-gem > >=20 > > The interesting things we're needing from the kernel: > > - Private storage associated with file descriptors > > - Callback to driver on destruction of file descriptor > > - Ability to allocate a swap-backed pile of memory > > - Ability to pin pages from that object and get addresses for them to > > stuff into the GTT. > > - Ability to map pages in the kernel with the uncached bits set > > (non-intel) > > - Ability to map pages to userland with the uncached bits set > > (non-intel, likely not required, but may come at a performance > > cost). > >=20 > > Interesting things we're considering needing from the kernel: > > - Ability to create fds above 1024 from our driver, associated with our > > own set of file operations (read/write/mmap/ioctl/close). > > - Ability to look up those fds and get our private storage associated > > with them. > >=20 > > Down the line, likely to happen: > > - Creating a filesystem exposing those objects we've been making fds > > for. Eric, I mentioned earlier that I would get my local git repo's changes to the mesa/drm tree available from fd.o up somewhere. I have them here: * http://www.cokane.org/cgi-bin/gitweb.cgi?p=3Ddrm.git My custom branch is 'cokane-master' The fd.o branch is tracked on 'fd-master' You can ignore the 'master' branch for now... I need to re-org my git a bit. Right now, this gets my RS690 notebook to almost work with the in-development radeonhd DRI code, but it causes Xorg to run in a busyloop when I try using the xf86-video-ati driver with it. I did a run at trying to get the vblank stuff ported over, but I got busy and haven't touched it in a bit. I also tried to tweak anything else that kept the radeon code from compiling under FreeBSD. If I have another set of eyes on this it might help me front-burner it more often to get patches in here-and-there. I've tried shoving some bug reports up to the DRI project, but they haven't been acted upon yet... --=20 Coleman Kane --=-yBBmb6AbjuCblXyHzTIP Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkgrXmwACgkQcMSxQcXat5dpKACfcxjNSh8P0aBxFxu1M+FJBxpf srMAnAkJRaFXh2fRnWdW7YZbiumPDITq =xxUW -----END PGP SIGNATURE----- --=-yBBmb6AbjuCblXyHzTIP-- From owner-freebsd-arch@FreeBSD.ORG Thu May 15 04:57:01 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AA7F1065677 for ; Thu, 15 May 2008 04:57:01 +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 1D1E98FC16 for ; Thu, 15 May 2008 04:57:01 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1JwVDF-0006Ly-Mj for freebsd-arch@freebsd.org; Wed, 14 May 2008 21:37:05 -0700 Message-ID: <17245805.post@talk.nabble.com> Date: Wed, 14 May 2008 21:37:05 -0700 (PDT) From: "R. Riehle" To: freebsd-arch@freebsd.org In-Reply-To: <1210640554.1439.11.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: rar102@ra.msstate.edu References: <1210436112.4825ca102cfce@webmail.msstate.edu> <1210437989.62567.17.camel@localhost> <1210439595.4825d7ab5c1df@webmail.msstate.edu> <1210444435.62567.19.camel@localhost> <1210510187.62567.22.camel@localhost> <200805121351.36765.rar102@ra.msstate.edu> <1210640554.1439.11.camel@localhost> Subject: Re: compaq 6515b turion x2 laptop X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2008 04:57:01 -0000 Coleman, This laptop has a flaky connector to the cdrom. It took me a lot of time and pulled-out hair to determine this. It needs to go back to HP before I can help you on this front. Coleman Kane-4 wrote: > > On Mon, 2008-05-12 at 13:51 -0500, Robertsen A. Riehle wrote: >> Coleman, >> >> Sorry for dropping off the Earth for a moment there. In order to make >> amends, >> I am giving you two dmesg's. One from the installed NetBSD and one from >> the >> FreeBSD livefs. Tell me if there is anything else I can get for you. I >> don't know if this is helpful or not. Possibly helpful command line >> output >> below: >> >> dmesg | grep pcm >> No output. This is not suprising for a livefs. >> >> kldload snd_hda >> kldload: can't load snd_hda: No such file or directory. Not >> surprising, >> again. But it was worth a try. >> >> dmesg | grep atapci >> atapci0: port >> 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem >> 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 >> atapci0: [ITHREAD] >> ata2: on atapci0 >> ata3: on atapci0 >> atapci1: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 >> on >> pci0 >> ata0: on atapci1 >> > > It looks to me that you have almost the identical system to what I have > from HP. The SATA controller is definitely the same exact memory > mapping. So, I've got two projects for you: > > 1) See if you can boot off the LiveFS again, and give me the output of > "devinfo -u -v" > 2) Visit the following page: > http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_hp_compaq_6715b_working > > Follow the directions that point you to where to find the good ISO > images, and > use them to boot the system. When you get to the boot menu, choose > option #6 > that will take you to the loader console. Then enter the following at > the > loader prompt: > > set hw.pci.hp6715b_membase_for_hda_audio="0xd0614000" > > Then enter (to start the system): > > boot > > See if that does anything for you better. If you still have problems, > then it is likely you'll need a different membase. I hopefully will be > able to give you a good mem-base depending upon the output of #1, above. > > The purpose of setting that loader variable is discussed further down > the document on my site, under the HDA Audio device discussion. You can > safely add that loader setting to /boot/loader.conf so that it is > automatically set after you get your system installed. > > I'd like to get a copy of your new dmesg (using my images) after you > boot up as well. > > -- > Coleman Kane > > > Rest of the blob copied below: >> ################################################################## >> Here is the FreeBSD dmesg: >> Copyright (c) 1992-2008 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 7.0-RELEASE #0: Sun Feb 24 10:35:36 UTC 2008 >> root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-64 (2194.58-MHz K8-class >> CPU) >> Origin = "AuthenticAMD" Id = 0x60f82 Stepping = 2 >> >> Features=0x178bfbff >> Features2=0x2001 >> AMD Features=0xea500800 >> AMD Features2=0x11f >> Cores per package: 2 >> usable memory = 4143468544 (3951 MB) >> avail memory = 3974230016 (3790 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> ACPI Error (tbfadt-0516): 32/64X address mismatch in "Pm2ControlBlock": [ >> 8800] [ 0 8100], using 64X [20070320] >> ioapic0: Changing APIC ID to 2 >> ioapic0 irqs 0-23 on motherboard >> kbd1 at kbdmux0 >> ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, >> RF5413) >> hptrr: HPT RocketRAID controller driver v1.1 (Feb 24 2008 10:34:18) >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> unknown: I/O range not supported >> acpi0: reservation of 0, 8000000 (3) failed >> acpi0: reservation of 100000, fff00000 (3) failed >> Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 >> acpi_timer0: <32-bit timer at 3.579545MHz> port 0x8008-0x800b on acpi0 >> acpi_ec0: port 0x62,0x66 on acpi0 >> cpu0: on acpi0 >> acpi_throttle0: on cpu0 >> powernow0: on cpu0 >> cpu1: on acpi0 >> acpi_throttle1: on cpu1 >> acpi_throttle1: failed to attach P_CNT >> device_attach: acpi_throttle1 attach returned 6 >> powernow1: on cpu1 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: at device 1.0 on pci0 >> pci1: on pcib1 >> vgapci0: port 0x4000-0x40ff mem >> 0xc0000000-0xc7ffffff,0xd0400000-0xd040ffff,0xd0500000-0xd05fffff irq 19 >> at >> device 5.0 on pci1 >> pcib2: at device 4.0 on pci0 >> pci16: on pcib2 >> pci0:16:0:0: failed to read VPD data. >> bge0: mem >> 0xd0000000-0xd000ffff >> irq 16 at device 0.0 on pci16 >> miibus0: on bge0 >> brgphy0: PHY 1 on miibus0 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> bge0: Ethernet address: 00:1f:29:85:3d:63 >> bge0: [ITHREAD] >> pcib3: at device 5.0 on pci0 >> pci32: on pcib3 >> pcib4: at device 6.0 on pci0 >> pci48: on pcib4 >> pci48: at device 0.0 (no driver attached) >> atapci0: port >> 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f mem >> 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 >> atapci0: [ITHREAD] >> ata2: on atapci0 >> ata2: [ITHREAD] >> ata3: on atapci0 >> ata3: [ITHREAD] >> ohci0: mem 0xd0601000-0xd0601fff irq 23 >> at >> device 19.0 on pci0 >> ohci0: [GIANT-LOCKED] >> ohci0: [ITHREAD] >> usb0: OHCI version 1.0, legacy support >> usb0: on ohci0 >> usb0: USB revision 1.0 >> uhub0: on usb0 >> uhub0: 2 ports with 2 removable, self powered >> ohci1: mem 0xd0602000-0xd0602fff irq 17 >> at >> device 19.1 on pci0 >> ohci1: [GIANT-LOCKED] >> ohci1: [ITHREAD] >> usb1: OHCI version 1.0, legacy support >> usb1: on ohci1 >> usb1: USB revision 1.0 >> uhub1: on usb1 >> uhub1: 2 ports with 2 removable, self powered >> ohci2: mem 0xd0603000-0xd0603fff irq 17 >> at >> device 19.2 on pci0 >> ohci2: [GIANT-LOCKED] >> ohci2: [ITHREAD] >> usb2: OHCI version 1.0, legacy support >> usb2: on ohci2 >> usb2: USB revision 1.0 >> uhub2: on usb2 >> uhub2: 2 ports with 2 removable, self powered >> ohci3: mem 0xd0604000-0xd0604fff irq 17 >> at >> device 19.3 on pci0 >> ohci3: [GIANT-LOCKED] >> ohci3: [ITHREAD] >> usb3: OHCI version 1.0, legacy support >> usb3: on ohci3 >> usb3: USB revision 1.0 >> uhub3: on usb3 >> uhub3: 2 ports with 2 removable, self powered >> ohci4: mem 0xd0605000-0xd0605fff irq 17 >> at >> device 19.4 on pci0 >> ohci4: [GIANT-LOCKED] >> ohci4: [ITHREAD] >> usb4: OHCI version 1.0, legacy support >> usb4: on ohci4 >> usb4: USB revision 1.0 >> uhub4: on usb4 >> uhub4: 2 ports with 2 removable, self powered >> ehci0: mem 0xd0606000-0xd06060ff irq >> 23 at >> device 19.5 on pci0 >> ehci0: [GIANT-LOCKED] >> ehci0: [ITHREAD] >> usb5: EHCI version 1.0 >> usb5: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4 >> usb5: on ehci0 >> usb5: USB revision 2.0 >> uhub5: on usb5 >> uhub5: 10 ports with 10 removable, self powered >> pci0: at device 20.0 (no driver attached) >> atapci1: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x5040-0x504f irq 16 at device 20.1 >> on >> pci0 >> ata0: on atapci1 >> ata0: [ITHREAD] >> pci0: at device 20.2 (no driver attached) >> isab0: at device 20.3 on pci0 >> isa0: on isab0 >> pcib5: at device 20.4 on pci0 >> pci2: on pcib5 >> cbb0: mem 0xd0100000-0xd0100fff irq 20 at >> device >> 4.0 on pci2 >> cardbus0: on cbb0 >> pccard0: <16-bit PCCard bus> on cbb0 >> cbb0: [ITHREAD] >> fwohci0: <1394 Open Host Controller Interface> mem 0xd0101000-0xd01017ff >> irq >> 21 at device 4.1 on pci2 >> fwohci0: [FILTER] >> fwohci0: OHCI version 1.10 (ROM=0) >> fwohci0: No. of Isochronous channels is 4. >> fwohci0: EUI64 00:02:3f:99:29:21:1d:10 >> fwohci0: Phy 1394a available S400, 1 ports. >> fwohci0: Link S400, max_rec 2048 bytes. >> firewire0: on fwohci0 >> dcons_crom0: on firewire0 >> dcons_crom0: bus_addr 0x15dc000 >> fwe0: on firewire0 >> if_fwe0: Fake Ethernet address: 02:02:3f:21:1d:10 >> fwe0: Ethernet address: 02:02:3f:21:1d:10 >> fwip0: on firewire0 >> fwip0: Firewire address: 00:02:3f:99:29:21:1d:10 @ 0xfffe00000000, S400, >> maxrec 2048 >> sbp0: on firewire0 >> fwohci0: Initiate bus reset >> fwohci0: BUS reset >> fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode >> battery0: on acpi0 >> battery1: on acpi0 >> acpi_acad0: on acpi0 >> acpi_button0: on acpi0 >> acpi_lid0: on acpi0 >> acpi_tz0: on acpi0 >> 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, device ID 3 >> ppc0: port 0-0x7,0x400-0x402 on acpi0 >> ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode >> ppbus0: on ppc0 >> plip0: on ppbus0 >> lpt0: on ppbus0 >> lpt0: Polled port >> ppi0: on ppbus0 >> orm0: at iomem 0xd0000-0xd0fff on isa0 >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0: configured irq 4 not in bitmap of probed irqs 0 >> sio0: port may not be enabled >> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 >> sio0: type 8250 or not responding >> sio0: [FILTER] >> sio1: configured irq 3 not in bitmap of probed irqs 0 >> sio1: port may not be enabled >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> ugen0: > addr >> 2> on uhub0 >> umass0: on uhub1 >> ugen1: > addr >> 2> on uhub2 >> Timecounters tick every 1.000 msec >> hptrr: no controller detected. >> firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) >> firewire0: bus manager 0 (me) >> md0: Preloaded image 4194304 bytes at 0xffffffff80bc6c08 >> acd0: DVDR at ata0-master PIO4 >> ad4: 114473MB at ata2-master UDMA33 >> acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 >> GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_LiveFS. >> acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 >> GEOM_LABEL: Label for provider ad4s3 is ntfs/HP_RECOVERY. >> GEOM_LABEL: Label for provider ad4s4 is ntfs/OS_TOOLS. >> SMP: AP CPU #1 Launched! >> da0 at umass-sim0 bus 0 target 0 lun 0 >> da0: Removable Direct Access SCSI-CCS device >> da0: 1.000MB/s transfers >> da0: 61MB (125952 512 byte sectors: 64H 32S/T 61C) >> GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. >> Trying to mount root from ufs:/dev/md0 >> GEOM_LABEL: Label msdosfs/CRUCIAL removed. >> GEOM_LABEL: Label for provider da0s1 is msdosfs/CRUCIAL. >> GEOM_LABEL: Label msdosfs/CRUCIAL removed. >> >> ####################################################################### >> Here is the NetBSD dmesg: >> >> Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, >> 2006, 2007 >> The NetBSD Foundation, Inc. All rights reserved. >> Copyright (c) 1982, 1986, 1989, 1991, 1993 >> The Regents of the University of California. All rights reserved. >> >> NetBSD 4.0 (GENERIC) #0: Sat Dec 15 22:25:31 PST 2007 >> >> builds@wb28:/home/builds/ab/netbsd-4-0-RELEASE/amd64/200712160005Z-obj/home/builds/ab/netbsd-4-0-RELEASE/src/sys/arch/amd64/compile/GENERIC >> total memory = 3967 MB >> avail memory = 3815 MB >> timecounter: Timecounters tick every 10.000 msec >> timecounter: Timecounter "i8254" frequency 1193182 Hz quality 100 >> mainbus0 (root) >> cpu0 at mainbus0: apid 0 (boot processor) >> cpu0: AMD Turion(tm) 64 X2 Mobile Technology TL-64, 2195.04 MHz >> cpu0: features: >> ffdbfbff >> cpu0: features: ffdbfbff >> cpu0: features: ffdbfbff >> cpu0: features2: 2001 >> cpu0: I-cache 64 KB 64B/line 2-way, D-cache 64 KB 64B/line 2-way >> cpu0: L2 cache 512 KB 64B/line 16-way >> cpu0: ITLB 32 4 KB entries fully associative, 8 4 MB entries fully >> associative >> cpu0: DTLB 32 4 KB entries fully associative, 8 4 MB entries fully >> associative >> cpu0: AMD Power Management features: 7f >> cpu0: AMD PowerNow! Technology 2200 MHz >> cpu0: available frequencies (Mhz): 800 1600 1800 2000 2200 >> cpu0: calibrating local timer >> cpu0: apic clock running at 199 MHz >> cpu0: 8 page colors >> cpu1 at mainbus0: apid 1 (application processor) >> cpu1: not started >> ioapic0 at mainbus0 apid 2 (I/O APIC) >> ioapic0: pa 0xfec00000, version 21, 24 pins >> ioapic0: misconfigured as apic 0 >> ioapic0: remapped to apic 2 >> acpi0 at mainbus0: Advanced Configuration and Power Interface >> acpi0: using Intel ACPI CA subsystem version 20060217 >> acpi0: X/RSDT: OemId , AslId >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A1 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C28C (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A2 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A3 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C253 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A4 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C3A5 (name not of >> form >> _Lxx or _Exx) [20060217] >> ACPI Error (evgpeblk-0394): Unknown GPE method type: C262 (name not of >> form >> _Lxx or _Exx) [20060217] >> acpi0: SCI interrupting at int 9 >> acpi0: fixed-feature power button present >> timecounter: Timecounter "ACPI-Fast" frequency 3579545 Hz quality 1000 >> ACPI-Fast 32-bit timer >> mpacpi: could not get bus number, assuming bus 0 >> ACPI Object Type 'Processor' (0x0c) at acpi0 not configured >> ACPI Object Type 'Processor' (0x0c) at acpi0 not configured >> PNP0C01 [System Board] at acpi0 not configured >> PNP0A03 [PCI/PCI-X Host Bridge] at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> acpiec0 at acpi0 (PNP0C09): ACPI Embedded Controller >> acpiec0: io 0x62,0x66 >> PNP0A06 [Generic Container Device] at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> IFX0102 at acpi0 not configured >> PNP0C04 [Math Coprocessor] at acpi0 not configured >> attimer1 at acpi0 (PNP0100): AT Timer >> attimer1: io 0x40-0x43 irq 0 >> PNP0200 [AT DMA Controller] at acpi0 not configured >> pcppi1 at acpi0 (PNP0800) >> pcppi1: io 0x61 >> pcppi1: children must have an explicit unit >> midi0 at pcppi1: PC speaker (CPU-intensive output) >> sysbeep0 at pcppi1 >> PNP0B00 [AT Real-Time Clock] at acpi0 not configured >> pckbc1 at acpi0 (PNP0303): kbd port >> pckbc1: io 0x60,0x64 irq 1 >> pckbc2 at acpi0 (SYN0131): aux port >> pckbc2: irq 12 >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> PNP0000 [AT Interrupt Controller] at acpi0 not configured >> PNP0C02 [Plug and Play motherboard register resources] at acpi0 not >> configured >> HPQ0004 at acpi0 not configured >> PNP0C02 [Plug and Play motherboard register resources] at acpi0 not >> configured >> HPQ0006 at acpi0 not configured >> acpibat0 at acpi0 (PNP0C0A-1): ACPI Battery (Control Method) >> acpibat1 at acpi0 (PNP0C0A-2): ACPI Battery (Control Method) >> acpiacad0 at acpi0 (ACPI0003): ACPI AC Adapter >> acpibut0 at acpi0 (PNP0C0E): ACPI Sleep Button >> acpilid0 at acpi0 (PNP0C0D): ACPI Lid Switch >> PNP0C14 at acpi0 not configured >> PNP0C02 [Plug and Play motherboard register resources] at acpi0 not >> configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> ACPI Object Type 'Power' (0x0b) at acpi0 not configured >> PNP0C0B [ACPI Fan] at acpi0 not configured >> PNP0C0B [ACPI Fan] at acpi0 not configured >> PNP0C0B [ACPI Fan] at acpi0 not configured >> PNP0C0B [ACPI Fan] at acpi0 not configured >> acpitz0 at acpi0: ACPI Thermal Zone >> acpitz0: unable to get polling interval; using default of 30.0s >> acpitz0: active cooling level 0: 70.0C >> acpitz0: active cooling level 1: 60.0C >> acpitz0: active cooling level 2: 50.0C >> acpitz0: active cooling level 3: 40.0C >> acpitz0: critical 105.0C passive 38.0C >> pcppi1: attached to attimer1 >> pckbd0 at pckbc1 (kbd slot) >> pckbc1: using irq 1 for kbd slot >> wskbd0 at pckbd0: console keyboard >> pms0 at pckbc1 (aux slot) >> pms0: Synaptics touchpad version 6.2 >> pms0: Palm detect, Multi-finger >> pckbc1: using irq 12 for aux slot >> wsmouse0 at pms0 mux 0 >> pci0 at mainbus0 bus 0: configuration mode 1 >> pci0: i/o space, memory space enabled, rd/line, rd/mult, wr/inv ok >> pchb0 at pci0 dev 0 function 0 >> pchb0: ATI Technologies product 0x7910 (rev. 0x00) >> ppb0 at pci0 dev 1 function 0: ATI Technologies product 0x7912 (rev. >> 0x00) >> pci1 at ppb0 bus 1 >> pci1: i/o space, memory space enabled >> vga0 at pci1 dev 5 function 0: ATI Technologies product 0x791f (rev. >> 0x00) >> wsdisplay0 at vga0 kbdmux 1: console (80x25, vt100 emulation), using >> wskbd0 >> wsmux1: connecting to wsdisplay0 >> ppb1 at pci0 dev 4 function 0: ATI Technologies product 0x7914 (rev. >> 0x00) >> pci2 at ppb1 bus 16 >> pci2: i/o space, memory space enabled, rd/line, wr/inv ok >> bge0 at pci2 dev 0 function 0: Broadcom BCM5787M Gigabit Ethernet >> bge0: interrupting at ioapic0 pin 16 (irq 10) >> bge0: ASIC BCM5754/5787 A2 (0xb002), Ethernet address 00:1f:29:85:3d:63 >> bge0: setting short Tx thresholds >> brgphy0 at bge0 phy 1: BCM5754/5787 1000BASE-T media interface, rev. 0 >> brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, >> 1000baseT-FDX, auto >> ppb2 at pci0 dev 5 function 0: ATI Technologies product 0x7915 (rev. >> 0x00) >> pci3 at ppb2 bus 32 >> pci3: i/o space, memory space enabled, rd/line, wr/inv ok >> ppb3 at pci0 dev 6 function 0: ATI Technologies product 0x7916 (rev. >> 0x00) >> pci4 at ppb3 bus 48 >> pci4: i/o space, memory space enabled, rd/line, wr/inv ok >> Broadcom BCM4312 (miscellaneous network, revision 0x02) at pci4 dev 0 >> function >> 0 not configured >> ixpide0 at pci0 dev 18 function 0 >> ixpide0: ATI Technologies IXP IDE Controller (rev. 0x00) >> ixpide0: bus-master DMA support present >> ixpide0: primary channel configured to native-PCI mode >> ixpide0: using ioapic0 pin 16 (irq 10) for native-PCI interrupt >> atabus0 at ixpide0 channel 0 >> ixpide0: secondary channel configured to native-PCI mode >> atabus1 at ixpide0 channel 1 >> ohci0 at pci0 dev 19 function 0: ATI Technologies product 0x4387 (rev. >> 0x00) >> ohci0: interrupting at ioapic0 pin 23 (irq 11) >> ohci0: OHCI version 1.0, legacy support >> usb0 at ohci0: USB revision 1.0 >> uhub0 at usb0 >> uhub0: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub0: 2 ports with 2 removable, self powered >> ohci1 at pci0 dev 19 function 1: ATI Technologies product 0x4388 (rev. >> 0x00) >> ohci1: interrupting at ioapic0 pin 17 (irq 5) >> ohci1: OHCI version 1.0, legacy support >> usb1 at ohci1: USB revision 1.0 >> uhub1 at usb1 >> uhub1: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub1: 2 ports with 2 removable, self powered >> ohci2 at pci0 dev 19 function 2: ATI Technologies product 0x4389 (rev. >> 0x00) >> ohci2: interrupting at ioapic0 pin 17 (irq 5) >> ohci2: OHCI version 1.0, legacy support >> usb2 at ohci2: USB revision 1.0 >> uhub2 at usb2 >> uhub2: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub2: 2 ports with 2 removable, self powered >> ohci3 at pci0 dev 19 function 3: ATI Technologies product 0x438a (rev. >> 0x00) >> ohci3: interrupting at ioapic0 pin 17 (irq 5) >> ohci3: OHCI version 1.0, legacy support >> usb3 at ohci3: USB revision 1.0 >> uhub3 at usb3 >> uhub3: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub3: 2 ports with 2 removable, self powered >> ohci4 at pci0 dev 19 function 4: ATI Technologies product 0x438b (rev. >> 0x00) >> ohci4: interrupting at ioapic0 pin 17 (irq 5) >> ohci4: OHCI version 1.0, legacy support >> usb4 at ohci4: USB revision 1.0 >> uhub4 at usb4 >> uhub4: ATI Technologie OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >> uhub4: 2 ports with 2 removable, self powered >> ehci0 at pci0 dev 19 function 5: ATI Technologies product 0x4386 (rev. >> 0x00) >> ehci0: interrupting at ioapic0 pin 23 (irq 11) >> ehci0: BIOS has given up ownership >> ehci0: EHCI version 1.0 >> ehci0: companion controllers, 2 ports each: ohci0 ohci1 ohci2 ohci3 ohci4 >> usb5 at ehci0: USB revision 2.0 >> uhub5 at usb5 >> uhub5: ATI Technologies EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 >> uhub5: 10 ports with 10 removable, self powered >> ATI Technologies product 0x4385 (SMBus serial bus, revision 0x14) at pci0 >> dev >> 20 function 0 not configured >> ixpide1 at pci0 dev 20 function 1 >> ixpide1: ATI Technologies IXP IDE Controller (rev. 0x00) >> ixpide1: bus-master DMA support present >> ixpide1: primary channel configured to compatibility mode >> ixpide1: primary channel interrupting at ioapic0 pin 14 (irq 14) >> atabus2 at ixpide1 channel 0 >> ixpide1: secondary channel wired to compatibility mode >> ixpide1: secondary channel interrupting at ioapic0 pin 15 (irq 15) >> atabus3 at ixpide1 channel 1 >> azalia0 at pci0 dev 20 function 2: Generic High Definition Audio >> Controller >> azalia0: interrupting at ioapic0 pin 16 (irq 10) >> azalia0: host: 0x1002/0x4383 (rev. 0) >> azalia0: host: High Definition Audio rev. 1.0 >> pcib0 at pci0 dev 20 function 3 >> pcib0: ATI Technologies product 0x438d (rev. 0x00) >> ppb4 at pci0 dev 20 function 4: ATI Technologies product 0x4384 (rev. >> 0x00) >> pci5 at ppb4 bus 2 >> pci5: i/o space, memory space enabled >> cbb0 at pci5 dev 4 function 0: Ricoh 5C476 PCI-CardBus bridge (rev. 0xb6) >> fwohci0 at pci5 dev 4 function 1: Ricoh product 0x0832 (rev. 0x02) >> fwohci0: interrupting at ioapic0 pin 21 (irq 5) >> fwohci0: OHCI version 1.10 (ROM=0) >> fwohci0: No. of Isochronous channels is 4. >> fwohci0: EUI64 00:02:3f:99:29:21:1d:10 >> fwohci0: Phy 1394a available S400, 1 ports. >> fwohci0: Link S400, max_rec 2048 bytes. >> ieee1394if0 at fwohci0: IEEE1394 bus >> fwip0 at ieee1394if0: IP over IEEE1394 >> fwohci0: Initiate bus reset >> cbb0: interrupting at ioapic0 pin 20 (irq 10) >> cardslot0 at cbb0 slot 0 flags 0 >> cardbus0 at cardslot0: bus 3 >> pcmcia0 at cardslot0 >> pchb1 at pci0 dev 24 function 0 >> pchb1: Advanced Micro Devices AMD64 HyperTransport configuration (rev. >> 0x00) >> pchb2 at pci0 dev 24 function 1 >> pchb2: Advanced Micro Devices AMD64 Address Map configuration (rev. 0x00) >> pchb3 at pci0 dev 24 function 2 >> pchb3: Advanced Micro Devices AMD64 DRAM configuration (rev. 0x00) >> pchb4 at pci0 dev 24 function 3 >> pchb4: Advanced Micro Devices AMD64 Miscellaneous configuration (rev. >> 0x00) >> isa0 at pcib0 >> ioapic0: enabling >> WARNING: Callback scheduled before sysmon task queue thread present. >> fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode >> ieee1394if0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) >> ieee1394if0: bus manager 0 (me) >> timecounter: Timecounter "clockinterrupt" frequency 100 Hz quality 0 >> azalia0: codec[0]: Analog Devices AD1981HD (rev. 2.0) >> azalia0: codec[0]: High Definition Audio rev. 1.0 >> azalia0: playback: max channels=2, encodings=1 >> azalia0: playback: PCM >> formats=e007f<24bit,20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.025kHz,8kHz> >> azalia0: recording: max channels=2, encodings=1 >> azalia0: recording: PCM >> formats=6007f<20bit,16bit,48kHz,44.1kHz,32kHz,22.05kHz,16kHz,11.025kHz,8kHz> >> azalia0: codec[1]: 0x11c1/0x1040 (rev. 2.0) >> azalia0: codec[1]: High Definition Audio rev. 1.0 >> azalia0: codec[1]: No support for modem function groups >> azalia0: codec[1] has no audio function groups >> audio0 at azalia0: full duplex, independent >> Kernelized RAIDframe activated >> acpibat0: battery info: Hewlett-Packard, LIon, Primary, 48204 2008/04/13 >> ugen0 at uhub2 port 1 >> ugen0: AuthenTec Fingerprint Sensor, rev 1.10/6.23, addr 2 >> wd0 at atabus0 drive 0: >> wd0: drive supports 16-sector PIO transfers, LBA48 addressing >> wd0: 111 GB, 232581 cyl, 16 head, 63 sec, 512 bytes/sect x 234441648 >> sectors >> wd0: 32-bit data port >> wd0: drive supports PIO mode 4, DMA mode 2, Ultra-DMA mode 5 (Ultra/100) >> wd0(ixpide0:0:0): using PIO mode 4, Ultra-DMA mode 5 (Ultra/100) (using >> DMA) >> atapibus0 at atabus2: 2 targets >> cd0 at atapibus0 drive 0: >> cdrom >> removable >> cd0: 32-bit data port >> cd0: drive supports PIO mode 4, DMA mode 2 >> cd0(ixpide1:0:0): using PIO mode 4, DMA mode 2 (using DMA) >> boot device: wd0 >> root on wd0a dumps on wd0b >> root file system type: ffs >> WARNING: clock gained 7 days >> WARNING: CHECK AND RESET THE DATE! >> wsdisplay0: screen 1 added (80x25, vt100 emulation) >> wsdisplay0: screen 2 added (80x25, vt100 emulation) >> wsdisplay0: screen 3 added (80x25, vt100 emulation) >> wsdisplay0: screen 4 added (80x25, vt100 emulation) >> >> >> >> >> >> >> On Sunday 11 May 2008 07:49:47 you wrote: >> > On Sat, 2008-05-10 at 14:33 -0400, Coleman Kane wrote: >> > > On Sat, 2008-05-10 at 12:13 -0500, rar102@ra.msstate.edu wrote: >> > > > Quoting Coleman Kane : >> > > > >> > > > Yes!!! thank you. Unfortunately, I don't have access to another >> amd64 >> > > > box to try your patch. Sorry. But, I will look at the dmesg and >> send >> > > > it to you. >> > > >> > > Excellent. A dmesg will be very helpful for me to write a patch from, >> as >> > > it will allow me to see if it is or is not the sound driver >> overlapping >> > > memory in your case. I suspect that the BIOS images are so similar >> that >> > > you probably even have almost the same bios-chosen memory regions on >> > > your system. >> > >> > If you're having difficulty getting a dmesg, you might want to try >> > booting off the LiveFS disc with a USB flash drive plugged in. You can >> > then mount the flash drive (which should be detected as SCSI) and write >> > the dmesg output there. >> > >> > > > > RAR, >> > > > > >> > > > > You are in luck! Well, actually I have good news and I have bad >> news. >> > > > > The good news is that I have nearly the same (6715b) laptop and >> > > > > experienced similar problems when getting FreeBSD onto it. After >> some >> > > > > work, I've been able to use FreeBSD reliably on the system. >> > > > > >> > > > > The bad news is that you probably have an overlap of PCI memory >> > > > > ranges between the SATA controller and another device in the >> system >> > > > > (likely the audio controller). >> > > > > >> > > > > I put up a page describing the problem here: >> > > > >> > > > >> http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#getting_the_ >> > > >hp_compaq_6715b_working >> > > > >> > > > > Specifically, read this section: >> > > > >> > > > >> http://www.cokane.org/dokuwiki/freebsd/amd64_compatibility#the_onboard_ >> > > >ati_sb600_hda_audio_controller >> > > > >> > > > > Give me the weekend, and I will post a 7.0-RELEASE CD with the >> patch >> > > > > in it. I figured that I should have done it a while ago. Oh well. >> > > > > >> > > > > While you are at it, see if you can use Scroll-Lock and the >> up/down >> > > > > keys to read the kernel messages. See if you can find the atapci0 >> > > > > probe line for your SATA controller (AHCI), as well as the line >> for >> > > > > your pcm0 device and send them back to me. I can add your info to >> my >> > > > > webpage to help others. >> > > > > >> > > > > It will look like this: >> > > > > atapci0: port >> > > > > >> 0x9000-0x9007,0x9008-0x900b,0x9010-0x9017,0x5018-0x501b,0x5020-0x502f >> > > > > mem 0xd0609000-0xd06093ff irq 16 at device 18.0 on pci0 >> > > > > ... >> > > > > pcm0: mem >> > > > > 0xd0608000-0xd060bfff irq 16 at device 20.2 on pci0 >> > > > > >> > > > > You'll notice the "mem" resource for the audio controller is >> > > > > 0xd0608000-0xd060bff, and the "mem" resource for the SATA >> controller >> > > > > is 0xd0609000-0xd06093ff. The SATA controller's "mem" resource is >> > > > > completely covered by this audio controller. >> > > > > >> > > > > If you happen to have access to another machine for building your >> own >> > > > > releases, you can try my patch and build them from it. >> > > > > >> > > > > -- >> > > > > Coleman Kane > > > > -- View this message in context: http://www.nabble.com/compaq-6515b-turion-x2-laptop-tp17165100p17245805.html Sent from the freebsd-arch mailing list archive at Nabble.com. From owner-freebsd-arch@FreeBSD.ORG Thu May 15 12:07:52 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CF79106566B for ; Thu, 15 May 2008 12:07:52 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id F18D98FC17 for ; Thu, 15 May 2008 12:07:51 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unknown [208.65.91.234]) by elvis.mu.org (Postfix) with ESMTP id 46FE41A4D8C; Thu, 15 May 2008 05:07:51 -0700 (PDT) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.14.2/8.14.2) with ESMTP id m4FC7fd2083425; Thu, 15 May 2008 08:07:42 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Thu, 15 May 2008 07:30:07 -0400 User-Agent: KMail/1.9.7 References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080513093734.GF18958@deviant.kiev.zoral.com.ua> <20080514093223.GN18958@deviant.kiev.zoral.com.ua> In-Reply-To: <20080514093223.GN18958@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200805150730.08418.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Thu, 15 May 2008 08:07:42 -0400 (EDT) X-Virus-Scanned: ClamAV 0.91.2/7127/Thu May 15 05:59:12 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kostik Belousov Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2008 12:07:52 -0000 On Wednesday 14 May 2008 05:32:23 am Kostik Belousov wrote: > On Tue, May 13, 2008 at 12:37:34PM +0300, Kostik Belousov wrote: > > On Mon, May 12, 2008 at 10:03:14AM -1000, Jeff Roberson wrote: > > > > > > On Mon, 12 May 2008, Kostik Belousov wrote: > > > > > > >On Sun, May 11, 2008 at 03:40:14PM -1000, Jeff Roberson wrote: > > > >> > > > >>On Sun, 11 May 2008, Kostik Belousov wrote: > > > >> > > > >>>On Sun, May 11, 2008 at 02:50:30PM +0300, Kostik Belousov wrote: > > > >>>>On Sat, May 10, 2008 at 09:53:12PM -1000, Jeff Roberson wrote: > > > >>>>>On Sun, 4 May 2008, Kostik Belousov wrote: > > > >>>>> > > > >>>>>>Since the review for the clone-at-open patch (fdclone) posted some > > > >>>>>>time > > > >>>>>>ago > > > >>>>>>mostly says that it would be better to implement per-file private data > > > >>>>>>instead, I produced the patch along this line, > > > >>>>>> > > > >>>>>>The patch does not change the cdevsw ABI, instead, three new functions > > > >>>>>>nt devfs_get_cdevpriv(void **datap); > > > >>>>>>int devfs_set_cdevpriv(void *priv, cdevpriv_dtr_t dtr); > > > >>>>>>void devfs_clear_cdevpriv(void); > > > >>>>>>are provided for manipulation of the per-file private data. > > > >>>>>> > > > >>>>>>devfs_set_cdevpriv assigns the priv as private data for the file > > > >>>>>>descriptor > > > >>>>>>which is used to initiate currently performed driver operation. dtr > > > >>>>>>is the function that will be called when either the last refernce to > > > >>>>>>the file goes away or devfs_clear_cdevpriv is called. > > > >>>>>> > > > >>>>>>devfs_get_cdevpriv is the obvious accessor. > > > >>>>>> > > > >>>>>>devfs_clear_cdevpriv allows to clear the private data for the still > > > >>>>>>open file. > > > >>>>>> > > > >>>>>>The synchronization of the cdev data and file private data is left > > > >>>>>>to the driver code, I did not found any generic helper mechanism that > > > >>>>>>could be useful there. > > > >>>>>> > > > >>>>>>Patch: > > > >>>>>>http://people.freebsd.org/~kib/misc/fdpriv.1.patch > > > >>>>>> > > > >>>>>>Dumb driver that shows the basic usage of the proposed KPI: > > > >>>>>>http://people.freebsd.org/~kib/misc/fpclone.c > > > >>>>>> > > > >>>>>>Previous version of the patch was tested by Peter Holm. > > > >>>>>> > > > >>>>> > > > >>>>>Hi Kostik, > > > >>>>> > > > >>>>>Are these per-instances structures intended to be used by anything > > > >>>>>other > > > >>>>>than devices? If not can we make them a union with the DTYPE_VNODE > > > >>>>>fields to save space? > > > >>>>> > > > >>>>>Thanks, > > > >>>>>Jeff > > > >>>> > > > >>>>The current version of the patch is at > > > >>>>http://people.freebsd.org/~kib/misc/fdpriv.3.patch > > > >>>> > > > >>>>Per insistence of John Baldwin and request of Eric Anholt, the > > > >>>>destructors > > > >>>>are called now when either file is last closed, or the device is > > > >>>>destroyed. > > > >>>>This versions adds only one pointer to the struct file. > > > >>>> > > > >>>>Jeff, would you, please, explicitely specify what field you propose to > > > >>>>union with the f_cdevpriv ? > > > >> > > > >>f_nextoff and f_seqcount are only used if vn_read() and vn_write() are > > > >>used. They do not apply to any other descriptors. > > > >I use the f_cdevpriv != NULL as an indicator for the necessity to enter > > > >the cdevpriv code, in particular, locking the cdevpriv_mtx, that would > > > >otherwise needed to be entered at each last close. I think that one > > > >pointer for the struct file is not too big cost, do you agree ? > > > > > > No, it's not a big cost, however if it is possible to avoid that is best. > > > > > > Can you not check the type before checking f_cdevpriv? Should we not only > > > be checking cdevpriv in contexts where we know that it is not a vnode? > > > > I am sorry, my english may be not enough, so I may interpret your > > proposal mistakenly. I read it as a suggestion to check the file type > > before accessing the f_cdevpriv. > > > > The problem with the f_cdevpriv exists only at the _fdrop(). There, we > > have a file of f_type == DTYPE_VNODE both for devfs and normal files. > > I cannot check the f_vnode since the vnode may be reclaimed. The only > > differentiator is the f_ops, that is devfs_ops_f for devfs file, and > > vnops for the normal file during the file lifetime. Unfortunately, > > f_ops is reset to the badfileops by vn_closefile before the _fdrop() is > > getting called. > > > > Reserving the flag in the f_flag looks not good due to interaction with > > the userspace. > > > > I do not want the callback to be called before the d_close() driver method > > gets a chance to clean the data. > > So, I cannot implement overlay of the cdevpriv over the seqaccess data > without some additional flag. On the other hand, use of 2 bytes for the > f_type is overkill when the range of the types is [1,8]. I divided it > to two one-byte fields, and new field is used for filetype-specific > flags. > > http://people.freebsd.org/~kib/misc/fdpriv.4.patch > shall give the same size of the struct file while not causing unconditional > acquire of the cdevpriv_mtx on the last file close. > > Jeff, do you agree with the proposed vivisection of the f_type ? I will > ask Peter to retest the patch then. I would rather add the new pointer to struct file and avoid breaking the ABI of fstat. That is, I would like this patch to be MFCable, but you can't MFC this w/o breaking the ABI of struct file since fstat(1) will be reading the full short to get the DTYPE. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu May 15 12:31:03 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9F201065681; Thu, 15 May 2008 12:31:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 4322F8FC15; Thu, 15 May 2008 12:31:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.226] (helo=skuns.kiev.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Jwcbt-00025Q-5k; Thu, 15 May 2008 15:31:01 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by skuns.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m4FCUwdC072953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 May 2008 15:30:58 +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.2/8.14.2) with ESMTP id m4FCUuJ9002669; Thu, 15 May 2008 15:30:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m4FCUt3s002668; Thu, 15 May 2008 15:30:55 +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: Thu, 15 May 2008 15:30:55 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20080515123055.GY18958@deviant.kiev.zoral.com.ua> References: <20080504171002.GN18958@deviant.kiev.zoral.com.ua> <20080513093734.GF18958@deviant.kiev.zoral.com.ua> <20080514093223.GN18958@deviant.kiev.zoral.com.ua> <200805150730.08418.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8L/iE/qKZ3QnHSPo" Content-Disposition: inline In-Reply-To: <200805150730.08418.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on 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.4 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on skuns.kiev.zoral.com.ua X-Scanner-Signature: d3dfc5a0b247ea81d48b6a940fe6235f X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2823 [May 13 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Method: none X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release Cc: freebsd-arch@freebsd.org Subject: Re: Per-open file private data for the cdevs X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2008 12:31:03 -0000 --8L/iE/qKZ3QnHSPo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 15, 2008 at 07:30:07AM -0400, John Baldwin wrote: > On Wednesday 14 May 2008 05:32:23 am Kostik Belousov wrote: > > So, I cannot implement overlay of the cdevpriv over the seqaccess data= =20 > > without some additional flag. On the other hand, use of 2 bytes for the > > f_type is overkill when the range of the types is [1,8]. I divided it > > to two one-byte fields, and new field is used for filetype-specific > > flags. > >=20 > > http://people.freebsd.org/~kib/misc/fdpriv.4.patch > > shall give the same size of the struct file while not causing unconditi= onal > > acquire of the cdevpriv_mtx on the last file close. > >=20 > > Jeff, do you agree with the proposed vivisection of the f_type ? I will > > ask Peter to retest the patch then. >=20 > I would rather add the new pointer to struct file and avoid breaking the = ABI=20 > of fstat. That is, I would like this patch to be MFCable, but you can't = MFC=20 > this w/o breaking the ABI of struct file since fstat(1) will be reading t= he=20 > full short to get the DTYPE. Oh, I thought that fstat uses struct xfile, at least for live systems. I considered to introduce new f_type value for devfs files; the DTYPE_VNODE is not a complete truth due to custom f_ops. But DTYPE_VNODE is special-cased in enough locations to make this much less preferrable then another pointer. --8L/iE/qKZ3QnHSPo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgsLP4ACgkQC3+MBN1Mb4g/lwCdGrz0F3zj0/usD4Fotd+u648k ysEAnjOqweaWFZFNBqpBiBXDPcKLdf6e =LG2H -----END PGP SIGNATURE----- --8L/iE/qKZ3QnHSPo-- From owner-freebsd-arch@FreeBSD.ORG Fri May 16 05:19:05 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8372106564A; Fri, 16 May 2008 05:19:05 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id E66738FC17; Fri, 16 May 2008 05:19:04 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [202.108.54.204]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 8FFEC28449; Fri, 16 May 2008 13:19:03 +0800 (CST) Received: from localhost (tarsier.geekcn.org [202.108.54.204]) by tarsier.geekcn.org (Postfix) with ESMTP id 197F1EB2507; Fri, 16 May 2008 13:19:03 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([202.108.54.204]) by localhost (mail.geekcn.org [202.108.54.204]) (amavisd-new, port 10024) with ESMTP id 91MfQ63LV5eB; Fri, 16 May 2008 13:18:57 +0800 (CST) Received: from charlie.delphij.net (c-69-181-135-56.hsd1.ca.comcast.net [69.181.135.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id E8FB3EB24FA; Fri, 16 May 2008 13:18:55 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:x-enigmail-version:openpgp:content-type; b=M1kMpISOdcgj33maNgbexpDTjhxHChG2RhW4Pp8Do+TeWo28RZBCRCKl9xhTp7hFY Sn/F3ESBhTmdmdhPuGt9Q== Message-ID: <482D193D.2010802@delphij.net> Date: Thu, 15 May 2008 22:18:53 -0700 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org X-Enigmail-Version: 0.95.6 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: multipart/mixed; boundary="------------070905020208020405010806" Cc: sephe@FreeBSD.org Subject: A couple of bitwise operations X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2008 05:19:06 -0000 This is a multi-part message in MIME format. --------------070905020208020405010806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I find the DragonFly macros, __BIT, __BITS, __LOWEST_SET_BIT, __SHIFTOUT, __SHIFTIN and __SHIFTOUT_MASK useful. Any objection adding this as sys/sys/bitops.h? (These macros are found in NetBSD in sys/sys/cdefs.h and DragonFly as sys/sys/bitops.h) Cheers, - -- ** Help China's quake relief at http://www.redcross.org.cn/ |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkgtGTwACgkQi+vbBBjt66DYYACePxDc5HaOpQXoJVSfttjukSvp bsAAnR61/+vOEaHqVNZjiynQzksLmTix =X14I -----END PGP SIGNATURE----- --------------070905020208020405010806 Content-Type: text/plain; name="bitops.h" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="bitops.h" /* * Copyright (c) 2004, 2005 David Young. All rights reserved. * * Programmed for NetBSD by David Young. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. The name of David Young may not be used to endorse or promote * products derived from this software without specific prior * written permission. * * THIS SOFTWARE IS PROVIDED BY David Young ``AS IS'' AND ANY * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL David * Young BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED * TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY * OF SUCH DAMAGE. * * $DragonFly: src/sys/sys/bitops.h,v 1.1 2007/10/14 04:15:17 sephe Exp $ * $FreeBSD$ */ #ifndef _SYS_BITOPS_H_ #define _SYS_BITOPS_H_ /* * __BIT(n): Return a bitmask with bit n set, where the least * significant bit is bit 0. * * __BITS(m, n): Return a bitmask with bits m through n, inclusive, * set. It does not matter whether m>n or m<=n. The * least significant bit is bit 0. * * A "bitfield" is a span of consecutive bits defined by a bitmask, * where 1s select the bits in the bitfield. __SHIFTIN, __SHIFTOUT, * and __SHIFTOUT_MASK help read and write bitfields from device * registers. * * __SHIFTIN(v, mask): Left-shift bits `v' into the bitfield * defined by `mask', and return them. No * side-effects. * * __SHIFTOUT(v, mask): Extract and return the bitfield selected * by `mask' from `v', right-shifting the * bits so that the rightmost selected bit * is at bit 0. No side-effects. * * __SHIFTOUT_MASK(mask): Right-shift the bits in `mask' so that * the rightmost non-zero bit is at bit * 0. This is useful for finding the * greatest unsigned value that a bitfield * can hold. No side-effects. Note that * __SHIFTOUT_MASK(m) = __SHIFTOUT(m, m). */ /* __BIT(n): nth bit, where __BIT(0) == 0x1. */ #define __BIT(__n) (((__n) == 32) ? 0 : ((uint32_t)1 << (__n))) /* __BITS(m, n): bits m through n, m < n. */ #define __BITS(__m, __n) \ ((__BIT(MAX((__m), (__n)) + 1) - 1) ^ (__BIT(MIN((__m), (__n))) - 1)) /* Find least significant bit that is set */ #define __LOWEST_SET_BIT(__mask) ((((__mask) - 1) & (__mask)) ^ (__mask)) #define __SHIFTOUT(__x, __mask) (((__x) & (__mask)) / __LOWEST_SET_BIT(__mask)) #define __SHIFTIN(__x, __mask) ((__x) * __LOWEST_SET_BIT(__mask)) #define __SHIFTOUT_MASK(__mask) __SHIFTOUT((__mask), (__mask)) #endif /* !_SYS_BITOPS_H_ */ --------------070905020208020405010806-- From owner-freebsd-arch@FreeBSD.ORG Fri May 16 06:45:53 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84B2A1065672 for ; Fri, 16 May 2008 06:45:53 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 066758FC17 for ; Fri, 16 May 2008 06:45:52 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m4G6ip67022790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 May 2008 16:45:04 +1000 Date: Fri, 16 May 2008 16:44:51 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: d@delphij.net In-Reply-To: <482D193D.2010802@delphij.net> Message-ID: <20080516163857.Y43605@delplex.bde.org> References: <482D193D.2010802@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: sephe@freebsd.org, freebsd-arch@freebsd.org Subject: Re: A couple of bitwise operations X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2008 06:45:53 -0000 On Thu, 15 May 2008, Xin LI wrote: > I find the DragonFly macros, __BIT, __BITS, __LOWEST_SET_BIT, > __SHIFTOUT, __SHIFTIN and __SHIFTOUT_MASK useful. Any objection adding > this as sys/sys/bitops.h? > > (These macros are found in NetBSD in sys/sys/cdefs.h and DragonFly as > sys/sys/bitops.h) WHat's wrong with bitstring(3)(9undoc), except that it was invented here and doesn't have a style bug after every #define? Both have naming errors -- bitstring has too many unsafe macros whose name is in lower case, while bitops uses upper case even for safe macros. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri May 16 10:27:45 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C9EE1065674; Fri, 16 May 2008 10:27:45 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.freebsd.org (Postfix) with ESMTP id E85598FC22; Fri, 16 May 2008 10:27:44 +0000 (UTC) (envelope-from eric@anholt.net) Received: from vonnegut.anholt.net (localhost [127.0.0.1]) by vonnegut.anholt.net (8.14.2/8.14.2) with ESMTP id m4FKcWdH096939; Thu, 15 May 2008 13:38:32 -0700 (PDT) (envelope-from eric@anholt.net) Received: (from anholt@localhost) by vonnegut.anholt.net (8.14.2/8.14.2/Submit) id m4FKcVnI096936; Thu, 15 May 2008 13:38:31 -0700 (PDT) (envelope-from eric@anholt.net) X-Authentication-Warning: vonnegut.anholt.net: anholt set sender to eric@anholt.net using -f From: Eric Anholt To: Coleman Kane In-Reply-To: <1210800676.2466.6.camel@localhost> References: <1210352688.2152.78.camel@localhost> <1210800676.2466.6.camel@localhost> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-ae3/nPhfCxp40QDrgRgR" Date: Thu, 15 May 2008 13:38:29 -0700 Message-Id: <1210883909.96116.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port Cc: arch@FreeBSD.org Subject: Re: Feature requests for open-source graphics X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2008 10:27:45 -0000 --=-ae3/nPhfCxp40QDrgRgR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 2008-05-14 at 17:31 -0400, Coleman Kane wrote: > On Fri, 2008-05-09 at 10:04 -0700, Eric Anholt wrote: > > email message attachment, "Forwarded message - Re: Forward: Updated > > FreeBSD kernel feature requests (NVIDIA graphics)" > > > -------- Forwarded Message -------- > > > From: Eric Anholt > > > To: Marcel Moolenaar > > > Cc: John Baldwin , Coleman Kane > > > , Dag-Erling Sm=C3=B8rgrav , Martin > > > Cracauer , gnn@freebsd.org, > > > developers@freebsd.org > > > Subject: Re: Forward: Updated FreeBSD kernel feature requests > > > (NVIDIA graphics) > > > Date: Thu, 08 May 2008 15:54:17 -0700 > > > Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port > > >=20 > > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > > > >=20 > > > > > Quite, and this has been covered several times already. In fact,= =20 > > > > > they engage > > > > > in several hacks to support Linux. Other OS's such as Solaris an= d =20 > > > > > OS X have > > > > > cleaner interfaces for many of the things they wish to do. > > > >=20 > > > > I think this is where I normally say that we need kernel drivers > > > > for graphics hardware. I'm not going to do that anymore; I've been > > > > stating the obvious too often already... > > >=20 > > > It's OK, we're finally listening. By the end of the year, major Linu= x > > > distributions should be shipping "DRM modesetting" -- the DRM device > > > takes over your graphics card and manages memory, execution, and > > > suspend/resume. Your kernel console and X Server then sit on top of > > > that, submitting video mode setting and command execution requests to > > > the DRM. The chips I would expect to be supported by then are all > > > Intel, pre-r500 ATI at least, and a subset of nvidia through nouveau. > > >=20 > > > What FreeBSD needs to do to keep up is implement the memory manager > > > part. I think I've got a reasonable design going that should take ab= out > > > a month of reimplementing for the FreeBSD kernel. If someone wanted = to > > > get us closer to doing that, > > >=20 > > > git clone anongit.freedesktop.org:/git/mesa/drm=20 > > >=20 > > > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER defin= es) > > > work on -current. > > >=20 > > > To see what we're working on for what we're calling the "graphics > > > execution manager" now (memory management plus caching management plu= s > > > plans for execution scheduling), > > >=20 > > > git-remote add anholt people.freedesktop.org:~anholt/drm > > > git-fetch anholt > > > git-checkout anholt/drm-gem > > >=20 > > > The interesting things we're needing from the kernel: > > > - Private storage associated with file descriptors > > > - Callback to driver on destruction of file descriptor > > > - Ability to allocate a swap-backed pile of memory > > > - Ability to pin pages from that object and get addresses for them to > > > stuff into the GTT. > > > - Ability to map pages in the kernel with the uncached bits set > > > (non-intel) > > > - Ability to map pages to userland with the uncached bits set > > > (non-intel, likely not required, but may come at a performance > > > cost). > > >=20 > > > Interesting things we're considering needing from the kernel: > > > - Ability to create fds above 1024 from our driver, associated with o= ur > > > own set of file operations (read/write/mmap/ioctl/close). > > > - Ability to look up those fds and get our private storage associated > > > with them. > > >=20 > > > Down the line, likely to happen: > > > - Creating a filesystem exposing those objects we've been making fds > > > for. >=20 > Eric, >=20 > I mentioned earlier that I would get my local git repo's changes to the > mesa/drm tree available from fd.o up somewhere. I have them here: > * http://www.cokane.org/cgi-bin/gitweb.cgi?p=3Ddrm.git >=20 > My custom branch is 'cokane-master' > The fd.o branch is tracked on 'fd-master' >=20 > You can ignore the 'master' branch for now... I need to re-org my git a > bit. >=20 > Right now, this gets my RS690 notebook to almost work with the > in-development radeonhd DRI code, but it causes Xorg to run in a > busyloop when I try using the xf86-video-ati driver with it. I did a run > at trying to get the vblank stuff ported over, but I got busy and > haven't touched it in a bit. I also tried to tweak anything else that > kept the radeon code from compiling under FreeBSD. >=20 > If I have another set of eyes on this it might help me front-burner it > more often to get patches in here-and-there. I've tried shoving some bug > reports up to the DRI project, but they haven't been acted upon yet... Looks like your webserver is dead. Could you push your tree up on freefall or something so I can just ssh and grab it? --=20 Eric Anholt anholt@FreeBSD.org eric@anholt.net eric.anholt@intel.com --=-ae3/nPhfCxp40QDrgRgR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEABECAAYFAkgsn0UACgkQHUdvYGzw6vcGyACfa7++aCWAl7mQHSxgany313o8 6oAAn0Ga/7uBZSWF8tPqty4mpejj6EpM =/n/I -----END PGP SIGNATURE----- --=-ae3/nPhfCxp40QDrgRgR-- From owner-freebsd-arch@FreeBSD.ORG Fri May 16 14:04:01 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E90D41065672 for ; Fri, 16 May 2008 14:04:01 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from vms048pub.verizon.net (vms048pub.verizon.net [206.46.252.48]) by mx1.freebsd.org (Postfix) with ESMTP id BDA138FC13 for ; Fri, 16 May 2008 14:04:01 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from mail.cokane.org ([71.181.74.204]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K0Y004QHSEABUW1@vms048.mailsrvcs.net> for arch@FreeBSD.org; Fri, 16 May 2008 09:03:47 -0500 (CDT) Received: by mail.cokane.org (Postfix, from userid 103) id 340BA1DB2F9; Fri, 16 May 2008 10:03:46 -0400 (EDT) Received: from [172.20.1.3] (unknown [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cokane.org (Postfix) with ESMTP id 1698F1DB2F9; Fri, 16 May 2008 10:03:35 -0400 (EDT) Date: Fri, 16 May 2008 10:03:25 -0400 From: Coleman Kane In-reply-to: <1210883909.96116.4.camel@localhost> To: Eric Anholt Message-id: <1210946605.2668.22.camel@localhost> Organization: FreeBSD Project MIME-version: 1.0 X-Mailer: Evolution 2.22.1.1 FreeBSD GNOME Team Port Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PV4XDANNPwIyzawesES7" X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia References: <1210352688.2152.78.camel@localhost> <1210800676.2466.6.camel@localhost> <1210883909.96116.4.camel@localhost> X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8-gr1 X-Spam-Level: Cc: arch@FreeBSD.org Subject: Re: Feature requests for open-source graphics (OT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2008 14:04:02 -0000 --=-PV4XDANNPwIyzawesES7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 2008-05-15 at 13:38 -0700, Eric Anholt wrote: > On Wed, 2008-05-14 at 17:31 -0400, Coleman Kane wrote: > > On Fri, 2008-05-09 at 10:04 -0700, Eric Anholt wrote: > > > email message attachment, "Forwarded message - Re: Forward: Updated > > > FreeBSD kernel feature requests (NVIDIA graphics)" > > > > -------- Forwarded Message -------- > > > > From: Eric Anholt > > > > To: Marcel Moolenaar > > > > Cc: John Baldwin , Coleman Kane > > > > , Dag-Erling Sm=C3=B8rgrav , Martin > > > > Cracauer , gnn@freebsd.org, > > > > developers@freebsd.org > > > > Subject: Re: Forward: Updated FreeBSD kernel feature requests > > > > (NVIDIA graphics) > > > > Date: Thu, 08 May 2008 15:54:17 -0700 > > > > Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port > > > >=20 > > > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > > > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > > > > >=20 > > > > > > Quite, and this has been covered several times already. In fac= t, =20 > > > > > > they engage > > > > > > in several hacks to support Linux. Other OS's such as Solaris = and =20 > > > > > > OS X have > > > > > > cleaner interfaces for many of the things they wish to do. > > > > >=20 > > > > > I think this is where I normally say that we need kernel drivers > > > > > for graphics hardware. I'm not going to do that anymore; I've bee= n > > > > > stating the obvious too often already... > > > >=20 > > > > It's OK, we're finally listening. By the end of the year, major Li= nux > > > > distributions should be shipping "DRM modesetting" -- the DRM devic= e > > > > takes over your graphics card and manages memory, execution, and > > > > suspend/resume. Your kernel console and X Server then sit on top o= f > > > > that, submitting video mode setting and command execution requests = to > > > > the DRM. The chips I would expect to be supported by then are all > > > > Intel, pre-r500 ATI at least, and a subset of nvidia through nouvea= u. > > > >=20 > > > > What FreeBSD needs to do to keep up is implement the memory manager > > > > part. I think I've got a reasonable design going that should take = about > > > > a month of reimplementing for the FreeBSD kernel. If someone wante= d to > > > > get us closer to doing that, > > > >=20 > > > > git clone anongit.freedesktop.org:/git/mesa/drm=20 > > > >=20 > > > > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER def= ines) > > > > work on -current. > > > >=20 > > > > To see what we're working on for what we're calling the "graphics > > > > execution manager" now (memory management plus caching management p= lus > > > > plans for execution scheduling), > > > >=20 > > > > git-remote add anholt people.freedesktop.org:~anholt/drm > > > > git-fetch anholt > > > > git-checkout anholt/drm-gem > > > >=20 > > > > The interesting things we're needing from the kernel: > > > > - Private storage associated with file descriptors > > > > - Callback to driver on destruction of file descriptor > > > > - Ability to allocate a swap-backed pile of memory > > > > - Ability to pin pages from that object and get addresses for them = to > > > > stuff into the GTT. > > > > - Ability to map pages in the kernel with the uncached bits set > > > > (non-intel) > > > > - Ability to map pages to userland with the uncached bits set > > > > (non-intel, likely not required, but may come at a performance > > > > cost). > > > >=20 > > > > Interesting things we're considering needing from the kernel: > > > > - Ability to create fds above 1024 from our driver, associated with= our > > > > own set of file operations (read/write/mmap/ioctl/close). > > > > - Ability to look up those fds and get our private storage associat= ed > > > > with them. > > > >=20 > > > > Down the line, likely to happen: > > > > - Creating a filesystem exposing those objects we've been making fd= s > > > > for. > >=20 > > Eric, > >=20 > > I mentioned earlier that I would get my local git repo's changes to the > > mesa/drm tree available from fd.o up somewhere. I have them here: > > * http://www.cokane.org/cgi-bin/gitweb.cgi?p=3Ddrm.git > >=20 > > My custom branch is 'cokane-master' > > The fd.o branch is tracked on 'fd-master' > >=20 > > You can ignore the 'master' branch for now... I need to re-org my git a > > bit. > >=20 > > Right now, this gets my RS690 notebook to almost work with the > > in-development radeonhd DRI code, but it causes Xorg to run in a > > busyloop when I try using the xf86-video-ati driver with it. I did a ru= n > > at trying to get the vblank stuff ported over, but I got busy and > > haven't touched it in a bit. I also tried to tweak anything else that > > kept the radeon code from compiling under FreeBSD. > >=20 > > If I have another set of eyes on this it might help me front-burner it > > more often to get patches in here-and-there. I've tried shoving some bu= g > > reports up to the DRI project, but they haven't been acted upon yet... >=20 > Looks like your webserver is dead. Could you push your tree up on > freefall or something so I can just ssh and grab it? >=20 Yeah. Thanks to the brilliance of subsidized monopoly I got my traffic blocked suddenly without notice. I am in the process of hopping to an ISP that actually respects customer right of use of service (I'm not doing anything illegal). I'll shove the stuff up to freefall in a bit and get back to you... Rant warning (look away if you don't want a rant about the "competitive" US ISP market): Had Comcast, and they decided that it is a better use of customer money to spend it on expensive half-baked filtering systems that make the service garbage even for non-bittorrent users (as well as preventing me from getting fbsd/linux ISOs with bittorrent), as well as threatening to disconnect all of my service if I didn't stop serving my personal website and personal email on my personal Internet connection. Moved to Verizon who said that they don't block. Turns out that they block port 80 but just don't tell anybody. If they are so ashamed to admit this block, then they shouldn't do it (IMHO). Otherwise, it should be clearly stated in the TOS agreement, and conveyed to the salespeople (who told me that I could run my server on their connection). The upper-level technicians' reason was that they specifically want to prevent residential lines from being webservers. No block on public mailservers, not even a block on public Windows filesharing ports (yes!! They are open!!). Their business class service also apparently blocks port 80 unless you get the highest-level static-IP service. So I am going with one of the independent DSL operators that provide service over Verizon's lines. Both Comcast and Verizon insist that these policies are exercised by all major providers, but this is not true. Time Warner cable doesn't do this, and neither does Cincinnati Bell (last remaining non-RBOC in the lower 48). Additionally, AT&T actually has a section dedicated to expressing the customers' rights. They specifically bar hosting a server only in the cases of dial-up accounts. Server usage appears to be allowed by them for their DSL service (but I've never used AT&T service before). One of the nice perks of DSL regulation is that the line controllers don't have a monopoly on the lines themselves, which are required to be open to other ISPs who are willing to invest in the DSL system. So I actually have a choice of about 10 companies that I can have DSL from. Almost all of my alternatives seem to provide a line that endorses running a server on it. So I chose dslextreme.com, which seems like a pretty decent vendor, and provides a line that can be served from. --=20 Coleman Kane --=-PV4XDANNPwIyzawesES7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkgtlCkACgkQcMSxQcXat5f5SwCfXdXT+JzXDfrA/RPFUMgp0TO0 KWoAnAoN0SQwal5C+ImtR0fjqwgdsXQp =FCTu -----END PGP SIGNATURE----- --=-PV4XDANNPwIyzawesES7-- From owner-freebsd-arch@FreeBSD.ORG Fri May 16 15:00:05 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75AAA1065675 for ; Fri, 16 May 2008 15:00:05 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id 373438FC23 for ; Fri, 16 May 2008 15:00:05 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.21] (helo=11.mx.freenet.de) by mout2.freenet.de.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #19) id 1Jx1Pg-0008G3-DG for freebsd-arch@freebsd.org; Fri, 16 May 2008 17:00:04 +0200 Received: from mb5d2.m.pppool.de ([89.49.181.210]:37325 helo=peedub.jennejohn.org) by 11.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #12) id 1Jx1Pg-0000Yl-5X for freebsd-arch@freebsd.org; Fri, 16 May 2008 17:00:04 +0200 Date: Fri, 16 May 2008 17:00:03 +0200 From: Gary Jennejohn To: freebsd-arch@freebsd.org Message-ID: <20080516170003.1734cb29@peedub.jennejohn.org> In-Reply-To: <1210946605.2668.22.camel@localhost> References: <1210352688.2152.78.camel@localhost> <1210800676.2466.6.camel@localhost> <1210883909.96116.4.camel@localhost> <1210946605.2668.22.camel@localhost> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.10.14; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: Feature requests for open-source graphics (OT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2008 15:00:05 -0000 On Fri, 16 May 2008 10:03:25 -0400 Coleman Kane wrote: [snip most of rant] > One of the nice perks of DSL regulation is that the line controllers > don't have a monopoly on the lines themselves, which are required to be > open to other ISPs who are willing to invest in the DSL system. So I > actually have a choice of about 10 companies that I can have DSL from. > Almost all of my alternatives seem to provide a line that endorses > running a server on it. So I chose dslextreme.com, which seems like a > pretty decent vendor, and provides a line that can be served from. > Even more OT. Sounds like the good ol' US of A is totally fubar in this regard. Here in Germany every fly-by-night DSL provider offers a domain name and home page hosting because _everybody else_ does too! It's hard to come by a static IP though. --- Gary Jennejohn From owner-freebsd-arch@FreeBSD.ORG Fri May 16 15:47:17 2008 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD7B81065671; Fri, 16 May 2008 15:47:17 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (unknown [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4092C8FC15; Fri, 16 May 2008 15:47:17 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.1/8.14.1) with ESMTP id m4GFlFFx045077; Fri, 16 May 2008 17:47:15 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.1/8.14.1/Submit) id m4GFlEZr045076; Fri, 16 May 2008 17:47:14 +0200 (CEST) (envelope-from olli) Date: Fri, 16 May 2008 17:47:14 +0200 (CEST) Message-Id: <200805161547.m4GFlEZr045076@lurza.secnetix.de> From: Oliver Fromme To: freebsd-arch@FreeBSD.ORG, freebsd-chat@FreeBSD.ORG, gary.jennejohn@freenet.de In-Reply-To: <20080516170003.1734cb29@peedub.jennejohn.org> X-Newsgroups: list.freebsd-arch User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.2-STABLE-20070808 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Fri, 16 May 2008 17:47:16 +0200 (CEST) Cc: Subject: Re: Feature requests for open-source graphics (OT) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-chat@FreeBSD.ORG, gary.jennejohn@freenet.de List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2008 15:47:17 -0000 Gary Jennejohn wrote: > Even more OT. Maybe we should redirect this to -chat? I set Reply-To accordingly. > Sounds like the good ol' US of A is totally fubar in this regard. Here > in Germany every fly-by-night DSL provider offers a domain name and home > page hosting because _everybody else_ does too! It's hard to come by a > static IP though. It's not hard, it's just expensive, depending on your ISP. For example, M-net (Bavaria) charges EUR 14.90 (~ USD 22) per Month for a static IP. Right now they have a special 50% offer, so it's only EUR 7.45 per month if you sign up with them now. On the other hand, for most private stuff a dynamic IP with something like dyndns service should be sufficient, I think. That's what i do. I'm not running any public services on my home machine, though, but the dyndns name enables me to ssh into it from somewhere else. Personally I decided to rent a root server for EUR 50 (from Hetzner) which includes a /29 with six static IPs. It's shared with three friends, so each of us pays only EUR 12,50 which is cheaper than a static IP with M-net, and it has a lot more bandwidth than my DSL box at home. Of course I replaced the Linux installation on the root server with FreeBSD. ;-) Best regards Oliver PS: I'm not affiliated with any of the above companies, and I don't benefit from mentioning them. I'm just a satisfied customer. -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd We're sysadmins. To us, data is a protocol-overhead. From owner-freebsd-arch@FreeBSD.ORG Fri May 16 16:13:43 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77A971065677 for ; Fri, 16 May 2008 16:13:43 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from vms048pub.verizon.net (vms048pub.verizon.net [206.46.252.48]) by mx1.freebsd.org (Postfix) with ESMTP id 4C6E78FC1D for ; Fri, 16 May 2008 16:13:43 +0000 (UTC) (envelope-from cokane@FreeBSD.org) Received: from mail.cokane.org ([71.181.74.204]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K0Y00B20YDUP154@vms048.mailsrvcs.net> for arch@FreeBSD.org; Fri, 16 May 2008 11:13:08 -0500 (CDT) Received: by mail.cokane.org (Postfix, from userid 103) id 6A88F25AD3C; Fri, 16 May 2008 12:13:06 -0400 (EDT) Received: from [172.20.1.3] (unknown [172.20.1.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cokane.org (Postfix) with ESMTP id 599321DB2F9; Fri, 16 May 2008 12:12:58 -0400 (EDT) Date: Fri, 16 May 2008 12:12:51 -0400 From: Coleman Kane In-reply-to: <1210883909.96116.4.camel@localhost> To: Eric Anholt Message-id: <1210954371.2668.24.camel@localhost> Organization: FreeBSD Project MIME-version: 1.0 X-Mailer: Evolution 2.22.1.1 FreeBSD GNOME Team Port Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-WesuScdxJn0CZ2EivpuK" X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia References: <1210352688.2152.78.camel@localhost> <1210800676.2466.6.camel@localhost> <1210883909.96116.4.camel@localhost> X-Spam-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8-gr1 X-Spam-Level: Cc: arch@FreeBSD.org Subject: Re: Feature requests for open-source graphics X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2008 16:13:43 -0000 --=-WesuScdxJn0CZ2EivpuK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 2008-05-15 at 13:38 -0700, Eric Anholt wrote: > On Wed, 2008-05-14 at 17:31 -0400, Coleman Kane wrote: > > On Fri, 2008-05-09 at 10:04 -0700, Eric Anholt wrote: > > > email message attachment, "Forwarded message - Re: Forward: Updated > > > FreeBSD kernel feature requests (NVIDIA graphics)" > > > > -------- Forwarded Message -------- > > > > From: Eric Anholt > > > > To: Marcel Moolenaar > > > > Cc: John Baldwin , Coleman Kane > > > > , Dag-Erling Sm=C3=B8rgrav , Martin > > > > Cracauer , gnn@freebsd.org, > > > > developers@freebsd.org > > > > Subject: Re: Forward: Updated FreeBSD kernel feature requests > > > > (NVIDIA graphics) > > > > Date: Thu, 08 May 2008 15:54:17 -0700 > > > > Mailer: Evolution 2.22.0 FreeBSD GNOME Team Port > > > >=20 > > > > On Wed, 2008-05-07 at 10:37 -0700, Marcel Moolenaar wrote: > > > > > On May 7, 2008, at 8:29 AM, John Baldwin wrote: > > > > >=20 > > > > > > Quite, and this has been covered several times already. In fac= t, =20 > > > > > > they engage > > > > > > in several hacks to support Linux. Other OS's such as Solaris = and =20 > > > > > > OS X have > > > > > > cleaner interfaces for many of the things they wish to do. > > > > >=20 > > > > > I think this is where I normally say that we need kernel drivers > > > > > for graphics hardware. I'm not going to do that anymore; I've bee= n > > > > > stating the obvious too often already... > > > >=20 > > > > It's OK, we're finally listening. By the end of the year, major Li= nux > > > > distributions should be shipping "DRM modesetting" -- the DRM devic= e > > > > takes over your graphics card and manages memory, execution, and > > > > suspend/resume. Your kernel console and X Server then sit on top o= f > > > > that, submitting video mode setting and command execution requests = to > > > > the DRM. The chips I would expect to be supported by then are all > > > > Intel, pre-r500 ATI at least, and a subset of nvidia through nouvea= u. > > > >=20 > > > > What FreeBSD needs to do to keep up is implement the memory manager > > > > part. I think I've got a reasonable design going that should take = about > > > > a month of reimplementing for the FreeBSD kernel. If someone wante= d to > > > > get us closer to doing that, > > > >=20 > > > > git clone anongit.freedesktop.org:/git/mesa/drm=20 > > > >=20 > > > > and make everything but TTM (the *_HAVE_FENCE and *_HAVE_BUFFER def= ines) > > > > work on -current. > > > >=20 > > > > To see what we're working on for what we're calling the "graphics > > > > execution manager" now (memory management plus caching management p= lus > > > > plans for execution scheduling), > > > >=20 > > > > git-remote add anholt people.freedesktop.org:~anholt/drm > > > > git-fetch anholt > > > > git-checkout anholt/drm-gem > > > >=20 > > > > The interesting things we're needing from the kernel: > > > > - Private storage associated with file descriptors > > > > - Callback to driver on destruction of file descriptor > > > > - Ability to allocate a swap-backed pile of memory > > > > - Ability to pin pages from that object and get addresses for them = to > > > > stuff into the GTT. > > > > - Ability to map pages in the kernel with the uncached bits set > > > > (non-intel) > > > > - Ability to map pages to userland with the uncached bits set > > > > (non-intel, likely not required, but may come at a performance > > > > cost). > > > >=20 > > > > Interesting things we're considering needing from the kernel: > > > > - Ability to create fds above 1024 from our driver, associated with= our > > > > own set of file operations (read/write/mmap/ioctl/close). > > > > - Ability to look up those fds and get our private storage associat= ed > > > > with them. > > > >=20 > > > > Down the line, likely to happen: > > > > - Creating a filesystem exposing those objects we've been making fd= s > > > > for. > >=20 > > Eric, > >=20 > > I mentioned earlier that I would get my local git repo's changes to the > > mesa/drm tree available from fd.o up somewhere. I have them here: > > * http://www.cokane.org/cgi-bin/gitweb.cgi?p=3Ddrm.git > >=20 > > My custom branch is 'cokane-master' > > The fd.o branch is tracked on 'fd-master' > >=20 > > You can ignore the 'master' branch for now... I need to re-org my git a > > bit. > >=20 > > Right now, this gets my RS690 notebook to almost work with the > > in-development radeonhd DRI code, but it causes Xorg to run in a > > busyloop when I try using the xf86-video-ati driver with it. I did a ru= n > > at trying to get the vblank stuff ported over, but I got busy and > > haven't touched it in a bit. I also tried to tweak anything else that > > kept the radeon code from compiling under FreeBSD. > >=20 > > If I have another set of eyes on this it might help me front-burner it > > more often to get patches in here-and-there. I've tried shoving some bu= g > > reports up to the DRI project, but they haven't been acted upon yet... >=20 > Looks like your webserver is dead. Could you push your tree up on > freefall or something so I can just ssh and grab it? >=20 Eric, I've pushed it up to ~cokane/drm-cokane.git on freefall. --=20 Coleman Kane --=-WesuScdxJn0CZ2EivpuK Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkgtsoIACgkQcMSxQcXat5eILACfWKKwZkCQY26wcuidJr13YhBA SZgAnRgziM/QTnIl04vh+rA64nulXbTo =jmhc -----END PGP SIGNATURE----- --=-WesuScdxJn0CZ2EivpuK--