From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 00:15:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81186106566C for ; Sun, 28 Jun 2009 00:15:06 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail3.es.net [IPv6:2001:400:4c01::2]) by mx1.freebsd.org (Postfix) with ESMTP id 560A98FC19 for ; Sun, 28 Jun 2009 00:15:06 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n5S0F5I6000737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Jun 2009 17:15:05 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id D3B1B1CC09; Sat, 27 Jun 2009 17:15:04 -0700 (PDT) To: Ron Freidel In-reply-to: Your message of "Sat, 27 Jun 2009 07:54:21 PDT." Date: Sat, 27 Jun 2009 17:15:04 -0700 From: "Kevin Oberman" Message-Id: <20090628001504.D3B1B1CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-06-27_02:2009-06-25, 2009-06-27, 2009-06-26 signatures=0 Cc: freebsd-current@freebsd.org Subject: Re: cpufreq probs dual core intel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 00:15:06 -0000 > Date: Sat, 27 Jun 2009 07:54:21 -0700 > From: Ron Freidel > Sender: owner-freebsd-current@freebsd.org > > Ok, a little more info... > > plugged in > > leroy# sysctl hw.acpi.acline > hw.acpi.acline: 1 > > unplugged > leroy# sysctl hw.acpi.acline > hw.acpi.acline: 0 > > and from /var/log/messages > Jun 27 07:18:46 leroy power_profile: changed to 'economy' > Jun 27 07:18:57 leroy power_profile: changed to 'performance' > > When unplugged the screen dims, the machine seems to slow down, yet heres > the problem... > plugged in > > leroy# sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2000 > > unplugged > > leroy# sysctl dev.cpu.0.freq > dev.cpu.0.freq: 2000 > > I can change the freq using sysctl but it doesn't stick, no crash or > anything though. > > Whats odd to me is the temp the cpu is running at. > unplugged > dev.cpu.0.temperature: 54 > dev.cpu.1.temperature: 55 > plugged in > dev.cpu.0.temperature: 61 > dev.cpu.1.temperature: 62 > > Everything seems to be working as it should, just that pesky cpu freq > > Oh by the way, the laptop is a Dell Latitude D820, and I did find out after > testing acpi sleep while X/gnome is running it works! And another side > note... with FreeBSD 7.2 I get approx 2 hours battery life using wifi, > windows gives 1.5 hrs, OpenSolaris 1 hour, have not left the laptop > unplugged with current long enough to test. One final thought on this...run powerd from the command line with the '-v' option so that you can see if it is trying to change the frequency. If it is (and I am pretty sure that it is), you can remove powerd from the list of suspects. If this proves the case and new BIOS and EC code does not fix the problem, you might try acpi@freebsd.org as the there are people there with the expertise to better diagnose ACPI issues than I. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 01:20:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A5DA81065673; Sun, 28 Jun 2009 01:20:51 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout023.mac.com (asmtpout023.mac.com [17.148.16.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7F2CF8FC22; Sun, 28 Jun 2009 01:20:51 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii; format=flowed; delsp=yes Received: from macbook-pro.lan.xcllnt.net (mail.xcllnt.net [75.101.29.67]) by asmtp023.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KLX007KJD2QER50@asmtp023.mac.com>; Sat, 27 Jun 2009 18:20:51 -0700 (PDT) From: Marcel Moolenaar In-reply-to: Date: Sat, 27 Jun 2009 18:20:49 -0700 Message-id: <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> To: Ivan Voras X-Mailer: Apple Mail (2.1067.4) Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-geom@freebsd.org Subject: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 01:20:52 -0000 On Jun 27, 2009, at 4:15 AM, Ivan Voras wrote: > Marcel Moolenaar wrote: >> On Jun 25, 2009, at 4:02 AM, Anton Shterenlikht wrote: >>> dev_taste(DEV,mirror/gm0) >>> g_part_taste(PART,mirror/gm0) >>> >>> GEOM: mirror/gm0: the secondary GPT table is corrupt or invalid. >>> GEOM: mirror/gm0: using the primary only -- recovery suggested. >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> You created the mirror after the GPT, which means you destroyed >> the GPT backup header. gmirror uses the last sector on the disk >> for metadata and that by itself is a cause for various problems. >> It's better to use gmirror per partition. > > Or create the GPT partition inside the gmirror device - then the GPT > backup table will be at last_sector-1, but... > >> You could run into a race condition between GPT and gmirror and >> GPT winning (again the result of gmirror using the last sector >> on a disk for metadata). > > unfortunately this could still happen, and will lead to the same > error if GPT is tasted first, since it is embedded in the first > sector and will assume the whole drive is available to GPT, and will > then proceed to not find its backup data in the last sector. > > It looks to me like GEOM classes should have a "priority" field for > tasting. Any objections to that idea? Using the last sector is not only flawed because it creates a race condition, it's flawed in the assumption that you can always make a geom part of a mirror by storing meta-data on the geom without causing corruption. This whole idea of using the last sector was so that a fully partitioned disk with data could be turned into a mirrored disk. A neat idea, but hardly the basis for a generic mirroring implementation when it silently corrupts a disk. I think it's better to change gmirror to use the first sector on the provider. This never creates a race condition and as such, you don't need to invent a priority scheme, that has it's own set of flaws on top of it. The only downside is that it's not easy to make a fully partitioned and populated disk part of a mirror: one would need to move the data forward one sector to free the first sector. This we can actually do by inserting a GEOM that does it while I/O is still ongoing. The good thing is: we need a class that does exactly this for implementing the "move" verb in gpart. In other words: Solving the problem that putting the metadata in the first sector creates, can and will be re-used in implementing the gpart "move partition" feature. I doubt anyone will complain that the creation of a mirror brings with it a few hours of disk activity that does not inhibit normal operation... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 03:48:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D29D1106564A for ; Sun, 28 Jun 2009 03:48:56 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id A2DA98FC12 for ; Sun, 28 Jun 2009 03:48:56 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from smoochies.rachie.is-a-geek.net (mailhub.lan.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 8C5F37E837 for ; Sat, 27 Jun 2009 19:48:55 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Sat, 27 Jun 2009 19:48:54 -0800 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906271948.54745.mel.flynn+fbsd.current@mailing.thruhere.net> Subject: Interface dependencies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 03:48:57 -0000 Hi, maybe I'm overlooking something, so I thought I'd ask. As far as I can tell, there is no way to specify interface dependencies, so I have an issue I cannot seem to solve: - Create a lagg0 that has em and wlan0 at boot time, because wlan0 takes too long to be configured - and the default network_interfaces=AUTO sorts alphabetically which is not making matters easier. I've been trying to use hacks, but I think interfaces really need dependencies. Like ifconfig_lagg0_require="wlan0 em0", which would first configure wlan0, wait for it to be availabe, then em0 and finally lagg0. Is there something available, is it a known issue and ENOTIME to fix or am I missing something else? At present, my rc.conf entries are: # Need to do this manually to prevent alphabetical sorting. network_interfaces="wpi0 lo0 em0" cloned_interfaces="lagg0" wlans_wpi0="wlan0" ifconfig_wpi0="ether 00:16:36:f2:3b:84" ifconfig_wlan0="WPA" ifconfig_em0="up" ifconfig_lagg0="laggproto failover laggport em0" ifconfig_lagg0_alias0="laggport wlan0" ifconfig_lagg0_alias1="inet 192.168.2.50 netmask 255.255.255.0" And this gives me a lagg0 at boottime without wlan0, since the interface don't exist. I also cannot add inet commands to laggport commands, thus the alias trick is already needed, yet the delay caused by running separate commands does not seem to be enough to have wlan0 available. -- Mel From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 04:21:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9032B106564A for ; Sun, 28 Jun 2009 04:21:28 +0000 (UTC) (envelope-from louie@transsys.com) Received: from ringworld.transsys.com (ringworld.transsys.com [144.202.0.15]) by mx1.freebsd.org (Postfix) with ESMTP id 666908FC26 for ; Sun, 28 Jun 2009 04:21:28 +0000 (UTC) (envelope-from louie@transsys.com) Received: from PM-G5.transsys.com (c-69-141-150-106.hsd1.nj.comcast.net [69.141.150.106]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: louie) by ringworld.transsys.com (Postfix) with ESMTP id 954CF5C04 for ; Sat, 27 Jun 2009 23:56:57 -0400 (EDT) Message-Id: <4DF26D1E-B437-4FB3-B210-50ACB727101A@transsys.com> From: Louis Mamakos To: freebsd-current@freebsd.org In-Reply-To: <200906280847.59316.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 27 Jun 2009 23:56:56 -0400 References: <4A4517BE.9040504@FreeBSD.org> <20090627141412.GN31709@acme.spoerlein.net> <4A462A7A.20005@haruhiism.net> <200906280847.59316.doconnor@gsoft.com.au> X-Mailer: Apple Mail (2.935.3) Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 04:21:28 -0000 On Jun 27, 2009, at 7:17 PM, Daniel O'Connor wrote: > On Sat, 27 Jun 2009, Kamigishi Rei wrote: >> Hello, hope you're having a nice day, >> >> Ulrich Sp=F6rlein wrote: >>> I, personally, think this is not very good idea. People are used to >>> CAM-devices getting enumerated as da0, da1, etc. All the >>> documentation talks about ad0 for ATA and da0 (plus camcontrol) for >>> SCSI, USB, Firewire devices. We also have fd0 and cd0 and should >>> stick to two-letter-plus-number codes. So either make them all ad0 >>> or da0. I'd vote for the latter, as that is what Linux is doing >>> (more or less) and people are already familiar with USB drives or >>> new SATA drives showing up as "SCSI drives, so they get the SCSI >>> names". >> >> This poses the question of daXX enumeration order. I've already had >> some 'fun' with an IBM server which has an LVD/320 SCSI controller. >> While the controller's bus was enumerated properly, somehow if you >> attach an USB mass storage device before the system boot that said >> mass storage could suddenly appear earlier than one of the SCSI disks >> (that was on 7.0-RELEASE) thus breaking the boot process sometimes >> (when it appeared as da0). > > 7.2 has UFSID in GENERIC so you can mount your disks that way which is > non-ambiguous. > > Unfortunately you can't specify swap this way because it has no ID, I > don't know how hard it would be to add such a thing (which would > require a mkswap or somesuch, and modification to the dump & swap > code..) > I use glabel to create containers with named labels that I then reference as swap devices. (e.g., /dev/label/swap0, etc.) # swapinfo Device 1024-blocks Used Avail Capacity /dev/label/swap2 1044192 0 1044192 0% /dev/label/swap3 1044192 0 1044192 0% /dev/label/swap4 1044192 0 1044192 0% Total 3132576 0 3132576 0% louie From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 05:00:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF9E5106564A for ; Sun, 28 Jun 2009 05:00:26 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 16BA38FC13 for ; Sun, 28 Jun 2009 05:00:25 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-162-173.lns11.adl2.internode.on.net [121.45.162.173]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n5S50NfU013619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 28 Jun 2009 14:30:23 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sun, 28 Jun 2009 14:30:02 +0930 User-Agent: KMail/1.9.10 References: <4A4517BE.9040504@FreeBSD.org> <200906280847.59316.doconnor@gsoft.com.au> <4DF26D1E-B437-4FB3-B210-50ACB727101A@transsys.com> In-Reply-To: <4DF26D1E-B437-4FB3-B210-50ACB727101A@transsys.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1614187.FEMWT3FR2i"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906281430.12157.doconnor@gsoft.com.au> X-Spam-Score: -1.314 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 05:00:27 -0000 --nextPart1614187.FEMWT3FR2i Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 28 Jun 2009, Louis Mamakos wrote: > > Unfortunately you can't specify swap this way because it has no ID, > > I don't know how hard it would be to add such a thing (which would > > require a mkswap or somesuch, and modification to the dump & swap > > code..) > > I use glabel to create containers with named labels that I then > reference as swap devices. (e.g., /dev/label/swap0, etc.) > > # swapinfo > Device 1024-blocks Used Avail Capacity > /dev/label/swap2 1044192 0 1044192 0% > /dev/label/swap3 1044192 0 1044192 0% > /dev/label/swap4 1044192 0 1044192 0% > Total 3132576 0 3132576 0% Ahh, of course, like this? glabel label swap0 /dev/ad0s1b (well that works for me but I'd like to check ;) Any idea if that works with dumping? dumpon accepts it but.. Thanks! =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1614187.FEMWT3FR2i Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKRvjc5ZPcIHs/zowRAtuoAJ43MLNtLt60Y+8g3mjhuagFJbRrRgCfbvv6 zddE/sCgtnHKiLLByDtzRlA= =0X+7 -----END PGP SIGNATURE----- --nextPart1614187.FEMWT3FR2i-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 07:44:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6505B106566C; Sun, 28 Jun 2009 07:44:15 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 673E18FC13; Sun, 28 Jun 2009 07:44:13 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247008961; Sun, 28 Jun 2009 10:44:10 +0300 Message-ID: <4A471F44.7010108@FreeBSD.org> Date: Sun, 28 Jun 2009 10:44:04 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Mike Tancsa References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> In-Reply-To: <200906272303.n5RN3rTi070177@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 07:44:15 -0000 Mike Tancsa wrote: > No luck with an ICH10 board > > I did a buildworld/kernel > > > BTX loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS 632kB/3136000kB available memory > > FreeBSD/i386 bootstrap loader, Revision 1.1 > (mdtancsa@i7.sentex.ca, Fri Jun 26 08:24:30 EDT 2009) > ** > > 28 ops 7 bypasses 93 hits 31 misses 1 flushes > Consoles: internal video/keyboard > BIOS drive C: is disk0 > BIOS 632kB/3136000kB available memory > > FreeBSD/i386 bootstrap loader, Revision 1.1 > (mdtancsa@i7.sentex.ca, Fri Jun 26 08:24:30 EDT 2009) > Can't work out which disk we are booting from. > Guessed BIOS device 0xffffffff not found by probes, defaulting to disk0: > > can't load 'kernel' > > Type '?' for a list of commands, 'help' for more detailed help. > OK > > OK lsdev > cd devices: > disk devices: > disk0: BIOS drive C: > pxe devices: > OK > > > OK ls > open '/' failed: input/output error > OK > > I tried with both a module and it built into the kernel > but no luck. putting it back into regular IDE mode allows it to boot > with the patched kernel I see no any relation to the patch here. I would say it is some BIOS/loader problem, as kernel wasn't yet booted. Have you been ever able to boot this system with AHCI enabled before? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 07:55:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E6A31065670; Sun, 28 Jun 2009 07:55:33 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 70EBF8FC0A; Sun, 28 Jun 2009 07:55:32 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247009403; Sun, 28 Jun 2009 10:55:29 +0300 Message-ID: <4A4721EB.9060404@FreeBSD.org> Date: Sun, 28 Jun 2009 10:55:23 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Daniel O'Connor References: <4A4517BE.9040504@FreeBSD.org> <20090627141412.GN31709@acme.spoerlein.net> <4A462A7A.20005@haruhiism.net> <200906280847.59316.doconnor@gsoft.com.au> In-Reply-To: <200906280847.59316.doconnor@gsoft.com.au> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: scottl@freebsd.org, freebsd-current@freebsd.org, Kamigishi Rei Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 07:55:33 -0000 Daniel O'Connor wrote: > On Sat, 27 Jun 2009, Kamigishi Rei wrote: >> This poses the question of daXX enumeration order. I've already had >> some 'fun' with an IBM server which has an LVD/320 SCSI controller. >> While the controller's bus was enumerated properly, somehow if you >> attach an USB mass storage device before the system boot that said >> mass storage could suddenly appear earlier than one of the SCSI disks >> (that was on 7.0-RELEASE) thus breaking the boot process sometimes >> (when it appeared as da0). > > 7.2 has UFSID in GENERIC so you can mount your disks that way which is > non-ambiguous. > > Unfortunately you can't specify swap this way because it has no ID, I > don't know how hard it would be to add such a thing (which would > require a mkswap or somesuch, and modification to the dump & swap > code..) Yes. I've hit this problem. I haven't tried yet, but probably marking the whole disk with glabel could be an option now. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 08:17:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60831106564A for ; Sun, 28 Jun 2009 08:17:03 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id EF2228FC16 for ; Sun, 28 Jun 2009 08:17:02 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.19] (helo=9.mx.freenet.de) by mout0.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MKpZM-0004Nx-84; Sun, 28 Jun 2009 10:17:00 +0200 Received: from td896.t.pppool.de ([89.55.216.150]:55569 helo=ernst.jennejohn.org) by 9.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1MKpZL-0002J3-VE; Sun, 28 Jun 2009 10:17:00 +0200 Date: Sun, 28 Jun 2009 10:16:58 +0200 From: Gary Jennejohn To: Randy Bush Message-ID: <20090628101658.401692ae@ernst.jennejohn.org> In-Reply-To: References: <20090627225436.C4FA01CC09@ptavv.es.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Steven Hartland Subject: Re: cpufreq probs dual core intel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 08:17:03 -0000 On Sun, 28 Jun 2009 08:37:38 +0900 Randy Bush wrote: > > C'mon respect others peoples preferences > > no problem. plonk! > I've been using e-mail since 1984 and bottom posting has always been the accepted way of doing things. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 08:28:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E8111065672; Sun, 28 Jun 2009 08:28:48 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id A44608FC0C; Sun, 28 Jun 2009 08:28:47 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-162-173.lns11.adl2.internode.on.net [121.45.162.173]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n5S8ShKl018414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 28 Jun 2009 17:58:44 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Alexander Motin Date: Sun, 28 Jun 2009 17:58:14 +0930 User-Agent: KMail/1.9.10 References: <4A4517BE.9040504@FreeBSD.org> <200906280847.59316.doconnor@gsoft.com.au> <4A4721EB.9060404@FreeBSD.org> In-Reply-To: <4A4721EB.9060404@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2292839.0ETLa2bhZh"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906281758.34283.doconnor@gsoft.com.au> X-Spam-Score: -1.32 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: scottl@freebsd.org, freebsd-current@freebsd.org, Kamigishi Rei Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 08:28:48 -0000 --nextPart2292839.0ETLa2bhZh Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 28 Jun 2009, Alexander Motin wrote: > > 7.2 has UFSID in GENERIC so you can mount your disks that way which > > is non-ambiguous. > > > > Unfortunately you can't specify swap this way because it has no ID, > > I don't know how hard it would be to add such a thing (which would > > require a mkswap or somesuch, and modification to the dump & swap > > code..) > > Yes. I've hit this problem. I haven't tried yet, but probably marking > the whole disk with glabel could be an option now. Louis' glabel solution works for me so far :) =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart2292839.0ETLa2bhZh Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKRymy5ZPcIHs/zowRAkyzAKCBxLOvM+IuRSTaQqpXN4n/mSMIaQCgoi9o 9usznICzlh4WuHDyK1tNUWo= =31ZW -----END PGP SIGNATURE----- --nextPart2292839.0ETLa2bhZh-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 08:50:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B12E51065670; Sun, 28 Jun 2009 08:50:00 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206192061.chello.pl [87.206.192.61]) by mx1.freebsd.org (Postfix) with ESMTP id EE5238FC14; Sun, 28 Jun 2009 08:49:59 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DAD9245B36; Sun, 28 Jun 2009 10:49:55 +0200 (CEST) Received: from localhost (chello087206192061.chello.pl [87.206.192.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id DA48545683; Sun, 28 Jun 2009 10:49:49 +0200 (CEST) Date: Sun, 28 Jun 2009 10:49:57 +0200 From: Pawel Jakub Dawidek To: Marcel Moolenaar Message-ID: <20090628084957.GB4159@garage.freebsd.pl> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-geom@freebsd.org Subject: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 08:50:01 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 27, 2009 at 06:20:49PM -0700, Marcel Moolenaar wrote: > Using the last sector is not only flawed because it creates a race > condition, it's flawed in the assumption that you can always make > a geom part of a mirror by storing meta-data on the geom without > causing corruption. This whole idea of using the last sector was > so that a fully partitioned disk with data could be turned into a > mirrored disk. A neat idea, but hardly the basis for a generic > mirroring implementation when it silently corrupts a disk. This wasn't the idea:) People started putting gmirror on top of partitioned disk, because it was easier/simpler/faster than creating mirror, partitioning and copying the data. I for one never put mirror on already partitioned disk. Although it is sometimes safe to use the last sector. Gjournal already looks for UFS and if UFS is in place, it figures out if the last sector is in use - it isn't if partition size is not multiple of UFS block size. > I think it's better to change gmirror to use the first sector on the > provider. This never creates a race condition and as such, you don't > need to invent a priority scheme, that has it's own set of flaws on > top of it. The only downside is that it's not easy to make a fully > partitioned and populated disk part of a mirror: one would need to > move the data forward one sector to free the first sector. This we > can actually do by inserting a GEOM that does it while I/O is still > ongoing. The good thing is: we need a class that does exactly this > for implementing the "move" verb in gpart. There were two reasons to use the last sector instead of first: 1. You want to be able to boot from gmirror. If all your data will be moved forward your boot sectors and kernel will be harder to find. 2. For recovery reasons you may want to turn off gmirror and still be able to access your data. Note that gmirror can handle the case where disk, slice and partition share the same last sector - it simply stores provider size in its metadata, so once it gets disk for tasting it detects its too big and ignores it, then slice will be given for tasting, but it also has larger size than expected and will be ignored as well. Finally partition will be tasted and gmirror configured. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFKRy61ForvXbEpPzQRAmOAAJ44Mp928wYkoBPD3p64vr3tA0aW9gCcDqWO Dr4QaHHEB5I33pAqDmt6CWQ= =6fRJ -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 08:56:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9327106566C for ; Sun, 28 Jun 2009 08:56:53 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mail-qy0-f186.google.com (mail-qy0-f186.google.com [209.85.221.186]) by mx1.freebsd.org (Postfix) with ESMTP id 89DEB8FC0A for ; Sun, 28 Jun 2009 08:56:53 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: by qyk16 with SMTP id 16so3815890qyk.3 for ; Sun, 28 Jun 2009 01:56:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=cmspFSjscfKIU1IbS25XCbj0G2B25vk1TVHE/H7pYi4=; b=qIpwmShhWmrtH5w3mdQTBP6g0bYN9R9xyn5xKc4VFHuHWn8im5JC0nm5hqd/mdN+r7 p6MfC7aS7VFkf/YA1v4NZe4UDGxd1S8ENG/d++QgwTQbWFLM+EoiaCA94ciDCf1ULuM2 FTUmplcEHYaAlVZZNBLiR/U4oBfDgzvZ0RFPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=GqjG4QhJi+wIoCRcuI/8Yo9h8A+Zaikq9U7fkh0wh1Opa3QeP1JJf36tkEwNfTj4zn AOiwsQql0XmvsmO16rlE1hvNioiL6gzCbm8wJRRsG6pyXVRHPlLg3TQsjNJp9bM/0z5V 0D01EdelMOcjvbOvLl6DhVvNdyTEuw5SA2680= Received: by 10.224.19.194 with SMTP id c2mr4539458qab.227.1246177480077; Sun, 28 Jun 2009 01:24:40 -0700 (PDT) Received: from aryeh-desktop.istudentunion.com (ool-44c0cd7a.dyn.optonline.net [68.192.205.122]) by mx.google.com with ESMTPS id 5sm10721112qwh.51.2009.06.28.01.24.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Jun 2009 01:24:39 -0700 (PDT) Message-ID: <4A4728C7.6030608@gmail.com> Date: Sun, 28 Jun 2009 04:24:39 -0400 From: "Aryeh M. Friedman" User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <20090627225436.C4FA01CC09@ptavv.es.net> <20090628101658.401692ae@ernst.jennejohn.org> In-Reply-To: <20090628101658.401692ae@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randy Bush , freebsd-current@freebsd.org, Steven Hartland Subject: Re: cpufreq probs dual core intel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 08:56:54 -0000 Gary Jennejohn wrote: > I've been using e-mail since 1984 and bottom posting has always been > the accepted way of doing things. > > the only problem with that theery is different MUA's have different ideas of the right default on that (top or bottom) for example gmail does top but thunderbird does bottom.... please show some tolerance From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 09:04:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2734B1065673; Sun, 28 Jun 2009 09:04:35 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id B586F8FC17; Sun, 28 Jun 2009 09:04:34 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.12] (helo=2.mx.freenet.de) by mout0.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MKqJO-0005wd-2U; Sun, 28 Jun 2009 11:04:34 +0200 Received: from td896.t.pppool.de ([89.55.216.150]:38574 helo=ernst.jennejohn.org) by 2.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1MKqJN-0003es-Ka; Sun, 28 Jun 2009 11:04:34 +0200 Date: Sun, 28 Jun 2009 11:04:33 +0200 From: Gary Jennejohn To: Alexander Motin Message-ID: <20090628110433.519c758a@ernst.jennejohn.org> In-Reply-To: <4A46553C.4000504@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <20090627164406.155f002d@ernst.jennejohn.org> <4A46553C.4000504@FreeBSD.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 09:04:35 -0000 On Sat, 27 Jun 2009 20:22:04 +0300 Alexander Motin wrote: > Gary Jennejohn wrote: > > - remove atapicam from you kernel config file, otherwise the kernel > > pancis in xpt (at least, mine did) > > Thank you for report. Problem is that atapicam provides fake emulated > SPI transport, but not a native ATA in terms of updated CAM. Small > attached patch fixes this for me: > > # camcontrol devlist > at scbus0 target 0 lun 0 (pass0,ada0) > at scbus3 target 0 lun 0 (cd0,pass1) > Thanks a lot. This patch fixed the problem for me too. Any plans to update your original patch? --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 09:14:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B7CC1065678 for ; Sun, 28 Jun 2009 09:14:12 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 204688FC08 for ; Sun, 28 Jun 2009 09:14:11 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247011558; Sun, 28 Jun 2009 12:14:08 +0300 Message-ID: <4A47345B.3030209@FreeBSD.org> Date: Sun, 28 Jun 2009 12:14:03 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4A4517BE.9040504@FreeBSD.org> <20090627164406.155f002d@ernst.jennejohn.org> <4A46553C.4000504@FreeBSD.org> <20090628110433.519c758a@ernst.jennejohn.org> In-Reply-To: <20090628110433.519c758a@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 09:14:12 -0000 Gary Jennejohn wrote: > Alexander Motin wrote: >> Gary Jennejohn wrote: >>> - remove atapicam from you kernel config file, otherwise the kernel >>> pancis in xpt (at least, mine did) >> Thank you for report. Problem is that atapicam provides fake emulated >> SPI transport, but not a native ATA in terms of updated CAM. Small >> attached patch fixes this for me: >> >> # camcontrol devlist >> at scbus0 target 0 lun 0 (pass0,ada0) >> at scbus3 target 0 lun 0 (cd0,pass1) >> > > Thanks a lot. This patch fixed the problem for me too. > > Any plans to update your original patch? Sure I will in few days. Just not after every single change. I am still investigating this issue to find real crash reason, that was triggered by this mistake. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 09:47:18 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C5191065673 for ; Sun, 28 Jun 2009 09:47:18 +0000 (UTC) (envelope-from mjs@rakupottery.org.uk) Received: from anchor-post-2.mail.demon.net (anchor-post-2.mail.demon.net [195.173.77.133]) by mx1.freebsd.org (Postfix) with ESMTP id CAE058FC1C for ; Sun, 28 Jun 2009 09:47:17 +0000 (UTC) (envelope-from mjs@rakupottery.org.uk) Received: from rakuman.demon.co.uk ([80.177.154.53] helo=rakuba.rakupottery.org.uk) by anchor-post-2.mail.demon.net with esmtp (Exim 4.69) id 1MKqne-0005nV-lG for freebsd-current@FreeBSD.org; Sun, 28 Jun 2009 09:35:50 +0000 Message-ID: <4A473976.6030807@rakupottery.org.uk> Date: Sun, 28 Jun 2009 10:35:50 +0100 From: Martin Smith User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <20090611194557.GC98175@bsdcrew.de> In-Reply-To: <20090611194557.GC98175@bsdcrew.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 09:47:18 -0000 Martin Wilke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Huhu, > > Yes we life and that's good :-). > Changes: > > - Fix build error when compiling in debug mode on FreeBSD HEAD > - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite timeout. > - Some FreeBSD relate typos > - Enable shared OpenGL service. Completely untested due to lack of > appropriate hardware but it compiles at least > - Add support for shared clipboards. Requires libXt > - FreeBSD: Implement preemption API for guest SMP and enable > it (slightly tested). Add neccessary RTMP* methods in userspace > for the frontends to detect the number of CPUs > - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex > instead of a spinlock to fix the problems users are seeing > (assertions with debugging enabled) while still being able > to run on 100Hz hosts. No problems detected so far and Solaris > doesn't use a spin mutex in this code too so it shouldn't do > any harm (keeping fingers crossed)space for the frontends to > detect the number of CPUs > - Add support for curl > - Add VBoxSharedClipboard > > Ports Changes; > - Force guestadditions version to 2.2.4 > - Removed Qt3 include replacements (already upstream) > - Removed cosmetic X11 include path patch > > Please make SURE, your world and kernel is in sync and you've read > the pkg-messages. Also please unload the kernel module before > you update the port ;-). > > Many thx to all Vbox Devs, All supporters, my nice team! :-) > > http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz > > Happy Testing! Well ,I have got it up and running on a stable of 26 June, managed to set up a vdi, no problem, but it will not see the cd drive. It (vbox) says the cd drive is always secondary master, but I only have one ata channel so it is primary master. The dropdown list just does not drop down. Is there a workaround for this, or have I missed something stupid? -- Martin From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 09:59:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEED01065672; Sun, 28 Jun 2009 09:59:39 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 85BCB8FC0C; Sun, 28 Jun 2009 09:59:39 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id A384178F7F; Sun, 28 Jun 2009 13:59:36 +0400 (MSD) Message-ID: <4A473F14.70009@haruhiism.net> Date: Sun, 28 Jun 2009 13:59:48 +0400 From: Aisaka Taiga User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Daniel O'Connor References: <4A4517BE.9040504@FreeBSD.org> <200906280847.59316.doconnor@gsoft.com.au> <4A4721EB.9060404@FreeBSD.org> <200906281758.34283.doconnor@gsoft.com.au> In-Reply-To: <200906281758.34283.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org, scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 09:59:40 -0000 Daniel O'Connor wrote: > Louis' glabel solution works for me so far :) I've experienced many weird things while trying to use glabel for swap partitions. I wonder where does GEOM store the label, because doing glabel create swap /dev/ad0s1b successfully adds a label, it shows up on boot: GEOM_LABEL: Label for provider /dev/ad0s1a is label/swap however, after a while the label is lost. Maybe the metadata is stored in the last sector of the swap space, and the swap data overwrites it, I don't know. There's even funnier thing about UFS labels. Let's say we have a gmirror device gm0. # gmirror create -v -b round-robin gm0 /dev/ad0 # gmirror insert gm0 /dev/ad2 # reboot # tunefs -L root /dev/mirror/gm0s1a *GEOM_LABEL: Label for provider /dev/mirror/gm0s1a is ufs/root* # vim /etc/fstab /dev/ufs/root / .......... # reboot It might work for a while, but usually almost on the next boot I see: ad0: TOOMANYMB on ata0-master SATA300 ad2: TOOMANYMB on ata1-master SATA300 *GEOM_LABEL: Label for provider /dev/ad0s1a is ufs/root* GEOM_MIRROR: Provider gm0 started (2/2) Trying to mount root from ufs:/dev/ufs/root... Manual root filesystem specification: And the system wants me to enter the root FS name manually because ad0 is locked by GEOM and ad0s1a can't be mounted therefore. GEOM_LABEL finds the label before GEOM_MIRROR is started properly. I've experienced this behaviour on both 7.2 and, I think, 8.0 too (May snapshot). I know we don't really need labels on a gmirror because a gmirror is a 'label' in itself and will always appear as /dev/mirror/device-name no matter how we swap HDDs and no matter in which order they are probed, however this is still a bit strange. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 10:25:08 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49D2E1065672; Sun, 28 Jun 2009 10:25:08 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id E4FB48FC16; Sun, 28 Jun 2009 10:25:07 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 1CFCB1E00287; Sun, 28 Jun 2009 12:25:07 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5SAGuVd039003; Sun, 28 Jun 2009 12:16:56 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5SAGuZe039002; Sun, 28 Jun 2009 12:16:56 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 28 Jun 2009 12:16:56 +0200 To: freebsd-current@FreeBSD.org Message-ID: <20090628101656.GA38983@triton.kn-bremen.de> References: <20090628101126.GA38813@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090628101126.GA38813@triton.kn-bremen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: mav@FreeBSD.org Subject: ata irq storm/probe failure; tdq_notify trap (was: pmap_extract trap @boot (20090623-JPSNAP-amd64-dvd1.iso)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 10:25:08 -0000 On Sun, Jun 28, 2009 at 12:11:26PM +0200, Juergen Lock wrote: > [looks like my first post didn't went thru so here goes again...] > [ditto] > I wanted to try a head snapshot iso a few days ago and it failed to boot: > http://people.freebsd.org/~nox/20090623-JPSNAP-amd64-bootpanic1.jpg > http://people.freebsd.org/~nox/20090623-JPSNAP-amd64-bootpanic2.jpg > (I tried to get a serial console but couldn't get this box' serial > port working for some reason... ): > > As you can see in the jpegs it panic'd at pmap_extract+0x106, which > I _think_ is in line 963: (unfortunately there's no kernel.symbols on > the iso) > pdep = pmap_pde(pmap, va); > (see > http://fxr.watson.org/fxr/source/amd64/amd64/pmap.c#L963 > ), and that got invoked from isa_dmarangecheck+0x98: > http://fxr.watson.org/fxr/source/amd64/isa/isa_dma.c#L374 > [...] And the dmesg I posted already points at the next problem... > [...] > start_init: trying /sbin/init > start_init: trying /sbin/oinit > start_init: trying /sbin/init.bak > start_init: trying /rescue/init > start_init: trying /stand/sysinstall > ata5: CONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000001 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: DISCONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000001 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: CONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000001 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: DISCONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000000 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: CONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000000 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: DISCONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000001 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: CONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000001 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: DISCONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > [...] i.e. ata5 isnt probed correctly anymore (its an optical drive), and meanwhile I discovered there's an irq storm on irq 22 too (shared between atapci0 and fwohci0), causing one cpu to be at near 100%. This doesn't seem to occur with a 20090315 snapshot so _maybe_ its related to this commit: mav 2009-03-30 22:18:38 UTC FreeBSD src repository Modified files: sys/dev/ata ata-pci.c ata-pci.h ata-sata.c sys/dev/ata/chipsets ata-ahci.c ata-intel.c ata-jmicron.c ata-marvell.c ata-nvidia.c ata-promise.c ata-siliconimage.c ata-sis.c ata-via.c Log: SVN rev 190581 on 2009-03-30 22:18:38Z by mav Integrate user/mav/ata branch: Add ch_suspend/ch_resume methods for PCI controllers and implement them for AHCI. Refactor AHCI channel initialization according to it. Fix Port Multipliers operation. It is far from perfect yet, but works now. Tested with JMicron JMB363 AHCI + SiI 3726 PMP pair. Previous version was also tested with SiI 4726 PMP. Hardware sponsored by: Vitsch Electronics / VEHosting.nl (I first tried manually reverting commit 191568 in the 20090623 kernel as this box has an amd/ati sb600, but that seemed to make no difference.) While doing that I discovered another problem tho: I installed onto an usb key for testing, and booting that panic'd in tdq_notify+0x4e with a trap due to a null pointer here: movzbl 0x27a(%rax),%edx (it was trying to read from 0x27a; the backtrace was almost empty as this seems to be part of the scheduler - I can post the backtrace too if anyone's interested.) I then got it to boot into single user, and from there got into multiuser, and then discovered the ata issue... The good news is the new usb stack seems to like my printer better! (I didn't actually test printing itself but at least it got detected at boot, which on 7-stable it doesn't, I always have to plug it into another port atm after boot before I can use it...) Ok that should be enough for now. Cheers, :) Juergen PS: ata5 related parts of stable dmesg: ... ata5: on atapci0 ata5: SATA connect time=0ms ata5: SIGNATURE: eb140101 ata5: ahci_reset devices=0x4 ata5: [MPSAFE] ata5: [ITHREAD] ... ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire ata5: device_reset timeout=660us acd1: DVDR drive at ata5 as master acd1: read 5512KB/s (5512KB/s) write 5512KB/s (5512KB/s), 16384KB buffer, SATA150 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd1: Writes: CDR, CDRW, DVDR, test write, burnproof acd1: Audio: play, 2 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc ... ...and the other optical drive that also gets detected on head (this dmesg still from stable:) ... ata3: on atapci0 ata3: SATA connect time=0ms ata3: SIGNATURE: eb140101 ata3: ahci_reset devices=0x4 ata3: [MPSAFE] ata3: [ITHREAD] ... ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire ata3: device_reset timeout=120us acd0: DVDR drive at ata3 as master acd0: read 6890KB/s (6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ... ..so maybe (wild guess!) UDMA100 is related? Here is the head dmesg related to that drive for comparison: ... ata3: on atapci0 ata3: AHCI reset... ata3: hardware reset ... ata3: SATA connect time=10ms status=00000113 ata3: ready wait time=183ms ata3: software reset port 15... ata3: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata3: port is not ready (timeout 0ms) tfd = 00000180 ata3: software reset clear timeout ata3: software reset port 0... ata3: ready wait time=0ms ata3: SIGNATURE: eb140101 ata3: AHCI reset done: devices=00010000 ata3: [MPSAFE] ata3: [ITHREAD] ... ata3: Identifying devices: 00010000 ata3: New devices: 00010000 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire ata3: device_reset timeout=120us uhub3: 6 ports with 6 removable, self powered uhub6: 6 ports with 6 removable, self powered acd0: DVDR drive at ata3 as master acd0: read 17583KB/s (17583KB/s) write 5410KB/s (5410KB/s), 2000KB buffer, +SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: DVD 120mm data disc From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 10:25:08 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBDC21065674 for ; Sun, 28 Jun 2009 10:25:08 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id E50348FC19 for ; Sun, 28 Jun 2009 10:25:07 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 17F451E0027B; Sun, 28 Jun 2009 12:25:07 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5SABQCm038974 for ; Sun, 28 Jun 2009 12:11:26 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5SABQQL038973 for freebsd-current@FreeBSD.org; Sun, 28 Jun 2009 12:11:26 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 28 Jun 2009 12:11:26 +0200 To: freebsd-current@FreeBSD.org Message-ID: <20090628101126.GA38813@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: pmap_extract trap @boot (20090623-JPSNAP-amd64-dvd1.iso) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 10:25:09 -0000 [looks like my first post didn't went thru so here goes again...] I wanted to try a head snapshot iso a few days ago and it failed to boot: http://people.freebsd.org/~nox/20090623-JPSNAP-amd64-bootpanic1.jpg http://people.freebsd.org/~nox/20090623-JPSNAP-amd64-bootpanic2.jpg (I tried to get a serial console but couldn't get this box' serial port working for some reason... ): As you can see in the jpegs it panic'd at pmap_extract+0x106, which I _think_ is in line 963: (unfortunately there's no kernel.symbols on the iso) pdep = pmap_pde(pmap, va); (see http://fxr.watson.org/fxr/source/amd64/amd64/pmap.c#L963 ), and that got invoked from isa_dmarangecheck+0x98: http://fxr.watson.org/fxr/source/amd64/isa/isa_dma.c#L374 So, anyone have an idea what's up with this? This box is running 7-stable/amd64 without major issues: FreeBSD triton.kn-bremen.de 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 10 19:06:01 CEST 2009 (there are some usb problems which made me curious to try out the new usb stack, and also k3b hangs on startup causing an irq storm on one cpu until reboot, but this pmap_extract panic certainly is new.) Also interestingly the i386 snapshot from the same date, http://pub.allbsd.org/FreeBSD-snapshots/i386/8.0-HEAD-20090623-JPSNAP/cdrom/8.0-HEAD-20090623-JPSNAP-i386-dvd1.iso boots without issues and I got out a verbose dmesg from it to compare, but since this box has 8 GB RAM i386 is kinda out of the question... :) [I since realized that ppc_isa_attach in the backtrace belongs to the parallel port driver which is unused on this box so I was able to work around this issue by disabling the parallel port in the bios. But still I think this bug should be fixed...] Here comes the dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-HEAD-20090623-JPSNAP #0: Tue Jun 23 02:04:14 UTC 2009 root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc1522000. Preloaded mfs_root "/boot/mfsroot" at 0xc152219c. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2812829239 Hz CPU: AMD Phenom(tm) II X4 920 Processor (2812.83-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant Data TLB: 48 entries, fully associative Instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001825000 - 0x00000000cc741fff, 3404845056 bytes (831261 pages) avail memory = 3403403264 (3245 MB) Table 'FACP' at 0xcfee3040 Table 'SSDT' at 0xcfee8fc0 Table 'HPET' at 0xcfee9880 Table 'MCFG' at 0xcfee98c0 Table 'TAMG' at 0xcfee9900 Table 'APIC' at 0xcfee8f00 MADT: Found table at 0xcfee8f00 MP Configuration Table version 1.4 found at 0xc00f0f00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 3 ACPI ID 3: enabled SMP: Added CPU 3 (AP) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 bios32: Found BIOS32 Service Directory header at 0xc00fb2d0 bios32: Entry = 0xfba20 (c00fba20) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xba50 pnpbios: Found PnP BIOS data at 0xc00fc2e0 pnpbios: Entry = f0000:c310 Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf6fe0 00014 (v0 GBT ) ACPI: RSDT 0xcfee3000 0003C (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: FACP 0xcfee3040 00074 (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: DSDT 0xcfee30c0 05E2B (v1 GBT GBTUACPI 00001000 MSFT 03000000) ACPI: FACS 0xcfee0000 00040 ACPI: SSDT 0xcfee8fc0 0088C (v1 PTLTD POWERNOW 00000001 LTP 00000001) ACPI: HPET 0xcfee9880 00038 (v1 GBT GBTUACPI 42302E31 GBTU 00000098) ACPI: MCFG 0xcfee98c0 0003C (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: TAMG 0xcfee9900 00302 (v1 GBT GBT B0 5455312E BG\^A\^A 53450101) ACPI: APIC 0xcfee8f00 00084 (v1 GBT GBTUACPI 42302E31 GBTU 01010101) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jun 23 2009 02:02:44) npx0: INT 16 interface acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 pcibios: BIOS version 3.00 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc6c0a000 pa 0x1000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SACS -> bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.BAR1 -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SMB0.HETT -> bus 0 dev 20 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfde0000 (3) failed ACPI timer: 1/2 1/2 1/1 1/1 1/1 1/2 1/2 1/2 1/2 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x4353 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1002, dev=0x5957, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[1c]: type Memory, range 64, base 0xe0000000, size 29, enabled found-> vendor=0x1002, dev=0x5978, revid=0x00 domain=0, bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x597d, revid=0x00 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.7.INTA pcib0: slot 7 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x597f, revid=0x00 domain=0, bus=0, slot=10, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.10.INTA pcib0: slot 10 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4390, revid=0x00 domain=0, bus=0, slot=17, func=0 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xff00, size 3, enabled map[14]: type I/O Port, range 32, base 0xfe00, size 2, enabled map[18]: type I/O Port, range 32, base 0xfd00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xfc00, size 2, enabled map[20]: type I/O Port, range 32, base 0xfb00, size 4, enabled map[24]: type Memory, range 32, base 0xfe02f000, size 10, enabled pcib0: matched entry for 0.17.INTA pcib0: slot 17 INTA hardwired to IRQ 22 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=18, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type Memory, range 32, base 0xfe02e000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=18, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type Memory, range 32, base 0xfe02d000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=18, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02c000, size 8, enabled pcib0: matched entry for 0.18.INTB pcib0: slot 18 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type Memory, range 32, base 0xfe02b000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type Memory, range 32, base 0xfe02a000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe029000, size 8, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4385, revid=0x3a domain=0, bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0403, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x439c, revid=0x00 domain=0, bus=0, slot=20, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 MSI supports 2 messages map[20]: type I/O Port, range 32, base 0xfa00, size 4, enabled found-> vendor=0x1002, dev=0x4383, revid=0x00 domain=0, bus=0, slot=20, func=2 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0410, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xfe024000, size 14, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x439d, revid=0x00 domain=0, bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4384, revid=0x00 domain=0, bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0027, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4399, revid=0x00 domain=0, bus=0, slot=20, func=5 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 map[10]: type Memory, range 32, base 0xfe028000, size 12, enabled pcib0: matched entry for 0.20.INTC pcib0: slot 20 INTC hardwired to IRQ 18 found-> vendor=0x1022, dev=0x1200, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1201, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1202, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1203, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1204, revid=0x00 domain=0, bus=0, slot=24, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: irq 18 at device 2.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfde00000-0xfdefffff pcib1: prefetched decode 0xd0000000-0xdfffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x9498, revid=0x00 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib1: requested memory range 0xd0000000-0xdfffffff: good map[18]: type Memory, range 64, base 0xfdee0000, size 16, enabled pcib1: requested memory range 0xfdee0000-0xfdeeffff: good map[20]: type I/O Port, range 32, base 0xee00, size 8, enabled pcib1: requested I/O range 0xee00-0xeeff: in range pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0xaa38, revid=0x00 domain=0, bus=1, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfdefc000, size 14, enabled pcib1: requested memory range 0xfdefc000-0xfdefffff: good pcib1: matched entry for 1.0.INTB pcib1: slot 0 INTB hardwired to IRQ 19 vgapci0: port 0xee00-0xeeff mem 0xd0000000-0xdfffffff,0xfdee0000-0xfdeeffff irq 18 at device 0.0 on pci1 pci1: at device 0.1 (no driver attached) pcib2: irq 19 at device 7.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfdd00000-0xfddfffff pcib2: prefetched decode 0xfdc00000-0xfdcfffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x10b9, revid=0x06 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfdde0000, size 17, enabled pcib2: requested memory range 0xfdde0000-0xfddfffff: good map[14]: type Memory, range 32, base 0xfddc0000, size 17, enabled pcib2: requested memory range 0xfddc0000-0xfdddffff: good map[18]: type I/O Port, range 32, base 0xdf00, size 5, enabled pcib2: requested I/O range 0xdf00-0xdf1f: in range pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 em0: port 0xdf00-0xdf1f mem 0xfdde0000-0xfddfffff,0xfddc0000-0xfdddffff irq 19 at device 0.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfdde0000 em0: attempting to allocate 1 MSI vectors (1 supported) em0: using IRQ 256 for MSI em0: Using MSI interrupt msi: Assigning MSI IRQ 256 to local APIC 0 vector 49 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1b:21:34:ef:46 pcib3: irq 18 at device 10.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfda00000-0xfdafffff pcib3: prefetched decode 0xfdf00000-0xfdffffff pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xce00, size 8, enabled pcib3: requested I/O range 0xce00-0xceff: in range map[18]: type Prefetchable Memory, range 64, base 0xfdfff000, size 12, enabled pcib3: requested memory range 0xfdfff000-0xfdffffff: good map[20]: type Prefetchable Memory, range 64, base 0xfdfe0000, size 16, enabled pcib3: requested memory range 0xfdfe0000-0xfdfeffff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 18 re0: port 0xce00-0xceff mem 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 18 at device 0.0 on pci3 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfdfff000 re0: MSI count : 2 re0: attempting to allocate 1 MSI vectors (2 supported) re0: using IRQ 257 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:1f:d0:d7:4c:1b msi: Assigning MSI IRQ 257 to local APIC 0 vector 50 re0: [MPSAFE] re0: [FILTER] atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfb00 atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe02f000 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 51 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported atapci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd CCC 4ports ata2: on atapci0 ata2: AHCI reset... ata2: hardware reset ... ata2: SATA connect time=0ms status=00000123 ata2: ready wait time=24ms ata2: software reset port 15... ata2: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata2: port is not ready (timeout 0ms) tfd = 000001d0 ata2: software reset clear timeout ata2: software reset port 0... ata2: ready wait time=0ms ata2: SIGNATURE: 00000101 ata2: AHCI reset done: devices=00000001 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: AHCI reset... ata3: hardware reset ... ata3: SATA connect time=10ms status=00000113 ata3: ready wait time=183ms ata3: software reset port 15... ata3: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata3: port is not ready (timeout 0ms) tfd = 00000180 ata3: software reset clear timeout ata3: software reset port 0... ata3: ready wait time=0ms ata3: SIGNATURE: eb140101 ata3: AHCI reset done: devices=00010000 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 ata4: AHCI reset... ata4: hardware reset ... ata4: SATA connect time=0ms status=00000123 ata4: ready wait time=16ms ata4: software reset port 15... ata4: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata4: port is not ready (timeout 0ms) tfd = 000001d0 ata4: software reset clear timeout ata4: software reset port 0... ata4: ready wait time=0ms ata4: SIGNATURE: 00000101 ata4: AHCI reset done: devices=00000001 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci0 ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: [MPSAFE] ata5: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02e000 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 52 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02d000 ohci1: [MPSAFE] ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe02c000 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 53 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at device 19.0 on pci0 ohci2: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02b000 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 54 ohci2: [MPSAFE] ohci2: [ITHREAD] usbus3: on ohci2 ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 ohci3: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 ohci3: [MPSAFE] ohci3: [ITHREAD] usbus4: on ohci3 ehci1: mem 0xfe029000-0xfe0290ff irq 19 at device 19.2 on pci0 ehci1: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe029000 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 55 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfa00 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=7f ostat1=7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 56 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=7f ostat1=7f ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat1=0x7f err=0xff lsb=0xff msb=0xff ata1: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 57 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xb000-0xbfff pcib4: memory decode 0xf8000000-0xfcffffff pcib4: prefetched decode 0xfdb00000-0xfdbfffff pcib4: Subtractively decoded bridge. pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x14f1, dev=0x8800, revid=0x05 domain=0, bus=4, slot=6, func=0 class=04-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x14 (5000 ns), maxlat=0x37 (13750 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf9000000, size 24, enabled pcib4: requested memory range 0xf9000000-0xf9ffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8811, revid=0x05 domain=0, bus=4, slot=6, func=1 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf8000000, size 24, enabled pcib4: requested memory range 0xf8000000-0xf8ffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8802, revid=0x05 domain=0, bus=4, slot=6, func=2 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x06 (1500 ns), maxlat=0x58 (22000 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfb000000, size 24, enabled pcib4: requested memory range 0xfb000000-0xfbffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8804, revid=0x05 domain=0, bus=4, slot=6, func=4 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfa000000, size 24, enabled pcib4: requested memory range 0xfa000000-0xfaffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x104c, dev=0x8024, revid=0x00 domain=0, bus=4, slot=14, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfcfff000, size 11, enabled pcib4: requested memory range 0xfcfff000-0xfcfff7ff: good map[14]: type Memory, range 32, base 0xfcff8000, size 14, enabled pcib4: requested memory range 0xfcff8000-0xfcffbfff: good pcib4: matched entry for 4.14.INTA pcib4: slot 14 INTA hardwired to IRQ 22 pci4: at device 6.0 (no driver attached) pci4: at device 6.1 (no driver attached) pci4: at device 6.2 (no driver attached) pci4: at device 6.4 (no driver attached) fwohci0: mem 0xfcfff000-0xfcfff7ff,0xfcff8000-0xfcffbfff irq 22 at device 14.0 on pci4 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfcfff000 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:ef:de:f8:00:00:1f:d0 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1ac4000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:ef:de:00:1f:d0 fwe0: bpf attached fwe0: Ethernet address: 02:ef:de:00:1f:d0 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:ef:de:f8:00:00:1f:d0 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 ohci4: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe028000 ohci4: [MPSAFE] ohci4: [ITHREAD] usbus6: on ohci4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 58 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 59 uart0: [FILTER] uart0: fast interrupt ppc0: using extended I/O port range ppc0: SPP ECP ECP+EPP ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 60 ppc0: [MPSAFE] ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached plip0: [MPSAFE] plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [MPSAFE] lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 61 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 62 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 atrtc1: port 0x70-0x73 on acpi0 atrtc1: registered as a time-of-day clock (resolution 1000000us) cpu0: on acpi0 cpu0: switching to generic Cx mode hwpstate0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 0: ioport 0xc00 alloc failed pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. atrtc1: removed as time-of-day clock: clock atrtc has higher resolution atrtc0: registered as a time-of-day clock (resolution 1000000us) uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 214210 -> 100000 procfs registered lapic: Divisor 2, Frequency 100458198 hz Timecounter "TSC" frequency 2812829239 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached ata5: CONNECT requested firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 hptrr: no controller detected. ata0: Identifying devices: 00000000 ata0: New devices: 00000000 ata1: Identifying devices: 00000000 ata1: New devices: 00000000 ata2: Identifying devices: 00000001 ata2: New devices: 00000001 usbus6: 12Mbps Full Speed USB v1.0 md0: Preloaded image 4423680 bytes at 0xc10e87a0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ugen6.1: at usbus6 uhub0: on usbus6 ugen0.1: at usbus0 uhub1: on usbus0 ugen1.1: at usbus1 uhub2: on usbus1 ugen2.1: at usbus2 uhub3: on usbus2 ugen3.1: at usbus3 uhub4: on usbus3 ugen4.1: at usbus4 uhub5: on usbus4 ugen5.1: at usbus5 uhub6: on usbus5 uhub0: 2 ports with 2 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub2: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered uhub5: 3 ports with 3 removable, self powered ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: DISCONNECT requested ata5: reinit done .. ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 953868MB at ata2-master SATA300 ad4: 1953523055 sectors [1938018C/16H/63S] 16 sectors/interrupt 1 depth queue ad4: Silicon Image check3 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3: Identifying devices: 00010000 ata3: New devices: 00010000 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire ata3: device_reset timeout=120us uhub3: 6 ports with 6 removable, self powered uhub6: 6 ports with 6 removable, self powered acd0: DVDR drive at ata3 as master acd0: read 17583KB/s (17583KB/s) write 5410KB/s (5410KB/s), 2000KB buffer, SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: DVD 120mm data disc ata4: Identifying devices: 00000001 ata4: New devices: 00000001 ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 953869MB at ata4-master SATA300 ad8: 1953525168 sectors [1938021C/16H/63S] 16 sectors/interrupt 1 depth queue ad8: Silicon Image check3 failed ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LSI (v2) check1 failed ad8: FreeBSD check1 failed ata5: Identifying devices: 00000000 ata5: New devices: 00000000 GEOM: new disk ad4 GEOM: new disk ad8 ugen1.2: at usbus1 ata5: CONNECT requested ulpt0: on usbus1 ulpt0: using bi-directional mode umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0000 (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... GEOM: ad8: partition 1 does not start on a track boundary. GEOM: ad8: partition 1 does not end on a track boundary. GEOM: ad4s2: geometry does not match label (255h,63s != 16h,63s). umass0:1:0:-1: Attached to scbus1 ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: DISCONNECT requested ata5: reinit done .. (probe0:umass-sim0:0:0:0): error 22 (probe0:umass-sim0:0:0:0): Unretryable Error (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present Unretryable error (probe0:umass-sim0:0:0:0): error 6 (probe0:umass-sim0:0:0:0): Unretryable Error ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. GEOM: new disk da0 ATA PseudoRAID loaded (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-2 device pass0: 1.000MB/s transfers SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 1 vector 48(da0: umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 -> 6ioapic0: routing intpin 6 ( ISA IRQ 6) to lapic 2 vector 48 ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 3 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 1 vector 49 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 2 vector 49 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 3 vector 49 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 1 vector 50 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 2 vector 50 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 3 vector 50 msi: Assigning MSI IRQ 256 to local APIC 1 vector 51 msi: Assigning MSI IRQ 257 to local APIC 2 vector 51 WARNING: WITNESS option enabled, expect reduced performance. (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 -> 6 Trying to mount root from ufs:/dev/md0 ct_to_ts([2009-06-25 19:46:54]) = 1245959214.000000000 start_init: trying /sbin/init start_init: trying /sbin/oinit start_init: trying /sbin/init.bak start_init: trying /rescue/init start_init: trying /stand/sysinstall ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 10:55:04 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C28CA106564A; Sun, 28 Jun 2009 10:55:04 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 739BA8FC0A; Sun, 28 Jun 2009 10:55:04 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n5SAqdOu074630; Sun, 28 Jun 2009 06:52:39 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200906281052.n5SAqdOu074630@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 28 Jun 2009 06:54:56 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <4A471F44.7010108@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 10:55:05 -0000 At 03:44 AM 6/28/2009, Alexander Motin wrote: >I see no any relation to the patch here. I would say it is some >BIOS/loader problem, as kernel wasn't yet booted. Have you been ever >able to boot this system with AHCI enabled before? Actually, I had never tried before. It does not work either with a generic kernel. Its a supermicro board. I will see if I can find a BIOS update ---Mike From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 11:09:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89C14106564A; Sun, 28 Jun 2009 11:09:13 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id D31A48FC14; Sun, 28 Jun 2009 11:09:12 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-162-173.lns11.adl2.internode.on.net [121.45.162.173]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n5SB9AFE022770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 28 Jun 2009 20:39:11 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Aisaka Taiga Date: Sun, 28 Jun 2009 20:38:47 +0930 User-Agent: KMail/1.9.10 References: <4A4517BE.9040504@FreeBSD.org> <200906281758.34283.doconnor@gsoft.com.au> <4A473F14.70009@haruhiism.net> In-Reply-To: <4A473F14.70009@haruhiism.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart42974049.KmEQ2YtpWy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906282038.58968.doconnor@gsoft.com.au> X-Spam-Score: -1.326 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Alexander Motin , freebsd-current@freebsd.org, scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 11:09:13 -0000 --nextPart42974049.KmEQ2YtpWy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 28 Jun 2009, Aisaka Taiga wrote: > Daniel O'Connor wrote: > > Louis' glabel solution works for me so far :) > > I've experienced many weird things while trying to use glabel for > swap partitions. I wonder where does GEOM store the label, because > doing > > glabel create swap /dev/ad0s1b > > successfully adds a label, it shows up on boot: > > GEOM_LABEL: Label for provider /dev/ad0s1a is label/swap > > however, after a while the label is lost. Maybe the metadata is > stored in the last sector of the swap space, and the swap data > overwrites it, I don't know. I think you want glabel label swap /dev/ad0s1b 'create' is the manual method which won't store any metadata - 'label'=20 stores it in the last sector of the provider. > And the system wants me to enter the root FS name manually because > ad0 is locked by GEOM and ad0s1a can't be mounted therefore. > GEOM_LABEL finds the label before GEOM_MIRROR is started properly. > > I've experienced this behaviour on both 7.2 and, I think, 8.0 too > (May snapshot). > I know we don't really need labels on a gmirror because a gmirror is > a 'label' in itself and will always appear as /dev/mirror/device-name > no matter how we swap HDDs and no matter in which order they are > probed, however this is still a bit strange. I think if you use label you'd be OK (but you'd need to newfs because=20 the created provider is 1 sector smaller). The other alternative is to=20 use /dev/ufsid/xxx which won't require a newfs as your existing FS's=20 have an ID already (presuming you are using GENERIC). =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart42974049.KmEQ2YtpWy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD4DBQBKR09K5ZPcIHs/zowRAmBrAJiqUvwg55NTaVOvnsPnEb7yVa1TAJ9lsNLE s7rxQJRo4mV6iCzv3xvZmQ== =rrPh -----END PGP SIGNATURE----- --nextPart42974049.KmEQ2YtpWy-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 11:24:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9B7E106564A; Sun, 28 Jun 2009 11:24:21 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 5F6158FC14; Sun, 28 Jun 2009 11:24:21 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 83F6B78F85; Sun, 28 Jun 2009 15:24:19 +0400 (MSD) Message-ID: <4A4752EF.8030101@haruhiism.net> Date: Sun, 28 Jun 2009 15:24:31 +0400 From: Aisaka Taiga User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Daniel O'Connor References: <4A4517BE.9040504@FreeBSD.org> <200906281758.34283.doconnor@gsoft.com.au> <4A473F14.70009@haruhiism.net> <200906282038.58968.doconnor@gsoft.com.au> In-Reply-To: <200906282038.58968.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org, scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 11:24:21 -0000 Hello, hope you're having a nice day, Daniel O'Connor wrote: > I think you want glabel label swap /dev/ad0s1b > > 'create' is the manual method which won't store any metadata - 'label' > stores it in the last sector of the provider. > I might be mistaken here as I tried that in May, when I upgraded my production server to 7.2; I probably tried using the 'label' subcommand or it wouldn't show up on boot, right? (There was a mistype in my earlier message; should be "label for provider ad0s1b is label/swap", not "ad0s1a".) > I think if you use label you'd be OK (but you'd need to newfs because > the created provider is 1 sector smaller). I'll check, though that'd require backing up and reformatting everything. > The other alternative is to > use /dev/ufsid/xxx which won't require a newfs as your existing FS's > have an ID already (presuming you are using GENERIC). The problem with ufsids is that unlike a manually set label, you can't really distinguish between them (as opposed to the default scheme of sXY where for a boot device you can be almost 80% certain that ad0s1a is /, f is /usr, etc etc - especially if the default number of partitions was created). -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 11:36:17 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 24F861065673 for ; Sun, 28 Jun 2009 11:36:17 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id B99D68FC0C for ; Sun, 28 Jun 2009 11:36:16 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.243.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 0F4E53988A for ; Sun, 28 Jun 2009 13:20:16 +0200 (SAST) Message-ID: <4A4751ED.8020002@phat.za.net> Date: Sun, 28 Jun 2009 13:20:13 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.21 (X11/20090331) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: recent boot0 changes dropped a partition type? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 11:36:17 -0000 Hi, I recently installed 8.0 from the June snapshot ISO. I noticed that the new boot0 code has had partition type 0xc removed as a recognised partition type. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/boot0/boot0.S.diff?r1=1.21;r2=1.22;f=h That ID is used by FAT32 partitions so in my case I'm getting a "?" on my Windows partition. If it was removed to save space, I think 0xb would be more appropriate for removal - it is the non-LBA equivalent of 0xc and I don't think any modern Windows partitioner sets it anymore. Thanks, Aragon From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 11:39:31 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2BE11065673; Sun, 28 Jun 2009 11:39:31 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 781ED8FC2E; Sun, 28 Jun 2009 11:39:31 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:40962 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MKsUT-0000hW-47; Sun, 28 Jun 2009 13:24:11 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 0354C5F5D2; Sun, 28 Jun 2009 13:24:05 +0200 (CEST) Message-Id: <24BDCB76-0304-443A-96A9-71C5E537FF37@exscape.org> From: Thomas Backman To: Dimitry Andric In-Reply-To: <4A43893F.5070100@andric.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 28 Jun 2009 13:24:02 +0200 References: <200906241741.n5OHfTaw022417@svn.freebsd.org> <4A43893F.5070100@andric.com> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MKsUT-0000hW-47. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MKsUT-0000hW-47 2c68fb25214baf1d138ddc5b80ecfd2f Cc: Jack F Vogel , Robert Watson , current@FreeBSD.org Subject: Re: VMWare if_em breakage (was: Re: svn commit: r194865 - in head/sys: dev/e1000 modules/igb) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 11:39:32 -0000 On Jun 25, 2009, at 04:27 PM, Dimitry Andric wrote: > On 2009-06-25 16:08, Robert Watson wrote: >> Since this change (and the two followups), I'm no longer able to >> use if_em >> reliable in VMWare Fusion. > > Same here, for VMware Workstation. The interface just stops working > after a bit of traffic. Not sure it's needed, but here's another "me too", also using Fusion. At first I thought it had frozen, but locally, in the VM window, everything worked fine. (I always interact with VMs via SSH to get copy/paste, better fonts etc). Also worth mentioning is that vmware-vmx ate 100% real CPU the entire time, despite the VM CPU (top in FreeBSD) showed 100% *idle*. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 11:43:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F097D106564A; Sun, 28 Jun 2009 11:43:53 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 45CDE8FC08; Sun, 28 Jun 2009 11:43:53 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-162-173.lns11.adl2.internode.on.net [121.45.162.173]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n5SBhpJg023919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 28 Jun 2009 21:13:51 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Aisaka Taiga Date: Sun, 28 Jun 2009 21:13:24 +0930 User-Agent: KMail/1.9.10 References: <4A4517BE.9040504@FreeBSD.org> <200906282038.58968.doconnor@gsoft.com.au> <4A4752EF.8030101@haruhiism.net> In-Reply-To: <4A4752EF.8030101@haruhiism.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1489171.a3BTac4nG2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906282113.42967.doconnor@gsoft.com.au> X-Spam-Score: -1.331 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Alexander Motin , freebsd-current@freebsd.org, scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 11:43:54 -0000 --nextPart1489171.a3BTac4nG2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 28 Jun 2009, Aisaka Taiga wrote: > > 'create' is the manual method which won't store any metadata - > > 'label' stores it in the last sector of the provider. > > I might be mistaken here as I tried that in May, when I upgraded my > production server to 7.2; I probably tried using the 'label' > subcommand or it wouldn't show up on boot, right? (There was a > mistype in my earlier message; should be "label for provider ad0s1b > is label/swap", not "ad0s1a".) I guess I'll find out tomorrow when I reboot my laptop and see what=20 happens. However, given that it works for Louis you might want to reconsider it. > > The other alternative is to > > use /dev/ufsid/xxx which won't require a newfs as your existing > > FS's have an ID already (presuming you are using GENERIC). > > The problem with ufsids is that unlike a manually set label, you > can't really distinguish between them (as opposed to the default > scheme of sXY where for a boot device you can be almost 80% certain > that ad0s1a is /, f is /usr, etc etc - especially if the default > number of partitions was created). The UFSID is unique for a given newfs (mostly - it is the timestamp I=20 believe). =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1489171.a3BTac4nG2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKR1du5ZPcIHs/zowRAsYjAJ9qTHNp57xsolsbjHjVLlqqyUgYkACfSq/o aHCIbh5N9IfvYVZavjyoh+M= =7/27 -----END PGP SIGNATURE----- --nextPart1489171.a3BTac4nG2-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 11:54:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAEC11065670; Sun, 28 Jun 2009 11:54:52 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 60B808FC1C; Sun, 28 Jun 2009 11:54:52 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 8527D78F98; Sun, 28 Jun 2009 15:54:50 +0400 (MSD) Message-ID: <4A475A16.4000108@haruhiism.net> Date: Sun, 28 Jun 2009 15:55:02 +0400 From: Aisaka Taiga User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Daniel O'Connor References: <4A4517BE.9040504@FreeBSD.org> <200906282038.58968.doconnor@gsoft.com.au> <4A4752EF.8030101@haruhiism.net> <200906282113.42967.doconnor@gsoft.com.au> In-Reply-To: <200906282113.42967.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org, scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 11:54:52 -0000 Hello, hope you're having a nice day, Daniel O'Connor wrote: > The UFSID is unique for a given newfs (mostly - it is the timestamp I > believe). > > It is unique; however, I'm not talking about it being unique. More like from a console standpoint. Imagine your system's asking for manual input for the root partition; what's easier to type - /dev/ufs/root, /dev/ufsid/{inserthugenumberinhexhere} or /dev/physical-device? Reading through /etc/fstab when it uses ufsids is a pain as well. By the way, in my opinion the current freebsd install system should allow running GEOM commands before partitioning/labelling devices. And should also recognize GEOM devices, as well, since for a clean install the transition to labels & gmirror is either 'not safe' (kern.geom.debugflags=16, then label the live system's drive) OR requires a dump/restore (label the 2nd drive, label the partitions, then copy data there, reboot to the 2nd drive, add the first to the mirror). P.S. Also, bsdlabel and glabel seem like ambiguous names (as well as using the term 'label' for both slice layout and GEOM labels) - so I see no problems naming AHCI devices "daX". ;) -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 11:55:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B391106566C; Sun, 28 Jun 2009 11:55:02 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id B09F88FC20; Sun, 28 Jun 2009 11:55:00 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id AE7AA78FA3; Sun, 28 Jun 2009 15:54:59 +0400 (MSD) Message-ID: <4A475A1F.1060805@haruhiism.net> Date: Sun, 28 Jun 2009 15:55:11 +0400 From: Aisaka Taiga User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Daniel O'Connor References: <4A4517BE.9040504@FreeBSD.org> <200906282038.58968.doconnor@gsoft.com.au> <4A4752EF.8030101@haruhiism.net> <200906282113.42967.doconnor@gsoft.com.au> In-Reply-To: <200906282113.42967.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Motin , freebsd-current@freebsd.org, scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 11:55:06 -0000 Hello, hope you're having a nice day, Daniel O'Connor wrote: > The UFSID is unique for a given newfs (mostly - it is the timestamp I > believe). > > It is unique; however, I'm not talking about it being unique. More like from a console standpoint. Imagine your system's asking for manual input for the root partition; what's easier to type - /dev/ufs/root, /dev/ufsid/{inserthugenumberinhexhere} or /dev/physical-device? Reading through /etc/fstab when it uses ufsids is a pain as well. By the way, in my opinion the current freebsd install system should allow running GEOM commands before partitioning/labelling devices. And should also recognize GEOM devices, as well, since for a clean install the transition to labels & gmirror is either 'not safe' (kern.geom.debugflags=16, then label the live system's drive) OR requires a dump/restore (label the 2nd drive, label the partitions, then copy data there, reboot to the 2nd drive, add the first to the mirror). P.S. Also, bsdlabel and glabel seem like ambiguous names (as well as using the term 'label' for both slice layout and GEOM labels) - so I see no problems naming AHCI devices "daX". ;) -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 12:29:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E503D106564A for ; Sun, 28 Jun 2009 12:29:27 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id E43D68FC18 for ; Sun, 28 Jun 2009 12:29:24 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,303,1243807200"; d="txt'?scan'208";a="6985061" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 28 Jun 2009 14:29:23 +0200 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id 8C7E11B07BA; Sun, 28 Jun 2009 14:29:23 +0200 (CEST) Date: Sun, 28 Jun 2009 14:29:11 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=+permail-2009062812291180e26a0b00000f15-a_best01+ Cc: Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 12:29:28 -0000 This is a MIME encoded multipart message. --+permail-2009062812291180e26a0b00000f15-a_best01+ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit after applying the patchset i cannot recompile my kernel. i've rebuild and reinstalled world after applying the patches. probably a kernelconf option is coliding with the ahci device. could somebody take a look at this and tell me what options i need to remove from my kernelconf? cheers --+permail-2009062812291180e26a0b00000f15-a_best01+ Content-Type: text/plain Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="build.txt" Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tCj4+PiBLZXJuZWwgYnVpbGQgZm9yIEFSVU5ERUwgc3RhcnRlZCBvbiBTdW4gSnVuIDI4 IDE0OjE5OjUxIENFU1QgMjAwOQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo9PT0+IEFSVU5ERUwKbWtkaXIgLXAgL3Vzci9vYmov dXNyL3NyYy9zeXMKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCj4+PiBzdGFnZSAxOiBjb25maWd1cmluZyB0aGUga2VybmVsCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCmNkIC91c3Ivc3JjL3N5cy9pMzg2L2NvbmY7ICBQQVRIPS91c3Ivb2JqL3Vzci9zcmMvdG1w L2xlZ2FjeS91c3Ivc2JpbjovdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2JpbjovdXNy L29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2dhbWVzOi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vz ci9zYmluOi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9iaW46L3Vzci9vYmovdXNyL3NyYy90bXAv dXNyL2dhbWVzOi9zYmluOi9iaW46L3Vzci9zYmluOi91c3IvYmluICBjb25maWcgIC1kIC91c3Iv b2JqL3Vzci9zcmMvc3lzL0FSVU5ERUwgIC91c3Ivc3JjL3N5cy9pMzg2L2NvbmYvQVJVTkRFTApX QVJOSU5HOiBkdXBsaWNhdGUgb3B0aW9uIGBHRU9NX1BBUlRfTUJSJyBlbmNvdW50ZXJlZC4KS2Vy bmVsIGJ1aWxkIGRpcmVjdG9yeSBpcyAvdXNyL29iai91c3Ivc3JjL3N5cy9BUlVOREVMCkRvbid0 IGZvcmdldCB0byBkbyBgYG1ha2UgY2xlYW5kZXBlbmQgJiYgbWFrZSBkZXBlbmQnJwoKLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K Pj4+IHN0YWdlIDIuMTogY2xlYW5pbmcgdXAgdGhlIG9iamVjdCB0cmVlCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmNkIC91c3Iv b2JqL3Vzci9zcmMvc3lzL0FSVU5ERUw7IE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmogIE1BQ0hJ TkVfQVJDSD1pMzg2ICBNQUNISU5FPWkzODYgIENQVVRZUEU9bmF0aXZlICBHUk9GRl9CSU5fUEFU SD0vdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2JpbiAgR1JPRkZfRk9OVF9QQVRIPS91 c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9udCAgR1JPRkZfVE1B Q19QQVRIPS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvdG1hYyAgX1NITElC RElSUFJFRklYPS91c3Ivb2JqL3Vzci9zcmMvdG1wICBWRVJTSU9OPSJGcmVlQlNEIDguMC1DVVJS RU5UIGkzODYgODAwMTAwIiAgSU5TVEFMTD0ic2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCIg IFBBVEg9L3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zYmluOi91c3Ivb2JqL3Vzci9z cmMvdG1wL2xlZ2FjeS91c3IvYmluOi91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvZ2Ft ZXM6L3Vzci9vYmovdXNyL3NyYy90bXAvdXNyL3NiaW46L3Vzci9vYmovdXNyL3NyYy90bXAvdXNy L2JpbjovdXNyL29iai91c3Ivc3JjL3RtcC91c3IvZ2FtZXM6L3NiaW46L2JpbjovdXNyL3NiaW46 L3Vzci9iaW4gTk9fQ1RGPTEgL3Vzci9vYmovdXNyL3NyYy9tYWtlLmkzODYvbWFrZSBLRVJORUw9 a2VybmVsIGNsZWFuZGlyCnJtIC1mICoubyAqLnNvICouU28gKi5rbyAqLnMgZWRkZXAgZXJycyAg a2VybmVsLmRlYnVnIGtlcm5lbCBrZXJuZWwuc3ltYm9scyAgbGludGVycnMgbWFrZWxpbmtzIHRh Z3MgdmVycy5jICB2bm9kZV9pZi5jIHZub2RlX2lmLmggdm5vZGVfaWZfbmV3cHJvdG8uaCB2bm9k ZV9pZl90eXBlZGVmLmggIGF0YV9pZi5jIGVpc2FfaWYuYyBtbWNicl9pZi5jIG1tY2J1c19pZi5j IGNhcmRfaWYuYyBwb3dlcl9pZi5jIHBjaV9pZi5jIHBjaWJfaWYuYyBhYzk3X2lmLmMgY2hhbm5l bF9pZi5jIGZlZWRlcl9pZi5jIG1peGVyX2lmLmMgbXB1X2lmLmMgbXB1Zm9pX2lmLmMgc3ludGhf aWYuYyB1c2JfaWYuYyBnX3BhcnRfaWYuYyBpc2FfaWYuYyBidXNfaWYuYyBjbG9ja19pZi5jIGNw dWZyZXFfaWYuYyBkZXZpY2VfaWYuYyBsaW5rZXJfaWYuYyBzZXJkZXZfaWYuYyBpY29udl9jb252 ZXJ0ZXJfaWYuYyBhY3BpX2lmLmMgYWNwaV93bWlfaWYuYyBhdGFfaWYuaCBlaXNhX2lmLmggbW1j YnJfaWYuaCBtbWNidXNfaWYuaCBjYXJkX2lmLmggcG93ZXJfaWYuaCBwY2lfaWYuaCBwY2liX2lm LmggYWM5N19pZi5oIGNoYW5uZWxfaWYuaCBmZWVkZXJfaWYuaCBtaXhlcl9pZi5oIG1wdV9pZi5o IG1wdWZvaV9pZi5oIHN5bnRoX2lmLmggdXNiX2lmLmggZ19wYXJ0X2lmLmggaXNhX2lmLmggYnVz X2lmLmggY2xvY2tfaWYuaCBjcHVmcmVxX2lmLmggZGV2aWNlX2lmLmggbGlua2VyX2lmLmggc2Vy ZGV2X2lmLmggaWNvbnZfY29udmVydGVyX2lmLmggYWNwaV9pZi5oIGFjcGlfd21pX2lmLmggIGZl ZWRlcl9lcV9nZW4uaCBmZWVkZXJfcmF0ZV9nZW4uaCBzbmRfZnhkaXZfZ2VuLmggcGNjYXJkZGV2 cy5oICB0ZWtlbl9zdGF0ZS5oIHVzYmRldnMuaCB1c2JkZXZzX2RhdGEuaCBsaW51eF9nZW5hc3N5 bS5vICBsaW51eF9hc3N5bS5oIHVrYmRtYXAuaApybSAtZiAuZGVwZW5kIG1hY2hpbmUKY2QgL3Vz ci9zcmMvc3lzL21vZHVsZXM7IE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmovdXNyL3NyYy9zeXMv QVJVTkRFTC9tb2R1bGVzIEtNT0RESVI9L2Jvb3Qva2VybmVsIE1PRFVMRVNfT1ZFUlJJREU9ImFj cGkvYWNwaSBhY3BpL2FjcGlfdmlkZW8gbmV0Z3JhcGgvbmV0Z3JhcGggIG5ldGdyYXBoL3NvY2tl dCBuZXRncmFwaC9ibHVldG9vdGgvYmx1ZXRvb3RoIG5ldGdyYXBoL2JsdWV0b290aC9oY2kgIG5l dGdyYXBoL2JsdWV0b290aC9sMmNhcCBuZXRncmFwaC9ibHVldG9vdGgvc29ja2V0IG5ldGdyYXBo L2JsdWV0b290aC91YnQiIERFQlVHX0ZMQUdTPSItZyIgTUFDSElORT1pMzg2IEtFUk5CVUlMRERJ Uj0iL3Vzci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTCIgU1lTRElSPSIvdXNyL3NyYy9zeXMiIC91 c3Ivb2JqL3Vzci9zcmMvbWFrZS5pMzg2L21ha2UgIGNsZWFuZGlyCj09PT4gYWNwaS9hY3BpIChj bGVhbmRpcikKPT09PiBhY3BpL2FjcGlfdmlkZW8gKGNsZWFuZGlyKQo9PT0+IG5ldGdyYXBoL25l dGdyYXBoIChjbGVhbmRpcikKPT09PiBuZXRncmFwaC9zb2NrZXQgKGNsZWFuZGlyKQo9PT0+IG5l dGdyYXBoL2JsdWV0b290aC9ibHVldG9vdGggKGNsZWFuZGlyKQo9PT0+IG5ldGdyYXBoL2JsdWV0 b290aC9oY2kgKGNsZWFuZGlyKQo9PT0+IG5ldGdyYXBoL2JsdWV0b290aC9sMmNhcCAoY2xlYW5k aXIpCj09PT4gbmV0Z3JhcGgvYmx1ZXRvb3RoL3NvY2tldCAoY2xlYW5kaXIpCj09PT4gbmV0Z3Jh cGgvYmx1ZXRvb3RoL3VidCAoY2xlYW5kaXIpCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Pj4gc3RhZ2UgMi4yOiByZWJ1aWxk aW5nIHRoZSBvYmplY3QgdHJlZQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpjZCAvdXNyL29iai91c3Ivc3JjL3N5cy9BUlVOREVM OyBNQUtFT0JKRElSUFJFRklYPS91c3Ivb2JqICBNQUNISU5FX0FSQ0g9aTM4NiAgTUFDSElORT1p Mzg2ICBDUFVUWVBFPW5hdGl2ZSAgR1JPRkZfQklOX1BBVEg9L3Vzci9vYmovdXNyL3NyYy90bXAv bGVnYWN5L3Vzci9iaW4gIEdST0ZGX0ZPTlRfUEFUSD0vdXNyL29iai91c3Ivc3JjL3RtcC9sZWdh Y3kvdXNyL3NoYXJlL2dyb2ZmX2ZvbnQgIEdST0ZGX1RNQUNfUEFUSD0vdXNyL29iai91c3Ivc3Jj L3RtcC9sZWdhY3kvdXNyL3NoYXJlL3RtYWMgIF9TSExJQkRJUlBSRUZJWD0vdXNyL29iai91c3Iv c3JjL3RtcCAgVkVSU0lPTj0iRnJlZUJTRCA4LjAtQ1VSUkVOVCBpMzg2IDgwMDEwMCIgIElOU1RB TEw9InNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2giICBQQVRIPS91c3Ivb2JqL3Vzci9zcmMv dG1wL2xlZ2FjeS91c3Ivc2JpbjovdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2Jpbjov dXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2dhbWVzOi91c3Ivb2JqL3Vzci9zcmMvdG1w L3Vzci9zYmluOi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9iaW46L3Vzci9vYmovdXNyL3NyYy90 bXAvdXNyL2dhbWVzOi9zYmluOi9iaW46L3Vzci9zYmluOi91c3IvYmluIE5PX0NURj0xIC91c3Iv b2JqL3Vzci9zcmMvbWFrZS5pMzg2L21ha2UgS0VSTkVMPWtlcm5lbCBvYmoKY2QgL3Vzci9zcmMv c3lzL21vZHVsZXM7IE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmovdXNyL3NyYy9zeXMvQVJVTkRF TC9tb2R1bGVzIEtNT0RESVI9L2Jvb3Qva2VybmVsIE1PRFVMRVNfT1ZFUlJJREU9ImFjcGkvYWNw aSBhY3BpL2FjcGlfdmlkZW8gbmV0Z3JhcGgvbmV0Z3JhcGggIG5ldGdyYXBoL3NvY2tldCBuZXRn cmFwaC9ibHVldG9vdGgvYmx1ZXRvb3RoIG5ldGdyYXBoL2JsdWV0b290aC9oY2kgIG5ldGdyYXBo L2JsdWV0b290aC9sMmNhcCBuZXRncmFwaC9ibHVldG9vdGgvc29ja2V0IG5ldGdyYXBoL2JsdWV0 b290aC91YnQiIERFQlVHX0ZMQUdTPSItZyIgTUFDSElORT1pMzg2IEtFUk5CVUlMRERJUj0iL3Vz ci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTCIgU1lTRElSPSIvdXNyL3NyYy9zeXMiIC91c3Ivb2Jq L3Vzci9zcmMvbWFrZS5pMzg2L21ha2UgIG9iago9PT0+IGFjcGkvYWNwaSAob2JqKQovdXNyL29i ai91c3Ivc3JjL3N5cy9BUlVOREVML21vZHVsZXMvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2Fj cGkgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpCj09PT4gYWNwaS9h Y3BpX3ZpZGVvIChvYmopCi91c3Ivb2JqL3Vzci9zcmMvc3lzL0FSVU5ERUwvbW9kdWxlcy91c3Iv c3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaV92aWRlbyBjcmVhdGVkIGZvciAvdXNyL3NyYy9zeXMv bW9kdWxlcy9hY3BpL2FjcGlfdmlkZW8KPT09PiBuZXRncmFwaC9uZXRncmFwaCAob2JqKQovdXNy L29iai91c3Ivc3JjL3N5cy9BUlVOREVML21vZHVsZXMvdXNyL3NyYy9zeXMvbW9kdWxlcy9uZXRn cmFwaC9uZXRncmFwaCBjcmVhdGVkIGZvciAvdXNyL3NyYy9zeXMvbW9kdWxlcy9uZXRncmFwaC9u ZXRncmFwaAo9PT0+IG5ldGdyYXBoL3NvY2tldCAob2JqKQovdXNyL29iai91c3Ivc3JjL3N5cy9B UlVOREVML21vZHVsZXMvdXNyL3NyYy9zeXMvbW9kdWxlcy9uZXRncmFwaC9zb2NrZXQgY3JlYXRl ZCBmb3IgL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvc29ja2V0Cj09PT4gbmV0Z3JhcGgv Ymx1ZXRvb3RoL2JsdWV0b290aCAob2JqKQovdXNyL29iai91c3Ivc3JjL3N5cy9BUlVOREVML21v ZHVsZXMvdXNyL3NyYy9zeXMvbW9kdWxlcy9uZXRncmFwaC9ibHVldG9vdGgvYmx1ZXRvb3RoIGNy ZWF0ZWQgZm9yIC91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL2JsdWV0b290aC9ibHVldG9v dGgKPT09PiBuZXRncmFwaC9ibHVldG9vdGgvaGNpIChvYmopCi91c3Ivb2JqL3Vzci9zcmMvc3lz L0FSVU5ERUwvbW9kdWxlcy91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL2JsdWV0b290aC9o Y2kgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL2hj aQo9PT0+IG5ldGdyYXBoL2JsdWV0b290aC9sMmNhcCAob2JqKQovdXNyL29iai91c3Ivc3JjL3N5 cy9BUlVOREVML21vZHVsZXMvdXNyL3NyYy9zeXMvbW9kdWxlcy9uZXRncmFwaC9ibHVldG9vdGgv bDJjYXAgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3Ro L2wyY2FwCj09PT4gbmV0Z3JhcGgvYmx1ZXRvb3RoL3NvY2tldCAob2JqKQovdXNyL29iai91c3Iv c3JjL3N5cy9BUlVOREVML21vZHVsZXMvdXNyL3NyYy9zeXMvbW9kdWxlcy9uZXRncmFwaC9ibHVl dG9vdGgvc29ja2V0IGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL2Js dWV0b290aC9zb2NrZXQKPT09PiBuZXRncmFwaC9ibHVldG9vdGgvdWJ0IChvYmopCi91c3Ivb2Jq L3Vzci9zcmMvc3lzL0FSVU5ERUwvbW9kdWxlcy91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBo L2JsdWV0b290aC91YnQgY3JlYXRlZCBmb3IgL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgv Ymx1ZXRvb3RoL3VidAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0KPj4+IHN0YWdlIDIuMzogYnVpbGQgdG9vbHMKLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KY2Qg L3Vzci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTDsgIE1BS0VTUkNQQVRIPS91c3Ivc3JjL3N5cy9k ZXYvYWljN3h4eC9haWNhc20gIC91c3Ivb2JqL3Vzci9zcmMvbWFrZS5pMzg2L21ha2UgU1NQX0NG TEFHUz0gLUROT19DUFVfQ0ZMQUdTIC1ETk9fQ1RGICAtZiAvdXNyL3NyYy9zeXMvZGV2L2FpYzd4 eHgvYWljYXNtL01ha2VmaWxlCldhcm5pbmc6IE9iamVjdCBkaXJlY3Rvcnkgbm90IGNoYW5nZWQg ZnJvbSBvcmlnaW5hbCAvdXNyL29iai91c3Ivc3JjL3N5cy9BUlVOREVMCmNjIC1PMiAtZm5vLXN0 cmljdC1hbGlhc2luZyAtcGlwZSAtbm9zdGRpbmMgLUkvdXNyL2luY2x1ZGUgLUkuIC1JL3Vzci9z cmMvc3lzL2Rldi9haWM3eHh4L2FpY2FzbSAtc3RkPWdudTk5ICAtV3N5c3RlbS1oZWFkZXJzIC1X ZXJyb3IgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0 cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV3Jl dHVybi10eXBlIC1XY2FzdC1xdWFsIC1Xd3JpdGUtc3RyaW5ncyAtV3N3aXRjaCAtV3NoYWRvdyAt V2Nhc3QtYWxpZ24gLVd1bnVzZWQtcGFyYW1ldGVyIC1XY2hhci1zdWJzY3JpcHRzIC1XaW5saW5l IC1XbmVzdGVkLWV4dGVybnMgLVdyZWR1bmRhbnQtZGVjbHMgLVduby1wb2ludGVyLXNpZ24gLWMg L3Vzci9zcmMvc3lzL2Rldi9haWM3eHh4L2FpY2FzbS9haWNhc20uYwpjYyAtTzIgLWZuby1zdHJp Y3QtYWxpYXNpbmcgLXBpcGUgLW5vc3RkaW5jIC1JL3Vzci9pbmNsdWRlIC1JLiAtSS91c3Ivc3Jj L3N5cy9kZXYvYWljN3h4eC9haWNhc20gLXN0ZD1nbnU5OSAgLVdzeXN0ZW0taGVhZGVycyAtV2Vy cm9yIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJp Y3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVdyZXR1 cm4tdHlwZSAtV2Nhc3QtcXVhbCAtV3dyaXRlLXN0cmluZ3MgLVdzd2l0Y2ggLVdzaGFkb3cgLVdj YXN0LWFsaWduIC1XdW51c2VkLXBhcmFtZXRlciAtV2NoYXItc3Vic2NyaXB0cyAtV2lubGluZSAt V25lc3RlZC1leHRlcm5zIC1XcmVkdW5kYW50LWRlY2xzIC1Xbm8tcG9pbnRlci1zaWduIC1jIC91 c3Ivc3JjL3N5cy9kZXYvYWljN3h4eC9haWNhc20vYWljYXNtX3N5bWJvbC5jCmNjIC1PMiAtZm5v LXN0cmljdC1hbGlhc2luZyAtcGlwZSAtbm9zdGRpbmMgLUkvdXNyL2luY2x1ZGUgLUkuIC1JL3Vz ci9zcmMvc3lzL2Rldi9haWM3eHh4L2FpY2FzbSAtc3RkPWdudTk5ICAtV3N5c3RlbS1oZWFkZXJz IC1XZXJyb3IgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAt V3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAt V3JldHVybi10eXBlIC1XY2FzdC1xdWFsIC1Xd3JpdGUtc3RyaW5ncyAtV3N3aXRjaCAtV3NoYWRv dyAtV2Nhc3QtYWxpZ24gLVd1bnVzZWQtcGFyYW1ldGVyIC1XY2hhci1zdWJzY3JpcHRzIC1XaW5s aW5lIC1XbmVzdGVkLWV4dGVybnMgLVdyZWR1bmRhbnQtZGVjbHMgLVduby1wb2ludGVyLXNpZ24g LWMgYWljYXNtX2dyYW0uYwpjYyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLW5vc3Rk aW5jIC1JL3Vzci9pbmNsdWRlIC1JLiAtSS91c3Ivc3JjL3N5cy9kZXYvYWljN3h4eC9haWNhc20g LXN0ZD1nbnU5OSAgLVdzeXN0ZW0taGVhZGVycyAtV2Vycm9yIC1XYWxsIC1Xbm8tZm9ybWF0LXky ayAtVyAtV25vLXVudXNlZC1wYXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3Npbmct cHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVdyZXR1cm4tdHlwZSAtV2Nhc3QtcXVhbCAtV3dy aXRlLXN0cmluZ3MgLVdzd2l0Y2ggLVdzaGFkb3cgLVdjYXN0LWFsaWduIC1XdW51c2VkLXBhcmFt ZXRlciAtV2NoYXItc3Vic2NyaXB0cyAtV2lubGluZSAtV25lc3RlZC1leHRlcm5zIC1XcmVkdW5k YW50LWRlY2xzIC1Xbm8tcG9pbnRlci1zaWduIC1jIGFpY2FzbV9tYWNyb19ncmFtLmMKY2MgLU8y IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1waXBlIC1ub3N0ZGluYyAtSS91c3IvaW5jbHVkZSAtSS4g LUkvdXNyL3NyYy9zeXMvZGV2L2FpYzd4eHgvYWljYXNtIC1zdGQ9Z251OTkgIC1Xc3lzdGVtLWhl YWRlcnMgLVdlcnJvciAtV2FsbCAtV25vLWZvcm1hdC15MmsgLVcgLVduby11bnVzZWQtcGFyYW1l dGVyIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFy aXRoIC1XcmV0dXJuLXR5cGUgLVdjYXN0LXF1YWwgLVd3cml0ZS1zdHJpbmdzIC1Xc3dpdGNoIC1X c2hhZG93IC1XY2FzdC1hbGlnbiAtV3VudXNlZC1wYXJhbWV0ZXIgLVdjaGFyLXN1YnNjcmlwdHMg LVdpbmxpbmUgLVduZXN0ZWQtZXh0ZXJucyAtV3JlZHVuZGFudC1kZWNscyAtV25vLXBvaW50ZXIt c2lnbiAtYyBhaWNhc21fc2Nhbi5jCmNjIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAt bm9zdGRpbmMgLUkvdXNyL2luY2x1ZGUgLUkuIC1JL3Vzci9zcmMvc3lzL2Rldi9haWM3eHh4L2Fp Y2FzbSAtc3RkPWdudTk5ICAtV3N5c3RlbS1oZWFkZXJzIC1XZXJyb3IgLVdhbGwgLVduby1mb3Jt YXQteTJrIC1XIC1Xbm8tdW51c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlz c2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV3JldHVybi10eXBlIC1XY2FzdC1xdWFs IC1Xd3JpdGUtc3RyaW5ncyAtV3N3aXRjaCAtV3NoYWRvdyAtV2Nhc3QtYWxpZ24gLVd1bnVzZWQt cGFyYW1ldGVyIC1XY2hhci1zdWJzY3JpcHRzIC1XaW5saW5lIC1XbmVzdGVkLWV4dGVybnMgLVdy ZWR1bmRhbnQtZGVjbHMgLVduby1wb2ludGVyLXNpZ24gLWMgYWljYXNtX21hY3JvX3NjYW4uYwpj YyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLW5vc3RkaW5jIC1JL3Vzci9pbmNsdWRl IC1JLiAtSS91c3Ivc3JjL3N5cy9kZXYvYWljN3h4eC9haWNhc20gLXN0ZD1nbnU5OSAgLVdzeXN0 ZW0taGVhZGVycyAtV2Vycm9yIC1XYWxsIC1Xbm8tZm9ybWF0LXkyayAtVyAtV25vLXVudXNlZC1w YXJhbWV0ZXIgLVdzdHJpY3QtcHJvdG90eXBlcyAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50 ZXItYXJpdGggLVdyZXR1cm4tdHlwZSAtV2Nhc3QtcXVhbCAtV3dyaXRlLXN0cmluZ3MgLVdzd2l0 Y2ggLVdzaGFkb3cgLVdjYXN0LWFsaWduIC1XdW51c2VkLXBhcmFtZXRlciAtV2NoYXItc3Vic2Ny aXB0cyAtV2lubGluZSAtV25lc3RlZC1leHRlcm5zIC1XcmVkdW5kYW50LWRlY2xzIC1Xbm8tcG9p bnRlci1zaWduICAtbyBhaWNhc20gYWljYXNtLm8gYWljYXNtX3N5bWJvbC5vIGFpY2FzbV9ncmFt Lm8gYWljYXNtX21hY3JvX2dyYW0ubyBhaWNhc21fc2Nhbi5vIGFpY2FzbV9tYWNyb19zY2FuLm8g LWxsCmNkIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FpYzd4eHgvYWljYXNtOyAgTUFLRU9CSkRJUlBS RUZJWD0vdXNyL29iai91c3Ivc3JjL3N5cy9BUlVOREVML21vZHVsZXMgIC91c3Ivb2JqL3Vzci9z cmMvbWFrZS5pMzg2L21ha2UgU1NQX0NGTEFHUz0gLUROT19DUFVfQ0ZMQUdTIC1ETk9fQ1RGIG9i agpjZCAvdXNyL3NyYy9zeXMvbW9kdWxlcy9haWM3eHh4L2FpY2FzbTsgIE1BS0VPQkpESVJQUkVG SVg9L3Vzci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTC9tb2R1bGVzICAvdXNyL29iai91c3Ivc3Jj L21ha2UuaTM4Ni9tYWtlIFNTUF9DRkxBR1M9IC1ETk9fQ1BVX0NGTEFHUyAtRE5PX0NURiBkZXBl bmQKY2QgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWljN3h4eC9haWNhc207ICBNQUtFT0JKRElSUFJF RklYPS91c3Ivb2JqL3Vzci9zcmMvc3lzL0FSVU5ERUwvbW9kdWxlcyAgL3Vzci9vYmovdXNyL3Ny Yy9tYWtlLmkzODYvbWFrZSBTU1BfQ0ZMQUdTPSAtRE5PX0NQVV9DRkxBR1MgLUROT19DVEYgYWxs CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQo+Pj4gc3RhZ2UgMy4xOiBtYWtpbmcgZGVwZW5kZW5jaWVzCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmNkIC91c3Iv b2JqL3Vzci9zcmMvc3lzL0FSVU5ERUw7IE1BS0VPQkpESVJQUkVGSVg9L3Vzci9vYmogIE1BQ0hJ TkVfQVJDSD1pMzg2ICBNQUNISU5FPWkzODYgIENQVVRZUEU9bmF0aXZlICBHUk9GRl9CSU5fUEFU SD0vdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2JpbiAgR1JPRkZfRk9OVF9QQVRIPS91 c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9udCAgR1JPRkZfVE1B Q19QQVRIPS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvdG1hYyAgX1NITElC RElSUFJFRklYPS91c3Ivb2JqL3Vzci9zcmMvdG1wICBWRVJTSU9OPSJGcmVlQlNEIDguMC1DVVJS RU5UIGkzODYgODAwMTAwIiAgSU5TVEFMTD0ic2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCIg IFBBVEg9L3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zYmluOi91c3Ivb2JqL3Vzci9z cmMvdG1wL2xlZ2FjeS91c3IvYmluOi91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvZ2Ft ZXM6L3Vzci9vYmovdXNyL3NyYy90bXAvdXNyL3NiaW46L3Vzci9vYmovdXNyL3NyYy90bXAvdXNy L2JpbjovdXNyL29iai91c3Ivc3JjL3RtcC91c3IvZ2FtZXM6L3NiaW46L2JpbjovdXNyL3NiaW46 L3Vzci9iaW4gTk9fQ1RGPTEgL3Vzci9vYmovdXNyL3NyYy9tYWtlLmkzODYvbWFrZSBLRVJORUw9 a2VybmVsIGRlcGVuZCAtRE5PX01PRFVMRVNfT0JKCm1hY2hpbmUgLT4gL3Vzci9zcmMvc3lzL2kz ODYvaW5jbHVkZQpjYyAtYyAtTyAtcGlwZSAtbWFyY2g9bmF0aXZlIC1zdGQ9Yzk5IC1nIC1XYWxs IC1XcmVkdW5kYW50LWRlY2xzIC1XbmVzdGVkLWV4dGVybnMgLVdzdHJpY3QtcHJvdG90eXBlcyAt V21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVdpbmxpbmUgLVdjYXN0LXF1YWwg LVd1bmRlZiAtV25vLXBvaW50ZXItc2lnbiAtZmZvcm1hdC1leHRlbnNpb25zIC1ub3N0ZGluYyAt SS4gLUkvdXNyL3NyYy9zeXMgLUkvdXNyL3NyYy9zeXMvY29udHJpYi9hbHRxIC1JL3Vzci9zcmMv c3lzL2NvbnRyaWIvaXBmaWx0ZXIgLUkvdXNyL3NyYy9zeXMvY29udHJpYi9wZiAtSS91c3Ivc3Jj L3N5cy9kZXYvYXRoIC1JL3Vzci9zcmMvc3lzL2Rldi9hdGgvYXRoX2hhbCAtSS91c3Ivc3JjL3N5 cy9jb250cmliL25nYXRtIC1JL3Vzci9zcmMvc3lzL2Rldi90d2EgLUkvdXNyL3NyYy9zeXMvZ251 L2ZzL3hmcy9GcmVlQlNEIC1JL3Vzci9zcmMvc3lzL2dudS9mcy94ZnMvRnJlZUJTRC9zdXBwb3J0 IC1JL3Vzci9zcmMvc3lzL2dudS9mcy94ZnMgLUkvdXNyL3NyYy9zeXMvY29udHJpYi9vcGVuc29s YXJpcy9jb21wYXQgLUkvdXNyL3NyYy9zeXMvZGV2L2N4Z2IgLURfS0VSTkVMIC1ESEFWRV9LRVJO RUxfT1BUSU9OX0hFQURFUlMgLWluY2x1ZGUgb3B0X2dsb2JhbC5oIC1maW5saW5lLWxpbWl0PTgw MDAgLS1wYXJhbSBpbmxpbmUtdW5pdC1ncm93dGg9MTAwIC0tcGFyYW0gbGFyZ2UtZnVuY3Rpb24t Z3Jvd3RoPTEwMDAgLW1uby1hbGlnbi1sb25nLXN0cmluZ3MgLW1wcmVmZXJyZWQtc3RhY2stYm91 bmRhcnk9MiAtbW5vLW1teCAtbW5vLTNkbm93IC1tbm8tc3NlIC1tbm8tc3NlMiAtbW5vLXNzZTMg LWZmcmVlc3RhbmRpbmcgLWZzdGFjay1wcm90ZWN0b3IgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni9n ZW5hc3N5bS5jCk5NPSdubScgc2ggL3Vzci9zcmMvc3lzL2tlcm4vZ2VuYXNzeW0uc2ggZ2VuYXNz eW0ubyA+IGFzc3ltLnMKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy92bm9kZV9pZi5hd2sgL3Vz ci9zcmMvc3lzL2tlcm4vdm5vZGVfaWYuc3JjIC1wCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMv dm5vZGVfaWYuYXdrIC91c3Ivc3JjL3N5cy9rZXJuL3Zub2RlX2lmLnNyYyAtcQphd2sgLWYgL3Vz ci9zcmMvc3lzL3Rvb2xzL3Zub2RlX2lmLmF3ayAvdXNyL3NyYy9zeXMva2Vybi92bm9kZV9pZi5z cmMgLWgKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy9zb3VuZC9mZWVkZXJfZXFfbWtmaWx0ZXIu YXdrIC0tICA+IGZlZWRlcl9lcV9nZW4uaAphd2sgLWYgL3Vzci9zcmMvc3lzL3Rvb2xzL3NvdW5k L2ZlZWRlcl9yYXRlX21rZmlsdGVyLmF3ayAtLSAgPiBmZWVkZXJfcmF0ZV9nZW4uaAphd2sgLWYg L3Vzci9zcmMvc3lzL3Rvb2xzL3NvdW5kL3NuZF9meGRpdl9nZW4uYXdrIC0tID4gc25kX2Z4ZGl2 X2dlbi5oCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvcGNjYXJkZGV2czJoLmF3ayAvdXNyL3Ny Yy9zeXMvZGV2L3BjY2FyZC9wY2NhcmRkZXZzCmF3ayAtZiAvdXNyL3NyYy9zeXMvZGV2L3N5c2Nv bnMvdGVrZW4vZ2Vuc2VxdWVuY2VzIC91c3Ivc3JjL3N5cy9kZXYvc3lzY29ucy90ZWtlbi9zZXF1 ZW5jZXMgPiB0ZWtlbl9zdGF0ZS5oCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvdXNiZGV2czJo LmF3ayAvdXNyL3NyYy9zeXMvZGV2L3VzYi91c2JkZXZzIC1oCmF3ayAtZiAvdXNyL3NyYy9zeXMv dG9vbHMvdXNiZGV2czJoLmF3ayAvdXNyL3NyYy9zeXMvZGV2L3VzYi91c2JkZXZzIC1kCmNjIC1P IC1waXBlIC1tYXJjaD1uYXRpdmUgLXN0ZD1jOTkgLWcgLVdhbGwgLVdyZWR1bmRhbnQtZGVjbHMg LVduZXN0ZWQtZXh0ZXJucyAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVz IC1XcG9pbnRlci1hcml0aCAtV2lubGluZSAtV2Nhc3QtcXVhbCAtV3VuZGVmIC1Xbm8tcG9pbnRl ci1zaWduIC1mZm9ybWF0LWV4dGVuc2lvbnMgLW5vc3RkaW5jIC1JLiAtSS91c3Ivc3JjL3N5cyAt SS91c3Ivc3JjL3N5cy9jb250cmliL2FsdHEgLUkvdXNyL3NyYy9zeXMvY29udHJpYi9pcGZpbHRl ciAtSS91c3Ivc3JjL3N5cy9jb250cmliL3BmIC1JL3Vzci9zcmMvc3lzL2Rldi9hdGggLUkvdXNy L3NyYy9zeXMvZGV2L2F0aC9hdGhfaGFsIC1JL3Vzci9zcmMvc3lzL2NvbnRyaWIvbmdhdG0gLUkv dXNyL3NyYy9zeXMvZGV2L3R3YSAtSS91c3Ivc3JjL3N5cy9nbnUvZnMveGZzL0ZyZWVCU0QgLUkv dXNyL3NyYy9zeXMvZ251L2ZzL3hmcy9GcmVlQlNEL3N1cHBvcnQgLUkvdXNyL3NyYy9zeXMvZ251 L2ZzL3hmcyAtSS91c3Ivc3JjL3N5cy9jb250cmliL29wZW5zb2xhcmlzL2NvbXBhdCAtSS91c3Iv c3JjL3N5cy9kZXYvY3hnYiAtRF9LRVJORUwgLURIQVZFX0tFUk5FTF9PUFRJT05fSEVBREVSUyAt aW5jbHVkZSBvcHRfZ2xvYmFsLmggLWZpbmxpbmUtbGltaXQ9ODAwMCAtLXBhcmFtIGlubGluZS11 bml0LWdyb3d0aD0xMDAgLS1wYXJhbSBsYXJnZS1mdW5jdGlvbi1ncm93dGg9MTAwMCAtbW5vLWFs aWduLWxvbmctc3RyaW5ncyAtbXByZWZlcnJlZC1zdGFjay1ib3VuZGFyeT0yIC1tbm8tbW14IC1t bm8tM2Rub3cgLW1uby1zc2UgLW1uby1zc2UyIC1tbm8tc3NlMyAtZmZyZWVzdGFuZGluZyAtZnN0 YWNrLXByb3RlY3RvciAtYyAvdXNyL3NyYy9zeXMvaTM4Ni9saW51eC9saW51eF9nZW5hc3N5bS5j CnNoIC91c3Ivc3JjL3N5cy9rZXJuL2dlbmFzc3ltLnNoIGxpbnV4X2dlbmFzc3ltLm8gPiBsaW51 eF9hc3N5bS5oCi91c3Ivc2Jpbi9rYmRjb250cm9sIC1MIGdlcm1hbi5pc28gfCBzZWQgLWUgJ3Mv XnN0YXRpYyBrZXltYXBfdC4qID0gL3N0YXRpYyBrZXltYXBfdCBrZXlfbWFwID0gLycgLWUgJ3Mv XnN0YXRpYyBhY2NlbnRtYXBfdC4qID0gL3N0YXRpYyBhY2NlbnRtYXBfdCBhY2NlbnRfbWFwID0g LycgPiB1a2JkbWFwLmgKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy92bm9kZV9pZi5hd2sgL3Vz ci9zcmMvc3lzL2tlcm4vdm5vZGVfaWYuc3JjIC1jCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMv bWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9hdGEvYXRhX2lmLm0gLWMKYXdrIC1mIC91 c3Ivc3JjL3N5cy90b29scy9tYWtlb2Jqb3BzLmF3ayAvdXNyL3NyYy9zeXMvZGV2L2Vpc2EvZWlz YV9pZi5tIC1jCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9z cmMvc3lzL2Rldi9tbWMvbW1jYnJfaWYubSAtYwphd2sgLWYgL3Vzci9zcmMvc3lzL3Rvb2xzL21h a2VvYmpvcHMuYXdrIC91c3Ivc3JjL3N5cy9kZXYvbW1jL21tY2J1c19pZi5tIC1jCmF3ayAtZiAv dXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9wY2NhcmQv Y2FyZF9pZi5tIC1jCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vz ci9zcmMvc3lzL2Rldi9wY2NhcmQvcG93ZXJfaWYubSAtYwphd2sgLWYgL3Vzci9zcmMvc3lzL3Rv b2xzL21ha2VvYmpvcHMuYXdrIC91c3Ivc3JjL3N5cy9kZXYvcGNpL3BjaV9pZi5tIC1jCmF3ayAt ZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9wY2kv cGNpYl9pZi5tIC1jCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vz ci9zcmMvc3lzL2Rldi9zb3VuZC9wY20vYWM5N19pZi5tIC1jCmF3ayAtZiAvdXNyL3NyYy9zeXMv dG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9zb3VuZC9wY20vY2hhbm5lbF9p Zi5tIC1jCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMv c3lzL2Rldi9zb3VuZC9wY20vZmVlZGVyX2lmLm0gLWMKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29s cy9tYWtlb2Jqb3BzLmF3ayAvdXNyL3NyYy9zeXMvZGV2L3NvdW5kL3BjbS9taXhlcl9pZi5tIC1j CmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rl di9zb3VuZC9taWRpL21wdV9pZi5tIC1jCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9i am9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9zb3VuZC9taWRpL21wdWZvaV9pZi5tIC1jCmF3ayAt ZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9zb3Vu ZC9taWRpL3N5bnRoX2lmLm0gLWMKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy9tYWtlb2Jqb3Bz LmF3ayAvdXNyL3NyYy9zeXMvZGV2L3VzYi91c2JfaWYubSAtYwphd2sgLWYgL3Vzci9zcmMvc3lz L3Rvb2xzL21ha2VvYmpvcHMuYXdrIC91c3Ivc3JjL3N5cy9nZW9tL3BhcnQvZ19wYXJ0X2lmLm0g LWMKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy9tYWtlb2Jqb3BzLmF3ayAvdXNyL3NyYy9zeXMv aXNhL2lzYV9pZi5tIC1jCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sg L3Vzci9zcmMvc3lzL2tlcm4vYnVzX2lmLm0gLWMKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy9t YWtlb2Jqb3BzLmF3ayAvdXNyL3NyYy9zeXMva2Vybi9jbG9ja19pZi5tIC1jCmF3ayAtZiAvdXNy L3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2tlcm4vY3B1ZnJlcV9p Zi5tIC1jCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMv c3lzL2tlcm4vZGV2aWNlX2lmLm0gLWMKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy9tYWtlb2Jq b3BzLmF3ayAvdXNyL3NyYy9zeXMva2Vybi9saW5rZXJfaWYubSAtYwphd2sgLWYgL3Vzci9zcmMv c3lzL3Rvb2xzL21ha2VvYmpvcHMuYXdrIC91c3Ivc3JjL3N5cy9rZXJuL3NlcmRldl9pZi5tIC1j CmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2xp Ymtlcm4vaWNvbnZfY29udmVydGVyX2lmLm0gLWMKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy9t YWtlb2Jqb3BzLmF3ayAvdXNyL3NyYy9zeXMvZGV2L2FjcGljYS9hY3BpX2lmLm0gLWMKYXdrIC1m IC91c3Ivc3JjL3N5cy90b29scy9tYWtlb2Jqb3BzLmF3ayAvdXNyL3NyYy9zeXMvZGV2L2FjcGlf c3VwcG9ydC9hY3BpX3dtaV9pZi5tIC1jCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9i am9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9hdGEvYXRhX2lmLm0gLWgKYXdrIC1mIC91c3Ivc3Jj L3N5cy90b29scy9tYWtlb2Jqb3BzLmF3ayAvdXNyL3NyYy9zeXMvZGV2L2Vpc2EvZWlzYV9pZi5t IC1oCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lz L2Rldi9tbWMvbW1jYnJfaWYubSAtaAphd2sgLWYgL3Vzci9zcmMvc3lzL3Rvb2xzL21ha2VvYmpv cHMuYXdrIC91c3Ivc3JjL3N5cy9kZXYvbW1jL21tY2J1c19pZi5tIC1oCmF3ayAtZiAvdXNyL3Ny Yy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9wY2NhcmQvY2FyZF9p Zi5tIC1oCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMv c3lzL2Rldi9wY2NhcmQvcG93ZXJfaWYubSAtaAphd2sgLWYgL3Vzci9zcmMvc3lzL3Rvb2xzL21h a2VvYmpvcHMuYXdrIC91c3Ivc3JjL3N5cy9kZXYvcGNpL3BjaV9pZi5tIC1oCmF3ayAtZiAvdXNy L3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9wY2kvcGNpYl9p Zi5tIC1oCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMv c3lzL2Rldi9zb3VuZC9wY20vYWM5N19pZi5tIC1oCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMv bWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9zb3VuZC9wY20vY2hhbm5lbF9pZi5tIC1o CmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rl di9zb3VuZC9wY20vZmVlZGVyX2lmLm0gLWgKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy9tYWtl b2Jqb3BzLmF3ayAvdXNyL3NyYy9zeXMvZGV2L3NvdW5kL3BjbS9taXhlcl9pZi5tIC1oCmF3ayAt ZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9zb3Vu ZC9taWRpL21wdV9pZi5tIC1oCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5h d2sgL3Vzci9zcmMvc3lzL2Rldi9zb3VuZC9taWRpL21wdWZvaV9pZi5tIC1oCmF3ayAtZiAvdXNy L3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2Rldi9zb3VuZC9taWRp L3N5bnRoX2lmLm0gLWgKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy9tYWtlb2Jqb3BzLmF3ayAv dXNyL3NyYy9zeXMvZGV2L3VzYi91c2JfaWYubSAtaAphd2sgLWYgL3Vzci9zcmMvc3lzL3Rvb2xz L21ha2VvYmpvcHMuYXdrIC91c3Ivc3JjL3N5cy9nZW9tL3BhcnQvZ19wYXJ0X2lmLm0gLWgKYXdr IC1mIC91c3Ivc3JjL3N5cy90b29scy9tYWtlb2Jqb3BzLmF3ayAvdXNyL3NyYy9zeXMvaXNhL2lz YV9pZi5tIC1oCmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9z cmMvc3lzL2tlcm4vYnVzX2lmLm0gLWgKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy9tYWtlb2Jq b3BzLmF3ayAvdXNyL3NyYy9zeXMva2Vybi9jbG9ja19pZi5tIC1oCmF3ayAtZiAvdXNyL3NyYy9z eXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2tlcm4vY3B1ZnJlcV9pZi5tIC1o CmF3ayAtZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2tl cm4vZGV2aWNlX2lmLm0gLWgKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy9tYWtlb2Jqb3BzLmF3 ayAvdXNyL3NyYy9zeXMva2Vybi9saW5rZXJfaWYubSAtaAphd2sgLWYgL3Vzci9zcmMvc3lzL3Rv b2xzL21ha2VvYmpvcHMuYXdrIC91c3Ivc3JjL3N5cy9rZXJuL3NlcmRldl9pZi5tIC1oCmF3ayAt ZiAvdXNyL3NyYy9zeXMvdG9vbHMvbWFrZW9iam9wcy5hd2sgL3Vzci9zcmMvc3lzL2xpYmtlcm4v aWNvbnZfY29udmVydGVyX2lmLm0gLWgKYXdrIC1mIC91c3Ivc3JjL3N5cy90b29scy9tYWtlb2Jq b3BzLmF3ayAvdXNyL3NyYy9zeXMvZGV2L2FjcGljYS9hY3BpX2lmLm0gLWgKYXdrIC1mIC91c3Iv c3JjL3N5cy90b29scy9tYWtlb2Jqb3BzLmF3ayAvdXNyL3NyYy9zeXMvZGV2L2FjcGlfc3VwcG9y dC9hY3BpX3dtaV9pZi5tIC1oCnJtIC1mIC5uZXdkZXAKL3Vzci9vYmovdXNyL3NyYy9tYWtlLmkz ODYvbWFrZSAtViBDRklMRVMgLVYgU1lTVEVNX0NGSUxFUyAtViBHRU5fQ0ZJTEVTIHwgIE1LREVQ X0NQUD0iY2MgLUUiIENDPSJjYyIgeGFyZ3MgbWtkZXAgLWEgLWYgLm5ld2RlcCAtTyAtcGlwZSAt bWFyY2g9bmF0aXZlIC1zdGQ9Yzk5IC1nIC1XYWxsIC1XcmVkdW5kYW50LWRlY2xzIC1XbmVzdGVk LWV4dGVybnMgLVdzdHJpY3QtcHJvdG90eXBlcyAgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2lu dGVyLWFyaXRoIC1XaW5saW5lIC1XY2FzdC1xdWFsICAtV3VuZGVmIC1Xbm8tcG9pbnRlci1zaWdu IC1mZm9ybWF0LWV4dGVuc2lvbnMgLW5vc3RkaW5jICAtSS4gLUkvdXNyL3NyYy9zeXMgLUkvdXNy L3NyYy9zeXMvY29udHJpYi9hbHRxIC1JL3Vzci9zcmMvc3lzL2NvbnRyaWIvaXBmaWx0ZXIgLUkv dXNyL3NyYy9zeXMvY29udHJpYi9wZiAtSS91c3Ivc3JjL3N5cy9kZXYvYXRoIC1JL3Vzci9zcmMv c3lzL2Rldi9hdGgvYXRoX2hhbCAtSS91c3Ivc3JjL3N5cy9jb250cmliL25nYXRtIC1JL3Vzci9z cmMvc3lzL2Rldi90d2EgLUkvdXNyL3NyYy9zeXMvZ251L2ZzL3hmcy9GcmVlQlNEIC1JL3Vzci9z cmMvc3lzL2dudS9mcy94ZnMvRnJlZUJTRC9zdXBwb3J0IC1JL3Vzci9zcmMvc3lzL2dudS9mcy94 ZnMgLUkvdXNyL3NyYy9zeXMvY29udHJpYi9vcGVuc29sYXJpcy9jb21wYXQgLUkvdXNyL3NyYy9z eXMvZGV2L2N4Z2IgLURfS0VSTkVMIC1ESEFWRV9LRVJORUxfT1BUSU9OX0hFQURFUlMgLWluY2x1 ZGUgb3B0X2dsb2JhbC5oIC1mbm8tY29tbW9uIC1maW5saW5lLWxpbWl0PTgwMDAgLS1wYXJhbSBp bmxpbmUtdW5pdC1ncm93dGg9MTAwIC0tcGFyYW0gbGFyZ2UtZnVuY3Rpb24tZ3Jvd3RoPTEwMDAg IC1tbm8tYWxpZ24tbG9uZy1zdHJpbmdzIC1tcHJlZmVycmVkLXN0YWNrLWJvdW5kYXJ5PTIgIC1t bm8tbW14IC1tbm8tM2Rub3cgLW1uby1zc2UgLW1uby1zc2UyIC1tbm8tc3NlMyAtZmZyZWVzdGFu ZGluZyAtZnN0YWNrLXByb3RlY3RvcgovdXNyL29iai91c3Ivc3JjL21ha2UuaTM4Ni9tYWtlIC1W IFNGSUxFUyB8ICBNS0RFUF9DUFA9ImNjIC1FIiB4YXJncyBta2RlcCAtYSAtZiAubmV3ZGVwIC14 IGFzc2VtYmxlci13aXRoLWNwcCAtRExPQ09SRSAtTyAtcGlwZSAtbWFyY2g9bmF0aXZlIC1zdGQ9 Yzk5IC1nIC1XYWxsIC1XcmVkdW5kYW50LWRlY2xzIC1XbmVzdGVkLWV4dGVybnMgLVdzdHJpY3Qt cHJvdG90eXBlcyAgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVyLWFyaXRoIC1XaW5saW5l IC1XY2FzdC1xdWFsICAtV3VuZGVmIC1Xbm8tcG9pbnRlci1zaWduIC1mZm9ybWF0LWV4dGVuc2lv bnMgLW5vc3RkaW5jICAtSS4gLUkvdXNyL3NyYy9zeXMgLUkvdXNyL3NyYy9zeXMvY29udHJpYi9h bHRxIC1JL3Vzci9zcmMvc3lzL2NvbnRyaWIvaXBmaWx0ZXIgLUkvdXNyL3NyYy9zeXMvY29udHJp Yi9wZiAtSS91c3Ivc3JjL3N5cy9kZXYvYXRoIC1JL3Vzci9zcmMvc3lzL2Rldi9hdGgvYXRoX2hh bCAtSS91c3Ivc3JjL3N5cy9jb250cmliL25nYXRtIC1JL3Vzci9zcmMvc3lzL2Rldi90d2EgLUkv dXNyL3NyYy9zeXMvZ251L2ZzL3hmcy9GcmVlQlNEIC1JL3Vzci9zcmMvc3lzL2dudS9mcy94ZnMv RnJlZUJTRC9zdXBwb3J0IC1JL3Vzci9zcmMvc3lzL2dudS9mcy94ZnMgLUkvdXNyL3NyYy9zeXMv Y29udHJpYi9vcGVuc29sYXJpcy9jb21wYXQgLUkvdXNyL3NyYy9zeXMvZGV2L2N4Z2IgLURfS0VS TkVMIC1ESEFWRV9LRVJORUxfT1BUSU9OX0hFQURFUlMgLWluY2x1ZGUgb3B0X2dsb2JhbC5oIC1m bm8tY29tbW9uIC1maW5saW5lLWxpbWl0PTgwMDAgLS1wYXJhbSBpbmxpbmUtdW5pdC1ncm93dGg9 MTAwIC0tcGFyYW0gbGFyZ2UtZnVuY3Rpb24tZ3Jvd3RoPTEwMDAgIC1tbm8tYWxpZ24tbG9uZy1z dHJpbmdzIC1tcHJlZmVycmVkLXN0YWNrLWJvdW5kYXJ5PTIgIC1tbm8tbW14IC1tbm8tM2Rub3cg LW1uby1zc2UgLW1uby1zc2UyIC1tbm8tc3NlMyAtZmZyZWVzdGFuZGluZyAtZnN0YWNrLXByb3Rl Y3RvcgpybSAtZiAuZGVwZW5kCm12IC5uZXdkZXAgLmRlcGVuZApjZCAvdXNyL3NyYy9zeXMvbW9k dWxlczsgTUFLRU9CSkRJUlBSRUZJWD0vdXNyL29iai91c3Ivc3JjL3N5cy9BUlVOREVML21vZHVs ZXMgS01PRERJUj0vYm9vdC9rZXJuZWwgTU9EVUxFU19PVkVSUklERT0iYWNwaS9hY3BpIGFjcGkv YWNwaV92aWRlbyBuZXRncmFwaC9uZXRncmFwaCAgbmV0Z3JhcGgvc29ja2V0IG5ldGdyYXBoL2Js dWV0b290aC9ibHVldG9vdGggbmV0Z3JhcGgvYmx1ZXRvb3RoL2hjaSAgbmV0Z3JhcGgvYmx1ZXRv b3RoL2wyY2FwIG5ldGdyYXBoL2JsdWV0b290aC9zb2NrZXQgbmV0Z3JhcGgvYmx1ZXRvb3RoL3Vi dCIgREVCVUdfRkxBR1M9Ii1nIiBNQUNISU5FPWkzODYgS0VSTkJVSUxERElSPSIvdXNyL29iai91 c3Ivc3JjL3N5cy9BUlVOREVMIiBTWVNESVI9Ii91c3Ivc3JjL3N5cyIgL3Vzci9vYmovdXNyL3Ny Yy9tYWtlLmkzODYvbWFrZSAgZGVwZW5kCj09PT4gYWNwaS9hY3BpIChkZXBlbmQpCkAgLT4gL3Vz ci9zcmMvc3lzCm1hY2hpbmUgLT4gL3Vzci9zcmMvc3lzL2kzODYvaW5jbHVkZQpsbiAtc2YgL3Vz ci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTC9vcHRfYWNwaS5oIG9wdF9hY3BpLmgKbG4gLXNmIC91 c3Ivb2JqL3Vzci9zcmMvc3lzL0FSVU5ERUwvb3B0X2J1cy5oIG9wdF9idXMuaApsbiAtc2YgL3Vz ci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTC9vcHRfZGRiLmggb3B0X2RkYi5oCmF3ayAtZiBAL3Rv b2xzL21ha2VvYmpvcHMuYXdrIEAvZGV2L2FjcGljYS9hY3BpX2lmLm0gLWgKYXdrIC1mIEAvdG9v bHMvYWNwaV9xdWlya3MyaC5hd2sgQC9kZXYvYWNwaWNhL2FjcGlfcXVpcmtzCmF3ayAtZiBAL3Rv b2xzL21ha2VvYmpvcHMuYXdrIEAva2Vybi9idXNfaWYubSAtaAphd2sgLWYgQC90b29scy9tYWtl b2Jqb3BzLmF3ayBAL2tlcm4vY3B1ZnJlcV9pZi5tIC1oCmF3ayAtZiBAL3Rvb2xzL21ha2VvYmpv cHMuYXdrIEAva2Vybi9kZXZpY2VfaWYubSAtaAphd2sgLWYgQC90b29scy9tYWtlb2Jqb3BzLmF3 ayBAL2lzYS9pc2FfaWYubSAtaAphd2sgLWYgQC90b29scy9tYWtlb2Jqb3BzLmF3ayBAL2Rldi9w Y2kvcGNpX2lmLm0gLWgKYXdrIC1mIEAvdG9vbHMvbWFrZW9iam9wcy5hd2sgQC9kZXYvcGNpL3Bj aWJfaWYubSAtaApsbiAtc2YgL3Vzci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTC9vcHRfa3N0YWNr X3BhZ2VzLmggb3B0X2tzdGFja19wYWdlcy5oCmxuIC1zZiAvdXNyL29iai91c3Ivc3JjL3N5cy9B UlVOREVML29wdF9uZnMuaCBvcHRfbmZzLmgKbG4gLXNmIC91c3Ivb2JqL3Vzci9zcmMvc3lzL0FS VU5ERUwvb3B0X2FwaWMuaCBvcHRfYXBpYy5oCmxuIC1zZiAvdXNyL29iai91c3Ivc3JjL3N5cy9B UlVOREVML29wdF9jb21wYXQuaCBvcHRfY29tcGF0LmgKbG4gLXNmIC91c3Ivb2JqL3Vzci9zcmMv c3lzL0FSVU5ERUwvb3B0X2h3cG1jX2hvb2tzLmggb3B0X2h3cG1jX2hvb2tzLmgKY2MgLWMgLU8y IC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1waXBlIC1tYXJjaD1uYXRpdmUgLVdlcnJvciAtRF9LRVJO RUwgLURLTERfTU9EVUxFIC1ub3N0ZGluYyAtREhBVkVfS0VSTkVMX09QVElPTl9IRUFERVJTIC1p bmNsdWRlIC91c3Ivb2JqL3Vzci9zcmMvc3lzL0FSVU5ERUwvb3B0X2dsb2JhbC5oIC1JLiAtSUAg LUlAL2NvbnRyaWIvYWx0cSAtZmlubGluZS1saW1pdD04MDAwIC0tcGFyYW0gaW5saW5lLXVuaXQt Z3Jvd3RoPTEwMCAtLXBhcmFtIGxhcmdlLWZ1bmN0aW9uLWdyb3d0aD0xMDAwIC1nIC1JL3Vzci9v YmovdXNyL3NyYy9zeXMvQVJVTkRFTCAtbW5vLWFsaWduLWxvbmctc3RyaW5ncyAtbXByZWZlcnJl ZC1zdGFjay1ib3VuZGFyeT0yIC1tbm8tbW14IC1tbm8tM2Rub3cgLW1uby1zc2UgLW1uby1zc2Uy IC1tbm8tc3NlMyAtZmZyZWVzdGFuZGluZyAtZnN0YWNrLXByb3RlY3RvciAtc3RkPWlzbzk4OTk6 MTk5OSAtZnN0YWNrLXByb3RlY3RvciAtV2FsbCAtV3JlZHVuZGFudC1kZWNscyAtV25lc3RlZC1l eHRlcm5zIC1Xc3RyaWN0LXByb3RvdHlwZXMgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdwb2ludGVy LWFyaXRoIC1XaW5saW5lIC1XY2FzdC1xdWFsIC1XdW5kZWYgLVduby1wb2ludGVyLXNpZ24gLWZm b3JtYXQtZXh0ZW5zaW9ucyAgQC9pMzg2L2kzODYvZ2VuYXNzeW0uYwpzaCBAL2tlcm4vZ2VuYXNz eW0uc2ggZ2VuYXNzeW0ubyA+IGFzc3ltLnMKL3Vzci9vYmovdXNyL3NyYy9tYWtlLmkzODYvbWFr ZSAtZiAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vaTM4Ni9hY3BpY2Ev TWFrZWZpbGUgIE1BS0VTUkNQQVRIPS91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8u Li8uLi9pMzg2L2FjcGljYQpjYyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLW1hcmNo PW5hdGl2ZSAtbm9zdGRpbmMgLUkuIC1JL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4u Ly4uLy4uL2kzODYvYWNwaWNhLy4uLy4uIC1nIC1zdGQ9Z251OTkgLWZzdGFjay1wcm90ZWN0b3Ig IC1jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9pMzg2L2FjcGljYS9h Y3BpX3dha2Vjb2RlLlMKb2JqY29weSAtUyAtTyBiaW5hcnkgYWNwaV93YWtlY29kZS5vIGFjcGlf d2FrZWNvZGUuYmluCnNoIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9p Mzg2L2FjcGljYS9nZW53YWtlY29kZS5zaCA+IGFjcGlfd2FrZWNvZGUuaApXYXJuaW5nOiBPYmpl Y3QgZGlyZWN0b3J5IG5vdCBjaGFuZ2VkIGZyb20gb3JpZ2luYWwgL3Vzci9vYmovdXNyL3NyYy9z eXMvQVJVTkRFTC9tb2R1bGVzL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpCnJtIC1mIC5k ZXBlbmQKbWtkZXAgLWYgLmRlcGVuZCAtYSAgIC1ub3N0ZGluYyAtRF9LRVJORUwgLURLTERfTU9E VUxFIC1ESEFWRV9LRVJORUxfT1BUSU9OX0hFQURFUlMgLUkuIC1JQCAtSUAvY29udHJpYi9hbHRx IC1JL3Vzci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTCAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3Bp L2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL2Rpc3BhdGNoZXIvZHNmaWVsZC5jIC91 c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2Ev ZGlzcGF0Y2hlci9kc2luaXQuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4v Li4vY29udHJpYi9kZXYvYWNwaWNhL2Rpc3BhdGNoZXIvZHNtZXRob2QuYyAvdXNyL3NyYy9zeXMv bW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL2Rpc3BhdGNoZXIv ZHNtdGhkYXQuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJp Yi9kZXYvYWNwaWNhL2Rpc3BhdGNoZXIvZHNvYmplY3QuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9h Y3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL2Rpc3BhdGNoZXIvZHNvcGNvZGUu YyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNw aWNhL2Rpc3BhdGNoZXIvZHN1dGlscy5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8u Li8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvZGlzcGF0Y2hlci9kc3dleGVjLmMgL3Vzci9zcmMv c3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9kaXNwYXRj aGVyL2Rzd2xvYWQuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29u dHJpYi9kZXYvYWNwaWNhL2Rpc3BhdGNoZXIvZHN3c2NvcGUuYyAvdXNyL3NyYy9zeXMvbW9kdWxl cy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL2Rpc3BhdGNoZXIvZHN3c3Rh dGUuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYv YWNwaWNhL2V2ZW50cy9ldmV2ZW50LmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4u Ly4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9ldmVudHMvZXZncGUuYyAvdXNyL3NyYy9zeXMvbW9k dWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL2V2ZW50cy9ldmdwZWJs ay5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9h Y3BpY2EvZXZlbnRzL2V2bWlzYy5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8u Li8uLi9jb250cmliL2Rldi9hY3BpY2EvZXZlbnRzL2V2cmVnaW9uLmMgL3Vzci9zcmMvc3lzL21v ZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9ldmVudHMvZXZyZ25p bmkuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYv YWNwaWNhL2V2ZW50cy9ldnNjaS5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8u Li8uLi9jb250cmliL2Rldi9hY3BpY2EvZXZlbnRzL2V2eGZhY2UuYyAvdXNyL3NyYy9zeXMvbW9k dWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL2V2ZW50cy9ldnhmZXZu dC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9h Y3BpY2EvZXZlbnRzL2V2eGZyZWduLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4u Ly4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9leGVjdXRlci9leGNvbmZpZy5jIC91c3Ivc3JjL3N5 cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvZXhlY3V0ZXIv ZXhjb252cnQuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJp Yi9kZXYvYWNwaWNhL2V4ZWN1dGVyL2V4Y3JlYXRlLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNw aS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9leGVjdXRlci9leGR1bXAuYyAvdXNy L3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL2V4 ZWN1dGVyL2V4ZmllbGQuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4v Y29udHJpYi9kZXYvYWNwaWNhL2V4ZWN1dGVyL2V4ZmxkaW8uYyAvdXNyL3NyYy9zeXMvbW9kdWxl cy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL2V4ZWN1dGVyL2V4bWlzYy5j IC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3Bp Y2EvZXhlY3V0ZXIvZXhtdXRleC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8u Li8uLi9jb250cmliL2Rldi9hY3BpY2EvZXhlY3V0ZXIvZXhuYW1lcy5jIC91c3Ivc3JjL3N5cy9t b2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvZXhlY3V0ZXIvZXhv cGFyZzEuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9k ZXYvYWNwaWNhL2V4ZWN1dGVyL2V4b3BhcmcyLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9h Y3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9leGVjdXRlci9leG9wYXJnMy5jIC91c3Iv c3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvZXhl Y3V0ZXIvZXhvcGFyZzYuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4v Y29udHJpYi9kZXYvYWNwaWNhL2V4ZWN1dGVyL2V4cHJlcC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVz L2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvZXhlY3V0ZXIvZXhyZWdpb24u YyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNw aWNhL2V4ZWN1dGVyL2V4cmVzbnRlLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4u Ly4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9leGVjdXRlci9leHJlc29sdi5jIC91c3Ivc3JjL3N5 cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvZXhlY3V0ZXIv ZXhyZXNvcC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmli L2Rldi9hY3BpY2EvZXhlY3V0ZXIvZXhzdG9yZS5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkv YWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvZXhlY3V0ZXIvZXhzdG9yZW4uYyAvdXNy L3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL2V4 ZWN1dGVyL2V4c3Rvcm9iLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4u L2NvbnRyaWIvZGV2L2FjcGljYS9leGVjdXRlci9leHN5c3RlbS5jIC91c3Ivc3JjL3N5cy9tb2R1 bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvZXhlY3V0ZXIvZXh1dGls cy5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9h Y3BpY2EvaGFyZHdhcmUvaHdhY3BpLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4u Ly4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9oYXJkd2FyZS9od2dwZS5jIC91c3Ivc3JjL3N5cy9t b2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvaGFyZHdhcmUvaHdy ZWdzLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2 L2FjcGljYS9oYXJkd2FyZS9od3NsZWVwLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3Bp Ly4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9oYXJkd2FyZS9od3RpbWVyLmMgL3Vzci9zcmMv c3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9oYXJkd2Fy ZS9od3ZhbGlkLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRy aWIvZGV2L2FjcGljYS9oYXJkd2FyZS9od3hmYWNlLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNw aS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9uYW1lc3BhY2UvbnNhY2Nlc3MuYyAv dXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNh L25hbWVzcGFjZS9uc2FsbG9jLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4u Ly4uL2NvbnRyaWIvZGV2L2FjcGljYS9uYW1lc3BhY2UvbnNkdW1wLmMgL3Vzci9zcmMvc3lzL21v ZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9uYW1lc3BhY2UvbnNl dmFsLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2 L2FjcGljYS9uYW1lc3BhY2UvbnNpbml0LmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3Bp Ly4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9uYW1lc3BhY2UvbnNsb2FkLmMgL3Vzci9zcmMv c3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9uYW1lc3Bh Y2UvbnNuYW1lcy5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250 cmliL2Rldi9hY3BpY2EvbmFtZXNwYWNlL25zb2JqZWN0LmMgL3Vzci9zcmMvc3lzL21vZHVsZXMv YWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9uYW1lc3BhY2UvbnNwYXJzZS5j IC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3Bp Y2EvbmFtZXNwYWNlL25zcHJlZGVmLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4u Ly4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9uYW1lc3BhY2UvbnNzZWFyY2guYyAvdXNyL3NyYy9z eXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL25hbWVzcGFj ZS9uc3V0aWxzLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRy aWIvZGV2L2FjcGljYS9uYW1lc3BhY2UvbnN3YWxrLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNw aS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9uYW1lc3BhY2UvbnN4ZmV2YWwuYyAv dXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNh L25hbWVzcGFjZS9uc3hmbmFtZS5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8u Li8uLi9jb250cmliL2Rldi9hY3BpY2EvbmFtZXNwYWNlL25zeGZvYmouYyAvdXNyL3NyYy9zeXMv bW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL3BhcnNlci9wc2Fy Z3MuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYv YWNwaWNhL3BhcnNlci9wc2xvb3AuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4v Li4vLi4vY29udHJpYi9kZXYvYWNwaWNhL3BhcnNlci9wc29wY29kZS5jIC91c3Ivc3JjL3N5cy9t b2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvcGFyc2VyL3BzcGFy c2UuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYv YWNwaWNhL3BhcnNlci9wc3Njb3BlLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4u Ly4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9wYXJzZXIvcHN0cmVlLmMgL3Vzci9zcmMvc3lzL21v ZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9wYXJzZXIvcHN1dGls cy5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9h Y3BpY2EvcGFyc2VyL3Bzd2Fsay5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8u Li8uLi9jb250cmliL2Rldi9hY3BpY2EvcGFyc2VyL3BzeGZhY2UuYyAvdXNyL3NyYy9zeXMvbW9k dWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL3Jlc291cmNlcy9yc2Fk ZHIuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYv YWNwaWNhL3Jlc291cmNlcy9yc2NhbGMuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkv Li4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL3Jlc291cmNlcy9yc2NyZWF0ZS5jIC91c3Ivc3Jj L3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvcmVzb3Vy Y2VzL3JzZHVtcC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250 cmliL2Rldi9hY3BpY2EvcmVzb3VyY2VzL3JzaW5mby5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2Fj cGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvcmVzb3VyY2VzL3JzaW8uYyAvdXNy L3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL3Jl c291cmNlcy9yc2lycS5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9j b250cmliL2Rldi9hY3BpY2EvcmVzb3VyY2VzL3JzbGlzdC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVz L2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvcmVzb3VyY2VzL3JzbWVtb3J5 LmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2Fj cGljYS9yZXNvdXJjZXMvcnNtaXNjLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4u Ly4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS9yZXNvdXJjZXMvcnN1dGlscy5jIC91c3Ivc3JjL3N5 cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvcmVzb3VyY2Vz L3JzeGZhY2UuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJp Yi9kZXYvYWNwaWNhL3RhYmxlcy90YmZhZHQuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2Fj cGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL3RhYmxlcy90YmZpbmQuYyAvdXNyL3NyYy9z eXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL3RhYmxlcy90 Ymluc3RhbC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmli L2Rldi9hY3BpY2EvdGFibGVzL3RidXRpbHMuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2Fj cGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL3RhYmxlcy90YnhmYWNlLmMgL3Vzci9zcmMv c3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS90YWJsZXMv dGJ4ZnJvb3QuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJp Yi9kZXYvYWNwaWNhL3V0aWxpdGllcy91dGFsbG9jLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNw aS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS91dGlsaXRpZXMvdXRjYWNoZS5jIC91 c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2Ev dXRpbGl0aWVzL3V0Y29weS5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8u Li9jb250cmliL2Rldi9hY3BpY2EvdXRpbGl0aWVzL3V0ZGVidWcuYyAvdXNyL3NyYy9zeXMvbW9k dWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL3V0aWxpdGllcy91dGRl bGV0ZS5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rl di9hY3BpY2EvdXRpbGl0aWVzL3V0ZXZhbC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNw aS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvdXRpbGl0aWVzL3V0Z2xvYmFsLmMgL3Vzci9z cmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS91dGls aXRpZXMvdXRpbml0LmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2Nv bnRyaWIvZGV2L2FjcGljYS91dGlsaXRpZXMvdXRsb2NrLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMv YWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGljYS91dGlsaXRpZXMvdXRtYXRoLmMg L3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIvZGV2L2FjcGlj YS91dGlsaXRpZXMvdXRtaXNjLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4u Ly4uL2NvbnRyaWIvZGV2L2FjcGljYS91dGlsaXRpZXMvdXRtdXRleC5jIC91c3Ivc3JjL3N5cy9t b2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvdXRpbGl0aWVzL3V0 b2JqZWN0LmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2NvbnRyaWIv ZGV2L2FjcGljYS91dGlsaXRpZXMvdXRyZXNyYy5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkv YWNwaS8uLi8uLi8uLi9jb250cmliL2Rldi9hY3BpY2EvdXRpbGl0aWVzL3V0c3RhdGUuYyAvdXNy L3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vY29udHJpYi9kZXYvYWNwaWNhL3V0 aWxpdGllcy91dHhmYWNlLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4u L2Rldi9hY3BpY2EvYWNwaS5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8u Li9kZXYvYWNwaWNhL2FjcGlfYnV0dG9uLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3Bp Ly4uLy4uLy4uL2Rldi9hY3BpY2EvYWNwaV9pc2FiLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNw aS9hY3BpLy4uLy4uLy4uL2Rldi9hY3BpY2EvYWNwaV9wYWNrYWdlLmMgL3Vzci9zcmMvc3lzL21v ZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2Rldi9hY3BpY2EvYWNwaV9wY2kuYyAvdXNyL3NyYy9z eXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vZGV2L2FjcGljYS9hY3BpX3BjaWIuYyAvdXNy L3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vZGV2L2FjcGljYS9hY3BpX3BjaWJf YWNwaS5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9kZXYvYWNwaWNh L2FjcGlfcGNpYl9wY2kuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4v ZGV2L2FjcGljYS9hY3BpX3Bvd2VycmVzLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3Bp Ly4uLy4uLy4uL2Rldi9hY3BpY2EvYWNwaV9xdWlyay5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2Fj cGkvYWNwaS8uLi8uLi8uLi9kZXYvYWNwaWNhL2FjcGlfcmVzb3VyY2UuYyAvdXNyL3NyYy9zeXMv bW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vZGV2L2FjcGljYS9hY3BpX3RpbWVyLmMgL3Vzci9z cmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2Rldi9hY3BpY2EvYWNwaV9wY2lfbGlu ay5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9kZXYvYWNwaWNhL2Fj cGlfdGhlcm1hbC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9kZXYv YWNwaWNhL2FjcGlfYWNhZC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8u Li9kZXYvYWNwaWNhL2FjcGlfYmF0dGVyeS5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNw aS8uLi8uLi8uLi9kZXYvYWNwaWNhL2FjcGlfY21iYXQuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9h Y3BpL2FjcGkvLi4vLi4vLi4vZGV2L2FjcGljYS9hY3BpX2NwdS5jIC91c3Ivc3JjL3N5cy9tb2R1 bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9kZXYvYWNwaWNhL2FjcGlfZWMuYyAvdXNyL3NyYy9zeXMv bW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vZGV2L2FjcGljYS9hY3BpX2hwZXQuYyAvdXNyL3Ny Yy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vZGV2L2FjcGljYS9hY3BpX2xpZC5jIC91 c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9kZXYvYWNwaWNhL2FjcGlfcGVy Zi5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9kZXYvYWNwaWNhL2Fj cGlfc21iYXQuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vZGV2L2Fj cGljYS9hY3BpX3Rocm90dGxlLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4u Ly4uL2Rldi9hY3BpY2EvT3NkL09zZERlYnVnLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9h Y3BpLy4uLy4uLy4uL2Rldi9hY3BpY2EvT3NkL09zZEhhcmR3YXJlLmMgL3Vzci9zcmMvc3lzL21v ZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2Rldi9hY3BpY2EvT3NkL09zZEludGVycnVwdC5jIC91 c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9kZXYvYWNwaWNhL09zZC9Pc2RN ZW1vcnkuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4vLi4vZGV2L2FjcGlj YS9Pc2QvT3NkU2NoZWR1bGUuYyAvdXNyL3NyYy9zeXMvbW9kdWxlcy9hY3BpL2FjcGkvLi4vLi4v Li4vZGV2L2FjcGljYS9Pc2QvT3NkU3RyZWFtLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9h Y3BpLy4uLy4uLy4uL2Rldi9hY3BpY2EvT3NkL09zZFN5bmNoLmMgL3Vzci9zcmMvc3lzL21vZHVs ZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2Rldi9hY3BpY2EvT3NkL09zZFRhYmxlLmMgL3Vzci9zcmMv c3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2kzODYvYWNwaWNhL09zZEVudmlyb25tZW50 LmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvYWNwaS9hY3BpLy4uLy4uLy4uL2kzODYvYWNwaWNhL2Fj cGlfbWFjaGRlcC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8uLi8uLi9pMzg2 L2FjcGljYS9hY3BpX3dha2V1cC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaS8uLi8u Li8uLi9pMzg2L2FjcGljYS9tYWR0LmMKPT09PiBhY3BpL2FjcGlfdmlkZW8gKGRlcGVuZCkKQCAt PiAvdXNyL3NyYy9zeXMKbWFjaGluZSAtPiAvdXNyL3NyYy9zeXMvaTM4Ni9pbmNsdWRlCmxuIC1z ZiAvdXNyL29iai91c3Ivc3JjL3N5cy9BUlVOREVML29wdF9hY3BpLmggb3B0X2FjcGkuaAphd2sg LWYgQC90b29scy9tYWtlb2Jqb3BzLmF3ayBAL2Rldi9hY3BpY2EvYWNwaV9pZi5tIC1oCmF3ayAt ZiBAL3Rvb2xzL21ha2VvYmpvcHMuYXdrIEAva2Vybi9idXNfaWYubSAtaAphd2sgLWYgQC90b29s cy9tYWtlb2Jqb3BzLmF3ayBAL2tlcm4vZGV2aWNlX2lmLm0gLWgKcm0gLWYgLmRlcGVuZApta2Rl cCAtZiAuZGVwZW5kIC1hICAgLW5vc3RkaW5jIC1EX0tFUk5FTCAtREtMRF9NT0RVTEUgLURIQVZF X0tFUk5FTF9PUFRJT05fSEVBREVSUyAtSS4gLUlAIC1JQC9jb250cmliL2FsdHEgLUkvdXNyL29i ai91c3Ivc3JjL3N5cy9BUlVOREVMIC91c3Ivc3JjL3N5cy9tb2R1bGVzL2FjcGkvYWNwaV92aWRl by8uLi8uLi8uLi9kZXYvYWNwaWNhL2FjcGlfdmlkZW8uYwo9PT0+IG5ldGdyYXBoL25ldGdyYXBo IChkZXBlbmQpCkAgLT4gL3Vzci9zcmMvc3lzCm1hY2hpbmUgLT4gL3Vzci9zcmMvc3lzL2kzODYv aW5jbHVkZQpsbiAtc2YgL3Vzci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTC9vcHRfbmV0Z3JhcGgu aCBvcHRfbmV0Z3JhcGguaApybSAtZiAuZGVwZW5kCm1rZGVwIC1mIC5kZXBlbmQgLWEgICAtbm9z dGRpbmMgLURfS0VSTkVMIC1ES0xEX01PRFVMRSAtREhBVkVfS0VSTkVMX09QVElPTl9IRUFERVJT IC1JLiAtSUAgLUlAL2NvbnRyaWIvYWx0cSAtSS91c3Ivb2JqL3Vzci9zcmMvc3lzL0FSVU5ERUwg L3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvbmV0Z3JhcGgvLi4vLi4vLi4vbmV0Z3JhcGgv bmdfYmFzZS5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL25ldGdyYXBoLy4uLy4uLy4u L25ldGdyYXBoL25nX3BhcnNlLmMKPT09PiBuZXRncmFwaC9zb2NrZXQgKGRlcGVuZCkKQCAtPiAv dXNyL3NyYy9zeXMKbWFjaGluZSAtPiAvdXNyL3NyYy9zeXMvaTM4Ni9pbmNsdWRlCmxuIC1zZiAv dXNyL29iai91c3Ivc3JjL3N5cy9BUlVOREVML29wdF9uZXRncmFwaC5oIG9wdF9uZXRncmFwaC5o CnJtIC1mIC5kZXBlbmQKbWtkZXAgLWYgLmRlcGVuZCAtYSAgIC1ub3N0ZGluYyAtRF9LRVJORUwg LURLTERfTU9EVUxFIC1ESEFWRV9LRVJORUxfT1BUSU9OX0hFQURFUlMgLUkuIC1JQCAtSUAvY29u dHJpYi9hbHRxIC1JL3Vzci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTCAvdXNyL3NyYy9zeXMvbW9k dWxlcy9uZXRncmFwaC9zb2NrZXQvLi4vLi4vLi4vbmV0Z3JhcGgvbmdfc29ja2V0LmMKPT09PiBu ZXRncmFwaC9ibHVldG9vdGgvYmx1ZXRvb3RoIChkZXBlbmQpCkAgLT4gL3Vzci9zcmMvc3lzCm1h Y2hpbmUgLT4gL3Vzci9zcmMvc3lzL2kzODYvaW5jbHVkZQpsbiAtc2YgL3Vzci9vYmovdXNyL3Ny Yy9zeXMvQVJVTkRFTC9vcHRfbmV0Z3JhcGguaCBvcHRfbmV0Z3JhcGguaApybSAtZiAuZGVwZW5k Cm1rZGVwIC1mIC5kZXBlbmQgLWEgICAtbm9zdGRpbmMgLURfS0VSTkVMIC1ES0xEX01PRFVMRSAt SS91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL2JsdWV0b290aC9ibHVldG9vdGgvLi4vLi4v Li4vLi4vbmV0Z3JhcGgvYmx1ZXRvb3RoL2luY2x1ZGUgLURIQVZFX0tFUk5FTF9PUFRJT05fSEVB REVSUyAtSS4gLUlAIC1JQC9jb250cmliL2FsdHEgLUkvdXNyL29iai91c3Ivc3JjL3N5cy9BUlVO REVMIC91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL2JsdWV0b290aC9ibHVldG9vdGgvLi4v Li4vLi4vLi4vbmV0Z3JhcGgvYmx1ZXRvb3RoL2NvbW1vbi9uZ19ibHVldG9vdGguYwo9PT0+IG5l dGdyYXBoL2JsdWV0b290aC9oY2kgKGRlcGVuZCkKQCAtPiAvdXNyL3NyYy9zeXMKbWFjaGluZSAt PiAvdXNyL3NyYy9zeXMvaTM4Ni9pbmNsdWRlCmxuIC1zZiAvdXNyL29iai91c3Ivc3JjL3N5cy9B UlVOREVML29wdF9uZXRncmFwaC5oIG9wdF9uZXRncmFwaC5oCnJtIC1mIC5kZXBlbmQKbWtkZXAg LWYgLmRlcGVuZCAtYSAgIC1ub3N0ZGluYyAtRF9LRVJORUwgLURLTERfTU9EVUxFIC1JL3Vzci9z cmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL2hjaS8uLi8uLi8uLi8uLi9uZXRncmFw aC9ibHVldG9vdGgvaW5jbHVkZSAtSS91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL2JsdWV0 b290aC9oY2kvLi4vLi4vLi4vLi4vbmV0Z3JhcGgvYmx1ZXRvb3RoL2hjaSAtREhBVkVfS0VSTkVM X09QVElPTl9IRUFERVJTIC1JLiAtSUAgLUlAL2NvbnRyaWIvYWx0cSAtSS91c3Ivb2JqL3Vzci9z cmMvc3lzL0FSVU5ERUwgL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL2hj aS8uLi8uLi8uLi8uLi9uZXRncmFwaC9ibHVldG9vdGgvaGNpL25nX2hjaV9tYWluLmMgL3Vzci9z cmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL2hjaS8uLi8uLi8uLi8uLi9uZXRncmFw aC9ibHVldG9vdGgvaGNpL25nX2hjaV9jbWRzLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3Jh cGgvYmx1ZXRvb3RoL2hjaS8uLi8uLi8uLi8uLi9uZXRncmFwaC9ibHVldG9vdGgvaGNpL25nX2hj aV9ldm50LmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL2hjaS8uLi8u Li8uLi8uLi9uZXRncmFwaC9ibHVldG9vdGgvaGNpL25nX2hjaV91bHBpLmMgL3Vzci9zcmMvc3lz L21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL2hjaS8uLi8uLi8uLi8uLi9uZXRncmFwaC9ibHVl dG9vdGgvaGNpL25nX2hjaV9taXNjLmMKPT09PiBuZXRncmFwaC9ibHVldG9vdGgvbDJjYXAgKGRl cGVuZCkKQCAtPiAvdXNyL3NyYy9zeXMKbWFjaGluZSAtPiAvdXNyL3NyYy9zeXMvaTM4Ni9pbmNs dWRlCmxuIC1zZiAvdXNyL29iai91c3Ivc3JjL3N5cy9BUlVOREVML29wdF9uZXRncmFwaC5oIG9w dF9uZXRncmFwaC5oCnJtIC1mIC5kZXBlbmQKbWtkZXAgLWYgLmRlcGVuZCAtYSAgIC1ub3N0ZGlu YyAtRF9LRVJORUwgLURLTERfTU9EVUxFIC1JL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgv Ymx1ZXRvb3RoL2wyY2FwLy4uLy4uLy4uLy4uL25ldGdyYXBoL2JsdWV0b290aC9pbmNsdWRlIC1J L3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL2wyY2FwLy4uLy4uLy4uLy4u L25ldGdyYXBoL2JsdWV0b290aC9sMmNhcCAtREhBVkVfS0VSTkVMX09QVElPTl9IRUFERVJTIC1J LiAtSUAgLUlAL2NvbnRyaWIvYWx0cSAtSS91c3Ivb2JqL3Vzci9zcmMvc3lzL0FSVU5ERUwgL3Vz ci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL2wyY2FwLy4uLy4uLy4uLy4uL25l dGdyYXBoL2JsdWV0b290aC9sMmNhcC9uZ19sMmNhcF9tYWluLmMgL3Vzci9zcmMvc3lzL21vZHVs ZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL2wyY2FwLy4uLy4uLy4uLy4uL25ldGdyYXBoL2JsdWV0b290 aC9sMmNhcC9uZ19sMmNhcF9jbWRzLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1 ZXRvb3RoL2wyY2FwLy4uLy4uLy4uLy4uL25ldGdyYXBoL2JsdWV0b290aC9sMmNhcC9uZ19sMmNh cF9ldm50LmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL2wyY2FwLy4u Ly4uLy4uLy4uL25ldGdyYXBoL2JsdWV0b290aC9sMmNhcC9uZ19sMmNhcF91bHBpLmMgL3Vzci9z cmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL2wyY2FwLy4uLy4uLy4uLy4uL25ldGdy YXBoL2JsdWV0b290aC9sMmNhcC9uZ19sMmNhcF9sbHBpLmMgL3Vzci9zcmMvc3lzL21vZHVsZXMv bmV0Z3JhcGgvYmx1ZXRvb3RoL2wyY2FwLy4uLy4uLy4uLy4uL25ldGdyYXBoL2JsdWV0b290aC9s MmNhcC9uZ19sMmNhcF9taXNjLmMKPT09PiBuZXRncmFwaC9ibHVldG9vdGgvc29ja2V0IChkZXBl bmQpCkAgLT4gL3Vzci9zcmMvc3lzCm1hY2hpbmUgLT4gL3Vzci9zcmMvc3lzL2kzODYvaW5jbHVk ZQpsbiAtc2YgL3Vzci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTC9vcHRfbmV0Z3JhcGguaCBvcHRf bmV0Z3JhcGguaApybSAtZiAuZGVwZW5kCm1rZGVwIC1mIC5kZXBlbmQgLWEgICAtbm9zdGRpbmMg LURfS0VSTkVMIC1ES0xEX01PRFVMRSAtSS91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL2Js dWV0b290aC9zb2NrZXQvLi4vLi4vLi4vLi4vbmV0Z3JhcGgvYmx1ZXRvb3RoL2luY2x1ZGUgLURI QVZFX0tFUk5FTF9PUFRJT05fSEVBREVSUyAtSS4gLUlAIC1JQC9jb250cmliL2FsdHEgLUkvdXNy L29iai91c3Ivc3JjL3N5cy9BUlVOREVMIC91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL2Js dWV0b290aC9zb2NrZXQvLi4vLi4vLi4vLi4vbmV0Z3JhcGgvYmx1ZXRvb3RoL3NvY2tldC9uZ19i dHNvY2tldC5jIC91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL2JsdWV0b290aC9zb2NrZXQv Li4vLi4vLi4vLi4vbmV0Z3JhcGgvYmx1ZXRvb3RoL3NvY2tldC9uZ19idHNvY2tldF9oY2lfcmF3 LmMgL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3JhcGgvYmx1ZXRvb3RoL3NvY2tldC8uLi8uLi8u Li8uLi9uZXRncmFwaC9ibHVldG9vdGgvc29ja2V0L25nX2J0c29ja2V0X2wyY2FwX3Jhdy5jIC91 c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL2JsdWV0b290aC9zb2NrZXQvLi4vLi4vLi4vLi4v bmV0Z3JhcGgvYmx1ZXRvb3RoL3NvY2tldC9uZ19idHNvY2tldF9sMmNhcC5jIC91c3Ivc3JjL3N5 cy9tb2R1bGVzL25ldGdyYXBoL2JsdWV0b290aC9zb2NrZXQvLi4vLi4vLi4vLi4vbmV0Z3JhcGgv Ymx1ZXRvb3RoL3NvY2tldC9uZ19idHNvY2tldF9yZmNvbW0uYyAvdXNyL3NyYy9zeXMvbW9kdWxl cy9uZXRncmFwaC9ibHVldG9vdGgvc29ja2V0Ly4uLy4uLy4uLy4uL25ldGdyYXBoL2JsdWV0b290 aC9zb2NrZXQvbmdfYnRzb2NrZXRfc2NvLmMKPT09PiBuZXRncmFwaC9ibHVldG9vdGgvdWJ0IChk ZXBlbmQpCkAgLT4gL3Vzci9zcmMvc3lzCm1hY2hpbmUgLT4gL3Vzci9zcmMvc3lzL2kzODYvaW5j bHVkZQpsbiAtc2YgL3Vzci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTC9vcHRfYnVzLmggb3B0X2J1 cy5oCmxuIC1zZiAvdXNyL29iai91c3Ivc3JjL3N5cy9BUlVOREVML29wdF91c2IuaCBvcHRfdXNi LmgKYXdrIC1mIEAvdG9vbHMvbWFrZW9iam9wcy5hd2sgQC9rZXJuL2RldmljZV9pZi5tIC1oCmF3 ayAtZiBAL3Rvb2xzL21ha2VvYmpvcHMuYXdrIEAva2Vybi9idXNfaWYubSAtaAphd2sgLWYgQC90 b29scy9tYWtlb2Jqb3BzLmF3ayBAL2Rldi91c2IvdXNiX2lmLm0gLWgKYXdrIC1mIEAvdG9vbHMv dXNiZGV2czJoLmF3ayBAL2Rldi91c2IvdXNiZGV2cyAtaApsbiAtc2YgL3Vzci9vYmovdXNyL3Ny Yy9zeXMvQVJVTkRFTC9vcHRfbmV0Z3JhcGguaCBvcHRfbmV0Z3JhcGguaApybSAtZiAuZGVwZW5k Cm1rZGVwIC1mIC5kZXBlbmQgLWEgICAtbm9zdGRpbmMgLURfS0VSTkVMIC1ES0xEX01PRFVMRSAt SS91c3Ivc3JjL3N5cy9tb2R1bGVzL25ldGdyYXBoL2JsdWV0b290aC91YnQvLi4vLi4vLi4vLi4v bmV0Z3JhcGgvYmx1ZXRvb3RoL2luY2x1ZGUgLUkvdXNyL3NyYy9zeXMvbW9kdWxlcy9uZXRncmFw aC9ibHVldG9vdGgvdWJ0Ly4uLy4uLy4uLy4uL25ldGdyYXBoL2JsdWV0b290aC9kcml2ZXJzL3Vi dCAtREhBVkVfS0VSTkVMX09QVElPTl9IRUFERVJTIC1JLiAtSUAgLUlAL2NvbnRyaWIvYWx0cSAt SS91c3Ivb2JqL3Vzci9zcmMvc3lzL0FSVU5ERUwgL3Vzci9zcmMvc3lzL21vZHVsZXMvbmV0Z3Jh cGgvYmx1ZXRvb3RoL3VidC8uLi8uLi8uLi8uLi9uZXRncmFwaC9ibHVldG9vdGgvZHJpdmVycy91 YnQvbmdfdWJ0LmMKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tCj4+PiBzdGFnZSAzLjI6IGJ1aWxkaW5nIGV2ZXJ5dGhpbmcKLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0KY2QgL3Vzci9vYmovdXNyL3NyYy9zeXMvQVJVTkRFTDsgTUFLRU9CSkRJUlBSRUZJWD0vdXNy L29iaiAgTUFDSElORV9BUkNIPWkzODYgIE1BQ0hJTkU9aTM4NiAgQ1BVVFlQRT1uYXRpdmUgIEdS T0ZGX0JJTl9QQVRIPS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvYmluICBHUk9GRl9G T05UX1BBVEg9L3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zaGFyZS9ncm9mZl9mb250 ICBHUk9GRl9UTUFDX1BBVEg9L3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zaGFyZS90 bWFjICBfU0hMSUJESVJQUkVGSVg9L3Vzci9vYmovdXNyL3NyYy90bXAgIFZFUlNJT049IkZyZWVC U0QgOC4wLUNVUlJFTlQgaTM4NiA4MDAxMDAiICBJTlNUQUxMPSJzaCAvdXNyL3NyYy90b29scy9p bnN0YWxsLnNoIiAgUEFUSD0vdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL3NiaW46L3Vz ci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9iaW46L3Vzci9vYmovdXNyL3NyYy90bXAvbGVn YWN5L3Vzci9nYW1lczovdXNyL29iai91c3Ivc3JjL3RtcC91c3Ivc2JpbjovdXNyL29iai91c3Iv c3JjL3RtcC91c3IvYmluOi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9nYW1lczovc2JpbjovYmlu Oi91c3Ivc2JpbjovdXNyL2JpbiBOT19DVEY9MSAvdXNyL29iai91c3Ivc3JjL21ha2UuaTM4Ni9t YWtlIEtFUk5FTD1rZXJuZWwgYWxsIC1ETk9fTU9EVUxFU19PQkoKY2MgLWMgLXggYXNzZW1ibGVy LXdpdGgtY3BwIC1ETE9DT1JFIC1PIC1waXBlIC1tYXJjaD1uYXRpdmUgLXN0ZD1jOTkgLWcgLVdh bGwgLVdyZWR1bmRhbnQtZGVjbHMgLVduZXN0ZWQtZXh0ZXJucyAtV3N0cmljdC1wcm90b3R5cGVz ICAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVdpbmxpbmUgLVdjYXN0LXF1 YWwgIC1XdW5kZWYgLVduby1wb2ludGVyLXNpZ24gLWZmb3JtYXQtZXh0ZW5zaW9ucyAtbm9zdGRp bmMgIC1JLiAtSS91c3Ivc3JjL3N5cyAtSS91c3Ivc3JjL3N5cy9jb250cmliL2FsdHEgLURfS0VS TkVMIC1ESEFWRV9LRVJORUxfT1BUSU9OX0hFQURFUlMgLWluY2x1ZGUgb3B0X2dsb2JhbC5oIC1m bm8tY29tbW9uIC1maW5saW5lLWxpbWl0PTgwMDAgLS1wYXJhbSBpbmxpbmUtdW5pdC1ncm93dGg9 MTAwIC0tcGFyYW0gbGFyZ2UtZnVuY3Rpb24tZ3Jvd3RoPTEwMDAgIC1tbm8tYWxpZ24tbG9uZy1z dHJpbmdzIC1tcHJlZmVycmVkLXN0YWNrLWJvdW5kYXJ5PTIgIC1tbm8tbW14IC1tbm8tM2Rub3cg LW1uby1zc2UgLW1uby1zc2UyIC1tbm8tc3NlMyAtZmZyZWVzdGFuZGluZyAtZnN0YWNrLXByb3Rl Y3RvciAtV2Vycm9yIC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvbG9jb3JlLnMKY2MgLWMgLU8gLXBp cGUgLW1hcmNoPW5hdGl2ZSAtc3RkPWM5OSAtZyAtV2FsbCAtV3JlZHVuZGFudC1kZWNscyAtV25l c3RlZC1leHRlcm5zIC1Xc3RyaWN0LXByb3RvdHlwZXMgIC1XbWlzc2luZy1wcm90b3R5cGVzIC1X cG9pbnRlci1hcml0aCAtV2lubGluZSAtV2Nhc3QtcXVhbCAgLVd1bmRlZiAtV25vLXBvaW50ZXIt c2lnbiAtZmZvcm1hdC1leHRlbnNpb25zIC1ub3N0ZGluYyAgLUkuIC1JL3Vzci9zcmMvc3lzIC1J L3Vzci9zcmMvc3lzL2NvbnRyaWIvYWx0cSAtRF9LRVJORUwgLURIQVZFX0tFUk5FTF9PUFRJT05f SEVBREVSUyAtaW5jbHVkZSBvcHRfZ2xvYmFsLmggLWZuby1jb21tb24gLWZpbmxpbmUtbGltaXQ9 ODAwMCAtLXBhcmFtIGlubGluZS11bml0LWdyb3d0aD0xMDAgLS1wYXJhbSBsYXJnZS1mdW5jdGlv bi1ncm93dGg9MTAwMCAgLW1uby1hbGlnbi1sb25nLXN0cmluZ3MgLW1wcmVmZXJyZWQtc3RhY2st Ym91bmRhcnk9MiAgLW1uby1tbXggLW1uby0zZG5vdyAtbW5vLXNzZSAtbW5vLXNzZTIgLW1uby1z c2UzIC1mZnJlZXN0YW5kaW5nIC1mc3RhY2stcHJvdGVjdG9yIC1XZXJyb3IgIC91c3Ivc3JjL3N5 cy9jYW0vY2FtLmMKY2MgLWMgLU8gLXBpcGUgLW1hcmNoPW5hdGl2ZSAtc3RkPWM5OSAtZyAtV2Fs bCAtV3JlZHVuZGFudC1kZWNscyAtV25lc3RlZC1leHRlcm5zIC1Xc3RyaWN0LXByb3RvdHlwZXMg IC1XbWlzc2luZy1wcm90b3R5cGVzIC1XcG9pbnRlci1hcml0aCAtV2lubGluZSAtV2Nhc3QtcXVh bCAgLVd1bmRlZiAtV25vLXBvaW50ZXItc2lnbiAtZmZvcm1hdC1leHRlbnNpb25zIC1ub3N0ZGlu YyAgLUkuIC1JL3Vzci9zcmMvc3lzIC1JL3Vzci9zcmMvc3lzL2NvbnRyaWIvYWx0cSAtRF9LRVJO RUwgLURIQVZFX0tFUk5FTF9PUFRJT05fSEVBREVSUyAtaW5jbHVkZSBvcHRfZ2xvYmFsLmggLWZu by1jb21tb24gLWZpbmxpbmUtbGltaXQ9ODAwMCAtLXBhcmFtIGlubGluZS11bml0LWdyb3d0aD0x MDAgLS1wYXJhbSBsYXJnZS1mdW5jdGlvbi1ncm93dGg9MTAwMCAgLW1uby1hbGlnbi1sb25nLXN0 cmluZ3MgLW1wcmVmZXJyZWQtc3RhY2stYm91bmRhcnk9MiAgLW1uby1tbXggLW1uby0zZG5vdyAt bW5vLXNzZSAtbW5vLXNzZTIgLW1uby1zc2UzIC1mZnJlZXN0YW5kaW5nIC1mc3RhY2stcHJvdGVj dG9yIC1XZXJyb3IgIC91c3Ivc3JjL3N5cy9jYW0vY2FtX3BlcmlwaC5jCmNjIC1jIC1PIC1waXBl IC1tYXJjaD1uYXRpdmUgLXN0ZD1jOTkgLWcgLVdhbGwgLVdyZWR1bmRhbnQtZGVjbHMgLVduZXN0 ZWQtZXh0ZXJucyAtV3N0cmljdC1wcm90b3R5cGVzICAtV21pc3NpbmctcHJvdG90eXBlcyAtV3Bv aW50ZXItYXJpdGggLVdpbmxpbmUgLVdjYXN0LXF1YWwgIC1XdW5kZWYgLVduby1wb2ludGVyLXNp Z24gLWZmb3JtYXQtZXh0ZW5zaW9ucyAtbm9zdGRpbmMgIC1JLiAtSS91c3Ivc3JjL3N5cyAtSS91 c3Ivc3JjL3N5cy9jb250cmliL2FsdHEgLURfS0VSTkVMIC1ESEFWRV9LRVJORUxfT1BUSU9OX0hF QURFUlMgLWluY2x1ZGUgb3B0X2dsb2JhbC5oIC1mbm8tY29tbW9uIC1maW5saW5lLWxpbWl0PTgw MDAgLS1wYXJhbSBpbmxpbmUtdW5pdC1ncm93dGg9MTAwIC0tcGFyYW0gbGFyZ2UtZnVuY3Rpb24t Z3Jvd3RoPTEwMDAgIC1tbm8tYWxpZ24tbG9uZy1zdHJpbmdzIC1tcHJlZmVycmVkLXN0YWNrLWJv dW5kYXJ5PTIgIC1tbm8tbW14IC1tbm8tM2Rub3cgLW1uby1zc2UgLW1uby1zc2UyIC1tbm8tc3Nl MyAtZmZyZWVzdGFuZGluZyAtZnN0YWNrLXByb3RlY3RvciAtV2Vycm9yICAvdXNyL3NyYy9zeXMv Y2FtL2NhbV9xdWV1ZS5jCmNjIC1jIC1PIC1waXBlIC1tYXJjaD1uYXRpdmUgLXN0ZD1jOTkgLWcg LVdhbGwgLVdyZWR1bmRhbnQtZGVjbHMgLVduZXN0ZWQtZXh0ZXJucyAtV3N0cmljdC1wcm90b3R5 cGVzICAtV21pc3NpbmctcHJvdG90eXBlcyAtV3BvaW50ZXItYXJpdGggLVdpbmxpbmUgLVdjYXN0 LXF1YWwgIC1XdW5kZWYgLVduby1wb2ludGVyLXNpZ24gLWZmb3JtYXQtZXh0ZW5zaW9ucyAtbm9z dGRpbmMgIC1JLiAtSS91c3Ivc3JjL3N5cyAtSS91c3Ivc3JjL3N5cy9jb250cmliL2FsdHEgLURf S0VSTkVMIC1ESEFWRV9LRVJORUxfT1BUSU9OX0hFQURFUlMgLWluY2x1ZGUgb3B0X2dsb2JhbC5o IC1mbm8tY29tbW9uIC1maW5saW5lLWxpbWl0PTgwMDAgLS1wYXJhbSBpbmxpbmUtdW5pdC1ncm93 dGg9MTAwIC0tcGFyYW0gbGFyZ2UtZnVuY3Rpb24tZ3Jvd3RoPTEwMDAgIC1tbm8tYWxpZ24tbG9u Zy1zdHJpbmdzIC1tcHJlZmVycmVkLXN0YWNrLWJvdW5kYXJ5PTIgIC1tbm8tbW14IC1tbm8tM2Ru b3cgLW1uby1zc2UgLW1uby1zc2UyIC1tbm8tc3NlMyAtZmZyZWVzdGFuZGluZyAtZnN0YWNrLXBy b3RlY3RvciAtV2Vycm9yICAvdXNyL3NyYy9zeXMvY2FtL2NhbV9zaW0uYwpjYyAtYyAtTyAtcGlw ZSAtbWFyY2g9bmF0aXZlIC1zdGQ9Yzk5IC1nIC1XYWxsIC1XcmVkdW5kYW50LWRlY2xzIC1XbmVz dGVkLWV4dGVybnMgLVdzdHJpY3QtcHJvdG90eXBlcyAgLVdtaXNzaW5nLXByb3RvdHlwZXMgLVdw b2ludGVyLWFyaXRoIC1XaW5saW5lIC1XY2FzdC1xdWFsICAtV3VuZGVmIC1Xbm8tcG9pbnRlci1z aWduIC1mZm9ybWF0LWV4dGVuc2lvbnMgLW5vc3RkaW5jICAtSS4gLUkvdXNyL3NyYy9zeXMgLUkv dXNyL3NyYy9zeXMvY29udHJpYi9hbHRxIC1EX0tFUk5FTCAtREhBVkVfS0VSTkVMX09QVElPTl9I RUFERVJTIC1pbmNsdWRlIG9wdF9nbG9iYWwuaCAtZm5vLWNvbW1vbiAtZmlubGluZS1saW1pdD04 MDAwIC0tcGFyYW0gaW5saW5lLXVuaXQtZ3Jvd3RoPTEwMCAtLXBhcmFtIGxhcmdlLWZ1bmN0aW9u LWdyb3d0aD0xMDAwICAtbW5vLWFsaWduLWxvbmctc3RyaW5ncyAtbXByZWZlcnJlZC1zdGFjay1i b3VuZGFyeT0yICAtbW5vLW1teCAtbW5vLTNkbm93IC1tbm8tc3NlIC1tbm8tc3NlMiAtbW5vLXNz ZTMgLWZmcmVlc3RhbmRpbmcgLWZzdGFjay1wcm90ZWN0b3IgLVdlcnJvciAgL3Vzci9zcmMvc3lz L2NhbS9jYW1feHB0LmMKSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC91c3Ivc3JjL3N5cy9jYW0vY2Ft X3hwdC5jOjY0OgovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRfaW50ZXJuYWwuaDoxNzk6IGVycm9y OiByZWRlZmluaXRpb24gb2YgdHlwZWRlZiAneHB0X2FsbG9jX2RldmljZV9mdW5jJwovdXNyL3Ny Yy9zeXMvY2FtL2NhbV94cHRfaW50ZXJuYWwuaDo3OiBlcnJvcjogcHJldmlvdXMgZGVjbGFyYXRp b24gb2YgJ3hwdF9hbGxvY19kZXZpY2VfZnVuYycgd2FzIGhlcmUKL3Vzci9zcmMvc3lzL2NhbS9j YW1feHB0X2ludGVybmFsLmg6MTgyOiBlcnJvcjogcmVkZWZpbml0aW9uIG9mIHR5cGVkZWYgJ3hw dF9yZWxlYXNlX2RldmljZV9mdW5jJwovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRfaW50ZXJuYWwu aDoxMDogZXJyb3I6IHByZXZpb3VzIGRlY2xhcmF0aW9uIG9mICd4cHRfcmVsZWFzZV9kZXZpY2Vf ZnVuYycgd2FzIGhlcmUKL3Vzci9zcmMvc3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6MTgzOiBl cnJvcjogcmVkZWZpbml0aW9uIG9mIHR5cGVkZWYgJ3hwdF9hY3Rpb25fZnVuYycKL3Vzci9zcmMv c3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6MTE6IGVycm9yOiBwcmV2aW91cyBkZWNsYXJhdGlv biBvZiAneHB0X2FjdGlvbl9mdW5jJyB3YXMgaGVyZQovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRf aW50ZXJuYWwuaDoxODg6IGVycm9yOiByZWRlZmluaXRpb24gb2YgdHlwZWRlZiAneHB0X2Rldl9h c3luY19mdW5jJwovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRfaW50ZXJuYWwuaDoxNjogZXJyb3I6 IHByZXZpb3VzIGRlY2xhcmF0aW9uIG9mICd4cHRfZGV2X2FzeW5jX2Z1bmMnIHdhcyBoZXJlCi91 c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjE5MDogZXJyb3I6IHJlZGVmaW5pdGlv biBvZiB0eXBlZGVmICd4cHRfYW5ub3VuY2VfcGVyaXBoX2Z1bmMnCi91c3Ivc3JjL3N5cy9jYW0v Y2FtX3hwdF9pbnRlcm5hbC5oOjE4OiBlcnJvcjogcHJldmlvdXMgZGVjbGFyYXRpb24gb2YgJ3hw dF9hbm5vdW5jZV9wZXJpcGhfZnVuYycgd2FzIGhlcmUKL3Vzci9zcmMvc3lzL2NhbS9jYW1feHB0 X2ludGVybmFsLmg6MTkyOiBlcnJvcjogcmVkZWZpbml0aW9uIG9mICdzdHJ1Y3QgeHB0X3hwb3J0 JwovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRfaW50ZXJuYWwuaDoyMDU6IGVycm9yOiByZWRlZmlu aXRpb24gb2YgJ3N0cnVjdCBjYW1fZWRfcWluZm8nCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9p bnRlcm5hbC5oOjIxNTogZXJyb3I6IHJlZGVmaW5pdGlvbiBvZiAnc3RydWN0IGNhbV9lZCcKL3Vz ci9zcmMvc3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6MjczOiBlcnJvcjogcmVkZWZpbml0aW9u IG9mICdzdHJ1Y3QgY2FtX2V0JwovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRfaW50ZXJuYWwuaDoy ODg6IGVycm9yOiByZWRlZmluaXRpb24gb2YgJ3N0cnVjdCBjYW1fZWInCi91c3Ivc3JjL3N5cy9j YW0vY2FtX3hwdF9pbnRlcm5hbC5oOjMwMjogZXJyb3I6IHJlZGVmaW5pdGlvbiBvZiAnc3RydWN0 IGNhbV9wYXRoJwpjYzE6IHdhcm5pbmdzIGJlaW5nIHRyZWF0ZWQgYXMgZXJyb3JzCi91c3Ivc3Jj L3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjMwOTogd2FybmluZzogcmVkdW5kYW50IHJlZGVj bGFyYXRpb24gb2YgJ3Njc2lfZ2V0X3hwb3J0JwovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRfaW50 ZXJuYWwuaDoxMzc6IHdhcm5pbmc6IHByZXZpb3VzIGRlY2xhcmF0aW9uIG9mICdzY3NpX2dldF94 cG9ydCcgd2FzIGhlcmUKL3Vzci9zcmMvc3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6MzEwOiB3 YXJuaW5nOiByZWR1bmRhbnQgcmVkZWNsYXJhdGlvbiBvZiAnYXRhX2dldF94cG9ydCcKL3Vzci9z cmMvc3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6MTM4OiB3YXJuaW5nOiBwcmV2aW91cyBkZWNs YXJhdGlvbiBvZiAnYXRhX2dldF94cG9ydCcgd2FzIGhlcmUKL3Vzci9zcmMvc3lzL2NhbS9jYW1f eHB0X2ludGVybmFsLmg6MzE0OiB3YXJuaW5nOiByZWR1bmRhbnQgcmVkZWNsYXJhdGlvbiBvZiAn eHB0X2FsbG9jX2RldmljZScKL3Vzci9zcmMvc3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6MTQy OiB3YXJuaW5nOiBwcmV2aW91cyBkZWNsYXJhdGlvbiBvZiAneHB0X2FsbG9jX2RldmljZScgd2Fz IGhlcmUKL3Vzci9zcmMvc3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6MzE1OiB3YXJuaW5nOiBy ZWR1bmRhbnQgcmVkZWNsYXJhdGlvbiBvZiAneHB0X3J1bl9kZXZfc2VuZHEnCi91c3Ivc3JjL3N5 cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjE0Mzogd2FybmluZzogcHJldmlvdXMgZGVjbGFyYXRp b24gb2YgJ3hwdF9ydW5fZGV2X3NlbmRxJyB3YXMgaGVyZQovdXNyL3NyYy9zeXMvY2FtL2NhbV94 cHRfaW50ZXJuYWwuaDozMTc6IHdhcm5pbmc6IHJlZHVuZGFudCByZWRlY2xhcmF0aW9uIG9mICd4 cHRfc2NoZWR1bGVfZGV2JwovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRfaW50ZXJuYWwuaDoxNDU6 IHdhcm5pbmc6IHByZXZpb3VzIGRlY2xhcmF0aW9uIG9mICd4cHRfc2NoZWR1bGVfZGV2JyB3YXMg aGVyZQovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRfaW50ZXJuYWwuaDozMTg6IHdhcm5pbmc6IHJl ZHVuZGFudCByZWRlY2xhcmF0aW9uIG9mICd4cHRfZGV2X2NjYnFfcmVzaXplJwovdXNyL3NyYy9z eXMvY2FtL2NhbV94cHRfaW50ZXJuYWwuaDoxNDY6IHdhcm5pbmc6IHByZXZpb3VzIGRlY2xhcmF0 aW9uIG9mICd4cHRfZGV2X2NjYnFfcmVzaXplJyB3YXMgaGVyZQovdXNyL3NyYy9zeXMvY2FtL2Nh bV94cHRfaW50ZXJuYWwuaDozMjQ6IGVycm9yOiByZWRlZmluaXRpb24gb2YgJ3hwdF9zY2hlZHVs ZV9kZXZfc2VuZHEnCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjE1MjogZXJy b3I6IHByZXZpb3VzIGRlZmluaXRpb24gb2YgJ3hwdF9zY2hlZHVsZV9kZXZfc2VuZHEnIHdhcyBo ZXJlCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjM0Mzogd2FybmluZzogcmVk dW5kYW50IHJlZGVjbGFyYXRpb24gb2YgJ01fQ0FNWFBUJwovdXNyL3NyYy9zeXMvY2FtL2NhbV94 cHRfaW50ZXJuYWwuaDoxNzE6IHdhcm5pbmc6IHByZXZpb3VzIGRlY2xhcmF0aW9uIG9mICdNX0NB TVhQVCcgd2FzIGhlcmUKL3Vzci9zcmMvc3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6MzUxOiBl cnJvcjogcmVkZWZpbml0aW9uIG9mIHR5cGVkZWYgJ3hwdF9hbGxvY19kZXZpY2VfZnVuYycKL3Vz ci9zcmMvc3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6MTc5OiBlcnJvcjogcHJldmlvdXMgZGVj bGFyYXRpb24gb2YgJ3hwdF9hbGxvY19kZXZpY2VfZnVuYycgd2FzIGhlcmUKL3Vzci9zcmMvc3lz L2NhbS9jYW1feHB0X2ludGVybmFsLmg6MzU0OiBlcnJvcjogcmVkZWZpbml0aW9uIG9mIHR5cGVk ZWYgJ3hwdF9yZWxlYXNlX2RldmljZV9mdW5jJwovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRfaW50 ZXJuYWwuaDoxODI6IGVycm9yOiBwcmV2aW91cyBkZWNsYXJhdGlvbiBvZiAneHB0X3JlbGVhc2Vf ZGV2aWNlX2Z1bmMnIHdhcyBoZXJlCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5o OjM1NTogZXJyb3I6IHJlZGVmaW5pdGlvbiBvZiB0eXBlZGVmICd4cHRfYWN0aW9uX2Z1bmMnCi91 c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjE4MzogZXJyb3I6IHByZXZpb3VzIGRl Y2xhcmF0aW9uIG9mICd4cHRfYWN0aW9uX2Z1bmMnIHdhcyBoZXJlCi91c3Ivc3JjL3N5cy9jYW0v Y2FtX3hwdF9pbnRlcm5hbC5oOjM2MDogZXJyb3I6IHJlZGVmaW5pdGlvbiBvZiB0eXBlZGVmICd4 cHRfZGV2X2FzeW5jX2Z1bmMnCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjE4 ODogZXJyb3I6IHByZXZpb3VzIGRlY2xhcmF0aW9uIG9mICd4cHRfZGV2X2FzeW5jX2Z1bmMnIHdh cyBoZXJlCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjM2MjogZXJyb3I6IHJl ZGVmaW5pdGlvbiBvZiB0eXBlZGVmICd4cHRfYW5ub3VuY2VfcGVyaXBoX2Z1bmMnCi91c3Ivc3Jj L3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjE5MDogZXJyb3I6IHByZXZpb3VzIGRlY2xhcmF0 aW9uIG9mICd4cHRfYW5ub3VuY2VfcGVyaXBoX2Z1bmMnIHdhcyBoZXJlCi91c3Ivc3JjL3N5cy9j YW0vY2FtX3hwdF9pbnRlcm5hbC5oOjM2NDogZXJyb3I6IHJlZGVmaW5pdGlvbiBvZiAnc3RydWN0 IHhwdF94cG9ydCcKL3Vzci9zcmMvc3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6Mzc3OiBlcnJv cjogcmVkZWZpbml0aW9uIG9mICdzdHJ1Y3QgY2FtX2VkX3FpbmZvJwovdXNyL3NyYy9zeXMvY2Ft L2NhbV94cHRfaW50ZXJuYWwuaDozODc6IGVycm9yOiByZWRlZmluaXRpb24gb2YgJ3N0cnVjdCBj YW1fZWQnCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjQ0NTogZXJyb3I6IHJl ZGVmaW5pdGlvbiBvZiAnc3RydWN0IGNhbV9ldCcKL3Vzci9zcmMvc3lzL2NhbS9jYW1feHB0X2lu dGVybmFsLmg6NDYwOiBlcnJvcjogcmVkZWZpbml0aW9uIG9mICdzdHJ1Y3QgY2FtX2ViJwovdXNy L3NyYy9zeXMvY2FtL2NhbV94cHRfaW50ZXJuYWwuaDo0NzQ6IGVycm9yOiByZWRlZmluaXRpb24g b2YgJ3N0cnVjdCBjYW1fcGF0aCcKL3Vzci9zcmMvc3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6 NDgxOiB3YXJuaW5nOiByZWR1bmRhbnQgcmVkZWNsYXJhdGlvbiBvZiAnc2NzaV9nZXRfeHBvcnQn Ci91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjMwOTogd2FybmluZzogcHJldmlv dXMgZGVjbGFyYXRpb24gb2YgJ3Njc2lfZ2V0X3hwb3J0JyB3YXMgaGVyZQovdXNyL3NyYy9zeXMv Y2FtL2NhbV94cHRfaW50ZXJuYWwuaDo0ODI6IHdhcm5pbmc6IHJlZHVuZGFudCByZWRlY2xhcmF0 aW9uIG9mICdhdGFfZ2V0X3hwb3J0JwovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRfaW50ZXJuYWwu aDozMTA6IHdhcm5pbmc6IHByZXZpb3VzIGRlY2xhcmF0aW9uIG9mICdhdGFfZ2V0X3hwb3J0JyB3 YXMgaGVyZQovdXNyL3NyYy9zeXMvY2FtL2NhbV94cHRfaW50ZXJuYWwuaDo0ODY6IHdhcm5pbmc6 IHJlZHVuZGFudCByZWRlY2xhcmF0aW9uIG9mICd4cHRfYWxsb2NfZGV2aWNlJwovdXNyL3NyYy9z eXMvY2FtL2NhbV94cHRfaW50ZXJuYWwuaDozMTQ6IHdhcm5pbmc6IHByZXZpb3VzIGRlY2xhcmF0 aW9uIG9mICd4cHRfYWxsb2NfZGV2aWNlJyB3YXMgaGVyZQovdXNyL3NyYy9zeXMvY2FtL2NhbV94 cHRfaW50ZXJuYWwuaDo0ODc6IHdhcm5pbmc6IHJlZHVuZGFudCByZWRlY2xhcmF0aW9uIG9mICd4 cHRfcnVuX2Rldl9zZW5kcScKL3Vzci9zcmMvc3lzL2NhbS9jYW1feHB0X2ludGVybmFsLmg6MzE1 OiB3YXJuaW5nOiBwcmV2aW91cyBkZWNsYXJhdGlvbiBvZiAneHB0X3J1bl9kZXZfc2VuZHEnIHdh cyBoZXJlCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjQ4OTogd2FybmluZzog cmVkdW5kYW50IHJlZGVjbGFyYXRpb24gb2YgJ3hwdF9zY2hlZHVsZV9kZXYnCi91c3Ivc3JjL3N5 cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjMxNzogd2FybmluZzogcHJldmlvdXMgZGVjbGFyYXRp b24gb2YgJ3hwdF9zY2hlZHVsZV9kZXYnIHdhcyBoZXJlCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hw dF9pbnRlcm5hbC5oOjQ5MDogd2FybmluZzogcmVkdW5kYW50IHJlZGVjbGFyYXRpb24gb2YgJ3hw dF9kZXZfY2NicV9yZXNpemUnCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjMx ODogd2FybmluZzogcHJldmlvdXMgZGVjbGFyYXRpb24gb2YgJ3hwdF9kZXZfY2NicV9yZXNpemUn IHdhcyBoZXJlCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjQ5NjogZXJyb3I6 IHJlZGVmaW5pdGlvbiBvZiAneHB0X3NjaGVkdWxlX2Rldl9zZW5kcScKL3Vzci9zcmMvc3lzL2Nh bS9jYW1feHB0X2ludGVybmFsLmg6MzI0OiBlcnJvcjogcHJldmlvdXMgZGVmaW5pdGlvbiBvZiAn eHB0X3NjaGVkdWxlX2Rldl9zZW5kcScgd2FzIGhlcmUKL3Vzci9zcmMvc3lzL2NhbS9jYW1feHB0 X2ludGVybmFsLmg6NTE1OiB3YXJuaW5nOiByZWR1bmRhbnQgcmVkZWNsYXJhdGlvbiBvZiAnTV9D QU1YUFQnCi91c3Ivc3JjL3N5cy9jYW0vY2FtX3hwdF9pbnRlcm5hbC5oOjM0Mzogd2FybmluZzog cHJldmlvdXMgZGVjbGFyYXRpb24gb2YgJ01fQ0FNWFBUJyB3YXMgaGVyZQoqKiogRXJyb3IgY29k ZSAxCgpTdG9wIGluIC91c3Ivb2JqL3Vzci9zcmMvc3lzL0FSVU5ERUwuCioqKiBFcnJvciBjb2Rl IDEKClN0b3AgaW4gL3Vzci9zcmMuCioqKiBFcnJvciBjb2RlIDEKClN0b3AgaW4gL3Vzci9zcmMu Cg== --+permail-2009062812291180e26a0b00000f15-a_best01+ Content-Type: application/octet-stream Content-Transfer-Encoding: Base64 Content-Disposition: attachment; filename="arundel" IyBERUJVRyBvcHRpb25zCm9wdGlvbnMJCUtEQgkJCSNDb21waWxlIHdpdGgga2VybmVsIGRlYnVn Z2VyIHJlbGF0ZWQgY29kZQpvcHRpb25zCQlLREJfVU5BVFRFTkRFRApvcHRpb25zCQlLREJfVFJB Q0UJCSNQcmludCBhIHN0YWNrIHRyYWNlIG9mIHRoZSBjdXJyZW50IHRocmVhZCBvbiB0aGUgY29u c29sZSBmb3IgYSBwYW5pYy4Kb3B0aW9ucwkJUFJFRU1QVElPTgpvcHRpb25zCQlJUElfUFJFRU1Q VElPTgpvcHRpb25zCQlEREIKCm1ha2VvcHRpb25zCURFQlVHPS1nCm9wdGlvbnMJCUlOVkFSSUFO VFMKb3B0aW9ucwkJSU5WQVJJQU5UX1NVUFBPUlQKb3B0aW9ucwkJV0lUTkVTUwpvcHRpb25zCQlE RUJVR19MT0NLUwpvcHRpb25zCQlERUJVR19WRlNfTE9DS1MKb3B0aW9ucwkJRElBR05PU1RJQwpv cHRpb25zCQlTV19XQVRDSERPRwpvcHRpb25zCQlLVFJBQ0UJCQkjIGt0cmFjZSgxKSBzdXBwb3J0 Cm9wdGlvbnMJCVNPQ0tCVUZfREVCVUcKb3B0aW9ucwkJREVCVUdfTUVNR1VBUkQKCmNwdQkJSTY4 Nl9DUFUKaWRlbnQJCUFSVU5ERUwKCm9wdGlvbnMJCVNDSEVEX1VMRQkJI1VMRSBzY2hlZHVsZXIK b3B0aW9ucwkJU0NIRURfU1RBVFMKb3B0aW9ucyAJSU5FVAkJCSNJbnRlck5FVHdvcmtpbmcKb3B0 aW9ucwkJUFJPQ0ZTCQkJI1Byb2Nlc3MgZmlsZXN5c3RlbSAocmVxdWlyZXMgUFNFVURPRlMpCm9w dGlvbnMJCVBTRVVET0ZTCQkjUHNldWRvLWZpbGVzeXN0ZW0gZnJhbWV3b3JrCm9wdGlvbnMJCUxJ QklDT05WCQkjS2VybmVsIHNpZGUgaWNvbnYgbGlicmFyeQpvcHRpb25zCQlDRDk2NjAJCQkjSVNP IDk2NjAgZmlsZXN5c3RlbQojb3B0aW9ucwkJQ0Q5NjYwX0lDT05WCm9wdGlvbnMJCU1TRE9TRlMJ CQkjTVMgRE9TIEZpbGUgU3lzdGVtIChGQVQsIEZBVDMyKQpvcHRpb25zCQlNU0RPU0ZTX0lDT05W Cm9wdGlvbnMgCUZGUwkJCSNCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJU09GVFVQ REFURVMJCSNFbmFibGUgRkZTIHNvZnQgdXBkYXRlcyBzdXBwb3J0Cm9wdGlvbnMgCVVGU19ESVJI QVNICQkjSW1wcm92ZSBwZXJmb3JtYW5jZSBvbiBiaWcgZGlyZWN0b3JpZXMKb3B0aW9ucwkJQ09N UEFUX0xJTlVYCQkjIEVuYWJsZSBMaW51eCBBQkkgZW11bGF0aW9uCm9wdGlvbnMJCUNPTVBBVF9G UkVFQlNENQpvcHRpb25zCQlDT01QQVRfRlJFRUJTRDcKb3B0aW9ucwkJTElOUFJPQ0ZTCQkjIEVu YWJsZSB0aGUgbGludXgtbGlrZSBwcm9jIGZpbGVzeXN0ZW0gc3VwcG9ydApvcHRpb25zCQlMSU5T WVNGUwkJIyBFbmFibGUgdGhlIGxpbnV4LWxpa2Ugc3lzIGZpbGVzeXN0ZW0gc3VwcG9ydAoKb3B0 aW9ucwkJU0NfSElTVE9SWV9TSVpFPTEwMDAJI251bWJlciBvZiBoaXN0b3J5IGJ1ZmZlciBsaW5l cwpvcHRpb25zCQlNU0dCVUZfU0laRT00MDk2MDAJIyBTaXplIG9mIHRoZSBrZXJuZWwgbWVzc2Fn ZSBidWZmZXIuICBTaG91bGQgYmUgTiAqIHBhZ2VzaXplLgpvcHRpb25zIAlTWVNWU0hNCQkJI1NZ U1Ytc3R5bGUgc2hhcmVkIG1lbW9yeQpvcHRpb25zIAlTWVNWTVNHCQkJI1NZU1Ytc3R5bGUgbWVz c2FnZSBxdWV1ZXMKb3B0aW9ucyAJU1lTVlNFTQkJCSNTWVNWLXN0eWxlIHNlbWFwaG9yZXMKb3B0 aW9ucyAJX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HICMgUE9TSVggUDEwMDNfMUIgcmVhbC10 aW1lIGV4dGVuc2lvbnMKb3B0aW9ucyAJS0JEX0lOU1RBTExfQ0RFVgkjaW5zdGFsbCBhIENERVYg ZW50cnkgaW4gL2RldgpvcHRpb25zCQlVS0JEX0RGTFRfS0VZTUFQCSNzcGVjaWZ5IHRoZSBidWls dC1pbiBrZXltYXAKbWFrZW9wdGlvbnMJVUtCRF9ERkxUX0tFWU1BUD0iZ2VybWFuLmlzbyIKCiNk ZXZpY2UJCWF0a2JkCiNkZXZpY2UJCWF0a2JkYwojbWFrZW9wdGlvbnMJQVRLQkRfREZMVF9LRVlN QVA9Imdlcm1hbi5pc28iCgpvcHRpb25zCQlTTVAJCQkjIFN5bW1ldHJpYyBNdWx0aVByb2Nlc3Nv ciBLZXJuZWwKb3B0aW9ucwkJUFJJTlRGX0JVRlJfU0laRT0xMjgKZGV2aWNlCQlhcGljCQkJIyBJ L08gQVBJQwoKI2RldmljZXMKZGV2aWNlCQllaXNhCmRldmljZQkJcGNpCiNkZXZpY2UJCWF0YQoK ZGV2aWNlCQlhdGFjb3JlCmRldmljZQkJYXRhYWhjaQpkZXZpY2UJCWF0YWptaWNyb24KZGV2aWNl CQlhdGFpbnRlbApkZXZpY2UJCWF0YXBjaQpkZXZpY2UJCWF0YWRpc2sKZGV2aWNlCQlhdGFwaWNk CmRldmljZQkJYXRhdXNiCgpkZXZpY2UJCXZnYQpkZXZpY2UJCXNjCgojdXNiCmRldmljZQkJdXNi CmRldmljZQkJdWhjaQpkZXZpY2UJCWVoY2kKZGV2aWNlCQl1a2JkCmRldmljZQkJdWxwdApkZXZp Y2UJCXVtYXNzCmRldmljZQkJdW1zCmRldmljZQkJdWhpZAojbWFrZW9wdGlvbnMJV0lUSF9MRUdB Q1kKCiNuZXR3b3JrCmRldmljZQkJd2xhbgpkZXZpY2UJCWF0aApkZXZpY2UJCWF0aF9oYWwKb3B0 aW9ucwkJQUhfU1VQUE9SVF9BUjU0MTYKZGV2aWNlCQlhdGhfcmF0ZV9zYW1wbGUKZGV2aWNlCQl3 bGFuX3dlcAojb3B0aW9ucwkJSUVFRTgwMjExX0RFQlVHCiNvcHRpb25zCQlBVEhfREVCVUcKCmRl dmljZQkJY3B1ZnJlcQpkZXZpY2UJCWNvcmV0ZW1wCgojcHNldWRvIGRldmljZXMKZGV2aWNlCQls b29wCmRldmljZQkJZXRoZXIKZGV2aWNlCQlwdHkKZGV2aWNlCQltZAoKI21pc2MKZGV2aWNlCQlz Y2J1cwpkZXZpY2UJCWNkCmRldmljZQkJcGFzcwpkZXZpY2UJCWRhCiMjZGV2aWNlCQlhdGFwaWNh bQpkZXZpY2UJCWFoY2kKZGV2aWNlCQlzb3VuZApkZXZpY2UJCXNuZF9oZGEKZGV2aWNlCQlyYW5k b20KCiNHRU9NCm9wdGlvbnMJCUdFT01fTEFCRUwKb3B0aW9ucwkJR0VPTV9WT0wKb3B0aW9ucwkJ R0VPTV9QQVJUX0dQVApvcHRpb25zCQlHRU9NX1BBUlRfTUJSCg== --+permail-2009062812291180e26a0b00000f15-a_best01+-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 12:39:31 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 84D9E1065670; Sun, 28 Jun 2009 12:39:31 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 37A868FC0C; Sun, 28 Jun 2009 12:39:31 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from [85.175.178.149] (helo=moosi) by services.ipt.ru with esmtpa (Exim 4.54 (FreeBSD)) id 1MKtfN-000A57-Lq; Sun, 28 Jun 2009 16:39:29 +0400 To: Juergen Lock References: <20090606162235.GA49444@triton.kn-bremen.de> <43784537@ipt.ru> <66988167@ipt.ru> <747dc8f30906261255s1ecc1420x574ded3be835b448@mail.gmail.com> <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> From: Boris Samorodov Date: Sun, 28 Jun 2009 16:40:20 +0400 In-Reply-To: <20090628082701.GA34665@triton.kn-bremen.de> (Juergen Lock's message of "Sun\, 28 Jun 2009 10\:27\:02 +0200") Message-ID: <56244219@ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Renato Botelho , freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, "Sean C. Farley" Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 12:39:31 -0000 Juergen Lock writes: > New patch and shar: No more comments from me, thanks! WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 12:46:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27D23106564A for ; Sun, 28 Jun 2009 12:46:56 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id C94B78FC15 for ; Sun, 28 Jun 2009 12:46:55 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by tydfam.jp (8.14.2/8.14.2) with ESMTP id n5SCksjK061751; Sun, 28 Jun 2009 21:46:55 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Sun, 28 Jun 2009 21:44:17 +0900 (JST) Message-Id: <20090628.214417.598552788769548331.ken@tydfam.jp> To: doconnor@gsoft.com.au From: ken In-Reply-To: <200906252320.32544.doconnor@gsoft.com.au> References: <200906252011.42597.doconnor@gsoft.com.au> <20090625.202617.598552788702437664.ken@tydfam.jp> <200906252320.32544.doconnor@gsoft.com.au> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=9.5 tests=ALL_TRUSTED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on daemon.sub.tydfam.jp Cc: freebsd-current@freebsd.org, admin@kkip.pl Subject: Re: 8.0-current cannot find disk!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 12:46:56 -0000 From: "Daniel O'Connor" > From what I can see it finds ad10 (Hitachi 100Gb on ata5) and ad12 (WD > 100Gb on ata6) disks.. > > ata5 & ata6 are on the JMicron JMB363. > > The question is why sysinstall thinks there are no disks :( > > What happens if you open a Fixit emergency holographic shell and run > echo /dev/ad* I took a little different approach because it looks to be not only sysinstall problem; a) create 7.2R and update src to -current. b) make buildworld && make installworld && make buildkernel && make installkernel c) reboot d) See what happens..... The result is at http://www.tydfam.jp/experimental/boot_photo2/. They are photos ordered by the sequence. And the last one showes 'db > where' result that says something is wrong at malloc_init!! I'll try what you are suggesting tomorrow.. From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 12:58:49 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57F1A1065670 for ; Sun, 28 Jun 2009 12:58:49 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id E9F2D8FC12 for ; Sun, 28 Jun 2009 12:58:48 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id E02261CD00; Sun, 28 Jun 2009 14:58:47 +0200 (CEST) Date: Sun, 28 Jun 2009 14:58:47 +0200 From: Ed Schouten To: Alexander Best Message-ID: <20090628125847.GP48776@hoeg.nl> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="I6qaxAmZPl8kCtac" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 12:58:49 -0000 --I6qaxAmZPl8kCtac Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Alexander, * Alexander Best wrote: > after applying the patchset i cannot recompile my kernel. i've rebuild and > reinstalled world after applying the patches. probably a kernelconf optio= n is > coliding with the ahci device. could somebody take a look at this and tel= l me > what options i need to remove from my kernelconf? It may be possible that you applied the patch twice, which means some files may have duplicate content. --=20 Ed Schouten WWW: http://80386.nl/ --I6qaxAmZPl8kCtac Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpHaQcACgkQ52SDGA2eCwWVLwCfRGnRn99soxOWRehoDU6bBqgl PN0An28wv1gXpQxDuUssa1UTDd9UFlq5 =5EdW -----END PGP SIGNATURE----- --I6qaxAmZPl8kCtac-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:04:05 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A593E1065670; Sun, 28 Jun 2009 13:04:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7D2478FC19; Sun, 28 Jun 2009 13:04:05 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D0D3A46B65; Sun, 28 Jun 2009 09:04:04 -0400 (EDT) Date: Sun, 28 Jun 2009 14:04:04 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Thomas Backman In-Reply-To: <24BDCB76-0304-443A-96A9-71C5E537FF37@exscape.org> Message-ID: References: <200906241741.n5OHfTaw022417@svn.freebsd.org> <4A43893F.5070100@andric.com> <24BDCB76-0304-443A-96A9-71C5E537FF37@exscape.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Jack F Vogel , Dimitry Andric , current@FreeBSD.org Subject: Re: VMWare if_em breakage (was: Re: svn commit: r194865 - in head/sys: dev/e1000 modules/igb) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:04:05 -0000 On Sun, 28 Jun 2009, Thomas Backman wrote: > On Jun 25, 2009, at 04:27 PM, Dimitry Andric wrote: > >> On 2009-06-25 16:08, Robert Watson wrote: >>> Since this change (and the two followups), I'm no longer able to use if_em >>> reliable in VMWare Fusion. >> >> Same here, for VMware Workstation. The interface just stops working after >> a bit of traffic. > > Not sure it's needed, but here's another "me too", also using Fusion. At > first I thought it had frozen, but locally, in the VM window, everything > worked fine. (I always interact with VMs via SSH to get copy/paste, better > fonts etc). Also worth mentioning is that vmware-vmx ate 100% real CPU the > entire time, despite the VM CPU (top in FreeBSD) showed 100% *idle*. Jack suggested this patch for me to test, and it seems to work here, so hopefully he doesn't mind my sharing it until it before it gets into SVN. It seems to entirely prevent the problem from occuring here. Robert N M Watson Computer Laboratory University of Cambridge Index: if_em.c =================================================================== --- if_em.c (revision 195108) +++ if_em.c (working copy) @@ -4446,7 +4446,7 @@ struct mbuf *mp; u8 status, accept_frame = 0, eop = 0; u16 len, desc_len, prev_len_adj; - u32 i, rx_sent = 0; + int i, rx_sent = 0; struct e1000_rx_desc *current_desc; EM_RX_LOCK(adapter); From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:18:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75ADA1065674; Sun, 28 Jun 2009 13:18:37 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by mx1.freebsd.org (Postfix) with ESMTP id A482B8FC19; Sun, 28 Jun 2009 13:18:36 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: by ewy9 with SMTP id 9so2920753ewy.43 for ; Sun, 28 Jun 2009 06:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=XnO120P/HEuzlrl0SjLrmgGQAT1/OAERpkN0C9fVH4k=; b=ClsfAbS8JfgxAZ2JRYUSnVrmLYLmr9fKoXSLItX09wA/Fo+D7Rg/cBvmi2WwQLgy8k 1TdxxEnO6BjY7HgrHQOZVAj/Y7QNM3I1tjDiQ6qOWm3js1IwufyVF+1co74mpEF7RZTt wY2H4lzK7mUQe/JQkzeHKWcQKpZdCWPRCIbSY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=irAcrXBOHnWjJq2i0np42qbeZyIsFat0bje6pcbj9GZIYbHyejQxUptF3gnzH5UKhb 7hRyLyhQWta8f/27IcJmQe84eYieMh23bYzhYjvfsRQIecmaW7vDHhQfuW3IpX4NIKK7 rJDOrWAW/NVUC8d92drewyMX3iyRqsG+HThvY= MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.210.91.7 with SMTP id o7mr2068474ebb.69.1246193482137; Sun, 28 Jun 2009 05:51:22 -0700 (PDT) In-Reply-To: <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> From: Ivan Voras Date: Sun, 28 Jun 2009 14:51:02 +0200 X-Google-Sender-Auth: 0a1d4c3dc2ba9046 Message-ID: <9bbcef730906280551r26e30b61oc84acdd02d94743e@mail.gmail.com> To: Marcel Moolenaar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-geom@freebsd.org Subject: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:18:38 -0000 2009/6/28 Marcel Moolenaar : > Using the last sector is not only flawed because it creates a race > condition, it's flawed in the assumption that you can always make > a geom part of a mirror by storing meta-data on the geom without > causing corruption. This whole idea of using the last sector was > so that a fully partitioned disk with data could be turned into a > mirrored disk. A neat idea, but hardly the basis for a generic > mirroring implementation when it silently corrupts a disk. > > I think it's better to change gmirror to use the first sector on the > provider. Yes, it would be cleaner to implement but it would also make the mirrored devices unbootable. But maybe the class of users needing the functionality is smaller now. > This never creates a race condition and as such, you don't > need to invent a priority scheme, that has it's own set of flaws on > top of it. The only downside is that it's not easy to make a fully > partitioned and populated disk part of a mirror: one would need to > move the data forward one sector to free the first sector. This we > can actually do by inserting a GEOM that does it while I/O is still > ongoing. The good thing is: we need a class that does exactly this > for implementing the "move" verb in gpart. Looks too complicated and fragile. Maybe there's a need for metadata-less automatic mirrors in some way, by storing the configuration somewhere else, possibly in /etc. From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:23:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 388DB10656AD for ; Sun, 28 Jun 2009 13:23:55 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id C00298FC15 for ; Sun, 28 Jun 2009 13:23:54 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,303,1243807200"; d="scan'208";a="6987363" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 28 Jun 2009 15:23:53 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 4825E1B075E; Sun, 28 Jun 2009 15:23:53 +0200 (CEST) Date: Sun, 28 Jun 2009 15:23:52 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Ed Schouten Message-ID: In-Reply-To: <20090628125847.GP48776@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:23:56 -0000 hmmm...i did the following to be sure: cd /usr/src sudo svn up . -> At revision 195136. sudo svn diff -> no output md5 cam-ata.20090626.patch -> MD5 (cam-ata.20090626.patch) = 893f8cb65c0fea384b6b8a8fbc3a9998 sudo patch -p0 -s < cam-ata.20090626.patch -> no output make buildkernel yet the same error. :-( Ed Schouten schrieb am 2009-06-28: > Hi Alexander, > * Alexander Best wrote: > > after applying the patchset i cannot recompile my kernel. i've > > rebuild and > > reinstalled world after applying the patches. probably a kernelconf > > option is > > coliding with the ahci device. could somebody take a look at this > > and tell me > > what options i need to remove from my kernelconf? > It may be possible that you applied the patch twice, which means some > files may have duplicate content. From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:25:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F12411065679 for ; Sun, 28 Jun 2009 13:25:33 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 986628FC1D for ; Sun, 28 Jun 2009 13:25:33 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 6464178F98; Sun, 28 Jun 2009 17:25:30 +0400 (MSD) Message-ID: <4A476F56.2030504@haruhiism.net> Date: Sun, 28 Jun 2009 17:25:42 +0400 From: Aisaka Taiga User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ivan Voras References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> <9bbcef730906280551r26e30b61oc84acdd02d94743e@mail.gmail.com> In-Reply-To: <9bbcef730906280551r26e30b61oc84acdd02d94743e@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org, Marcel Moolenaar , freebsd-questions@freebsd.org, freebsd-current@freebsd.org Subject: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:25:34 -0000 Ivan Voras wrote: > Yes, it would be cleaner to implement but it would also make the > mirrored devices unbootable. > But maybe the class of users needing the functionality is smaller now. > Most dedicated server providers can't afford to use hardware RAID systems because that would drastically increase the price of a single system; yet many customers want mirroring. > Looks too complicated and fragile. Maybe there's a need for > metadata-less automatic mirrors in some way, by storing the > configuration somewhere else, possibly in /etc. This might be dangerous in some cases. Imagine booting with two drives swapped; such a configuration might lead to data corruption on a volume which was enumerated incorrectly or swapped. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:25:55 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F260D1065674 for ; Sun, 28 Jun 2009 13:25:55 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id B64CC8FC18 for ; Sun, 28 Jun 2009 13:25:55 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 269E21CD00; Sun, 28 Jun 2009 15:25:55 +0200 (CEST) Date: Sun, 28 Jun 2009 15:25:55 +0200 From: Ed Schouten To: Alexander Best Message-ID: <20090628132555.GQ48776@hoeg.nl> References: <20090628125847.GP48776@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="btzwrGUqmPmhyR/R" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:25:56 -0000 --btzwrGUqmPmhyR/R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Alexander Best wrote: > sudo svn up . -> At revision 195136. > sudo svn diff -> no output Yes, but what about `svn status --no-ignore'? --=20 Ed Schouten WWW: http://80386.nl/ --btzwrGUqmPmhyR/R Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpHb2MACgkQ52SDGA2eCwV8rACeMj4y2R6azR2Uy4i99u/AYbnm gy0AnjXQuYDdFJh2qRM56hmGsPzSkcY7 =kU35 -----END PGP SIGNATURE----- --btzwrGUqmPmhyR/R-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:29:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31CB1106564A for ; Sun, 28 Jun 2009 13:29:51 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id BB0548FC15 for ; Sun, 28 Jun 2009 13:29:50 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,303,1243807200"; d="scan'208";a="6987628" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 28 Jun 2009 15:29:49 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 9B5FF1B075E; Sun, 28 Jun 2009 15:29:49 +0200 (CEST) Date: Sun, 28 Jun 2009 15:29:49 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Ed Schouten Message-ID: In-Reply-To: <20090628132555.GQ48776@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:29:51 -0000 this is the output: ? cam-ata.20090626.patch ? kdump.diff ? games.diff ? ldd.diff ? usr.bin/kdump/kdump.c.orig ? include/Makefile.orig M include/Makefile ? sbin/camcontrol/camcontrol.c.orig M sbin/camcontrol/camcontrol.c ? tools/kerneldoc/subsys/uart_if.h ? tools/kerneldoc/subsys/pci_if.h ? tools/kerneldoc/subsys/acpi_if.h ? tools/kerneldoc/subsys/cryptodev_if.h ? tools/kerneldoc/subsys/eisa_if.h ? tools/kerneldoc/subsys/serdev_if.h ? tools/kerneldoc/subsys/bus_if.h ? tools/kerneldoc/subsys/usb_if.h ? tools/kerneldoc/subsys/smbus_if.h ? tools/kerneldoc/subsys/clock_if.h ? tools/kerneldoc/subsys/mpufoi_if.h ? tools/kerneldoc/subsys/ac97_if.h ? tools/kerneldoc/subsys/spibus_if.h ? tools/kerneldoc/subsys/ata_if.h ? tools/kerneldoc/subsys/iicbb_if.h ? tools/kerneldoc/subsys/scc_if.h ? tools/kerneldoc/subsys/card_if.h ? tools/kerneldoc/subsys/canbus_if.h ? tools/kerneldoc/subsys/isa_if.h ? tools/kerneldoc/subsys/g_part_if.h ? tools/kerneldoc/subsys/pcib_if.h ? tools/kerneldoc/subsys/iicbus_if.h ? tools/kerneldoc/subsys/mixer_if.h ? tools/kerneldoc/subsys/linker_if.h ? tools/kerneldoc/subsys/mmcbus_if.h ? tools/kerneldoc/subsys/miibus_if.h ? tools/kerneldoc/subsys/ppbus_if.h ? tools/kerneldoc/subsys/feeder_if.h ? tools/kerneldoc/subsys/power_if.h ? tools/kerneldoc/subsys/device_if.h ? tools/kerneldoc/subsys/mmcbr_if.h ? tools/kerneldoc/subsys/mpu_if.h ? tools/kerneldoc/subsys/ofw_bus_if.h ? tools/kerneldoc/subsys/cpufreq_if.h ? tools/kerneldoc/subsys/synth_if.h ? tools/kerneldoc/subsys/iconv_converter_if.h ? tools/kerneldoc/subsys/channel_if.h ? contrib/gcc/config.log ? share/man/man4/ahci.4.orig ? share/man/man4/Makefile.orig ? share/man/man4/ahci.4 M share/man/man4/Makefile ? etc/Makefile.orig ? etc/mtree/BSD.usr.dist.orig ? etc/mtree/BSD.include.dist.orig ? etc/mtree/BSD.var.dist.orig ? etc/mtree/BSD.games.dist.orig ? etc/mtree/BSD.games.dist M etc/mtree/BSD.include.dist I sys/powerpc/conf/LINT I sys/sparc64/conf/LINT ? sys/conf/files.orig M sys/conf/files ? sys/kern/imgact_elf.c.orig ? sys/cam/cam.c.orig ? sys/cam/cam_xpt.h.orig ? sys/cam/cam.h.orig ? sys/cam/cam_periph.c.orig ? sys/cam/cam_xpt_periph.h.orig ? sys/cam/cam_ccb.h.orig ? sys/cam/ata ? sys/cam/cam_xpt.c.orig ? sys/cam/cam_xpt_internal.h.orig ? sys/cam/cam_xpt_internal.h M sys/cam/cam.c M sys/cam/cam_xpt.h M sys/cam/cam.h M sys/cam/cam_periph.c M sys/cam/cam_xpt_periph.h M sys/cam/cam_ccb.h ? sys/cam/scsi/scsi_cd.c.orig ? sys/cam/scsi/scsi_ch.c.orig ? sys/cam/scsi/scsi_xpt.c ? sys/cam/scsi/scsi_xpt.h.orig ? sys/cam/scsi/scsi_xpt.h ? sys/cam/scsi/scsi_pt.c.orig ? sys/cam/scsi/scsi_da.c.orig ? sys/cam/scsi/scsi_ses.c.orig ? sys/cam/scsi/scsi_sa.c.orig ? sys/cam/scsi/scsi_all.c.orig ? sys/cam/scsi/scsi_sg.c.orig ? sys/cam/scsi/scsi_xpt.c.orig M sys/cam/scsi/scsi_pt.c M sys/cam/scsi/scsi_da.c M sys/cam/scsi/scsi_cd.c M sys/cam/scsi/scsi_ses.c M sys/cam/scsi/scsi_ch.c M sys/cam/scsi/scsi_sa.c M sys/cam/scsi/scsi_all.c M sys/cam/scsi/scsi_sg.c M sys/cam/cam_xpt.c I sys/ia64/conf/LINT ? sys/modules/ahci ? sys/modules/Makefile.orig ? sys/modules/cam/Makefile.orig M sys/modules/cam/Makefile M sys/modules/Makefile ? sys/dev/ahci ? sys/dev/usb/usb_sw_transfer.c ? sys/dev/usb/usb_sw_transfer.h I sys/sun4v/conf/LINT ? sys/compat/linux/linux_elf.h I sys/pc98/conf/LINT I sys/i386/conf/LINT I sys/i386/conf/ARUNDEL I sys/amd64/conf/LINT alex Ed Schouten schrieb am 2009-06-28: > * Alexander Best wrote: > > sudo svn up . -> At revision 195136. > > sudo svn diff -> no output > Yes, but what about `svn status --no-ignore'? From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:30:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FAC4106567B for ; Sun, 28 Jun 2009 13:30:22 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from mail.digiware.nl (mail.digiware.nl [80.255.245.173]) by mx1.freebsd.org (Postfix) with ESMTP id F15018FC28 for ; Sun, 28 Jun 2009 13:30:21 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id F2EDE153434 for ; Sun, 28 Jun 2009 15:13:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBmElssxNvGo; Sun, 28 Jun 2009 15:13:29 +0200 (CEST) Received: from [192.168.2.10] (vaio [192.168.2.10]) by mail.digiware.nl (Postfix) with ESMTP id 25AFF153433 for ; Sun, 28 Jun 2009 15:13:29 +0200 (CEST) Message-ID: <4A476C7C.3020605@withagen.nl> Date: Sun, 28 Jun 2009 15:13:32 +0200 From: Willem Jan Withagen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: 7.2-stable upgrade changes disknames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:30:22 -0000 Hi, Tried UPGRADING, but could not find any suggestions that this was to be expected. Could also not find any previous suggestions for this. I upgraded from stable to current just by the regular cvsup/compile/install kernel/reboot cycle. After which I got complaints that ad0s1a no longer existed. Al of a sudden it was called ad0a... Adjusting /etc/fstab made life again enjoyable. In essence not a serious problem if one is a little fluent in FreeBSD, but could prove a source of a lot of questions, once 8.0 is released. So is this just because I missed something, or becasue I'm using a relatively old motherboard/processor combo: CPU: AMD Duron(tm) Processor (807.19-MHz 686-class CPU) acpi0: on motherboard --WjW From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:32:39 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C67FD106567B for ; Sun, 28 Jun 2009 13:32:39 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6238FC12 for ; Sun, 28 Jun 2009 13:32:39 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id F1F211CD00; Sun, 28 Jun 2009 15:32:38 +0200 (CEST) Date: Sun, 28 Jun 2009 15:32:38 +0200 From: Ed Schouten To: Alexander Best Message-ID: <20090628133238.GR48776@hoeg.nl> References: <20090628132555.GQ48776@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SrkHqWf2uD5orhVO" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:32:40 -0000 --SrkHqWf2uD5orhVO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Alexander Best wrote: > this is the output: > ... > ? sys/cam/cam_xpt_internal.h.orig > ? sys/cam/cam_xpt_internal.h Remove all those unneeded files from your tree before applying the patch. --=20 Ed Schouten WWW: http://80386.nl/ --SrkHqWf2uD5orhVO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpHcPYACgkQ52SDGA2eCwX9EQCfQCC9sMQqcADYRpww3Bzjp26D agcAn1Fc/TSSIGnblRJGG2pqgtaFMol/ =jzr5 -----END PGP SIGNATURE----- --SrkHqWf2uD5orhVO-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:42:07 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 80FC2106564A for ; Sun, 28 Jun 2009 13:42:07 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (mail.hidden-powers.com [213.242.135.162]) by mx1.freebsd.org (Postfix) with ESMTP id 2CA408FC13 for ; Sun, 28 Jun 2009 13:42:06 +0000 (UTC) (envelope-from glz@hidden-powers.com) Received: from mail.hidden-powers.com (localhost [127.0.0.1]) by dkim.hidden-powers.com (Postfix) with ESMTP id ED0896E226; Sun, 28 Jun 2009 15:22:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hidden-powers.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s= selector1; bh=Fb474EsjyOr6NnLxvxkwR+uPlMc=; b=gEGsBmZIH3cJUxJPy4 Itvi275axRl7ibh4NGclM6luoP7KBgR9gEcNyjqkHoJYx1XBVDG44GjP9+dXnWMd Hf23EEp85kFchHcr8/ZzOZPyXTkKW39KTwvOIdrWktZ0W1j+NFUrloZ4dIbH0eSc f39+ruyeg52gjI+5amUsDii24= Received: from [10.123.8.60] (unknown [192.36.80.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.hidden-powers.com (Postfix) with ESMTPSA id 0CC536E225; Sun, 28 Jun 2009 15:22:34 +0200 (CEST) Date: Sun, 28 Jun 2009 15:22:33 +0200 From: Goran Lowkrantz To: Alexander Best Message-ID: In-Reply-To: <20090628125847.GP48776@hoeg.nl> References: <20090628125847.GP48776@hoeg.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:42:07 -0000 Hi, Clean CURRENT as of this morning, patches: ===> ahci (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -fno-omit-frame-pointer -I/usr/obj/usr/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c: In function 'ahci_dmasetprd': /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1032: error: 'AHCI_DMA_ENTRIES' undeclared (first use in this function) /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1032: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1032: error: for each function it appears in.) *** Error code 1 Stop in /usr/src/sys/modules/ahci. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/obj/usr/src/sys/GENERIC. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Sun Jun 28 10:54:24 CEST 2009 /glz --On June 28, 2009 14:58:47 +0200 Ed Schouten wrote: > Hi Alexander, > > * Alexander Best wrote: >> after applying the patchset i cannot recompile my kernel. i've rebuild >> and reinstalled world after applying the patches. probably a kernelconf >> option is coliding with the ahci device. could somebody take a look at >> this and tell me what options i need to remove from my kernelconf? > > It may be possible that you applied the patch twice, which means some > files may have duplicate content. > > -- > Ed Schouten > WWW: http://80386.nl/ --- "There is hopeful symbolism in the fact that flags do not wave in a vacuum." -- Arthur C. Clarke From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:48:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 186D11065670 for ; Sun, 28 Jun 2009 13:48:48 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9FAB18FC0A for ; Sun, 28 Jun 2009 13:48:47 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,303,1243807200"; d="scan'208";a="6988422" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 28 Jun 2009 15:48:46 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id B7B991B07E4; Sun, 28 Jun 2009 15:48:46 +0200 (CEST) Date: Sun, 28 Jun 2009 15:48:46 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Ed Schouten Message-ID: In-Reply-To: <20090628133238.GR48776@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:48:48 -0000 thanks a lot. after removing all the unneeded files the build error i was experiencing disappeared. however now i'm getting the same build error as Goran Lowkrantz describes here: http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008666.html cheers. Ed Schouten schrieb am 2009-06-28: > * Alexander Best wrote: > > this is the output: > > ... > > ? sys/cam/cam_xpt_internal.h.orig > > ? sys/cam/cam_xpt_internal.h > Remove all those unneeded files from your tree before applying the > patch. From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:50:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C47431065672; Sun, 28 Jun 2009 13:50:33 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 031BC8FC2E; Sun, 28 Jun 2009 13:50:32 +0000 (UTC) (envelope-from unixmania@gmail.com) Received: by fxm18 with SMTP id 18so1458360fxm.43 for ; Sun, 28 Jun 2009 06:50:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=vgt0YR6EbiZOJtDkdiisL1wRfY9qo3QAt5zllim/HfI=; b=l+iZZVxpdgVqdmTI6ni5uLDrmJel1d5S2P0GcM7EG+JRIPpK6bZTKM1I3geqRiCsAW yT7CqEVySGlIVyJinrUYGajeISHvPBPessvkjT0449AJ9nngtkJeRiGLHjOXUVymjZ10 GpK/XGKtf12SIdn4OUfrYwCD0TBV/jePrmY2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s4Fw3+ZhPtJSB84CWkCwriGjv8rykqNP+Umur7jOYAloSuh2S6uIXU1M2V0nkljEOK uHtZMCBcVkktNlqZ9LkwJtG7i44D2IXIVRp/xRYR7Jr3wfb4bV8tq9ZVDaL9nZkvgV2E u+E61wW7H3B18BuY4UdQxkjc7C2ySczBBgq2s= MIME-Version: 1.0 Received: by 10.239.171.148 with SMTP id w20mr521454hbe.171.1246197031881; Sun, 28 Jun 2009 06:50:31 -0700 (PDT) In-Reply-To: <200906280847.59316.doconnor@gsoft.com.au> References: <4A4517BE.9040504@FreeBSD.org> <20090627141412.GN31709@acme.spoerlein.net> <4A462A7A.20005@haruhiism.net> <200906280847.59316.doconnor@gsoft.com.au> Date: Sun, 28 Jun 2009 10:50:31 -0300 Message-ID: From: "Carlos A. M. dos Santos" To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kamigishi Rei , Alexander Motin , freebsd-current@freebsd.org, scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:50:34 -0000 On Sat, Jun 27, 2009 at 8:17 PM, Daniel O'Connor wrote: [...] > 7.2 has UFSID in GENERIC so you can mount your disks that way which is > non-ambiguous. > > Unfortunately you can't specify swap this way because it has no ID, I > don't know how hard it would be to add such a thing (which would > require a mkswap or somesuch, and modification to the dump & swap > code..) You can use glabel to add a label to the raw swap partition. I use to have a line containing /dev/label/BSDSWAP none swap sw 0 0 in /etc/fstab. -- My preferred quotation of Robert Louis Stevenson is "You cannot make an omelette without breaking eggs". Not because I like the omelettes, but because I like the sound of eggs being broken. From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 13:56:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4F021065674 for ; Sun, 28 Jun 2009 13:56:28 +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 9CA9A8FC12 for ; Sun, 28 Jun 2009 13:56:28 +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 7480069959 for ; Sun, 28 Jun 2009 13:37:33 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n5SDbWg5004294 for ; Sun, 28 Jun 2009 13:37:33 GMT (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Sun, 28 Jun 2009 13:37:32 +0000 Message-ID: <4293.1246196252@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: GCC inline bug on -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 13:56:29 -0000 While hacking up some code on "8.0-CURRENT #0 r195095M: Sat Jun 27 12:24:33 UTC 2009", I have run into a GCC bug with inlining: Download the three files in this directory: http://phk.freebsd.dk/misc/P Run "make test" The #if in line 183 controls if the function FindLoops() is inlined. If it is not inlined, the program runs to completion with the message 347 loops If it is inlined, the program enters an infinite loop. Enjoy... -- 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-current@FreeBSD.ORG Sun Jun 28 14:07:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42D791065670; Sun, 28 Jun 2009 14:07:44 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8B4C18FC18; Sun, 28 Jun 2009 14:07:43 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp121-45-162-173.lns11.adl2.internode.on.net [121.45.162.173]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n5SE7f1d029185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 28 Jun 2009 23:37:41 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Aisaka Taiga Date: Sun, 28 Jun 2009 23:37:12 +0930 User-Agent: KMail/1.9.10 References: <4A4517BE.9040504@FreeBSD.org> <200906282113.42967.doconnor@gsoft.com.au> <4A475A16.4000108@haruhiism.net> In-Reply-To: <4A475A16.4000108@haruhiism.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1624725.feAl1Pfglu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200906282337.30386.doconnor@gsoft.com.au> X-Spam-Score: -1.336 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Alexander Motin , freebsd-current@freebsd.org, scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 14:07:44 -0000 --nextPart1624725.feAl1Pfglu Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 28 Jun 2009, Aisaka Taiga wrote: > Hello, hope you're having a nice day, > > Daniel O'Connor wrote: > > The UFSID is unique for a given newfs (mostly - it is the timestamp > > I believe). > > It is unique; however, I'm not talking about it being unique. More > like from a console standpoint. > Imagine your system's asking for manual input for the root partition; > what's easier to type - /dev/ufs/root, > /dev/ufsid/{inserthugenumberinhexhere} or /dev/physical-device? The latter obviously, however that situation is rare, and you can list=20 the available devices by entering '?'. > Reading through /etc/fstab when it uses ufsids is a pain as well. True, but it is not a very common thing to read through it.. > By the way, in my opinion the current freebsd install system should > allow running GEOM commands before partitioning/labelling devices. > And should also recognize GEOM devices, as well, since for a clean > install the transition to labels & gmirror is either 'not safe' > (kern.geom.debugflags=3D16, then label the live system's drive) OR > requires a dump/restore (label the 2nd drive, label the partitions, > then copy data there, reboot to the 2nd drive, add the first to the > mirror). sysinstall is fun like that, it has many limitations.. You might want to try the bsdinstaller snapshots.. > P.S. Also, bsdlabel and glabel seem like ambiguous names (as well as > using the term 'label' for both slice layout and GEOM labels) - so I > see no problems naming AHCI devices "daX". ;) bsdlabel is a historic, and glabel is a fairly intuitive name.. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1624725.feAl1Pfglu Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKR3ki5ZPcIHs/zowRAldFAJ0R2y4/062hMCe1rrbYUxgDac5AzACdFRjj t5Mb5jcMXuwkR/I1bMna0ag= =etWd -----END PGP SIGNATURE----- --nextPart1624725.feAl1Pfglu-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 14:08:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C5E9106567B for ; Sun, 28 Jun 2009 14:08:51 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id B9EA98FC18 for ; Sun, 28 Jun 2009 14:08:50 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 40E4778F98; Sun, 28 Jun 2009 17:51:38 +0400 (MSD) Message-ID: <4A477576.6030701@haruhiism.net> Date: Sun, 28 Jun 2009 17:51:50 +0400 From: Aisaka Taiga User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Willem Jan Withagen References: <4A476C7C.3020605@withagen.nl> In-Reply-To: <4A476C7C.3020605@withagen.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: 7.2-stable upgrade changes disknames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 14:08:51 -0000 Willem Jan Withagen wrote: > Tried UPGRADING, but could not find any suggestions that this was to > be expected. Could also not find any previous suggestions for this. > After which I got complaints that ad0s1a no longer existed. > Al of a sudden it was called ad0a... > In essence not a serious problem if one is a little fluent in FreeBSD, > but could prove a source of a lot of questions, once 8.0 is released. This isn't related to -current changes. The naming scheme of ad0s1a refers to a classic DOS partition table with a FreeBSD slice as DOS partition 0, and the FreeBSD root partition as the first (a) partition inside the slice. ad0a device name stands for a dangerously dedicated disk with no partition table whatsoever; i.e. it's like doing not "fdisk /dev/ad0 ; bsdlabel {params} /dev/ad0s1", but going "bsdlabel /dev/ad0" without creating a DOS-style partition table. In your case it might mean some data corruption within the partition table. What does fdisk /dev/ad0 report? -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 14:13:51 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E7391065674; Sun, 28 Jun 2009 14:13:51 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 03FD38FC23; Sun, 28 Jun 2009 14:13:51 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 2AEA21E00218; Sun, 28 Jun 2009 16:13:50 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5SEA9KV003865; Sun, 28 Jun 2009 16:10:09 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5SEA8O2003864; Sun, 28 Jun 2009 16:10:08 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 28 Jun 2009 16:10:08 +0200 To: Boris Samorodov Message-ID: <20090628141008.GA3841@triton.kn-bremen.de> References: <66988167@ipt.ru> <747dc8f30906261255s1ecc1420x574ded3be835b448@mail.gmail.com> <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56244219@ipt.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Renato Botelho , freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, Juergen Lock , "Sean C. Farley" Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 14:13:51 -0000 On Sun, Jun 28, 2009 at 04:40:20PM +0400, Boris Samorodov wrote: > Juergen Lock writes: > > > New patch and shar: > > No more comments from me, thanks! Ok. Has anyone tested this yet tho? (Besides me in a vm... :) Juergen From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 14:31:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD9BF1065676 for ; Sun, 28 Jun 2009 14:31:26 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 5ED538FC19 for ; Sun, 28 Jun 2009 14:31:26 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:41245 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MKvPW-0006NL-6I for freebsd-current@freebsd.org; Sun, 28 Jun 2009 16:31:17 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 27D1E5F982 for ; Sun, 28 Jun 2009 16:31:14 +0200 (CEST) Message-Id: <0A918DF9-F417-4AD5-935B-1F2E397DBB80@exscape.org> From: Thomas Backman To: FreeBSD current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 28 Jun 2009 16:31:11 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MKvPW-0006NL-6I. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MKvPW-0006NL-6I 23455b768d01c1a742c454d17dc1b7c3 Subject: ifconfig and a soon following panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 14:31:27 -0000 OK, so I was (not knowing what I was/am doing, I might add) trying to get jumbo frames running on my LAN. After all, all my NICs should support it, as should my switch. Warning: You could say that this post is a bit incoherent, and you'd be right. Sorry about that. Anyway... Step 1: ifconfig nfe0 mtu 7000 (as that was the maximum I managed to get out my Linux box), and then check if it worked. It had, according to ifconfig. Step 2: Try it out. Average frame size: ~1400 bytes (during some heavy file transfer). I guess it didn't work. Ah well, I guess I'll try again later, not really feeling like it right now. Step 3: ifconfig nfe0 1500. OOPS. Note that I did NOT say "mtu 1500". Network access lost! Step 4: Physically access the computer; notice nfe0 has an incorrect IP address (see above) and run /etc/rc.d/netif restart (again, could be the wrong way). Step 5 (I think there were no step 4.5): double fault panic. So, two problems (I *guess* the first one is a... feature..., that is, setting the IP based on a decimal(?) number?) i.e. losing net access on "ifconfig ", and the kernel panic following a netif restart. The interface has a static IP: # grep 192 /etc/rc.conf defaultrouter="192.168.1.1" ifconfig_nfe0="inet 192.168.1.10 netmask 255.255.255.0" The panic: Unread portion of the kernel message buffer: Fatal double fault rip = 0xffffffff8065eb19 rsp = 0xffffff8000021fc0 rbp = 0xffffff8000022050 cpuid = 0; apic id = 00 panic: double fault cpuid = 0 KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 2d0h59m13s Physical memory: 2027 MB #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:223 #1 0xffffffff805a5249 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xffffffff805a569c in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xffffffff801f1ee7 in db_panic (addr=Variable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801f22f1 in db_command (last_cmdp=0xffffffff80c35820, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801f2540 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #6 0xffffffff801f44d9 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff805d7465 in kdb_trap (type=3, code=0, tf=0xffffffff80ceb490) at /usr/src/sys/kern/subr_kdb.c:534 #8 0xffffffff80893538 in trap (frame=0xffffffff80ceb490) at /usr/src/sys/amd64/amd64/trap.c:613 #9 0xffffffff80879647 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #10 0xffffffff805d763d in kdb_enter (why=0xffffffff80982c1c "panic", msg=0xa
) at cpufunc.h:63 #11 0xffffffff805a56ab in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:558 #12 0xffffffff80892534 in dblfault_handler (frame=Variable "frame" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:879 #13 0xffffffff8087972c in Xdblfault () at /usr/src/sys/amd64/amd64/exception.S:274 #14 0xffffffff8065eb19 in rtalloc1_fib (dst=0xffffff80000220b0, report=1, ignflags=0, fibnum=0) at /usr/src/sys/net/route.c:395 Previous frame inner to this frame (corrupt stack?) The bt I got in ddb looked way different, of course, and looked like a "loop" of some sort (it was at least 30 functions deep, and it looked like two of them were repeating again and again). I was expecting it to be saved with the dump, so I didn't bother to write anything down... I tried to reproduce twice but it worked as it should (except that /etc/rc.d/defaultroute restart doesn't actually set the default route set in rc.conf - intentional?) the next two times. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 15:39:03 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C818C1065735; Sun, 28 Jun 2009 15:39:03 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0EEDF8FC14; Sun, 28 Jun 2009 15:39:02 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:818b:7399:d9b:9c85] (unknown [IPv6:2001:7b8:3a7:0:818b:7399:d9b:9c85]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 10AF35C42; Sun, 28 Jun 2009 17:39:02 +0200 (CEST) Message-ID: <4A478E97.4040806@andric.com> Date: Sun, 28 Jun 2009 17:39:03 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1pre) Gecko/20090627 Shredder/3.0b3pre MIME-Version: 1.0 To: Robert Watson References: <200906241741.n5OHfTaw022417@svn.freebsd.org> <4A43893F.5070100@andric.com> <24BDCB76-0304-443A-96A9-71C5E537FF37@exscape.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jack F Vogel , current@FreeBSD.org, Thomas Backman Subject: Re: VMWare if_em breakage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 15:39:04 -0000 On 2009-06-28 15:04, Robert Watson wrote: > Jack suggested this patch for me to test, and it seems to work here, so > hopefully he doesn't mind my sharing it until it before it gets into SVN. It > seems to entirely prevent the problem from occuring here. It works fine for me too, using VMware Workstation 6.5. No connection issues whatsoever anymore. Thanks Jack. :) From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 16:29:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D7DB1065673 for ; Sun, 28 Jun 2009 16:29:51 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id B6FAD8FC15 for ; Sun, 28 Jun 2009 16:29:50 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by fxm18 with SMTP id 18so1497494fxm.43 for ; Sun, 28 Jun 2009 09:29:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cgfJgEqoLGKJLAvP2A0SC0JSoZXIMAEHMsBkbryCID8=; b=CYneXrZKCcP2UCH0gidCPhO90UQqMYANJ+ZIw2XsG477ogIwMM4sNeztPatArA3jjx ytPzcJEWLbDvJciyAtRIKbxoyWHzUazsOnq9cA97Et+hqU7oIC5rdsm8s6OzFksO0i/y bqAkXvWCDva3EUMo3IJQEiOQt5r1zdoLHOL0A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=apOfxEKl6OCpa0/+wCtRVn9UoHQecq1CFPAdNhuqIaPqAslChYio3jMa/9CX2Uhz1U nHHBXIuwgBCcBmmW4F1xDEN3JVk8aEeAnBLaZaKKt/nUacgjizu/RwuOdNjLDwr+YwAO fZ9HODkcUu4CcJyZydimCyEWUVWkD1t9f4F4s= MIME-Version: 1.0 Received: by 10.204.102.14 with SMTP id e14mr6171824bko.209.1246206589638; Sun, 28 Jun 2009 09:29:49 -0700 (PDT) In-Reply-To: <20090628141008.GA3841@triton.kn-bremen.de> References: <747dc8f30906261255s1ecc1420x574ded3be835b448@mail.gmail.com> <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> Date: Sun, 28 Jun 2009 16:29:49 +0000 Message-ID: <179b97fb0906280929u654129bfoaefa2a43f7058dc5@mail.gmail.com> From: Brandon Gooch To: Juergen Lock Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Boris Samorodov , Renato Botelho , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, "Sean C. Farley" Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 16:29:51 -0000 On Sun, Jun 28, 2009 at 2:10 PM, Juergen Lock wrote= : > On Sun, Jun 28, 2009 at 04:40:20PM +0400, Boris Samorodov wrote: >> Juergen Lock writes: >> >> > =A0New patch and shar: >> >> No more comments from me, thanks! > > Ok. =A0Has anyone tested this yet tho? =A0(Besides me in a vm... :) > I have. I'm using it with about the same level of success as the previous versions of Flash (I need to map a couple of keys to run `pkill npviewer.bin`). Nevertheless, thanks for this! -Brandon From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 16:54:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C02701065678; Sun, 28 Jun 2009 16:54:30 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-px0-f191.google.com (mail-px0-f191.google.com [209.85.216.191]) by mx1.freebsd.org (Postfix) with ESMTP id 822338FC16; Sun, 28 Jun 2009 16:54:30 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by pxi29 with SMTP id 29so2862066pxi.3 for ; Sun, 28 Jun 2009 09:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=g1MdW45bDfCAPYa5C9iEmL6bp/xKwCEyZOE2kwQoQGU=; b=MjjvAueZaxd5znOBklViS30Sjc+JtjnBnXcJWArh/4vWihUoVpybTzNBsRMXEKwpQg YRgWfxaKTByi6vvhYGGLfOPD1AF8m/EsdLgMIvsW9ZEPOzg18/gy28SzjG0UT32Y7Q/z i/dHr8kiAw7nku/XmW3jUIrHaZO0fUV9QlRzU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=riamjR49qcdhsXx2KCyPGu4zk0RkCqma7s07roHKt8TET1iVyEaTmXcsPZ6bevipBn ME1uvVA2YP0ynC7+kf0QT2N54IILzqeiKZLCRqKHByoWnMF+ZHNk7DwR1fsKR9B5yKZG Jb8K9GkcZC6QbeJkOumB7GufieOZl6OX2E21A= MIME-Version: 1.0 Received: by 10.114.122.9 with SMTP id u9mr10004270wac.206.1246208070318; Sun, 28 Jun 2009 09:54:30 -0700 (PDT) In-Reply-To: <4A478E97.4040806@andric.com> References: <200906241741.n5OHfTaw022417@svn.freebsd.org> <4A43893F.5070100@andric.com> <24BDCB76-0304-443A-96A9-71C5E537FF37@exscape.org> <4A478E97.4040806@andric.com> Date: Sun, 28 Jun 2009 09:54:30 -0700 Message-ID: <2a41acea0906280954y1cc04e86k31fb8c63f96086a7@mail.gmail.com> From: Jack Vogel To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jack F Vogel , Robert Watson , current@freebsd.org, Thomas Backman Subject: Re: VMWare if_em breakage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 16:54:31 -0000 OK, great to hear, I'll get this checked in tomorrow. Jack On Sun, Jun 28, 2009 at 8:39 AM, Dimitry Andric wrote: > On 2009-06-28 15:04, Robert Watson wrote: > > Jack suggested this patch for me to test, and it seems to work here, so > > hopefully he doesn't mind my sharing it until it before it gets into SVN. > It > > seems to entirely prevent the problem from occuring here. > > It works fine for me too, using VMware Workstation 6.5. No connection > issues whatsoever anymore. Thanks Jack. :) > From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 16:55:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 908721065676; Sun, 28 Jun 2009 16:55:07 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from contrabass.post.ru (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 341678FC0A; Sun, 28 Jun 2009 16:55:06 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.post.ru (Postfix) with ESMTP id 8AA1AA50DE; Sun, 28 Jun 2009 20:55:04 +0400 (MSD) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.17.3] (HELO dchagin.static.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 1843810253; Sun, 28 Jun 2009 20:55:04 +0400 Received: from dchagin.static.corbina.ru (localhost.chd.net [127.0.0.1]) by dchagin.static.corbina.ru (8.14.3/8.14.3) with ESMTP id n5SGt4df025471; Sun, 28 Jun 2009 20:55:04 +0400 (MSD) (envelope-from dchagin@dchagin.static.corbina.ru) Received: (from dchagin@localhost) by dchagin.static.corbina.ru (8.14.3/8.14.3/Submit) id n5SGswsT025470; Sun, 28 Jun 2009 20:54:58 +0400 (MSD) (envelope-from dchagin) Date: Sun, 28 Jun 2009 20:54:58 +0400 From: Chagin Dmitry To: Brandon Gooch Message-ID: <20090628165458.GA25437@dchagin.static.corbina.ru> References: <747dc8f30906261255s1ecc1420x574ded3be835b448@mail.gmail.com> <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <179b97fb0906280929u654129bfoaefa2a43f7058dc5@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <179b97fb0906280929u654129bfoaefa2a43f7058dc5@mail.gmail.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Juergen Lock , Boris Samorodov , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Renato Botelho , "Sean C. Farley" Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 16:55:08 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 28, 2009 at 04:29:49PM +0000, Brandon Gooch wrote: > On Sun, Jun 28, 2009 at 2:10 PM, Juergen Lock wro= te: > > On Sun, Jun 28, 2009 at 04:40:20PM +0400, Boris Samorodov wrote: > >> Juergen Lock writes: > >> > >> > =9ANew patch and shar: > >> > >> No more comments from me, thanks! > > > > Ok. =9AHas anyone tested this yet tho? =9A(Besides me in a vm... :) > > >=20 > I have. I'm using it with about the same level of success as the > previous versions of Flash (I need to map a couple of keys to run > `pkill npviewer.bin`). >=20 for amd64 try: compat.linux32.maxssiz=3D4194304 for i386 try: limit stacksize to 4mb or set unlimited. > Nevertheless, thanks for this! >=20 > -Brandon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --=20 Have fun! chd --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkpHoGIACgkQ0t2Tb3OO/O3gSACfeZFyb/RFkDpu81UaLWWSvVgN lPcAoMq8JFPWhloyxVIWdXnA9Zb992BH =Q2b/ -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 16:55:56 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BBB61065688; Sun, 28 Jun 2009 16:55:56 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by mx1.freebsd.org (Postfix) with ESMTP id 0B72C8FC0A; Sun, 28 Jun 2009 16:55:55 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: by wa-out-1112.google.com with SMTP id m38so960981waf.27 for ; Sun, 28 Jun 2009 09:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=iZ3hBa34nWz0MCBO4dtgiybijBDXLJXr8Eeb9mRFBwc=; b=Ep/QFHiac9+3jLQNHUJJXZvZwKJyKFa6kHxKnPA6rkDB2/8lpjLowbc1btf5qcOFeX 4W+qqWM0iWfCT6p52wEk+gG0Yk2J4fBeqIJjApn+vW60aQNY0qm36Vg7QResGiTT7Wq2 3NUbhvgKrBW1wekk2HrAbtSKXCp1mRVjO/PC4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Hq/Y7c69OedRb4EinDvxz47mf8Rh6AlKww8jQ0eSrYprYz6If6cePCTyhU4OOumSb5 qjMsdPXWAGop8buephQ9U0pykz3r1Jco5+s+UddEezerhOa6WOufXbuzfTZKU9jW2MKJ PWEjyP7RJd23Oa4yE2FubRLrcl8aSo0vd/vfM= MIME-Version: 1.0 Received: by 10.114.185.12 with SMTP id i12mr9864791waf.123.1246207726547; Sun, 28 Jun 2009 09:48:46 -0700 (PDT) In-Reply-To: References: <200906241741.n5OHfTaw022417@svn.freebsd.org> <4A43893F.5070100@andric.com> <24BDCB76-0304-443A-96A9-71C5E537FF37@exscape.org> Date: Sun, 28 Jun 2009 09:48:46 -0700 Message-ID: <2a41acea0906280948x34d64510v23b17c75d9fac0b@mail.gmail.com> From: Jack Vogel To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jack F Vogel , Dimitry Andric , current@freebsd.org, Thomas Backman Subject: Re: VMWare if_em breakage (was: Re: svn commit: r194865 - in head/sys: dev/e1000 modules/igb) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 16:55:56 -0000 Yes, thanks Robert. I was planning on submitting this on Monday. Talk about a annoying little bug :) Jack On Sun, Jun 28, 2009 at 6:04 AM, Robert Watson wrote: > > On Sun, 28 Jun 2009, Thomas Backman wrote: > > On Jun 25, 2009, at 04:27 PM, Dimitry Andric wrote: >> >> On 2009-06-25 16:08, Robert Watson wrote: >>> >>>> Since this change (and the two followups), I'm no longer able to use >>>> if_em reliable in VMWare Fusion. >>>> >>> >>> Same here, for VMware Workstation. The interface just stops working >>> after a bit of traffic. >>> >> >> Not sure it's needed, but here's another "me too", also using Fusion. At >> first I thought it had frozen, but locally, in the VM window, everything >> worked fine. (I always interact with VMs via SSH to get copy/paste, better >> fonts etc). Also worth mentioning is that vmware-vmx ate 100% real CPU the >> entire time, despite the VM CPU (top in FreeBSD) showed 100% *idle*. >> > > Jack suggested this patch for me to test, and it seems to work here, so > hopefully he doesn't mind my sharing it until it before it gets into SVN. > It seems to entirely prevent the problem from occuring here. > > Robert N M Watson > Computer Laboratory > University of Cambridge > > Index: if_em.c > =================================================================== > --- if_em.c (revision 195108) > +++ if_em.c (working copy) > @@ -4446,7 +4446,7 @@ > struct mbuf *mp; > u8 status, accept_frame = 0, eop = 0; > u16 len, desc_len, prev_len_adj; > - u32 i, rx_sent = 0; > + int i, rx_sent = 0; > struct e1000_rx_desc *current_desc; > > EM_RX_LOCK(adapter); > > From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 17:31:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 032571065673; Sun, 28 Jun 2009 17:31:50 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by mx1.freebsd.org (Postfix) with ESMTP id 8A6678FC19; Sun, 28 Jun 2009 17:31:49 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from merom.hotsoft.nl (beasties.demon.nl [82.161.3.114]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id n5SHL6Ss023551; Sun, 28 Jun 2009 19:21:06 +0200 (CEST) (envelope-from hansot@iae.nl) Message-ID: <4A47A681.3040100@iae.nl> Date: Sun, 28 Jun 2009 19:21:05 +0200 From: Hans Ottevanger User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20090628034654.bdb728c4.nork@FreeBSD.org> In-Reply-To: <20090628034654.bdb728c4.nork@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Norikatsu Shigemura Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 17:31:50 -0000 Norikatsu Shigemura wrote: > Hi. > Hi, I have almost the same issue, just the addresses are different and in my case the trap occurs on cpu2. My system is based on an Intel PB965LT main board with a Q6600 quad core CPU and 8 Gbyte of RAM. I am also using the amd64 kernel, where kernel configuration is almost identical to GENERIC, with devices removed that I do not have and the following lines added device drm device radeondrm device sound device snd_hda If I remove the drm and radeondrm devices from the config file and recompile the kernel, the panic does not occur and the corresponding modules can be loaded without a problem. Some "binary searching" of Subversion releases shows that the problem first occurs with r194985. If I update to r195137 and revert the relevant files from the revision r194985 to r194984, no panic occurs. Of course it could very well be that r194985 itself is not the issue, but triggers a problem somewhere else in the kernel. Kind regards, Hans > I got a panic after AP CPU launched on boot. So I couldn't get > crash dump and information. > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > FreeBSD nadesico.ninth-nine.com 8.0-CURRENT FreeBSD 8.0-CURRENT #49: Sun Jun 28 02:53:48 JST 2009 nork@nadesico.ninth-nine.com:/usr/obj/usr/src/sys/NADESICO amd64 > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > SMP: AP CPU #3 Launched! > SMP: AP CPU #1 Launched! > SMP: AP CPU #2 Launched! > > Fatal trap 30: reserved (unknown) fault while in kernel mode > cpuid = 3; apic id = 03 > instruction pointer = 0x20:0xffffffff804bce56 > stack pointer = 0x20:0xffffff8000039b60 > frame pointer = 0x20:0xffffff8000039b70 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 11 (idle: cpu3) > [thread pid 11 tid 100003 ] > Stopped at acpi_cpu_c1+0x6: leave > db> bt > Tracing pid 11 tid 100003 td 0xffffff8001863720 > acpi_cpu_c1() at acpi_cpu_c1+0x6 > acpi_cpu_idle() at acpi_cpu_idle+0x20c > sched_idletd() at sched_idletd+0x123 > fork_exit() at fork_exit+0x117 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8000039d40, rbp = 0 --- > db> > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > I can boot with kern.smp.diabled=1, so I get address lines. > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > (kgdb) list *acpi_cpu_c1+0x6 > 0xffffffff804bce56 is in acpi_cpu_c1 (/usr/src/sys/amd64/acpica/acpi_machdep.c:100). > 95 > 96 void > 97 acpi_cpu_c1() > 98 { > 99 __asm __volatile("sti; hlt"); > 100 } > (kgdb) list *acpi_cpu_idle+0x20c > 0xffffffff801b443c is in acpi_cpu_idle (/usr/src/sys/dev/acpica/acpi_cpu.c:966). > 961 ACPI_ENABLE_IRQS(); > 962 > 963 /* Find the actual time asleep in microseconds. */ > 964 end_time = acpi_TimerDelta(end_time, start_time); > 965 sc->cpu_prev_sleep = (sc->cpu_prev_sleep * 3 + PM_USEC(end_time)) / 4; > 966 } > (kgdb) list *sched_idletd+0x123 > 0xffffffff8030b733 is in sched_idletd (/usr/src/sys/kern/sched_ule.c:2562). > 2557 cpu_spinwait(); > 2558 } > 2559 } > 2560 switchcnt = tdq->tdq_switchcnt + tdq->tdq_oldswitchcnt; > 2561 if (tdq->tdq_load == 0) > 2562 cpu_idle(switchcnt > 1); > 2563 if (tdq->tdq_load) { > 2564 thread_lock(td); > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 17:39:10 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4CC0106564A; Sun, 28 Jun 2009 17:39:10 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (mail.farley.org [IPv6:2001:470:1f0f:20:2::11]) by mx1.freebsd.org (Postfix) with ESMTP id A62418FC0C; Sun, 28 Jun 2009 17:39:10 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (HPooka@thor.farley.org [IPv6:2001:470:1f0f:20:1::5]) by mail.farley.org (8.14.3/8.14.3) with ESMTP id n5SHd9Iq013938; Sun, 28 Jun 2009 12:39:09 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Sun, 28 Jun 2009 12:39:09 -0500 (CDT) From: "Sean C. Farley" To: Chagin Dmitry In-Reply-To: <20090628165458.GA25437@dchagin.static.corbina.ru> Message-ID: References: <747dc8f30906261255s1ecc1420x574ded3be835b448@mail.gmail.com> <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <179b97fb0906280929u654129bfoaefa2a43f7058dc5@mail.gmail.com> <20090628165458.GA25437@dchagin.static.corbina.ru> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Spam-Status: No, score=-2.7 required=4.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail.farley.org Cc: Brandon Gooch , freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 17:39:11 -0000 On Sun, 28 Jun 2009, Chagin Dmitry wrote: > On Sun, Jun 28, 2009 at 04:29:49PM +0000, Brandon Gooch wrote: *snip* >> I have. I'm using it with about the same level of success as the >> previous versions of Flash (I need to map a couple of keys to run >> `pkill npviewer.bin`). I also have a key mapping to killall npviewer.bin. > for amd64 try: compat.linux32.maxssiz=4194304 > > for i386 try: limit stacksize to 4mb or set unlimited. Thank you. I tested viewing "TXT ISLAND" on YouTube. Works at higher limits for me such as 32MB but not at my default of 64MB. Why/how does this help? At least on i386, it stops Flash from choking on YouTube videos when switching to HD or jumping within a video. Sean -- scf@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 17:47:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C6EB1065672; Sun, 28 Jun 2009 17:47:55 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from contrabass.post.ru (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 243698FC16; Sun, 28 Jun 2009 17:47:55 +0000 (UTC) (envelope-from dchagin@dchagin.static.corbina.ru) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.post.ru (Postfix) with ESMTP id 506A1A3CA8; Sun, 28 Jun 2009 21:47:54 +0400 (MSD) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.17.3] (HELO dchagin.static.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 1843842191; Sun, 28 Jun 2009 21:47:54 +0400 Received: from dchagin.static.corbina.ru (localhost.chd.net [127.0.0.1]) by dchagin.static.corbina.ru (8.14.3/8.14.3) with ESMTP id n5SHlr1e027344; Sun, 28 Jun 2009 21:47:53 +0400 (MSD) (envelope-from dchagin@dchagin.static.corbina.ru) Received: (from dchagin@localhost) by dchagin.static.corbina.ru (8.14.3/8.14.3/Submit) id n5SHlmCn027343; Sun, 28 Jun 2009 21:47:48 +0400 (MSD) (envelope-from dchagin) Date: Sun, 28 Jun 2009 21:47:48 +0400 From: Chagin Dmitry To: "Sean C. Farley" Message-ID: <20090628174748.GA27292@dchagin.static.corbina.ru> References: <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <179b97fb0906280929u654129bfoaefa2a43f7058dc5@mail.gmail.com> <20090628165458.GA25437@dchagin.static.corbina.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Brandon Gooch , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 17:47:56 -0000 --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 28, 2009 at 12:39:09PM -0500, Sean C. Farley wrote: > On Sun, 28 Jun 2009, Chagin Dmitry wrote: >=20 > > On Sun, Jun 28, 2009 at 04:29:49PM +0000, Brandon Gooch wrote: >=20 > *snip* >=20 > >> I have. I'm using it with about the same level of success as the=20 > >> previous versions of Flash (I need to map a couple of keys to run=20 > >> `pkill npviewer.bin`). >=20 > I also have a key mapping to killall npviewer.bin. >=20 > > for amd64 try: compat.linux32.maxssiz=3D4194304 > > > > for i386 try: limit stacksize to 4mb or set unlimited. >=20 > Thank you. I tested viewing "TXT ISLAND" on YouTube. Works at higher=20 > limits for me such as 32MB but not at my default of 64MB. >=20 > Why/how does this help? At least on i386, it stops Flash from choking=20 > on YouTube videos when switching to HD or jumping within a video. >=20 the reason? foolish waves in a Uli head and stupid bug in flash plugin. flash uses pthread_detach() after pthread_join() call. glibc allows such behaviour (if stack limit < 40Mb) piece of shit... --=20 Have fun! chd --envbJBWh7q8WU6mo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkpHrMMACgkQ0t2Tb3OO/O3N3ACeJFyr+93f7LDKOilE+e0HkdIh yjsAn1JpsMBxG1PAegyHzazA2LpPwg3M =gaUb -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 17:51:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 370B71065670; Sun, 28 Jun 2009 17:51:35 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f210.google.com (mail-bw0-f210.google.com [209.85.218.210]) by mx1.freebsd.org (Postfix) with ESMTP id 7FE548FC08; Sun, 28 Jun 2009 17:51:34 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz6 with SMTP id 6so416585bwz.43 for ; Sun, 28 Jun 2009 10:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=syNwAOWNqA19Vf4FDgXNbxctIp5/EftxpMdsXe+uE+Y=; b=CgRXhhpZ1azb0ldBhNufguIEkxhJwYRUK5jzR3+RqAGmwNN0t5Xm34+9vQ/GttIopi Kjgs/C7S7ucUwr8SpO5UY7bwwSHdPX5q4NnkUh3PY3lS5bWWTvJoXFIe86mH8NxVp2wN mbn814TagTkGUV3kApDnYB0RvIXgy7vDpqL2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=ktdSyBbxpZQ+1Ky3oqiB1A5MrBRbRcUY7HbxaqrzlsFyQzq32LssbW5PKAQ1C14ROQ goOOjo5djQO6rzj0bwpLzR9dSAUWtKEjp5Do5v/1Oy+Vf5ut502XjMGvoGUt68goj8Sv TGTim+2vutREVijc5xx6LI6KMgy7sH2tqJJqk= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.115.80 with SMTP id h16mr4021668faq.94.1246211493272; Sun, 28 Jun 2009 10:51:33 -0700 (PDT) In-Reply-To: <2BE0378C-96A3-4714-A5C3-7B1A6AA0DCE2@lakerest.net> References: <951233.95131.qm@web39108.mail.mud.yahoo.com> <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> <4A23919F.8050905@mail.zedat.fu-berlin.de> <4A2B3040.7020509@poildetroll.net> <3bbf2fe10906070339k663bace7qe5142702248ce6c9@mail.gmail.com> <4A2BBDC0.6000801@poildetroll.net> <3bbf2fe10906070623o65ce021fkb7f59fe1924cc1ec@mail.gmail.com> <4A353E21.1080001@poildetroll.net> <2BE0378C-96A3-4714-A5C3-7B1A6AA0DCE2@lakerest.net> Date: Sun, 28 Jun 2009 19:51:33 +0200 X-Google-Sender-Auth: 74da3dc5546bdc71 Message-ID: <3bbf2fe10906281051k1da8d1edwc49388e30d3df492@mail.gmail.com> From: Attilio Rao To: Randall Stewart Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: bf , "O. Hartmann" , freebsd-current@freebsd.org, Pierre Guinoiseau , Kip Macy Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 17:51:35 -0000 2009/6/24 Randall Stewart : > One thing I have noticed for a while.. and have not > been able to track down.. > > If one runs > > /usr/src/tools/tools/syscall_timing/syscall_timing > > On a 7.2 kernel and compare it on the same machine to an 8.0 kernel > you will see almost a 3x slow down in 8. So, as long as I think that for the pressing, next release, it is very important to track such regressions down, I hope both Pierre and Randall want to lend an hand. First thing, Randall, could you recompile your kernel with HWPMC_HOOKS, device hwpmc, and do some pmcstat runs in order to see where/how the slowdown happens? For example you could check if the number of cache misses increases, or similar. Both could provide, instead, once the slowdown takes place, verbose top, ps and possibly vmstat, just to be sure in case. If you are unable to reproduce the slowdown or give an hand, please let me know. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 18:05:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 999D21065672 for ; Sun, 28 Jun 2009 18:05:34 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 6183C8FC14 for ; Sun, 28 Jun 2009 18:05:34 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 4A4C0730A1; Sun, 28 Jun 2009 20:11:05 +0200 (CEST) Date: Sun, 28 Jun 2009 20:11:05 +0200 From: Luigi Rizzo To: Aragon Gouveia Message-ID: <20090628181105.GA98246@onelab2.iet.unipi.it> References: <4A4751ED.8020002@phat.za.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4751ED.8020002@phat.za.net> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: recent boot0 changes dropped a partition type? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 18:05:34 -0000 On Sun, Jun 28, 2009 at 01:20:13PM +0200, Aragon Gouveia wrote: > Hi, > > I recently installed 8.0 from the June snapshot ISO. I noticed that the > new boot0 code has had partition type 0xc removed as a recognised > partition type. > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/boot0/boot0.S.diff?r1=1.21;r2=1.22;f=h > > That ID is used by FAT32 partitions so in my case I'm getting a "?" on > my Windows partition. If it was removed to save space, I think 0xb > would be more appropriate for removal - it is the non-LBA equivalent of > 0xc and I don't think any modern Windows partitioner sets it anymore. yes it was removed to save space, i am more than happy to replace 0xb with 0xc if the latter turns out to be more popular. So far we have the following (all the rest is basically commented out because we need space for other stuff): 131 linux 165 FreeBSD 166 [Open]BSD 169 [Net]BSD 6 Win [FAT16 >= 32MB] 7 Win [NTFS] 11 Win [FAT32] Suggestions for replacements are welcome cheers luigi From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 19:07:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EEB4106566C; Sun, 28 Jun 2009 19:07:47 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 7E8B08FC08; Sun, 28 Jun 2009 19:07:46 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: by bwz12 with SMTP id 12so149bwz.43 for ; Sun, 28 Jun 2009 12:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=tT8mxTq9KJQIo17Yf/jOG/cJ9UV+Dm6NgvWUC8x59vQ=; b=JG1wjPBgtdXk6egYIHDhjnC0TzVqsefM28Z57zkEKaSguMTbrzHz20cdNIvxSeB2cR T8xAtrkiha2+i8n0Jg8gar3jVhSP6TlumClH/5lrPIYkjL8auyvugzTjL7NPd9qjDqf5 xa4+ezdTNVRimdEnSJKBc/GrVxYxLQURJHhJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=Yp1S4Yd4DWdPtfDw+YKxChRIhglBAXlItbfTEgnD8Bpsp0nQnbzpcDvXIBj6D6lAmY RBo/53Pqp0qB5aBVvHxeWMVVATc/SaynCnQKC1tOpvWvLdsSIOFteZctsJKLHCwwHt5x tbTvK47gx1wHtaBV9KzJHU/rBV6cDzdpUPS+o= Received: by 10.103.182.1 with SMTP id j1mr3564602mup.119.1246214213821; Sun, 28 Jun 2009 11:36:53 -0700 (PDT) Received: from localhost (95-24-212-252.broadband.corbina.ru [95.24.212.252]) by mx.google.com with ESMTPS id 25sm10927773mul.50.2009.06.28.11.36.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Jun 2009 11:36:52 -0700 (PDT) From: Anonymous To: Hans Ottevanger References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> Date: Sun, 28 Jun 2009 22:36:47 +0400 In-Reply-To: <4A47A681.3040100@iae.nl> (Hans Ottevanger's message of "Sun, 28 Jun 2009 19:21:05 +0200") Message-ID: <86bpo8b3y8.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, Norikatsu Shigemura Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 19:07:47 -0000 Hans Ottevanger writes: > Norikatsu Shigemura wrote: >> Hi. >> > > Hi, > > I have almost the same issue, just the addresses are different and in > my case the trap occurs on cpu2. > > My system is based on an Intel PB965LT main board with a Q6600 quad > core CPU and 8 Gbyte of RAM. I am also using the amd64 kernel, where > kernel configuration is almost identical to GENERIC, with devices > removed that I do not have and the following lines added > > device drm > device radeondrm > device sound > device snd_hda > > If I remove the drm and radeondrm devices from the config file and > recompile the kernel, the panic does not occur and the corresponding > modules can be loaded without a problem. Can you try to boot with DRM and hw.drm.msi=0? In my case it does not panic then. > > Some "binary searching" of Subversion releases shows that the problem > first occurs with r194985. If I update to r195137 and revert the > relevant files from the revision r194985 to r194984, no panic occurs. > > Of course it could very well be that r194985 itself is not the issue, > but triggers a problem somewhere else in the kernel. > > Kind regards, > > Hans > >> I got a panic after AP CPU launched on boot. So I couldn't get >> crash dump and information. >> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> FreeBSD nadesico.ninth-nine.com 8.0-CURRENT FreeBSD 8.0-CURRENT #49: Sun Jun 28 02:53:48 JST 2009 nork@nadesico.ninth-nine.com:/usr/obj/usr/src/sys/NADESICO amd64 >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> SMP: AP CPU #3 Launched! >> SMP: AP CPU #1 Launched! >> SMP: AP CPU #2 Launched! >> >> Fatal trap 30: reserved (unknown) fault while in kernel mode >> cpuid = 3; apic id = 03 >> instruction pointer = 0x20:0xffffffff804bce56 >> stack pointer = 0x20:0xffffff8000039b60 >> frame pointer = 0x20:0xffffff8000039b70 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, IOPL = 0 >> current process = 11 (idle: cpu3) >> [thread pid 11 tid 100003 ] >> Stopped at acpi_cpu_c1+0x6: leave >> db> bt >> Tracing pid 11 tid 100003 td 0xffffff8001863720 >> acpi_cpu_c1() at acpi_cpu_c1+0x6 >> acpi_cpu_idle() at acpi_cpu_idle+0x20c >> sched_idletd() at sched_idletd+0x123 >> fork_exit() at fork_exit+0x117 >> fork_trampoline() at fork_trampoline+0xe >> --- trap 0, rip = 0, rsp = 0xffffff8000039d40, rbp = 0 --- >> db> >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> >> I can boot with kern.smp.diabled=1, so I get address lines. >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> (kgdb) list *acpi_cpu_c1+0x6 >> 0xffffffff804bce56 is in acpi_cpu_c1 (/usr/src/sys/amd64/acpica/acpi_machdep.c:100). >> 95 >> 96 void >> 97 acpi_cpu_c1() >> 98 { >> 99 __asm __volatile("sti; hlt"); >> 100 } >> (kgdb) list *acpi_cpu_idle+0x20c >> 0xffffffff801b443c is in acpi_cpu_idle (/usr/src/sys/dev/acpica/acpi_cpu.c:966). >> 961 ACPI_ENABLE_IRQS(); >> 962 >> 963 /* Find the actual time asleep in microseconds. */ >> 964 end_time = acpi_TimerDelta(end_time, start_time); >> 965 sc->cpu_prev_sleep = (sc->cpu_prev_sleep * 3 + PM_USEC(end_time)) / 4; >> 966 } >> (kgdb) list *sched_idletd+0x123 >> 0xffffffff8030b733 is in sched_idletd (/usr/src/sys/kern/sched_ule.c:2562). >> 2557 cpu_spinwait(); >> 2558 } >> 2559 } >> 2560 switchcnt = tdq->tdq_switchcnt + tdq->tdq_oldswitchcnt; >> 2561 if (tdq->tdq_load == 0) >> 2562 cpu_idle(switchcnt > 1); >> 2563 if (tdq->tdq_load) { >> 2564 thread_lock(td); >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 19:18:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 844C0106564A for ; Sun, 28 Jun 2009 19:18:10 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 239BE8FC14 for ; Sun, 28 Jun 2009 19:18:10 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from fuzz.geek.sh (unknown [196.209.243.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id A96E03A465; Sun, 28 Jun 2009 21:18:08 +0200 (SAST) Message-ID: <4A47C1DF.2020908@phat.za.net> Date: Sun, 28 Jun 2009 21:17:51 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.22 (X11/20090628) MIME-Version: 1.0 To: Luigi Rizzo References: <4A4751ED.8020002@phat.za.net> <20090628181105.GA98246@onelab2.iet.unipi.it> In-Reply-To: <20090628181105.GA98246@onelab2.iet.unipi.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: recent boot0 changes dropped a partition type? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 19:18:10 -0000 Hi, Luigi Rizzo wrote: > yes it was removed to save space, i am more than happy to replace 0xb > with 0xc if the latter turns out to be more popular. > > So far we have the following (all the rest is basically commented > out because we need space for other stuff): > > 131 linux > 165 FreeBSD > 166 [Open]BSD > 169 [Net]BSD > 6 Win [FAT16 >= 32MB] > 7 Win [NTFS] > 11 Win [FAT32] > > Suggestions for replacements are welcome From my bit of research now, it looks like types 6 and 11 should be changed. Their modern equivalents are 0xE and 0xC respectively. I think the only Redmond systems that still use 0x6 and 0xB pre-date Windows XP. I'm basing my opinions on personal experience and: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html http://en.wikipedia.org/wiki/File_Allocation_Table The only caveat I see is: http://support.microsoft.com/kb/151414 But with limited space we probably should just decide to not worry about anything older than Windows XP... Thanks, Aragon From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 19:27:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E9941065670 for ; Sun, 28 Jun 2009 19:27:01 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id B94FE8FC2B for ; Sun, 28 Jun 2009 19:27:00 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from orion.SpringDaemons.com (unknown [77.232.3.143]) by mx0.deglitch.com (Postfix) with ESMTPA id A46C28FC27; Sun, 28 Jun 2009 23:26:58 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id 424A739C4F; Sun, 28 Jun 2009 23:27:15 +0400 (MSD) Date: Sun, 28 Jun 2009 23:27:08 +0400 From: Stanislav Sedov To: "Daniel O'Connor" Message-Id: <20090628232708.0328701d.stas@FreeBSD.org> In-Reply-To: <200906281430.12157.doconnor@gsoft.com.au> References: <4A4517BE.9040504@FreeBSD.org> <200906280847.59316.doconnor@gsoft.com.au> <4DF26D1E-B437-4FB3-B210-50ACB727101A@transsys.com> <200906281430.12157.doconnor@gsoft.com.au> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Sun__28_Jun_2009_23_27_08_+0400_67eTc5Ew+G0Qlgb3" Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 19:27:01 -0000 --Signature=_Sun__28_Jun_2009_23_27_08_+0400_67eTc5Ew+G0Qlgb3 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 28 Jun 2009 14:30:02 +0930 "Daniel O'Connor" mentioned: > On Sun, 28 Jun 2009, Louis Mamakos wrote: > > > Unfortunately you can't specify swap this way because it has no ID, > > > I don't know how hard it would be to add such a thing (which would > > > require a mkswap or somesuch, and modification to the dump & swap > > > code..) > > > > I use glabel to create containers with named labels that I then > > reference as swap devices. (e.g., /dev/label/swap0, etc.) > > > > # swapinfo > > Device 1024-blocks Used Avail Capacity > > /dev/label/swap2 1044192 0 1044192 0% > > /dev/label/swap3 1044192 0 1044192 0% > > /dev/label/swap4 1044192 0 1044192 0% > > Total 3132576 0 3132576 0% >=20 > Ahh, of course, like this? > glabel label swap0 /dev/ad0s1b > (well that works for me but I'd like to check ;) >=20 > Any idea if that works with dumping? dumpon accepts it but.. >=20 It does for sure. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Sun__28_Jun_2009_23_27_08_+0400_67eTc5Ew+G0Qlgb3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKR8QTAAoJEKN82nOYvCd0zlEP/0dMXabZBsBvKVy3vSHNf0lF PJjbPcZo/qJ4n/EVFihjnY6y1JoidKMS0WpGCVoiU9Fr1xEPiNgyGRKp+dXUnu9y dURMKs/WvWt5uvJTngVZuknIpWQr93eWTC9l0KSTdr1fPsuwX91JV3bd3D0kV7IF ktYb7R4fIPwDVwcEqZreJ3TyRCbpksZ6Vmg6KGrutPqtUVZRcjm0ubBdtYvRt/+w U8vWPOVNb7LYbqaarSI8ssSK7NZ2cLsAtaBv/aV3bCs8mnSGiArQfR/QHSgD1PiW j0OXzHf8ayNhsf8RMnPEDOiY0hmFYtjwPSDr5cr4MFW9wNyHlJc8OSZcnclZVyKB 64WezKi8KQzVLTEiQ1KOad+/dW+G5VQm+G/6L533CXZb+gPBo2/xdQ41GkDrp99N JcpWdHMbSdm6JeI6H3gUlTJD3rDH2D1QRdriZdUrFxtvF/0tkxz/eysO/5Bolb7E ViKcN1P/uCRw6+Hmg0FjdPtB8oUdo9Q6lNfinJhJrhxm0diOaQagwZaIddznx5NZ RB/hui9alt2BiyRg8fOp1V8ob5jH36GrusVhCXGB1XsaY+Uv6b4vlM4uZAn1iE5z E4r5svzM+FdxRYKis5JWJ+gXshFZZRvqz/aJ6tZ/DlSDdrfVM9aGpiqwNOPQ8DPD 5MvNGTCZaE4aWhW9e/cH =Gp4R -----END PGP SIGNATURE----- --Signature=_Sun__28_Jun_2009_23_27_08_+0400_67eTc5Ew+G0Qlgb3-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 19:29:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F22B11065672; Sun, 28 Jun 2009 19:29:49 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from smtp-vbr15.xs4all.nl (smtp-vbr15.xs4all.nl [194.109.24.35]) by mx1.freebsd.org (Postfix) with ESMTP id 9FB408FC22; Sun, 28 Jun 2009 19:29:49 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from merom.hotsoft.nl (beasties.demon.nl [82.161.3.114]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id n5SJThlj084354; Sun, 28 Jun 2009 21:29:48 +0200 (CEST) (envelope-from hansot@iae.nl) Message-ID: <4A47C4A6.3050001@iae.nl> Date: Sun, 28 Jun 2009 21:29:42 +0200 From: Hans Ottevanger User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: Anonymous References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> In-Reply-To: <86bpo8b3y8.fsf@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org, Norikatsu Shigemura Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 19:29:50 -0000 Anonymous wrote: > Hans Ottevanger writes: > >> Norikatsu Shigemura wrote: >>> Hi. >>> >> Hi, >> >> I have almost the same issue, just the addresses are different and in >> my case the trap occurs on cpu2. >> >> My system is based on an Intel PB965LT main board with a Q6600 quad >> core CPU and 8 Gbyte of RAM. I am also using the amd64 kernel, where >> kernel configuration is almost identical to GENERIC, with devices >> removed that I do not have and the following lines added >> >> device drm >> device radeondrm >> device sound >> device snd_hda >> >> If I remove the drm and radeondrm devices from the config file and >> recompile the kernel, the panic does not occur and the corresponding >> modules can be loaded without a problem. > > Can you try to boot with DRM and hw.drm.msi=0? In my case it does not > panic then. > Hi, I have just tried this with r195137 and the drm devices described above in my kernel configuration file. If I specify "set hw.drm.msi=0" from the loader prompt -no- panic occurs, otherwise it does. So it appears that this workaround works. Kind regards, Hans >> Some "binary searching" of Subversion releases shows that the problem >> first occurs with r194985. If I update to r195137 and revert the >> relevant files from the revision r194985 to r194984, no panic occurs. >> >> Of course it could very well be that r194985 itself is not the issue, >> but triggers a problem somewhere else in the kernel. >> >> Kind regards, >> >> Hans >> >>> I got a panic after AP CPU launched on boot. So I couldn't get >>> crash dump and information. >>> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> FreeBSD nadesico.ninth-nine.com 8.0-CURRENT FreeBSD 8.0-CURRENT #49: Sun Jun 28 02:53:48 JST 2009 nork@nadesico.ninth-nine.com:/usr/obj/usr/src/sys/NADESICO amd64 >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> SMP: AP CPU #3 Launched! >>> SMP: AP CPU #1 Launched! >>> SMP: AP CPU #2 Launched! >>> >>> Fatal trap 30: reserved (unknown) fault while in kernel mode >>> cpuid = 3; apic id = 03 >>> instruction pointer = 0x20:0xffffffff804bce56 >>> stack pointer = 0x20:0xffffff8000039b60 >>> frame pointer = 0x20:0xffffff8000039b70 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, IOPL = 0 >>> current process = 11 (idle: cpu3) >>> [thread pid 11 tid 100003 ] >>> Stopped at acpi_cpu_c1+0x6: leave >>> db> bt >>> Tracing pid 11 tid 100003 td 0xffffff8001863720 >>> acpi_cpu_c1() at acpi_cpu_c1+0x6 >>> acpi_cpu_idle() at acpi_cpu_idle+0x20c >>> sched_idletd() at sched_idletd+0x123 >>> fork_exit() at fork_exit+0x117 >>> fork_trampoline() at fork_trampoline+0xe >>> --- trap 0, rip = 0, rsp = 0xffffff8000039d40, rbp = 0 --- >>> db> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> >>> I can boot with kern.smp.diabled=1, so I get address lines. >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> (kgdb) list *acpi_cpu_c1+0x6 >>> 0xffffffff804bce56 is in acpi_cpu_c1 (/usr/src/sys/amd64/acpica/acpi_machdep.c:100). >>> 95 >>> 96 void >>> 97 acpi_cpu_c1() >>> 98 { >>> 99 __asm __volatile("sti; hlt"); >>> 100 } >>> (kgdb) list *acpi_cpu_idle+0x20c >>> 0xffffffff801b443c is in acpi_cpu_idle (/usr/src/sys/dev/acpica/acpi_cpu.c:966). >>> 961 ACPI_ENABLE_IRQS(); >>> 962 >>> 963 /* Find the actual time asleep in microseconds. */ >>> 964 end_time = acpi_TimerDelta(end_time, start_time); >>> 965 sc->cpu_prev_sleep = (sc->cpu_prev_sleep * 3 + PM_USEC(end_time)) / 4; >>> 966 } >>> (kgdb) list *sched_idletd+0x123 >>> 0xffffffff8030b733 is in sched_idletd (/usr/src/sys/kern/sched_ule.c:2562). >>> 2557 cpu_spinwait(); >>> 2558 } >>> 2559 } >>> 2560 switchcnt = tdq->tdq_switchcnt + tdq->tdq_oldswitchcnt; >>> 2561 if (tdq->tdq_load == 0) >>> 2562 cpu_idle(switchcnt > 1); >>> 2563 if (tdq->tdq_load) { >>> 2564 thread_lock(td); >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 19:41:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44CB61065676 for ; Sun, 28 Jun 2009 19:41:47 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id ED90D8FC19 for ; Sun, 28 Jun 2009 19:41:46 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n5SJKgBN041845; Sun, 28 Jun 2009 13:20:42 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A47C28A.2030000@samsco.org> Date: Sun, 28 Jun 2009 13:20:42 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Aragon Gouveia References: <4A4751ED.8020002@phat.za.net> <20090628181105.GA98246@onelab2.iet.unipi.it> <4A47C1DF.2020908@phat.za.net> In-Reply-To: <4A47C1DF.2020908@phat.za.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Luigi Rizzo , current@freebsd.org Subject: Re: recent boot0 changes dropped a partition type? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 19:41:47 -0000 Aragon Gouveia wrote: > Hi, > > Luigi Rizzo wrote: >> yes it was removed to save space, i am more than happy to replace 0xb >> with 0xc if the latter turns out to be more popular. >> >> So far we have the following (all the rest is basically commented >> out because we need space for other stuff): >> >> 131 linux >> 165 FreeBSD >> 166 [Open]BSD >> 169 [Net]BSD >> 6 Win [FAT16 >= 32MB] >> 7 Win [NTFS] >> 11 Win [FAT32] >> >> Suggestions for replacements are welcome > > From my bit of research now, it looks like types 6 and 11 should be > changed. Their modern equivalents are 0xE and 0xC respectively. I > think the only Redmond systems that still use 0x6 and 0xB pre-date > Windows XP. I'm basing my opinions on personal experience and: > > http://www.win.tue.nl/~aeb/partitions/partition_types-1.html > http://en.wikipedia.org/wiki/File_Allocation_Table > > The only caveat I see is: > > http://support.microsoft.com/kb/151414 > > But with limited space we probably should just decide to not worry about > anything older than Windows XP... How about not worrying about NetBSD or OpenBSD? How many people typically multi-boot OpenBSD? Scott From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 20:06:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 384311065679 for ; Sun, 28 Jun 2009 20:06:58 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id BCCED8FC1C for ; Sun, 28 Jun 2009 20:06:57 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fxm18 with SMTP id 18so1556252fxm.43 for ; Sun, 28 Jun 2009 13:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/2Yvbf1N+7sEPizI+AoO9PPZhf8wkZQbYFqQq4LCwEM=; b=Oag+wLHo7oJex0uGezKesJog1/L58MquDM0FwMX+no2PIhynq+JzZTHcJgrsegZ+du RSNfUjzCm5GhLkqHpqajMCuCNisLYTVING3P5r5QlYjFDb7sSMTe4OuYe8TI/vq8zQo1 4bQqqEgpygeBVXIOHuMCy5qM6c43wdzxEnPqs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e6Rb8Px+ZU73PreKrGppyJxf2W+DM+uaxtgjI5vqpEn/hDDoCwYsXNWI+/g26m5jjV DMt03UrJE2yd+Yeeydxewu5sW9xcdGxCnjSPgRsHvJZHXZyZ6JDzFsDBWZeDJ3jw/VX+ /QEs97pJdne9TF7uE34O75YQi+ruEZP/vpACU= MIME-Version: 1.0 Received: by 10.204.56.206 with SMTP id z14mr6321108bkg.34.1246219616149; Sun, 28 Jun 2009 13:06:56 -0700 (PDT) In-Reply-To: <20090628.214417.598552788769548331.ken@tydfam.jp> References: <200906252011.42597.doconnor@gsoft.com.au> <20090625.202617.598552788702437664.ken@tydfam.jp> <200906252320.32544.doconnor@gsoft.com.au> <20090628.214417.598552788769548331.ken@tydfam.jp> Date: Mon, 29 Jun 2009 00:06:56 +0400 Message-ID: From: pluknet To: ken Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, admin@kkip.pl Subject: Re: 8.0-current cannot find disk!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 20:06:59 -0000 2009/6/28 ken : > > From: "Daniel O'Connor" >> From what I can see it finds ad10 (Hitachi 100Gb on ata5) and ad12 (WD >> 100Gb on ata6) disks.. >> >> ata5 & ata6 are on the JMicron JMB363. >> >> The question is why sysinstall thinks there are no disks :( >> >> What happens if you open a Fixit emergency holographic shell and run >> echo /dev/ad* > > I took a little different approach because it looks to be not only sysinstall problem; > a) create 7.2R and update src to -current. > b) make buildworld && make installworld && make buildkernel && make installkernel > c) reboot > d) See what happens..... > > The result is at http://www.tydfam.jp/experimental/boot_photo2/. They are photos ordered by the sequence. And the last one showes 'db > where' result that says something is wrong at malloc_init!! > > It points to You might have incompatible kernel modules left after 7.2. 20090419: The layout of struct malloc_type, used by modules to register new memory allocation types, has changed. Most modules will need to be rebuilt or panics may be experienced. Bump __FreeBSD_version to 800081. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 20:14:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F849106566C; Sun, 28 Jun 2009 20:14:30 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 2DC5F8FC1E; Sun, 28 Jun 2009 20:14:30 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:43435 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1ML0lX-0006VX-5y; Sun, 28 Jun 2009 22:14:21 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 6A20F61C15; Sun, 28 Jun 2009 22:14:19 +0200 (CEST) Message-Id: <09277772-9C54-4AE6-A147-CB6A4ED38C48@exscape.org> From: Thomas Backman To: FreeBSD current In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 28 Jun 2009 22:14:16 +0200 References: <08D1E6DF-89D3-4887-9234-C3DB9164D794@exscape.org> <20090514133017.362075dhcdy7o2bs@webmail.leidinger.net> <7CD27FF0-CBFA-48B7-9E18-763D8C3ED9B8@exscape.org> <4A0C9B0C.4050403@jrv.org> X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1ML0lX-0006VX-5y. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1ML0lX-0006VX-5y 208144b44b36969805de88ad507ee025 Cc: freebsd-fs@freebsd.org Subject: Re: zfs send -R segfault, anyone else? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 20:14:31 -0000 On May 15, 2009, at 11:30 AM, Thomas Backman wrote: > > On May 15, 2009, at 12:28 AM, James R. Van Artsdalen wrote: > >> Thomas Backman wrote: >>> [root@chaos ~]# zfs send -R -I $OLD tank@$NOW > diff-snap >>> [root@chaos ~]# cat diff-snap | zfs recv -Fvd slave >>> Segmentation fault: 11 (core dumped) >>> >>> Same kinda backtrace, but what's up with strcmp()? >>> I suppose the issue stems from libzfs, and is not within libc: >> >> Different problem The SIGSEGV is happening in strcmp because it is >> called with strcmp(0,0) >> and tries to dereference address -4 (probably another bug itself). >> >> This hack gets around the issue but someone familiar with this >> needs to >> decide the correct action. >> >> The first change is actually unrelated (a sorry attempt at fixing the >> previous zfs send bug). >> >> The last change may be unnecessary as that case may never happen >> unless >> the pool can be renamed? >> >> [... patch ...] > > Thanks! This list is pretty impressive. :) > I can't validate how correct the fix is, considering my lacking > knowledge in C (I know the basics, but kernel/related programming? > no way!), but I CAN say that it appears to work just fine! > > Regards, > Thomas > Any news on this? The bug's been around for a long time, and a fix has been around for at least 1.5 months now, and AFAIK the bug still lives. The patch, again (I can't vouch for its correctness, but I can certainly say that it works just fine *for me*) follows. Regards, Thomas Index: cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c =================================================================== --- cddl/contrib/opensolaris/lib/libzfs/common/ libzfs_sendrecv.c (revision 194851) +++ cddl/contrib/opensolaris/lib/libzfs/common/ libzfs_sendrecv.c (working copy) @@ -239,6 +239,8 @@ char *propname = nvpair_name(elem); zfs_prop_t prop = zfs_name_to_prop(propname); nvlist_t *propnv; + if (prop == ZPROP_INVAL) + continue; if (!zfs_prop_user(propname) && zfs_prop_readonly(prop)) continue; @@ -1126,7 +1128,7 @@ uint64_t originguid = 0; uint64_t stream_originguid = 0; uint64_t parent_fromsnap_guid, stream_parent_fromsnap_guid; - char *fsname, *stream_fsname; + char *fsname, *stream_fsname, *p1, *p2; nextfselem = nvlist_next_nvpair(local_nv, fselem); @@ -1295,10 +1297,13 @@ "parentfromsnap", &stream_parent_fromsnap_guid)); /* check for rename */ + p1 = strrchr(fsname, '/'); + p2 = strrchr(stream_fsname, '/'); + if ((stream_parent_fromsnap_guid != 0 && stream_parent_fromsnap_guid != parent_fromsnap_guid) || - strcmp(strrchr(fsname, '/'), - strrchr(stream_fsname, '/')) != 0) { + (p1 != NULL && p2 != NULL && strcmp (p1, p2) != 0) || + ((p1 == NULL) ^ (p2 == NULL))) { nvlist_t *parent; char tryname[ZFS_MAXNAMELEN]; @@ -1317,7 +1322,7 @@ VERIFY(0 == nvlist_lookup_string(parent, "name", &pname)); (void) snprintf(tryname, sizeof (tryname), - "%s%s", pname, strrchr(stream_fsname, '/')); + "%s%s", pname, p2 ? p2 : ""); } else { tryname[0] = '\0'; if (flags.verbose) { From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 20:18:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8C42D106564A for ; Sun, 28 Jun 2009 20:18:34 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 5F11A8FC15 for ; Sun, 28 Jun 2009 20:18:34 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-156-4-82.bna.bellsouth.net [70.156.4.82]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n5SKIVd5027633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jun 2009 16:18:32 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Anonymous In-Reply-To: <86bpo8b3y8.fsf@gmail.com> References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-mnIwif1iAmzW9SawMXMK" Organization: FreeBSD Date: Sun, 28 Jun 2009 15:18:26 -0500 Message-Id: <1246220306.1759.43.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Hans Ottevanger , Norikatsu Shigemura , freebsd-current@freebsd.org Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 20:18:34 -0000 --=-mnIwif1iAmzW9SawMXMK Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2009-06-28 at 22:36 +0400, Anonymous wrote: > Hans Ottevanger writes: >=20 > > Norikatsu Shigemura wrote: > >> Hi. > >> > > > > Hi, > > > > I have almost the same issue, just the addresses are different and in > > my case the trap occurs on cpu2. > > > > My system is based on an Intel PB965LT main board with a Q6600 quad > > core CPU and 8 Gbyte of RAM. I am also using the amd64 kernel, where > > kernel configuration is almost identical to GENERIC, with devices > > removed that I do not have and the following lines added > > > > device drm > > device radeondrm > > device sound > > device snd_hda > > > > If I remove the drm and radeondrm devices from the config file and > > recompile the kernel, the panic does not occur and the corresponding > > modules can be loaded without a problem. >=20 > Can you try to boot with DRM and hw.drm.msi=3D0? In my case it does not > panic then. drm is a consumer of msi if the hardware is capable. If you disable msi you won't take the path that 194985 fixes, or any path that involves msi... The panic message seemed rather unhelpful to me and I can't think of a reason that it would work as a module and not if it is compiled in. Did you clean your kernel and rebuild? robert. > > > > Some "binary searching" of Subversion releases shows that the problem > > first occurs with r194985. If I update to r195137 and revert the > > relevant files from the revision r194985 to r194984, no panic occurs. > > > > Of course it could very well be that r194985 itself is not the issue, > > but triggers a problem somewhere else in the kernel. > > > > Kind regards, > > > > Hans > > > >> I got a panic after AP CPU launched on boot. So I couldn't get > >> crash dump and information. > >> > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - > >> FreeBSD nadesico.ninth-nine.com 8.0-CURRENT FreeBSD 8.0-CURRENT #49: S= un Jun 28 02:53:48 JST 2009 nork@nadesico.ninth-nine.com:/usr/obj/usr/s= rc/sys/NADESICO amd64 > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - > >> > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - > >> SMP: AP CPU #3 Launched! > >> SMP: AP CPU #1 Launched! > >> SMP: AP CPU #2 Launched! > >> > >> Fatal trap 30: reserved (unknown) fault while in kernel mode > >> cpuid =3D 3; apic id =3D 03 > >> instruction pointer =3D 0x20:0xffffffff804bce56 > >> stack pointer =3D 0x20:0xffffff8000039b60 > >> frame pointer =3D 0x20:0xffffff8000039b70 > >> code segment =3D base 0x0, limit 0xfffff, type 0x1b > >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 > >> processor eflags =3D interrupt enabled, IOPL =3D 0 > >> current process =3D 11 (idle: cpu3) > >> [thread pid 11 tid 100003 ] > >> Stopped at acpi_cpu_c1+0x6: leave > >> db> bt > >> Tracing pid 11 tid 100003 td 0xffffff8001863720 > >> acpi_cpu_c1() at acpi_cpu_c1+0x6 > >> acpi_cpu_idle() at acpi_cpu_idle+0x20c > >> sched_idletd() at sched_idletd+0x123 > >> fork_exit() at fork_exit+0x117 > >> fork_trampoline() at fork_trampoline+0xe > >> --- trap 0, rip =3D 0, rsp =3D 0xffffff8000039d40, rbp =3D 0 --- > >> db> > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - > >> > >> I can boot with kern.smp.diabled=3D1, so I get address lines. > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - > >> (kgdb) list *acpi_cpu_c1+0x6 > >> 0xffffffff804bce56 is in acpi_cpu_c1 (/usr/src/sys/amd64/acpica/acpi_m= achdep.c:100). > >> 95 > >> 96 void > >> 97 acpi_cpu_c1() > >> 98 { > >> 99 __asm __volatile("sti; hlt"); > >> 100 } > >> (kgdb) list *acpi_cpu_idle+0x20c > >> 0xffffffff801b443c is in acpi_cpu_idle (/usr/src/sys/dev/acpica/acpi_c= pu.c:966). > >> 961 ACPI_ENABLE_IRQS(); > >> 962 > >> 963 /* Find the actual time asleep in microseconds. */ > >> 964 end_time =3D acpi_TimerDelta(end_time, start_time); > >> 965 sc->cpu_prev_sleep =3D (sc->cpu_prev_sleep * 3 + PM_USEC(e= nd_time)) / 4; > >> 966 } > >> (kgdb) list *sched_idletd+0x123 > >> 0xffffffff8030b733 is in sched_idletd (/usr/src/sys/kern/sched_ule.c:2= 562). > >> 2557 cpu_spinwait(); > >> 2558 } > >> 2559 } > >> 2560 switchcnt =3D tdq->tdq_switchcnt + tdq->tdq_ol= dswitchcnt; > >> 2561 if (tdq->tdq_load =3D=3D 0) > >> 2562 cpu_idle(switchcnt > 1); > >> 2563 if (tdq->tdq_load) { > >> 2564 thread_lock(td); > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-mnIwif1iAmzW9SawMXMK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkpH0BIACgkQM4TrQ4qfRONxCgCaAxCzdLnPfEqgL2Ayc/Q5rKPw 8acAnRquXAu486j2Qa8kBh2vHrpX8HW4 =PeBX -----END PGP SIGNATURE----- --=-mnIwif1iAmzW9SawMXMK-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 20:36:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA6A8106564A; Sun, 28 Jun 2009 20:36:31 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7478FC19; Sun, 28 Jun 2009 20:36:31 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from [85.175.178.149] (helo=moosi) by services.ipt.ru with esmtpa (Exim 4.54 (FreeBSD)) id 1ML16z-000G7k-Iz; Mon, 29 Jun 2009 00:36:29 +0400 To: Chagin Dmitry References: <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <179b97fb0906280929u654129bfoaefa2a43f7058dc5@mail.gmail.com> <20090628165458.GA25437@dchagin.static.corbina.ru> <20090628174748.GA27292@dchagin.static.corbina.ru> From: Boris Samorodov Date: Mon, 29 Jun 2009 00:37:12 +0400 In-Reply-To: <20090628174748.GA27292@dchagin.static.corbina.ru> (Chagin Dmitry's message of "Sun\, 28 Jun 2009 21\:47\:48 +0400") Message-ID: <91921319@ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Brandon Gooch , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Juergen Lock , "Sean C. Farley" Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 20:36:32 -0000 Chagin Dmitry writes: > On Sun, Jun 28, 2009 at 12:39:09PM -0500, Sean C. Farley wrote: >> On Sun, 28 Jun 2009, Chagin Dmitry wrote: >> >> > On Sun, Jun 28, 2009 at 04:29:49PM +0000, Brandon Gooch wrote: >> >> *snip* >> >> >> I have. I'm using it with about the same level of success as the >> >> previous versions of Flash (I need to map a couple of keys to run >> >> `pkill npviewer.bin`). >> >> I also have a key mapping to killall npviewer.bin. >> >> > for amd64 try: compat.linux32.maxssiz=4194304 >> > >> > for i386 try: limit stacksize to 4mb or set unlimited. >> >> Thank you. I tested viewing "TXT ISLAND" on YouTube. Works at higher >> limits for me such as 32MB but not at my default of 64MB. >> >> Why/how does this help? At least on i386, it stops Flash from choking >> on YouTube videos when switching to HD or jumping within a video. > > the reason? foolish waves in a Uli head and stupid bug in flash plugin. > flash uses pthread_detach() after pthread_join() call. > glibc allows such behaviour (if stack limit < 40Mb) piece of shit... If that helps then it's a good idea to create a pkg-message for the port (Juergen Lock is CCed). WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 20:37:54 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C33D1065703; Sun, 28 Jun 2009 20:37:54 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from smtp-vbr7.xs4all.nl (smtp-vbr7.xs4all.nl [194.109.24.27]) by mx1.freebsd.org (Postfix) with ESMTP id A33598FC18; Sun, 28 Jun 2009 20:37:53 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from merom.hotsoft.nl (beasties.demon.nl [82.161.3.114]) by smtp-vbr7.xs4all.nl (8.13.8/8.13.8) with ESMTP id n5SKblvJ020222; Sun, 28 Jun 2009 22:37:52 +0200 (CEST) (envelope-from hansot@iae.nl) Message-ID: <4A47D49B.9000504@iae.nl> Date: Sun, 28 Jun 2009 22:37:47 +0200 From: Hans Ottevanger User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: Robert Noland References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> In-Reply-To: <1246220306.1759.43.camel@balrog.2hip.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Anonymous , freebsd-current@FreeBSD.org, Norikatsu Shigemura Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 20:37:54 -0000 Robert Noland wrote: > On Sun, 2009-06-28 at 22:36 +0400, Anonymous wrote: >> Hans Ottevanger writes: >> >>> Norikatsu Shigemura wrote: >>>> Hi. >>>> >>> Hi, >>> >>> I have almost the same issue, just the addresses are different and in >>> my case the trap occurs on cpu2. >>> >>> My system is based on an Intel PB965LT main board with a Q6600 quad >>> core CPU and 8 Gbyte of RAM. I am also using the amd64 kernel, where >>> kernel configuration is almost identical to GENERIC, with devices >>> removed that I do not have and the following lines added >>> >>> device drm >>> device radeondrm >>> device sound >>> device snd_hda >>> >>> If I remove the drm and radeondrm devices from the config file and >>> recompile the kernel, the panic does not occur and the corresponding >>> modules can be loaded without a problem. >> Can you try to boot with DRM and hw.drm.msi=0? In my case it does not >> panic then. > > drm is a consumer of msi if the hardware is capable. If you disable msi > you won't take the path that 194985 fixes, or any path that involves > msi... The panic message seemed rather unhelpful to me and I can't > think of a reason that it would work as a module and not if it is > compiled in. Did you clean your kernel and rebuild? > Hi, I updated my tree to the appropriate revision, completely deleted /usr/obj and rebuilt using "make buildkernel KERNCONF=TEST && make installkernel KERNCONF=TEST". I suppose that should do the trick. Kind regards Hans > robert. > >>> Some "binary searching" of Subversion releases shows that the problem >>> first occurs with r194985. If I update to r195137 and revert the >>> relevant files from the revision r194985 to r194984, no panic occurs. >>> >>> Of course it could very well be that r194985 itself is not the issue, >>> but triggers a problem somewhere else in the kernel. >>> >>> Kind regards, >>> >>> Hans >>> >>>> I got a panic after AP CPU launched on boot. So I couldn't get >>>> crash dump and information. >>>> >>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>>> FreeBSD nadesico.ninth-nine.com 8.0-CURRENT FreeBSD 8.0-CURRENT #49: Sun Jun 28 02:53:48 JST 2009 nork@nadesico.ninth-nine.com:/usr/obj/usr/src/sys/NADESICO amd64 >>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>>> >>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>>> SMP: AP CPU #3 Launched! >>>> SMP: AP CPU #1 Launched! >>>> SMP: AP CPU #2 Launched! >>>> >>>> Fatal trap 30: reserved (unknown) fault while in kernel mode >>>> cpuid = 3; apic id = 03 >>>> instruction pointer = 0x20:0xffffffff804bce56 >>>> stack pointer = 0x20:0xffffff8000039b60 >>>> frame pointer = 0x20:0xffffff8000039b70 >>>> code segment = base 0x0, limit 0xfffff, type 0x1b >>>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>>> processor eflags = interrupt enabled, IOPL = 0 >>>> current process = 11 (idle: cpu3) >>>> [thread pid 11 tid 100003 ] >>>> Stopped at acpi_cpu_c1+0x6: leave >>>> db> bt >>>> Tracing pid 11 tid 100003 td 0xffffff8001863720 >>>> acpi_cpu_c1() at acpi_cpu_c1+0x6 >>>> acpi_cpu_idle() at acpi_cpu_idle+0x20c >>>> sched_idletd() at sched_idletd+0x123 >>>> fork_exit() at fork_exit+0x117 >>>> fork_trampoline() at fork_trampoline+0xe >>>> --- trap 0, rip = 0, rsp = 0xffffff8000039d40, rbp = 0 --- >>>> db> >>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>>> >>>> I can boot with kern.smp.diabled=1, so I get address lines. >>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>>> (kgdb) list *acpi_cpu_c1+0x6 >>>> 0xffffffff804bce56 is in acpi_cpu_c1 (/usr/src/sys/amd64/acpica/acpi_machdep.c:100). >>>> 95 >>>> 96 void >>>> 97 acpi_cpu_c1() >>>> 98 { >>>> 99 __asm __volatile("sti; hlt"); >>>> 100 } >>>> (kgdb) list *acpi_cpu_idle+0x20c >>>> 0xffffffff801b443c is in acpi_cpu_idle (/usr/src/sys/dev/acpica/acpi_cpu.c:966). >>>> 961 ACPI_ENABLE_IRQS(); >>>> 962 >>>> 963 /* Find the actual time asleep in microseconds. */ >>>> 964 end_time = acpi_TimerDelta(end_time, start_time); >>>> 965 sc->cpu_prev_sleep = (sc->cpu_prev_sleep * 3 + PM_USEC(end_time)) / 4; >>>> 966 } >>>> (kgdb) list *sched_idletd+0x123 >>>> 0xffffffff8030b733 is in sched_idletd (/usr/src/sys/kern/sched_ule.c:2562). >>>> 2557 cpu_spinwait(); >>>> 2558 } >>>> 2559 } >>>> 2560 switchcnt = tdq->tdq_switchcnt + tdq->tdq_oldswitchcnt; >>>> 2561 if (tdq->tdq_load == 0) >>>> 2562 cpu_idle(switchcnt > 1); >>>> 2563 if (tdq->tdq_load) { >>>> 2564 thread_lock(td); >>>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 20:41:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0168210656D3; Sun, 28 Jun 2009 20:41:45 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 944EA8FC1B; Sun, 28 Jun 2009 20:41:44 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so1025414and.13 for ; Sun, 28 Jun 2009 13:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=1OnplT3p5OCapLXx/SxCJPs3LkFMoDKbfg8GXZzX3kg=; b=T0aA1XuAqQjTrNbxsosHb0xphryWFCKPbj6/1DHqSea4ZL4F2YxOzMf6XkacErAbbl SDhIXBvxgMWTADvXUHi+VZjGuw6Ar54N/Uy1+/QoK/9ka5uIL3Br4dhwIGjL/Hb0TAVk q/3rTO34v85WnLcpjVwCXl3iKi9igTE30glJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=VJF4SQzAy0C8XpHlCxOFrAnzZ1cs7rf9qB79LP08Os9SOAM3y86vDO25l6xOXhkmYm kbN1yY3THi4TESkL9aJDJXPmPVrxflpjTi5OBRwo4weOqp9j9aSKt2xoroK6QZ45l/Er UEif+1OEUKg0qqSV/LgJ4CIekOaVeqrGv4PPk= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.251.6 with SMTP id y6mr8115892anh.44.1246221703553; Sun, 28 Jun 2009 13:41:43 -0700 (PDT) In-Reply-To: <09277772-9C54-4AE6-A147-CB6A4ED38C48@exscape.org> References: <08D1E6DF-89D3-4887-9234-C3DB9164D794@exscape.org> <20090514133017.362075dhcdy7o2bs@webmail.leidinger.net> <7CD27FF0-CBFA-48B7-9E18-763D8C3ED9B8@exscape.org> <4A0C9B0C.4050403@jrv.org> <09277772-9C54-4AE6-A147-CB6A4ED38C48@exscape.org> Date: Sun, 28 Jun 2009 13:41:43 -0700 X-Google-Sender-Auth: 8e6ff7087de777d1 Message-ID: <3c1674c90906281341w4b235dd7y809e1b23978ad5c3@mail.gmail.com> From: Kip Macy To: Thomas Backman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, FreeBSD current Subject: Re: zfs send -R segfault, anyone else? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 20:41:45 -0000 I'm a bit preoccupied at the moment. Keep reminding me ... -Kip On Sun, Jun 28, 2009 at 1:14 PM, Thomas Backman wrote= : > On May 15, 2009, at 11:30 AM, Thomas Backman wrote: >> >> On May 15, 2009, at 12:28 AM, James R. Van Artsdalen wrote: >> >>> Thomas Backman wrote: >>>> >>>> [root@chaos ~]# zfs send -R -I $OLD tank@$NOW > diff-snap >>>> [root@chaos ~]# cat diff-snap | zfs recv -Fvd slave >>>> Segmentation fault: 11 (core dumped) >>>> >>>> Same kinda backtrace, but what's up with strcmp()? >>>> I suppose the issue stems from libzfs, and is not within libc: >>> >>> Different problem =A0The SIGSEGV is happening in strcmp because it is >>> called with strcmp(0,0) >>> and tries to dereference address -4 (probably another bug itself). >>> >>> This hack gets around the issue but someone familiar with this needs to >>> decide the correct action. >>> >>> The first change is actually unrelated (a sorry attempt at fixing the >>> previous zfs send bug). >>> >>> The last change may be unnecessary as that case may never happen unless >>> the pool can be renamed? >>> >>> [... patch ...] >> >> Thanks! This list is pretty impressive. :) >> I can't validate how correct the fix is, considering my lacking knowledg= e >> in C (I know the basics, but kernel/related programming? no way!), but I= CAN >> say that it appears to work just fine! >> >> Regards, >> Thomas >> > Any news on this? The bug's been around for a long time, and a fix has be= en > around for at least 1.5 months now, and AFAIK the bug still lives. > The patch, again (I can't vouch for its correctness, but I can certainly = say > that it works just fine *for me*) follows. > > Regards, > Thomas > > Index: cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c > =A0(revision 194851) > +++ cddl/contrib/opensolaris/lib/libzfs/common/libzfs_sendrecv.c > =A0(working copy) > @@ -239,6 +239,8 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *propname =3D nvpair_name(elem); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0zfs_prop_t prop =3D zfs_name_to_prop(propn= ame); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nvlist_t *propnv; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (prop =3D=3D ZPROP_INVAL) > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 continue; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (!zfs_prop_user(propname) && zfs_prop_r= eadonly(prop)) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0continue; > @@ -1126,7 +1128,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t originguid =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t stream_originguid =3D 0; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0uint64_t parent_fromsnap_guid, stream_pare= nt_fromsnap_guid; > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *fsname, *stream_fsname; > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *fsname, *stream_fsname, *p1, *p2; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nextfselem =3D nvlist_next_nvpair(local_nv= , fselem); > > @@ -1295,10 +1297,13 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"parentfromsnap", &stream_parent_f= romsnap_guid)); > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0/* check for rename */ > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 p1 =3D strrchr(fsname, '/'); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 p2 =3D strrchr(stream_fsname, '/'); > + > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if ((stream_parent_fromsnap_guid !=3D 0 && > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0stream_parent_fromsnap_guid !=3D p= arent_fromsnap_guid) || > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 strcmp(strrchr(fsname, '/'), > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 strrchr(stream_fsname, '/')) !=3D 0= ) { > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (p1 !=3D NULL && p2 !=3D NULL && st= rcmp (p1, p2) !=3D 0) || > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0((p1 =3D=3D NULL) ^ (p2 =3D=3D N= ULL))) { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0nvlist_t *parent; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char tryname[ZFS_MAXNAMELE= N]; > > @@ -1317,7 +1322,7 @@ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0VERIFY(0 = =3D=3D nvlist_lookup_string(parent, > "name", > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0&p= name)); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(void) snp= rintf(tryname, sizeof (tryname), > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "%s= %s", pname, strrchr(stream_fsname, > '/')); > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "%s%s", pna= me, p2 ? p2 : ""); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0} else { > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0tryname[0]= =3D '\0'; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (flags.= verbose) { > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > --=20 When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 20:44:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 801C81065670 for ; Sun, 28 Jun 2009 20:44:33 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id E76598FC08 for ; Sun, 28 Jun 2009 20:44:32 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: by qw-out-2122.google.com with SMTP id 5so515470qwd.7 for ; Sun, 28 Jun 2009 13:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=8a3PCeys3c3EOZV7RM15flVVCUClU8EZNQWSIDbStOo=; b=KkVToc2yff4xDtu+rMKzRhRj8v1dXjyDPREo56tM8uq+yrRVTnIWRFkwoO5S3/ueSE 1A9BuOr82Y+OUTYfwqBBqc3fUBpbF3sxPormq7He3a6Z3RsEr0fSYlagyazozMlV3ylb 3NSP+/Nb9NrFiSo02yP6cqslG8ydp7uwhAe2o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=G2d0P4BkpDEbQAF60YJLtDV8QH9nb+7ffvCUtzAvUM80m3x8c92CIYcsad0B7VeNJm OE1Y0k637axSH494pfTq3LCIW2Q9XE+itSnewGFH8s6hcq60pmsFyYFj2EUB0YdoCq1x 9C4mLE/QxXbyC9CmMNFAQIFysQrZpFz5L2Wb0= MIME-Version: 1.0 Received: by 10.220.99.149 with SMTP id u21mr1504250vcn.9.1246221872112; Sun, 28 Jun 2009 13:44:32 -0700 (PDT) In-Reply-To: <1246220306.1759.43.camel@balrog.2hip.net> References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> From: Maxim Ignatenko Date: Sun, 28 Jun 2009 23:44:12 +0300 Message-ID: To: Robert Noland Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Anonymous , Hans Ottevanger , Norikatsu Shigemura , freebsd-current@freebsd.org Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 20:44:33 -0000 > Fatal trap 30: reserved (unknown) fault while in kernel mode > cpuid =3D 3; apic id =3D 03 > instruction pointer =C2=A0 =C2=A0 =3D 0x20:0xffffffff804bce56 > stack pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x20:0xffffff8000039= b60 > frame pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x20:0xffffff8000039= b70 > code segment =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D base 0x0, limit= 0xfffff, type 0x1b > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0=3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D interrupt enabled, IOPL = =3D 0 > current process =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 11 (idle: cpu3) > [thread pid 11 tid 100003 ] > Stopped at =C2=A0 =C2=A0 =C2=A0acpi_cpu_c1+0x6: =C2=A0 =C2=A0 =C2=A0 =C2= =A0leave > db> bt > Tracing pid 11 tid 100003 td 0xffffff8001863720 > acpi_cpu_c1() at acpi_cpu_c1+0x6 > acpi_cpu_idle() at acpi_cpu_idle+0x20c > sched_idletd() at sched_idletd+0x123 > fork_exit() at fork_exit+0x117 > fork_trampoline() at fork_trampoline+0xe As for me, r194984 runs normally, but when I tried to boot with r194985 at second try it paniced with backtrace very similar to shown in first message, and at first try even earlier: in sched_ideltd and again on instruction that uses %ebp when ebp =3D 0. First time I stepped on this panic after updating to r195130: Trying to mount root from ufs:/dev/ufs/root Fatal trap 30; reserved (unknown) fault while in kernel mode cpuid =3D 1; apic id =3D 01 instruction ponter =3D 0x20:0xc09252c5 stack pointer =3D 0x28:0xc4ecec94 frame pointer =3D 0x28:0xc4ecec94 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, IOPL =3D 0 current process =3D 11 (idle: cpu1) [thread pid 11 tid 100003] Stopped at 0xc09252c5 =3D acpi_cpu_c1+0x5: popl %ebp db> bt Tracing pid 11 tid 100003 td 0xc5176af0 acpi_cpu_c1(1,c4ececa8,1,0,c4ececc0,...) at 0xc09252c5 =3D acpi_cpu_c1+0x5 acpi_cpu_idle(c4ececd4,c093c0ab,0,c4ececf4,c066fdec,...) at 0xc04acf37 =3D acpi_cpu_idle+0x107 cpu_idle_acpi(0,c4ececf4,c066fdec,0,0,...) at 0xc093d5bb =3D cpu_idle_acpi+= 0x1b cpu_idle(0,0,c5176af0,c4ececf4,202,...) at 0xc093c0ab =3D cpu_idle+0x1b sched_idletd(0,c4ececd38,a4108400,2c0a0e,7022d00,...) at 0xc066fdec =3D sched_idletd+0x1c fork_exit(c066fdd0,0,c4eced38) at 0xc0623aa1 =3D fork_exit+0x91 fork_trampoline() at 0xc0930c80 =3D fork_tramoline+0x8 --- trap 0, eip =3D 0, esp =3D 0xc4ececd70, ebp =3D 0 --- P.S.: i386, dual-core, drm and radeon compiled as modules When I'm trying to boot w/o ACPI support all seems work fine, but system hangs just before starting kdm From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 20:58:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 766A0106566C; Sun, 28 Jun 2009 20:58:04 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 346B38FC1B; Sun, 28 Jun 2009 20:58:04 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id C84F160E6; Sun, 28 Jun 2009 16:58:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1246222683; bh=6rNCKoofpaIKi8haNFsvWg8I8g4wdTkS93quTwQx12Y=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Z3VczB0hqUH/DfJnEiKLMQ+qkp96eJ1SKBDOjMzskjpMQqdWILVFWXKyw9Sd+DTb3 rf0h/2jvVi6OkJqhZMDsnUEMYFwv2YzkfoaVUj1zY4NIMThr/QuLB2cIUQfGJ8t DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=I+TxO7XOMJ6sUZSvUwk0JWK0R4keP3+VVM5R0Heqxwd1A4PNOXevBfZtxNRni0gO+ 4e2jplVoM9JIW/xOhJLBlJtUiSYc4Ymc08Is1Xjjrbud+2gO9dU5zxvJKlbv5w0 Message-ID: <4A47D953.6000600@protected-networks.net> Date: Sun, 28 Jun 2009 16:57:55 -0400 From: Michael Butler User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: Maxim Ignatenko References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=0442D492 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Robert Noland Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 20:58:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maxim Ignatenko wrote: > P.S.: i386, dual-core, drm and radeon compiled as modules > When I'm trying to boot w/o ACPI support all seems work fine, but > system hangs just before starting kdm This can also happen if you haven't recompiled some ports after the shmctl change - kde apps like digikam, plasma etc. are all affected. Also ensure that libdrm, the xorg-server itself and drivers have been recompiled - really 'odd things' happen if you don't - some will dump core, some will hang the system, imb -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpH2VMACgkQQv9rrgRC1JK/+QCdHdi9aaeN9CvsLPbnym+swukp hvwAoMicJTLDYNLJlnx2WbymO3UYOZ/G =x6Jf -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 21:06:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 44E0A1065672; Sun, 28 Jun 2009 21:06:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9FCDD8FC0C; Sun, 28 Jun 2009 21:06:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n5SKRdjQ070099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jun 2009 23:27:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n5SKRdUj093819; Sun, 28 Jun 2009 23:27:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n5SKRdFo093818; Sun, 28 Jun 2009 23:27:39 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 28 Jun 2009 23:27:39 +0300 From: Kostik Belousov To: Robert Noland Message-ID: <20090628202739.GQ2884@deviant.kiev.zoral.com.ua> References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H5oeNUPfJ0vte6JU" Content-Disposition: inline In-Reply-To: <1246220306.1759.43.camel@balrog.2hip.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Anonymous , Hans Ottevanger , Norikatsu Shigemura , freebsd-current@freebsd.org Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 21:06:20 -0000 --H5oeNUPfJ0vte6JU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 28, 2009 at 03:18:26PM -0500, Robert Noland wrote: > On Sun, 2009-06-28 at 22:36 +0400, Anonymous wrote: > > Hans Ottevanger writes: > >=20 > > > Norikatsu Shigemura wrote: > > >> Hi. > > >> > > > > > > Hi, > > > > > > I have almost the same issue, just the addresses are different and in > > > my case the trap occurs on cpu2. > > > > > > My system is based on an Intel PB965LT main board with a Q6600 quad > > > core CPU and 8 Gbyte of RAM. I am also using the amd64 kernel, where > > > kernel configuration is almost identical to GENERIC, with devices > > > removed that I do not have and the following lines added > > > > > > device drm > > > device radeondrm > > > device sound > > > device snd_hda > > > > > > If I remove the drm and radeondrm devices from the config file and > > > recompile the kernel, the panic does not occur and the corresponding > > > modules can be loaded without a problem. > >=20 > > Can you try to boot with DRM and hw.drm.msi=3D0? In my case it does not > > panic then. >=20 > drm is a consumer of msi if the hardware is capable. If you disable msi > you won't take the path that 194985 fixes, or any path that involves > msi... The panic message seemed rather unhelpful to me and I can't > think of a reason that it would work as a module and not if it is > compiled in. Did you clean your kernel and rebuild? Trap 30 is usually indicates that interrupts were enabled before the handler was established. rsvd is set as a filler for unused IDT entries. >=20 > robert. >=20 > > > > > > Some "binary searching" of Subversion releases shows that the problem > > > first occurs with r194985. If I update to r195137 and revert the > > > relevant files from the revision r194985 to r194984, no panic occurs. > > > > > > Of course it could very well be that r194985 itself is not the issue, > > > but triggers a problem somewhere else in the kernel. > > > > > > Kind regards, > > > > > > Hans > > > > > >> I got a panic after AP CPU launched on boot. So I couldn't get > > >> crash dump and information. > > >> > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - > > >> FreeBSD nadesico.ninth-nine.com 8.0-CURRENT FreeBSD 8.0-CURRENT #49:= Sun Jun 28 02:53:48 JST 2009 nork@nadesico.ninth-nine.com:/usr/obj/usr= /src/sys/NADESICO amd64 > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - > > >> > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - > > >> SMP: AP CPU #3 Launched! > > >> SMP: AP CPU #1 Launched! > > >> SMP: AP CPU #2 Launched! > > >> > > >> Fatal trap 30: reserved (unknown) fault while in kernel mode > > >> cpuid =3D 3; apic id =3D 03 > > >> instruction pointer =3D 0x20:0xffffffff804bce56 > > >> stack pointer =3D 0x20:0xffffff8000039b60 > > >> frame pointer =3D 0x20:0xffffff8000039b70 > > >> code segment =3D base 0x0, limit 0xfffff, type 0x1b > > >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > >> processor eflags =3D interrupt enabled, IOPL =3D 0 > > >> current process =3D 11 (idle: cpu3) > > >> [thread pid 11 tid 100003 ] > > >> Stopped at acpi_cpu_c1+0x6: leave > > >> db> bt > > >> Tracing pid 11 tid 100003 td 0xffffff8001863720 > > >> acpi_cpu_c1() at acpi_cpu_c1+0x6 > > >> acpi_cpu_idle() at acpi_cpu_idle+0x20c > > >> sched_idletd() at sched_idletd+0x123 > > >> fork_exit() at fork_exit+0x117 > > >> fork_trampoline() at fork_trampoline+0xe > > >> --- trap 0, rip =3D 0, rsp =3D 0xffffff8000039d40, rbp =3D 0 --- > > >> db> > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - > > >> > > >> I can boot with kern.smp.diabled=3D1, so I get address lines. > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - > > >> (kgdb) list *acpi_cpu_c1+0x6 > > >> 0xffffffff804bce56 is in acpi_cpu_c1 (/usr/src/sys/amd64/acpica/acpi= _machdep.c:100). > > >> 95 > > >> 96 void > > >> 97 acpi_cpu_c1() > > >> 98 { > > >> 99 __asm __volatile("sti; hlt"); > > >> 100 } > > >> (kgdb) list *acpi_cpu_idle+0x20c > > >> 0xffffffff801b443c is in acpi_cpu_idle (/usr/src/sys/dev/acpica/acpi= _cpu.c:966). > > >> 961 ACPI_ENABLE_IRQS(); > > >> 962 > > >> 963 /* Find the actual time asleep in microseconds. */ > > >> 964 end_time =3D acpi_TimerDelta(end_time, start_time); > > >> 965 sc->cpu_prev_sleep =3D (sc->cpu_prev_sleep * 3 + PM_USEC= (end_time)) / 4; > > >> 966 } > > >> (kgdb) list *sched_idletd+0x123 > > >> 0xffffffff8030b733 is in sched_idletd (/usr/src/sys/kern/sched_ule.c= :2562). > > >> 2557 cpu_spinwait(); > > >> 2558 } > > >> 2559 } > > >> 2560 switchcnt =3D tdq->tdq_switchcnt + tdq->tdq_= oldswitchcnt; > > >> 2561 if (tdq->tdq_load =3D=3D 0) > > >> 2562 cpu_idle(switchcnt > 1); > > >> 2563 if (tdq->tdq_load) { > > >> 2564 thread_lock(td); > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" > --=20 > Robert Noland > FreeBSD --H5oeNUPfJ0vte6JU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpH0joACgkQC3+MBN1Mb4ggMACfV4mE/KGKK5DsEElmyvK/AG2s EysAnRAXm+FPsVd3Nj3CBx9yOSc96w6t =IDFm -----END PGP SIGNATURE----- --H5oeNUPfJ0vte6JU-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 21:11:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB282106566C for ; Sun, 28 Jun 2009 21:11:20 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 490D58FC0A for ; Sun, 28 Jun 2009 21:11:20 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.243.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id B1BF33B580; Sun, 28 Jun 2009 23:11:18 +0200 (SAST) Message-ID: <4A47DC74.9060304@phat.za.net> Date: Sun, 28 Jun 2009 23:11:16 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.21 (X11/20090331) MIME-Version: 1.0 To: Scott Long References: <4A4751ED.8020002@phat.za.net> <20090628181105.GA98246@onelab2.iet.unipi.it> <4A47C1DF.2020908@phat.za.net> <4A47C28A.2030000@samsco.org> In-Reply-To: <4A47C28A.2030000@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , current@freebsd.org Subject: Re: recent boot0 changes dropped a partition type? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 21:11:21 -0000 Scott Long wrote: > Aragon Gouveia wrote: >> But with limited space we probably should just decide to not worry >> about anything older than Windows XP... > > How about not worrying about NetBSD or OpenBSD? How many people > typically multi-boot OpenBSD? Another benefit of dropping MS OSes older than Windows XP is removing all references to "DOS" when displaying the boot menu. Regards, Aragon From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 21:14:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B49301065672; Sun, 28 Jun 2009 21:14:52 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 907068FC13; Sun, 28 Jun 2009 21:14:51 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: by bwz12 with SMTP id 12so35104bwz.43 for ; Sun, 28 Jun 2009 14:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=m0aVMwTGHXKVXR5RWXh/apkfn1ESJ9exgHjcfFNFL4c=; b=RdsDVdJqM1i/eShRySeO3gH9TrOc+OyQkNYAZxqPz0+q6I25TcVYbh57V1okOkNl8L JHBKuuE65LAcTj4ht0B+ZkOYg6JDoDa53P0o8Bvi78kg812NAOpBog9kDYexd1e8vB3Y TAybiwnU8R4joAGBzs4OZz54LMU8GvMo+kwro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=PXjxXtfQtfVGcZnx/D6xMSBt1QoLZLObcGBBygMjEcrAg8q4U8rym3vNuM8kFpAn/p bvcDwm/YV+BMPrzGWLN5Y7uEqhpo1ziC/0rELxv5yOw2bWXr0NDIOaKi/AJLgp4BTdAI bzBRXxv7nf5WBDofImk7EqS/ee4BCcN5apOAU= MIME-Version: 1.0 Received: by 10.204.73.12 with SMTP id o12mr4188487bkj.80.1246223690351; Sun, 28 Jun 2009 14:14:50 -0700 (PDT) In-Reply-To: <91921319@ipt.ru> References: <20090627143719.GA28318@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <179b97fb0906280929u654129bfoaefa2a43f7058dc5@mail.gmail.com> <20090628165458.GA25437@dchagin.static.corbina.ru> <20090628174748.GA27292@dchagin.static.corbina.ru> <91921319@ipt.ru> Date: Sun, 28 Jun 2009 21:14:50 +0000 Message-ID: <179b97fb0906281414q3ce8dac2t45d899b1df00dc30@mail.gmail.com> From: Brandon Gooch To: Boris Samorodov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, "Sean C. Farley" , Chagin Dmitry , Juergen Lock Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 21:14:53 -0000 On Sun, Jun 28, 2009 at 8:37 PM, Boris Samorodov wrote: > Chagin Dmitry writes: >> On Sun, Jun 28, 2009 at 12:39:09PM -0500, Sean C. Farley wrote: >>> On Sun, 28 Jun 2009, Chagin Dmitry wrote: >>> >>> > On Sun, Jun 28, 2009 at 04:29:49PM +0000, Brandon Gooch wrote: >>> >>> *snip* >>> >>> >> I have. I'm using it with about the same level of success as the >>> >> previous versions of Flash (I need to map a couple of keys to run >>> >> `pkill npviewer.bin`). >>> >>> I also have a key mapping to killall npviewer.bin. >>> >>> > for amd64 try: compat.linux32.maxssiz=3D4194304 >>> > >>> > for i386 try: limit stacksize to 4mb or set unlimited. >>> >>> Thank you. =A0I tested viewing "TXT ISLAND" on YouTube. =A0Works at hig= her >>> limits for me such as 32MB but not at my default of 64MB. >>> >>> Why/how does this help? =A0At least on i386, it stops Flash from chokin= g >>> on YouTube videos when switching to HD or jumping within a video. >> >> the reason? foolish waves in a Uli head and stupid bug in flash plugin. >> flash uses pthread_detach() after pthread_join() call. >> glibc allows such behaviour (if stack limit < 40Mb) =A0piece of shit... > > If that helps then it's a good idea to create a pkg-message for > the port (Juergen Lock is CCed). It does indeed help. I can switch between HD and standard resolution in youtube vids, I can skip around in the vid, and I don't have to kill the npviewer.bin process when I navigate from one Flash site to the next. Oh, and I haven't seen a core from npviewer yet... I've set the sysctl compat.linux32.maxssiz to 33554432 (32 MB). It would definitely be helpful to have this in the pkg-message, or at least documented somewhere (if it's not already -- this is the first I've heard of it). -Brandon > WBR > -- > bsam > From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 21:29:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67DF11065676; Sun, 28 Jun 2009 21:29:24 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 151568FC1C; Sun, 28 Jun 2009 21:29:23 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 2E7021E001E3; Sun, 28 Jun 2009 23:29:23 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5SLRLIO030474; Sun, 28 Jun 2009 23:27:21 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5SLRKij030473; Sun, 28 Jun 2009 23:27:20 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 28 Jun 2009 23:27:20 +0200 To: Boris Samorodov Message-ID: <20090628212720.GA29902@triton.kn-bremen.de> References: <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <179b97fb0906280929u654129bfoaefa2a43f7058dc5@mail.gmail.com> <20090628165458.GA25437@dchagin.static.corbina.ru> <20090628174748.GA27292@dchagin.static.corbina.ru> <91921319@ipt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91921319@ipt.ru> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Brandon Gooch , Juergen Lock , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Chagin Dmitry , "Sean C. Farley" Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 21:29:25 -0000 On Mon, Jun 29, 2009 at 12:37:12AM +0400, Boris Samorodov wrote: > Chagin Dmitry writes: > > On Sun, Jun 28, 2009 at 12:39:09PM -0500, Sean C. Farley wrote: > >> On Sun, 28 Jun 2009, Chagin Dmitry wrote: > >> > >> > On Sun, Jun 28, 2009 at 04:29:49PM +0000, Brandon Gooch wrote: > >> > >> *snip* > >> > >> >> I have. I'm using it with about the same level of success as the > >> >> previous versions of Flash (I need to map a couple of keys to run > >> >> `pkill npviewer.bin`). > >> > >> I also have a key mapping to killall npviewer.bin. > >> > >> > for amd64 try: compat.linux32.maxssiz=4194304 > >> > > >> > for i386 try: limit stacksize to 4mb or set unlimited. > >> > >> Thank you. I tested viewing "TXT ISLAND" on YouTube. Works at higher > >> limits for me such as 32MB but not at my default of 64MB. > >> > >> Why/how does this help? At least on i386, it stops Flash from choking > >> on YouTube videos when switching to HD or jumping within a video. > > > > the reason? foolish waves in a Uli head and stupid bug in flash plugin. > > flash uses pthread_detach() after pthread_join() call. > > glibc allows such behaviour (if stack limit < 40Mb) piece of shit... > .oO(Why does that remind me again of http://developers.slashdot.org/comments.pl?sid=1063323&cid=26128419 ?) > If that helps then it's a good idea to create a pkg-message for > the port (Juergen Lock is CCed). Well i386 doesn't seem to have a sysctl for linux stacksize, can ulimit be used for this too? Because I can't seem to reproduce this problem on an i386 20090605 vbox head guest with the new ports, suddenly flash behaves even when I click the youtube `watch in hd' button, even multiple times... (On 7-stable amd64 with f8 the sysctl does help tho.) Oh and if ulimit does indeed work for the linuxulator maybe nspluginwrapper should be patched instead? (Or at least on i386?) Wondering... Juergen From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 21:51:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 841B51065673 for ; Sun, 28 Jun 2009 21:51:10 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 49CA98FC1C for ; Sun, 28 Jun 2009 21:51:10 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 02BF573098; Sun, 28 Jun 2009 23:56:41 +0200 (CEST) Date: Sun, 28 Jun 2009 23:56:40 +0200 From: Luigi Rizzo To: Aragon Gouveia Message-ID: <20090628215640.GA4771@onelab2.iet.unipi.it> References: <4A4751ED.8020002@phat.za.net> <20090628181105.GA98246@onelab2.iet.unipi.it> <4A47C1DF.2020908@phat.za.net> <4A47C28A.2030000@samsco.org> <4A47DC74.9060304@phat.za.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A47DC74.9060304@phat.za.net> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: recent boot0 changes dropped a partition type? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 21:51:10 -0000 On Sun, Jun 28, 2009 at 11:11:16PM +0200, Aragon Gouveia wrote: > Scott Long wrote: > >Aragon Gouveia wrote: > >>But with limited space we probably should just decide to not worry > >>about anything older than Windows XP... > > > >How about not worrying about NetBSD or OpenBSD? How many people > >typically multi-boot OpenBSD? I was about to suggest that -- in terms of popularity, the various FAT alternatives versions are by far more common. > Another benefit of dropping MS OSes older than Windows XP is removing > all references to "DOS" when displaying the boot menu. this is already gone. There is a DOS string but almost always it maps to Windows due to space constraints. cheers luigi From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 22:00:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E3441065670; Sun, 28 Jun 2009 22:00:39 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id 02DEE8FC1C; Sun, 28 Jun 2009 22:00:38 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so405906fgb.12 for ; Sun, 28 Jun 2009 15:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=rJrNqN3B2v+gikRdAODWCVT6Lkr2qn5DqHMT4MT9NEw=; b=mdCAdsIJFzVN6LTdTjtI3PCuV1lYSlf/wGQZqs7gOD2QOkglBOiizwzF3rqKYVboCR u+L5pcbHlVtN6EPavo3lMqEoj8/yeZqDW35lTI4VEDy+kBlqj7P5O5RtaFqtioQBR/12 j/wctP77eiivOes7+WrTVYtQ+3W6Y/O/NPPFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=AtVjNKBFmq9BOitn4qrXUNjA066Uya4TbkdXgAOCBsH9B7D0rXC4MhwD3YnJAe5sJB NfaX/07k7Wq/6RyW3AqZ0nSiKQ+zM3gKCHrPnPXnB0CH/Jhu7Dr2+oPGuZWGBRgGxo8i mZjYasUPi30x4yMxTxtuCP5vabMwHaaDPzn6Y= Received: by 10.86.60.9 with SMTP id i9mr1550294fga.10.1246226437984; Sun, 28 Jun 2009 15:00:37 -0700 (PDT) Received: from localhost (95-24-212-252.broadband.corbina.ru [95.24.212.252]) by mx.google.com with ESMTPS id l19sm10986541fgb.16.2009.06.28.15.00.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Jun 2009 15:00:37 -0700 (PDT) From: Anonymous To: "Carlos A. M. dos Santos" References: <4A4517BE.9040504@FreeBSD.org> <20090627141412.GN31709@acme.spoerlein.net> <4A462A7A.20005@haruhiism.net> <200906280847.59316.doconnor@gsoft.com.au> Date: Mon, 29 Jun 2009 02:00:32 +0400 In-Reply-To: (Carlos A. M. dos Santos's message of "Sun, 28 Jun 2009 10:50:31 -0300") Message-ID: <86hby010jj.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: scottl@freebsd.org, Alexander Motin , freebsd-current@freebsd.org, Kamigishi Rei Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 22:00:40 -0000 "Carlos A. M. dos Santos" writes: > On Sat, Jun 27, 2009 at 8:17 PM, Daniel O'Connor wrote: > [...] >> 7.2 has UFSID in GENERIC so you can mount your disks that way which is >> non-ambiguous. >> >> Unfortunately you can't specify swap this way because it has no ID, I >> don't know how hard it would be to add such a thing (which would >> require a mkswap or somesuch, and modification to the dump & swap >> code..) > > You can use glabel to add a label to the raw swap partition. I use to > have a line containing > > /dev/label/BSDSWAP none swap sw 0 0 > > in /etc/fstab. Or you can use GPT-specific labels, as well. They would look like /dev/gpt/swap1 /dev/gptid/adec0ea7-642e-11de-85dc-000476911739 From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 23:04:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8C6A106566C; Sun, 28 Jun 2009 23:04:34 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id AF4638FC14; Sun, 28 Jun 2009 23:04:34 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-156-4-82.bna.bellsouth.net [70.156.4.82]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n5SN4W1C028441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Jun 2009 19:04:32 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Kostik Belousov In-Reply-To: <20090628202739.GQ2884@deviant.kiev.zoral.com.ua> References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> <20090628202739.GQ2884@deviant.kiev.zoral.com.ua> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-HN0bXImThdPqdyzEgQyA" Organization: FreeBSD Date: Sun, 28 Jun 2009 18:04:26 -0500 Message-Id: <1246230266.1759.45.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Anonymous , Hans Ottevanger , Norikatsu Shigemura , freebsd-current@freebsd.org Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 23:04:35 -0000 --=-HN0bXImThdPqdyzEgQyA Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2009-06-28 at 23:27 +0300, Kostik Belousov wrote: > On Sun, Jun 28, 2009 at 03:18:26PM -0500, Robert Noland wrote: > > On Sun, 2009-06-28 at 22:36 +0400, Anonymous wrote: > > > Hans Ottevanger writes: > > >=20 > > > > Norikatsu Shigemura wrote: > > > >> Hi. > > > >> > > > > > > > > Hi, > > > > > > > > I have almost the same issue, just the addresses are different and = in > > > > my case the trap occurs on cpu2. > > > > > > > > My system is based on an Intel PB965LT main board with a Q6600 quad > > > > core CPU and 8 Gbyte of RAM. I am also using the amd64 kernel, wher= e > > > > kernel configuration is almost identical to GENERIC, with devices > > > > removed that I do not have and the following lines added > > > > > > > > device drm > > > > device radeondrm > > > > device sound > > > > device snd_hda > > > > > > > > If I remove the drm and radeondrm devices from the config file and > > > > recompile the kernel, the panic does not occur and the correspondin= g > > > > modules can be loaded without a problem. > > >=20 > > > Can you try to boot with DRM and hw.drm.msi=3D0? In my case it does n= ot > > > panic then. > >=20 > > drm is a consumer of msi if the hardware is capable. If you disable ms= i > > you won't take the path that 194985 fixes, or any path that involves > > msi... The panic message seemed rather unhelpful to me and I can't > > think of a reason that it would work as a module and not if it is > > compiled in. Did you clean your kernel and rebuild? > Trap 30 is usually indicates that interrupts were enabled before the > handler was established. Hrm, That might make some sense. drm allocates the resources for interrupts when the driver loads. It doesn't setup the handler until something opens the drm device. Still unclear how it is different for module vs. in-kernel. robert. > rsvd is set as a filler for unused IDT entries. > >=20 > > robert. > >=20 > > > > > > > > Some "binary searching" of Subversion releases shows that the probl= em > > > > first occurs with r194985. If I update to r195137 and revert the > > > > relevant files from the revision r194985 to r194984, no panic occur= s. > > > > > > > > Of course it could very well be that r194985 itself is not the issu= e, > > > > but triggers a problem somewhere else in the kernel. > > > > > > > > Kind regards, > > > > > > > > Hans > > > > > > > >> I got a panic after AP CPU launched on boot. So I couldn't get > > > >> crash dump and information. > > > >> > > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - - > > > >> FreeBSD nadesico.ninth-nine.com 8.0-CURRENT FreeBSD 8.0-CURRENT #4= 9: Sun Jun 28 02:53:48 JST 2009 nork@nadesico.ninth-nine.com:/usr/obj/u= sr/src/sys/NADESICO amd64 > > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - - > > > >> > > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - - > > > >> SMP: AP CPU #3 Launched! > > > >> SMP: AP CPU #1 Launched! > > > >> SMP: AP CPU #2 Launched! > > > >> > > > >> Fatal trap 30: reserved (unknown) fault while in kernel mode > > > >> cpuid =3D 3; apic id =3D 03 > > > >> instruction pointer =3D 0x20:0xffffffff804bce56 > > > >> stack pointer =3D 0x20:0xffffff8000039b60 > > > >> frame pointer =3D 0x20:0xffffff8000039b70 > > > >> code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > >> =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > > >> processor eflags =3D interrupt enabled, IOPL =3D 0 > > > >> current process =3D 11 (idle: cpu3) > > > >> [thread pid 11 tid 100003 ] > > > >> Stopped at acpi_cpu_c1+0x6: leave > > > >> db> bt > > > >> Tracing pid 11 tid 100003 td 0xffffff8001863720 > > > >> acpi_cpu_c1() at acpi_cpu_c1+0x6 > > > >> acpi_cpu_idle() at acpi_cpu_idle+0x20c > > > >> sched_idletd() at sched_idletd+0x123 > > > >> fork_exit() at fork_exit+0x117 > > > >> fork_trampoline() at fork_trampoline+0xe > > > >> --- trap 0, rip =3D 0, rsp =3D 0xffffff8000039d40, rbp =3D 0 --- > > > >> db> > > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - - > > > >> > > > >> I can boot with kern.smp.diabled=3D1, so I get address lines. > > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - - > > > >> (kgdb) list *acpi_cpu_c1+0x6 > > > >> 0xffffffff804bce56 is in acpi_cpu_c1 (/usr/src/sys/amd64/acpica/ac= pi_machdep.c:100). > > > >> 95 > > > >> 96 void > > > >> 97 acpi_cpu_c1() > > > >> 98 { > > > >> 99 __asm __volatile("sti; hlt"); > > > >> 100 } > > > >> (kgdb) list *acpi_cpu_idle+0x20c > > > >> 0xffffffff801b443c is in acpi_cpu_idle (/usr/src/sys/dev/acpica/ac= pi_cpu.c:966). > > > >> 961 ACPI_ENABLE_IRQS(); > > > >> 962 > > > >> 963 /* Find the actual time asleep in microseconds. */ > > > >> 964 end_time =3D acpi_TimerDelta(end_time, start_time); > > > >> 965 sc->cpu_prev_sleep =3D (sc->cpu_prev_sleep * 3 + PM_US= EC(end_time)) / 4; > > > >> 966 } > > > >> (kgdb) list *sched_idletd+0x123 > > > >> 0xffffffff8030b733 is in sched_idletd (/usr/src/sys/kern/sched_ule= .c:2562). > > > >> 2557 cpu_spinwait(); > > > >> 2558 } > > > >> 2559 } > > > >> 2560 switchcnt =3D tdq->tdq_switchcnt + tdq->td= q_oldswitchcnt; > > > >> 2561 if (tdq->tdq_load =3D=3D 0) > > > >> 2562 cpu_idle(switchcnt > 1); > > > >> 2563 if (tdq->tdq_load) { > > > >> 2564 thread_lock(td); > > > >> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - = - - - - - - - - - - - - - - - > > > _______________________________________________ > > > freebsd-current@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd= .org" > > --=20 > > Robert Noland > > FreeBSD >=20 >=20 --=20 Robert Noland FreeBSD --=-HN0bXImThdPqdyzEgQyA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkpH9voACgkQM4TrQ4qfROMSrgCfTBEBqwfVkq/DAvW0vTIS193c NhUAoIdx+xgpXTOLKeNvPGCGvYZmcLIM =JPhd -----END PGP SIGNATURE----- --=-HN0bXImThdPqdyzEgQyA-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 23:11:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECEB51065676 for ; Sun, 28 Jun 2009 23:11:10 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 986C38FC14 for ; Sun, 28 Jun 2009 23:11:10 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by qw-out-2122.google.com with SMTP id 5so532467qwd.7 for ; Sun, 28 Jun 2009 16:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=ylTXw+v+2vGCIwwn22HfO+F1da3lYPtyTqN5YT/e620=; b=nPySe9fjQRPKUObPeavDN1hB7ALGXFyz9h72JvJei3BlKsOu7Cq61Q661DTNxjw8h9 eLS+lT7Iq0f4/4EhlJ2X4wASqLdje50wleXEZEA5eH+afUbBG1gaTdymwBiRVkzY1o9M jSMO3+FodHfbP79LefuvgeK/MMaxXesjQTMis= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=oEBHzsmwlrlYsdiAkKHbo0t33K0cVSkMrX7WljlZcAz6AK5aiDhAE1/uvMJkxEIVgC uvu2QzUr77uh4TcAoVf5E57SLkFKJg/6WVEzziIHjorVJOBz5oHtol3XZ2pptaqIuxXK rc12oWHBPiU9t50Cc6fXwrqwTZqG5aTw1O4Rc= Received: by 10.224.28.130 with SMTP id m2mr5047395qac.274.1246230669611; Sun, 28 Jun 2009 16:11:09 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.105.194]) by mx.google.com with ESMTPS id 5sm13950761qwg.25.2009.06.28.16.11.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Jun 2009 16:11:07 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 033A3B8083; Sun, 28 Jun 2009 20:11:01 -0300 (BRT) Received: from 10.1.1.80 (SquirrelMail authenticated user matheus) by 10.1.1.10 with HTTP; Sun, 28 Jun 2009 20:11:01 -0300 (BRT) Message-ID: <02adbf3fa5824e700084900f071435b6.squirrel@10.1.1.10> In-Reply-To: <4A473976.6030807@rakupottery.org.uk> References: <20090611194557.GC98175@bsdcrew.de> <4A473976.6030807@rakupottery.org.uk> Date: Sun, 28 Jun 2009 20:11:01 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 23:11:11 -0000 On Sun, June 28, 2009 06:35, Martin Smith wrote: > Martin Wilke wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Huhu, >> >> Yes we life and that's good :-). >> Changes: >> >> - Fix build error when compiling in debug mode on FreeBSD HEAD >> - SemEvent?-r0drv/FreeBSD: Don't use tvtohz for an infinite timeout. >> - Some FreeBSD relate typos >> - Enable shared OpenGL service. Completely untested due to lack of >> appropriate hardware but it compiles at least >> - Add support for shared clipboards. Requires libXt >> - FreeBSD: Implement preemption API for guest SMP and enable >> it (slightly tested). Add neccessary RTMP* methods in userspace >> for the frontends to detect the number of CPUs >> - Runtime/semevent-r0drv-freebsd: Use a sleeping mutex >> instead of a spinlock to fix the problems users are seeing >> (assertions with debugging enabled) while still being able >> to run on 100Hz hosts. No problems detected so far and Solaris >> doesn't use a spin mutex in this code too so it shouldn't do >> any harm (keeping fingers crossed)space for the frontends to >> detect the number of CPUs >> - Add support for curl >> - Add VBoxSharedClipboard >> >> Ports Changes; >> - Force guestadditions version to 2.2.4 >> - Removed Qt3 include replacements (already upstream) >> - Removed cosmetic X11 include path patch >> >> Please make SURE, your world and kernel is in sync and you've read >> the pkg-messages. Also please unload the kernel module before >> you update the port ;-). >> >> Many thx to all Vbox Devs, All supporters, my nice team! :-) >> >> http://people.freebsd.org/~miwi/vbox/virtualbox_6.tgz >> >> Happy Testing! > > Well ,I have got it up and running on a stable of 26 June, managed to > set up a vdi, no problem, but it will not see the cd drive. > It (vbox) says the cd drive is always secondary master, but I only have > one ata channel so it is primary master. The dropdown list just does > not drop down. > Is there a workaround for this, or have I missed something stupid? hi, I have the latest running on stable from two weeks ago. I can get it to install, but never boot using 4 cpu's (real quad core and vt-x enabled). debian amd64 is the guest os. should it run fine with 4 cpu's ? (I think I read about it was to be ok on new 3.0 family). and by the way, the 3.0 beta will build out-of-the-box in FreeBSD ? thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 23:39:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7958B1065670; Sun, 28 Jun 2009 23:39:50 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by mx1.freebsd.org (Postfix) with ESMTP id ACD448FC0A; Sun, 28 Jun 2009 23:39:49 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by ewy9 with SMTP id 9so3162642ewy.43 for ; Sun, 28 Jun 2009 16:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bF9BEopxtZVaavjh9iSBBFbdiSbsHzJi1O0bbbnnuVw=; b=apkmwTZbupSBKYNzTROX9PzyFBLrMPFq7TKGO1pPoNAbzCsncYboiXVLJWJb1qn6hN AjVw6Ca57ZOswwiKKAaYa5YBHkkex1b048i0ReAd8gcE8OcksHBnGbFKn1iX6CNKdWBK JYIEA36LfsGZmVPCkX0nsvI4+V2ALlPtD2z7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UogHgJosddzyIpOIrRcJeVxIB8iOWkP19UFUxDEnVamg18S9Idpvgc9BQMMQTiMJeT OHs/M7WB9MreHA74l5kUYdMm/ZJoi8Zq30wFeYO694vVEWMA1sSeMrucXlz8NYoTYjNO ft/a4AXjVoEAWtNl6IztM9bxa0yOVQq/zaScE= MIME-Version: 1.0 Received: by 10.216.13.194 with SMTP id b44mr1935214web.139.1246231168067; Sun, 28 Jun 2009 16:19:28 -0700 (PDT) In-Reply-To: <1246230266.1759.45.camel@balrog.2hip.net> References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> <20090628202739.GQ2884@deviant.kiev.zoral.com.ua> <1246230266.1759.45.camel@balrog.2hip.net> Date: Sun, 28 Jun 2009 19:19:28 -0400 Message-ID: From: Ryan Stone To: Robert Noland Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kostik Belousov , Anonymous , Hans Ottevanger , Norikatsu Shigemura , freebsd-current@freebsd.org Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 23:39:50 -0000 Is the drm module getting loaded by the bootloader, or might a startup script be doing it? If the module gets loaded later in the boot process that could account for the difference. Ryan From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 23:42:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E4FA1065670 for ; Sun, 28 Jun 2009 23:42:40 +0000 (UTC) (envelope-from freebsd.work@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id DCAA08FC08 for ; Sun, 28 Jun 2009 23:42:39 +0000 (UTC) (envelope-from freebsd.work@gmail.com) Received: by an-out-0708.google.com with SMTP id d14so1054320and.13 for ; Sun, 28 Jun 2009 16:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=GlwRe0uih2sL99TsUMKn/zg6ec2Gopm2T4HCYhIFLRM=; b=jQqtPOmrz2m/c0Zvjg0KZfzCUeHkv4u6TPz0rMePAnylqsM6UX+8nmt7AKrGrDT7+K k05SGsVm3KXALrNcaFw5nkLdA3CzZsbOP0ypPPyIKXh/9a3Fhid8tyT9tPx+CSuwSJWf nOW+cKtUHHrmyI/1ekqqMVI9Paz4QUSOUydAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QWHucAycEpw+IrvsCwdy0tJiefsFmI7oRhN8ClScBQhI4Y1LdB0uBgxDU9muVHSpQq Gx2fTeLcIHFjzbmG4ehrrt3mAKVSYNznHKcZXQK/64xxRzUTcFsGOTEsCDtKucP60PmA +ti78/wKHULuXvGiieKbwjUFjrBb9sE4bMNZM= MIME-Version: 1.0 Received: by 10.231.32.139 with SMTP id c11mr334106ibd.44.1246232558978; Sun, 28 Jun 2009 16:42:38 -0700 (PDT) Date: Sun, 28 Jun 2009 16:42:38 -0700 Message-ID: <45d874490906281642r470089e2sc5b770f239f428e2@mail.gmail.com> From: "Sean P. Dew" To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: segment alignment in AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 23:42:40 -0000 Hi, Why is a loadable segment aligned to 1 MB on AMD64 while the pagezie is still 4K for a user application. Is there anyway to change it back to 4K, It is not making sense to me is because if my file segment is around 400K, we are wasting 1 MB of virtual address space ( granted it is not a lot for X64). I am trying to find out the reason. I am posting the readelf output of a .so. Any help is appreciated. Thanks Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x001428 0x001428 R E 0x100000 LOAD 0x001428 0x0000000000101428 0x0000000000101428 0x000438 0x007bd8 RW 0x100000 DYNAMIC 0x001618 0x0000000000101618 0x0000000000101618 0x000180 0x000180 RW 0x8 GNU_EH_FRAME 0x001420 0x0000000000001420 0x0000000000001420 0x000008 0x000008 R 0x4 Section to Segment mapping: Segment Sections... 00 .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr 01 .data .eh_frame .dynamic .ctors .dtors .jcr .got .bss 02 .dynamic 03 .eh_frame_hdr From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 23:58:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D02431065673 for ; Sun, 28 Jun 2009 23:58:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7305B8FC16 for ; Sun, 28 Jun 2009 23:58:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocGAO+fR0qDaFvL/2dsb2JhbACOZQG7aYQNBQ X-IronPort-AV: E=Sophos;i="4.42,305,1243828800"; d="scan'208";a="37686296" Received: from nile.cs.uoguelph.ca ([131.104.91.203]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 28 Jun 2009 19:57:59 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id 9298B8D40DC; Sun, 28 Jun 2009 19:57:59 -0400 (EDT) X-Virus-Scanned: amavisd-new at nile.cs.uoguelph.ca Received: from nile.cs.uoguelph.ca ([127.0.0.1]) by localhost (nile.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM37aPjy+qfV; Sun, 28 Jun 2009 19:57:58 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id BDF9F8D40A3; Sun, 28 Jun 2009 19:57:58 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5T00Df05807; Sun, 28 Jun 2009 20:00:14 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 28 Jun 2009 20:00:13 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 23:58:01 -0000 I just noticed that when I do the following: - start a large write to an NFS mounted fs - network partition the server (unplug a net cable) - do a "umount -f " on the machine that it gets stuck trying to write dirty blocks to the server. I had, in the past, assumed that a "umount -f" of an NFS mount would be used to get rid of an NFS mount on an unresponsive server and that loss of "writes in progress" would be expected to happen. Does that sound correct? (In other words, an I seeing a bug or a feature?) Thanks in advance for any info, rick ps: I have a simple "fix" if this is a bug, but I wanted to check before submitting a patch. From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 00:18:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D52A71065677; Mon, 29 Jun 2009 00:18:59 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id 09BE68FC16; Mon, 29 Jun 2009 00:18:58 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: by fg-out-1718.google.com with SMTP id 13so692887fge.12 for ; Sun, 28 Jun 2009 17:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:message-id:user-agent:mime-version:content-type; bh=pS4SW30Qp1/ZWJPbFNcOL0uDE6E0LPMevKj/sgiFnIc=; b=RlFCay+cVcBsBN0cHO9URtZKBhs/+YHMc/O42l67qTFGQUF6S/sobj2/c8a6hH5X5l /H9Rf4JUGUMW1oHz+LhbahjYMEwHj+9qbTtwjm6Rqc9wNIV6h27QUPpM5usTDL345/gJ FmXHe/+ChheDqW+YqnqdoDS7koyNhNhsUwXHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=MA0eUtbo9jvP/F6hA9KgyJwAikZHPpa1VMqIAc/5f4fTgC/tsQwhGlDmaxqhd5B3/e tytjUmRWexmeVKCsHwfqnoW7RUqtNew2jVhyufrxTZcw1bm7rl7HkTzlQ91EuLETM6WV PG/BHmeL6saGzcLbwjzRDkIMaMWWOzOgLlpOU= Received: by 10.86.1.1 with SMTP id 1mr1473284fga.42.1246234737875; Sun, 28 Jun 2009 17:18:57 -0700 (PDT) Received: from localhost (95-24-212-252.broadband.corbina.ru [95.24.212.252]) by mx.google.com with ESMTPS id 4sm5242649fgg.7.2009.06.28.17.18.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Jun 2009 17:18:57 -0700 (PDT) From: Anonymous To: Ryan Stone References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> <20090628202739.GQ2884@deviant.kiev.zoral.com.ua> <1246230266.1759.45.camel@balrog.2hip.net> Date: Mon, 29 Jun 2009 04:18:37 +0400 Message-ID: <86vdmfnb8i.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kostik Belousov , Hans Ottevanger , Norikatsu Shigemura , Robert Noland , freebsd-current@freebsd.org Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 00:19:00 -0000 Ryan Stone writes: > Is the drm module getting loaded by the bootloader, or might a startup > script be doing it? If the module gets loaded later in the boot > process that could account for the difference. In my case with nouveau drm kernel panics either when - drm loaded with kernel at boot time - drm compiled in And panic message either about acpi_cpu_c1 or sched_idletd. I'm not sure why it changes sometimes. The kernel doesn't panic if I load drm later in boot process after kernel initialized, e.g. in single user mode or multiuser mode. > > Ryan From owner-freebsd-current@FreeBSD.ORG Thu Jun 25 20:29:51 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 006991065674 for ; Thu, 25 Jun 2009 20:29:50 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 18F8D8FC18 for ; Thu, 25 Jun 2009 20:29:49 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 7B01D1E001E2; Thu, 25 Jun 2009 22:29:48 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5PKPaUJ003746 for ; Thu, 25 Jun 2009 22:25:36 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5PKPagK003745 for freebsd-current@FreeBSD.org; Thu, 25 Jun 2009 22:25:36 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Thu, 25 Jun 2009 22:25:36 +0200 To: freebsd-current@FreeBSD.org Message-ID: <20090625202536.GA2645@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 29 Jun 2009 00:48:32 +0000 Cc: Subject: pmap_extract panic @boot (20090623-JPSNAP-amd64-dvd1.iso) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 20:29:51 -0000 I wanted to try a head snapshot iso today and it failed to boot: http://people.freebsd.org/~nox/20090623-JPSNAP-amd64-bootpanic1.jpg http://people.freebsd.org/~nox/20090623-JPSNAP-amd64-bootpanic2.jpg (I tried to get a serial console but couldn't get this box' serial port working for some reason... ): As you can see in the jpegs it panic'd at pmap_extract+0x106, which I _think_ is in line 963: (unfortunately there's no kernel.symbols on the iso) pdep = pmap_pde(pmap, va); (see http://fxr.watson.org/fxr/source/amd64/amd64/pmap.c#L963 ), and that got invoked from isa_dmarangecheck+0x98: http://fxr.watson.org/fxr/source/amd64/isa/isa_dma.c#L374 So, anyone have an idea what's up with this? This box is running 7-stable/amd64 without major issues: FreeBSD triton.kn-bremen.de 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun May 10 19:06:01 CEST 2009 (there are some usb problems which made me curious to try out the new usb stack, and also k3b hangs on startup causing an irq storm on one cpu until reboot, but this pmap_extract panic certainly is new.) Also interestingly the i386 snapshot from the same date, http://pub.allbsd.org/FreeBSD-snapshots/i386/8.0-HEAD-20090623-JPSNAP/cdrom/8.0-HEAD-20090623-JPSNAP-i386-dvd1.iso boots without issues and I got out a verbose dmesg from it to compare, but since this box has 8 GB RAM i386 is kinda out of the question... :) Here comes the dmesg: Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-HEAD-20090623-JPSNAP #0: Tue Jun 23 02:04:14 UTC 2009 root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc1522000. Preloaded mfs_root "/boot/mfsroot" at 0xc152219c. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2812829239 Hz CPU: AMD Phenom(tm) II X4 920 Processor (2812.83-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant Data TLB: 48 entries, fully associative Instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 512 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 8589934592 (8192 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001825000 - 0x00000000cc741fff, 3404845056 bytes (831261 pages) avail memory = 3403403264 (3245 MB) Table 'FACP' at 0xcfee3040 Table 'SSDT' at 0xcfee8fc0 Table 'HPET' at 0xcfee9880 Table 'MCFG' at 0xcfee98c0 Table 'TAMG' at 0xcfee9900 Table 'APIC' at 0xcfee8f00 MADT: Found table at 0xcfee8f00 MP Configuration Table version 1.4 found at 0xc00f0f00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: enabled SMP: Added CPU 1 (AP) MADT: Found CPU APIC ID 2 ACPI ID 2: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 3 ACPI ID 3: enabled SMP: Added CPU 3 (AP) ACPI APIC Table: INTR: Adding local APIC 1 as a target INTR: Adding local APIC 2 as a target INTR: Adding local APIC 3 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 bios32: Found BIOS32 Service Directory header at 0xc00fb2d0 bios32: Entry = 0xfba20 (c00fba20) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xba50 pnpbios: Found PnP BIOS data at 0xc00fc2e0 pnpbios: Entry = f0000:c310 Rev = 1.0 Other BIOS signatures found: ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xf6fe0 00014 (v0 GBT ) ACPI: RSDT 0xcfee3000 0003C (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: FACP 0xcfee3040 00074 (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: DSDT 0xcfee30c0 05E2B (v1 GBT GBTUACPI 00001000 MSFT 03000000) ACPI: FACS 0xcfee0000 00040 ACPI: SSDT 0xcfee8fc0 0088C (v1 PTLTD POWERNOW 00000001 LTP 00000001) ACPI: HPET 0xcfee9880 00038 (v1 GBT GBTUACPI 42302E31 GBTU 00000098) ACPI: MCFG 0xcfee98c0 0003C (v1 GBT GBTUACPI 42302E31 GBTU 01010101) ACPI: TAMG 0xcfee9900 00302 (v1 GBT GBT B0 5455312E BG\^A\^A 53450101) ACPI: APIC 0xcfee8f00 00084 (v1 GBT GBTUACPI 42302E31 GBTU 01010101) MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 2 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high lapic1: Routing NMI -> LINT1 lapic1: LINT1 trigger: edge lapic1: LINT1 polarity: high lapic2: Routing NMI -> LINT1 lapic2: LINT1 trigger: edge lapic2: LINT1 polarity: high lapic3: Routing NMI -> LINT1 lapic3: LINT1 trigger: edge lapic3: LINT1 polarity: high ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled io: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 (Jun 23 2009 02:02:44) npx0: INT 16 interface acpi0: on motherboard PCIe: Memory Mapped configuration base @ 0xe0000000 pcibios: BIOS version 3.00 ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: wakeup code va 0xc6c0a000 pa 0x1000 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SATA.SACS -> bus 0 dev 17 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.BAR1 -> bus 0 dev 0 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: \\_SB_.PCI0.SMB0.HETT -> bus 0 dev 20 func 0 acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfde0000 (3) failed ACPI timer: 1/2 1/2 1/1 1/1 1/1 1/2 1/2 1/2 1/2 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link4: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link5: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link6: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 pci_link7: Index IRQ Rtd Ref IRQs Initial Probe 0 255 N 0 3 4 5 6 7 10 11 Validation 0 255 N 0 3 4 5 6 7 10 11 After Disable 0 255 N 0 3 4 5 6 7 10 11 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x4353 rev: 0x1 num: 3 hz: 14318180 opts: legacy_route Timecounter "HPET" frequency 14318180 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x1002, dev=0x5957, revid=0x00 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[1c]: type Memory, range 64, base 0xe0000000, size 29, enabled found-> vendor=0x1002, dev=0x5978, revid=0x00 domain=0, bus=0, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.2.INTA pcib0: slot 2 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x597d, revid=0x00 domain=0, bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.7.INTA pcib0: slot 7 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x597f, revid=0x00 domain=0, bus=0, slot=10, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: matched entry for 0.10.INTA pcib0: slot 10 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4390, revid=0x00 domain=0, bus=0, slot=17, func=0 class=01-01-8f, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type I/O Port, range 32, base 0xff00, size 3, enabled map[14]: type I/O Port, range 32, base 0xfe00, size 2, enabled map[18]: type I/O Port, range 32, base 0xfd00, size 3, enabled map[1c]: type I/O Port, range 32, base 0xfc00, size 2, enabled map[20]: type I/O Port, range 32, base 0xfb00, size 4, enabled map[24]: type Memory, range 32, base 0xfe02f000, size 10, enabled pcib0: matched entry for 0.17.INTA pcib0: slot 17 INTA hardwired to IRQ 22 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=18, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type Memory, range 32, base 0xfe02e000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=18, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type Memory, range 32, base 0xfe02d000, size 12, enabled pcib0: matched entry for 0.18.INTA pcib0: slot 18 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=18, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe02c000, size 8, enabled pcib0: matched entry for 0.18.INTB pcib0: slot 18 INTB hardwired to IRQ 17 found-> vendor=0x1002, dev=0x4397, revid=0x00 domain=0, bus=0, slot=19, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type Memory, range 32, base 0xfe02b000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4398, revid=0x00 domain=0, bus=0, slot=19, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type Memory, range 32, base 0xfe02a000, size 12, enabled pcib0: matched entry for 0.19.INTA pcib0: slot 19 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0x4396, revid=0x00 domain=0, bus=0, slot=19, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02b0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfe029000, size 8, enabled pcib0: matched entry for 0.19.INTB pcib0: slot 19 INTB hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4385, revid=0x3a domain=0, bus=0, slot=20, func=0 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0403, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x439c, revid=0x00 domain=0, bus=0, slot=20, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 MSI supports 2 messages map[20]: type I/O Port, range 32, base 0xfa00, size 4, enabled found-> vendor=0x1002, dev=0x4383, revid=0x00 domain=0, bus=0, slot=20, func=2 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0410, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 64, base 0xfe024000, size 14, enabled pcib0: matched entry for 0.20.INTA pcib0: slot 20 INTA hardwired to IRQ 16 found-> vendor=0x1002, dev=0x439d, revid=0x00 domain=0, bus=0, slot=20, func=3 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4384, revid=0x00 domain=0, bus=0, slot=20, func=4 class=06-04-01, hdrtype=0x01, mfdev=1 cmdreg=0x0027, statreg=0x02a0, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1002, dev=0x4399, revid=0x00 domain=0, bus=0, slot=20, func=5 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0002, statreg=0x02a0, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=5 map[10]: type Memory, range 32, base 0xfe028000, size 12, enabled pcib0: matched entry for 0.20.INTC pcib0: slot 20 INTC hardwired to IRQ 18 found-> vendor=0x1022, dev=0x1200, revid=0x00 domain=0, bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1201, revid=0x00 domain=0, bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1202, revid=0x00 domain=0, bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1203, revid=0x00 domain=0, bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1204, revid=0x00 domain=0, bus=0, slot=24, func=4 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: irq 18 at device 2.0 on pci0 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xe000-0xefff pcib1: memory decode 0xfde00000-0xfdefffff pcib1: prefetched decode 0xd0000000-0xdfffffff pci1: on pcib1 pci1: domain=0, physical bus=1 found-> vendor=0x1002, dev=0x9498, revid=0x00 domain=0, bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Prefetchable Memory, range 64, base 0xd0000000, size 28, enabled pcib1: requested memory range 0xd0000000-0xdfffffff: good map[18]: type Memory, range 64, base 0xfdee0000, size 16, enabled pcib1: requested memory range 0xfdee0000-0xfdeeffff: good map[20]: type I/O Port, range 32, base 0xee00, size 8, enabled pcib1: requested I/O range 0xee00-0xeeff: in range pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 18 found-> vendor=0x1002, dev=0xaa38, revid=0x00 domain=0, bus=1, slot=0, func=1 class=04-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 64, base 0xfdefc000, size 14, enabled pcib1: requested memory range 0xfdefc000-0xfdefffff: good pcib1: matched entry for 1.0.INTB pcib1: slot 0 INTB hardwired to IRQ 19 vgapci0: port 0xee00-0xeeff mem 0xd0000000-0xdfffffff,0xfdee0000-0xfdeeffff irq 18 at device 0.0 on pci1 pci1: at device 0.1 (no driver attached) pcib2: irq 19 at device 7.0 on pci0 pcib2: domain 0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfdd00000-0xfddfffff pcib2: prefetched decode 0xfdc00000-0xfdcfffff pci2: on pcib2 pci2: domain=0, physical bus=2 found-> vendor=0x8086, dev=0x10b9, revid=0x06 domain=0, bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type Memory, range 32, base 0xfdde0000, size 17, enabled pcib2: requested memory range 0xfdde0000-0xfddfffff: good map[14]: type Memory, range 32, base 0xfddc0000, size 17, enabled pcib2: requested memory range 0xfddc0000-0xfdddffff: good map[18]: type I/O Port, range 32, base 0xdf00, size 5, enabled pcib2: requested I/O range 0xdf00-0xdf1f: in range pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 19 em0: port 0xdf00-0xdf1f mem 0xfdde0000-0xfddfffff,0xfddc0000-0xfdddffff irq 19 at device 0.0 on pci2 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xfdde0000 em0: attempting to allocate 1 MSI vectors (1 supported) em0: using IRQ 256 for MSI em0: Using MSI interrupt msi: Assigning MSI IRQ 256 to local APIC 0 vector 49 em0: [FILTER] em0: bpf attached em0: Ethernet address: 00:1b:21:34:ef:46 pcib3: irq 18 at device 10.0 on pci0 pcib3: domain 0 pcib3: secondary bus 3 pcib3: subordinate bus 3 pcib3: I/O decode 0xc000-0xcfff pcib3: memory decode 0xfda00000-0xfdafffff pcib3: prefetched decode 0xfdf00000-0xfdffffff pci3: on pcib3 pci3: domain=0, physical bus=3 found-> vendor=0x10ec, dev=0x8168, revid=0x02 domain=0, bus=3, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0010, cachelnsz=1 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 3 supports D0 D1 D2 D3 current D0 MSI supports 2 messages, 64 bit MSI-X supports 2 messages in map 0x20 map[10]: type I/O Port, range 32, base 0xce00, size 8, enabled pcib3: requested I/O range 0xce00-0xceff: in range map[18]: type Prefetchable Memory, range 64, base 0xfdfff000, size 12, enabled pcib3: requested memory range 0xfdfff000-0xfdffffff: good map[20]: type Prefetchable Memory, range 64, base 0xfdfe0000, size 16, enabled pcib3: requested memory range 0xfdfe0000-0xfdfeffff: good pcib3: matched entry for 3.0.INTA pcib3: slot 0 INTA hardwired to IRQ 18 re0: port 0xce00-0xceff mem 0xfdfff000-0xfdffffff,0xfdfe0000-0xfdfeffff irq 18 at device 0.0 on pci3 re0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xfdfff000 re0: MSI count : 2 re0: attempting to allocate 1 MSI vectors (2 supported) re0: using IRQ 257 for MSI re0: Using 1 MSI messages re0: Chip rev. 0x3c000000 re0: MAC rev. 0x00400000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: bpf attached re0: Ethernet address: 00:1f:d0:d7:4c:1b msi: Assigning MSI IRQ 257 to local APIC 0 vector 50 re0: [MPSAFE] re0: [FILTER] atapci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfb00 atapci0: Reserved 0x400 bytes for rid 0x24 type 3 at 0xfe02f000 ioapic0: routing intpin 22 (PCI IRQ 22) to lapic 0 vector 51 atapci0: [MPSAFE] atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported atapci0: Caps: 64bit NCQ SNTF MPS ALP AL CLO 3Gbps PM PMD SSC PSC 32cmd CCC 4ports ata2: on atapci0 ata2: AHCI reset... ata2: hardware reset ... ata2: SATA connect time=0ms status=00000123 ata2: ready wait time=24ms ata2: software reset port 15... ata2: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata2: port is not ready (timeout 0ms) tfd = 000001d0 ata2: software reset clear timeout ata2: software reset port 0... ata2: ready wait time=0ms ata2: SIGNATURE: 00000101 ata2: AHCI reset done: devices=00000001 ata2: [MPSAFE] ata2: [ITHREAD] ata3: on atapci0 ata3: AHCI reset... ata3: hardware reset ... ata3: SATA connect time=10ms status=00000113 ata3: ready wait time=183ms ata3: software reset port 15... ata3: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata3: port is not ready (timeout 0ms) tfd = 00000180 ata3: software reset clear timeout ata3: software reset port 0... ata3: ready wait time=0ms ata3: SIGNATURE: eb140101 ata3: AHCI reset done: devices=00010000 ata3: [MPSAFE] ata3: [ITHREAD] ata4: on atapci0 ata4: AHCI reset... ata4: hardware reset ... ata4: SATA connect time=0ms status=00000123 ata4: ready wait time=16ms ata4: software reset port 15... ata4: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata4: port is not ready (timeout 0ms) tfd = 000001d0 ata4: software reset clear timeout ata4: software reset port 0... ata4: ready wait time=0ms ata4: SIGNATURE: 00000101 ata4: AHCI reset done: devices=00000001 ata4: [MPSAFE] ata4: [ITHREAD] ata5: on atapci0 ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: [MPSAFE] ata5: [ITHREAD] ohci0: mem 0xfe02e000-0xfe02efff irq 16 at device 18.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02e000 ioapic0: routing intpin 16 (PCI IRQ 16) to lapic 0 vector 52 ohci0: [MPSAFE] ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe02d000-0xfe02dfff irq 16 at device 18.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02d000 ohci1: [MPSAFE] ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xfe02c000-0xfe02c0ff irq 17 at device 18.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe02c000 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 0 vector 53 ehci0: [MPSAFE] ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfe02b000-0xfe02bfff irq 18 at device 19.0 on pci0 ohci2: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02b000 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 0 vector 54 ohci2: [MPSAFE] ohci2: [ITHREAD] usbus3: on ohci2 ohci3: mem 0xfe02a000-0xfe02afff irq 18 at device 19.1 on pci0 ohci3: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe02a000 ohci3: [MPSAFE] ohci3: [ITHREAD] usbus4: on ohci3 ehci1: mem 0xfe029000-0xfe0290ff irq 19 at device 19.2 on pci0 ehci1: Reserved 0x100 bytes for rid 0x10 type 3 at 0xfe029000 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 0 vector 55 ehci1: [MPSAFE] ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfa00 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=7f ostat1=7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat0=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: stat1=0x7f err=0x7f lsb=0x7f msb=0x7f ata0: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 56 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=7f ostat1=7f ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat0=0x7f err=0xff lsb=0xff msb=0xff ata1: stat1=0x7f err=0xff lsb=0xff msb=0xff ata1: reset tp2 stat0=ff stat1=ff devices=0x0 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 57 ata1: [MPSAFE] ata1: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib4: at device 20.4 on pci0 pcib4: domain 0 pcib4: secondary bus 4 pcib4: subordinate bus 4 pcib4: I/O decode 0xb000-0xbfff pcib4: memory decode 0xf8000000-0xfcffffff pcib4: prefetched decode 0xfdb00000-0xfdbfffff pcib4: Subtractively decoded bridge. pci4: on pcib4 pci4: domain=0, physical bus=4 found-> vendor=0x14f1, dev=0x8800, revid=0x05 domain=0, bus=4, slot=6, func=0 class=04-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x14 (5000 ns), maxlat=0x37 (13750 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf9000000, size 24, enabled pcib4: requested memory range 0xf9000000-0xf9ffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8811, revid=0x05 domain=0, bus=4, slot=6, func=1 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0xff (63750 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xf8000000, size 24, enabled pcib4: requested memory range 0xf8000000-0xf8ffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8802, revid=0x05 domain=0, bus=4, slot=6, func=2 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x06 (1500 ns), maxlat=0x58 (22000 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfb000000, size 24, enabled pcib4: requested memory range 0xfb000000-0xfbffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x14f1, dev=0x8804, revid=0x05 domain=0, bus=4, slot=6, func=4 class=04-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x0290, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x06 (1500 ns), maxlat=0xff (63750 ns) intpin=a, irq=3 powerspec 2 supports D0 D3 current D0 map[10]: type Memory, range 32, base 0xfa000000, size 24, enabled pcib4: requested memory range 0xfa000000-0xfaffffff: good pcib4: matched entry for 4.6.INTA pcib4: slot 6 INTA hardwired to IRQ 20 found-> vendor=0x104c, dev=0x8024, revid=0x00 domain=0, bus=4, slot=14, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0210, cachelnsz=1 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type Memory, range 32, base 0xfcfff000, size 11, enabled pcib4: requested memory range 0xfcfff000-0xfcfff7ff: good map[14]: type Memory, range 32, base 0xfcff8000, size 14, enabled pcib4: requested memory range 0xfcff8000-0xfcffbfff: good pcib4: matched entry for 4.14.INTA pcib4: slot 14 INTA hardwired to IRQ 22 pci4: at device 6.0 (no driver attached) pci4: at device 6.1 (no driver attached) pci4: at device 6.2 (no driver attached) pci4: at device 6.4 (no driver attached) fwohci0: mem 0xfcfff000-0xfcfff7ff,0xfcff8000-0xfcffbfff irq 22 at device 14.0 on pci4 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfcfff000 fwohci0: [MPSAFE] fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:ef:de:f8:00:00:1f:d0 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1ac4000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:ef:de:00:1f:d0 fwe0: bpf attached fwe0: Ethernet address: 02:ef:de:00:1f:d0 fwip0: on firewire0 fwip0: bpf attached fwip0: Firewire address: 00:ef:de:f8:00:00:1f:d0 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode ohci4: mem 0xfe028000-0xfe028fff irq 18 at device 20.5 on pci0 ohci4: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfe028000 ohci4: [MPSAFE] ohci4: [ITHREAD] usbus6: on ohci4 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to lapic 0 vector 58 fdc0: [FILTER] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 59 uart0: [FILTER] uart0: fast interrupt ppc0: using extended I/O port range ppc0: SPP ECP ECP+EPP ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 60 ppc0: [MPSAFE] ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached plip0: [MPSAFE] plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [MPSAFE] lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 61 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0047 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 62 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 atrtc1: port 0x70-0x73 on acpi0 atrtc1: registered as a time-of-day clock (resolution 1000000us) cpu0: on acpi0 cpu0: switching to generic Cx mode hwpstate0: on cpu0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 0: ioport 0xc00 alloc failed pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete ex_isa_identify() isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcefff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atrtc0: at port 0x70 irq 8 on isa0 atrtc0: Warning: Couldn't map I/O. atrtc0: Warning: Couldn't map Interrupt. atrtc1: removed as time-of-day clock: clock atrtc has higher resolution atrtc0: registered as a time-of-day clock (resolution 1000000us) uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 214210 -> 100000 procfs registered lapic: Divisor 2, Frequency 100458198 hz Timecounter "TSC" frequency 2812829239 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached ata5: CONNECT requested firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 hptrr: no controller detected. ata0: Identifying devices: 00000000 ata0: New devices: 00000000 ata1: Identifying devices: 00000000 ata1: New devices: 00000000 ata2: Identifying devices: 00000001 ata2: New devices: 00000001 usbus6: 12Mbps Full Speed USB v1.0 md0: Preloaded image 4423680 bytes at 0xc10e87a0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ugen6.1: at usbus6 uhub0: on usbus6 ugen0.1: at usbus0 uhub1: on usbus0 ugen1.1: at usbus1 uhub2: on usbus1 ugen2.1: at usbus2 uhub3: on usbus2 ugen3.1: at usbus3 uhub4: on usbus3 ugen4.1: at usbus4 uhub5: on usbus4 ugen5.1: at usbus5 uhub6: on usbus5 uhub0: 2 ports with 2 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub2: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered uhub5: 3 ports with 3 removable, self powered ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: DISCONNECT requested ata5: reinit done .. ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 953868MB at ata2-master SATA300 ad4: 1953523055 sectors [1938018C/16H/63S] 16 sectors/interrupt 1 depth queue ad4: Silicon Image check3 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD check1 failed ata3: Identifying devices: 00010000 ata3: New devices: 00010000 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire ata3: device_reset timeout=120us uhub3: 6 ports with 6 removable, self powered uhub6: 6 ports with 6 removable, self powered acd0: DVDR drive at ata3 as master acd0: read 17583KB/s (17583KB/s) write 5410KB/s (5410KB/s), 2000KB buffer, SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: DVD 120mm data disc ata4: Identifying devices: 00000001 ata4: New devices: 00000001 ata4-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad8: 953869MB at ata4-master SATA300 ad8: 1953525168 sectors [1938021C/16H/63S] 16 sectors/interrupt 1 depth queue ad8: Silicon Image check3 failed ad8: Adaptec check1 failed ad8: LSI (v3) check1 failed ad8: LSI (v2) check1 failed ad8: FreeBSD check1 failed ata5: Identifying devices: 00000000 ata5: New devices: 00000000 GEOM: new disk ad4 GEOM: new disk ad8 ugen1.2: at usbus1 ata5: CONNECT requested ulpt0: on usbus1 ulpt0: using bi-directional mode umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x0000 (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... GEOM: ad8: partition 1 does not start on a track boundary. GEOM: ad8: partition 1 does not end on a track boundary. GEOM: ad4s2: geometry does not match label (255h,63s != 16h,63s). umass0:1:0:-1: Attached to scbus1 ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: DISCONNECT requested ata5: reinit done .. (probe0:umass-sim0:0:0:0): error 22 (probe0:umass-sim0:0:0:0): Unretryable Error (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present (probe0:umass-sim0:0:0:0): (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): NOT READY asc:3a,0 (probe0:umass-sim0:0:0:0): Medium not present Unretryable error (probe0:umass-sim0:0:0:0): error 6 (probe0:umass-sim0:0:0:0): Unretryable Error ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. GEOM: new disk da0 ATA PseudoRAID loaded (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-2 device pass0: 1.000MB/s transfers SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x03000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x02000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x80050010 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00000400 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 1 vector 48(da0: umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 -> 6ioapic0: routing intpin 6 ( ISA IRQ 6) to lapic 2 vector 48 ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 3 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 1 vector 49 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 2 vector 49 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 3 vector 49 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 1 vector 50 ioapic0: routing intpin 18 (PCI IRQ 18) to lapic 2 vector 50 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 3 vector 50 msi: Assigning MSI IRQ 256 to local APIC 1 vector 51 msi: Assigning MSI IRQ 257 to local APIC 2 vector 51 WARNING: WITNESS option enabled, expect reduced performance. (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error Opened disk da0 -> 6 Trying to mount root from ufs:/dev/md0 ct_to_ts([2009-06-25 19:46:54]) = 1245959214.000000000 start_init: trying /sbin/init start_init: trying /sbin/oinit start_init: trying /sbin/init.bak start_init: trying /rescue/init start_init: trying /stand/sysinstall ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000001 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: CONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. ata5: DISCONNECT requested ata5: reiniting channel .. ata5: AHCI reset... ata5: hardware reset ... ata5: SATA connect timeout status=00000000 ata5: AHCI reset done: phy reset found no device ata5: reinit done .. From owner-freebsd-current@FreeBSD.ORG Fri Jun 26 16:38:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2CB51065674; Fri, 26 Jun 2009 16:38:04 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 9A29F8FC0A; Fri, 26 Jun 2009 16:38:04 +0000 (UTC) (envelope-from gabor@kovesdan.org) Received: from localhost (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id A83B714D8AF3; Fri, 26 Jun 2009 18:18:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at t-hosting.hu Received: from server.mypc.hu ([127.0.0.1]) by localhost (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id t6TcX2+s1X8Q; Fri, 26 Jun 2009 18:18:14 +0200 (CEST) Received: from [192.168.3.188] (arribagr.adsl.datanet.hu [195.56.3.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 7558814D8ADB; Fri, 26 Jun 2009 18:18:14 +0200 (CEST) Message-ID: <4A44F4E4.2030104@kovesdan.org> Date: Fri, 26 Jun 2009 18:18:44 +0200 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 2.0.0.21 (X11/20090516) MIME-Version: 1.0 To: Alexey Shuvaev References: <4A246C4D.6080409@FreeBSD.org> <4A407CB1.2060107@FreeBSD.org> <20090626161057.GA47554@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090626161057.GA47554@wep4035.physik.uni-wuerzburg.de> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 29 Jun 2009 00:48:51 +0000 Cc: FreeBSD Current , Gabor Kovesdan Subject: Re: RFC: Replacing bc/dc to BSDL versions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 16:38:05 -0000 Alexey Shuvaev wrote: > Thanks! > I'm running the system with BSD bc/dc now. > The only small thing I've noticed is: > > ~> dc -h > dc: invalid option -- h > usage: dc [-hVx] [-e expression] [file] > ~> dc --help > usage: dc [-hVx] [-e expression] [file] > > This seems to come from this line in dc.c: > > + /* accept and ignore a single dash to be 4.4BSD dc(1) compatible */ > + while ((ch = getopt_long(argc, argv, "e:f:Vx", long_options, NULL)) != -1) { > > Possibly one should just use "e:f:Vhx"? > Otherwise looks good, I'm using dc from time to time. > Thanks Alexey, your observation is correct, I'll fix my patch. We cannot replace bc/dc for 8.X, however, because re's decision was to defer this change after the code freeze. In the meantime, all of your input is very important so that we can polish possible remaining items. Thanks for taking your time to try BSD bc/dc. Regards, Gabor From owner-freebsd-current@FreeBSD.ORG Fri Jun 26 22:32:57 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9B9C1065679; Fri, 26 Jun 2009 22:32:57 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 65BD18FC08; Fri, 26 Jun 2009 22:32:57 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 183841E00261; Sat, 27 Jun 2009 00:32:56 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5QMQTtp002596; Sat, 27 Jun 2009 00:26:29 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5QMQTtQ002595; Sat, 27 Jun 2009 00:26:29 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 27 Jun 2009 00:26:29 +0200 To: freebsd-current@FreeBSD.org Message-ID: <20090626222629.GA1909@triton.kn-bremen.de> References: <20090625202536.GA2645@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090625202536.GA2645@triton.kn-bremen.de> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 29 Jun 2009 00:49:37 +0000 Cc: mav@FreeBSD.org Subject: ata irq storm/probe failure; tdq_notify pagefault (was: pmap_extract panic @boot (20090623-JPSNAP-amd64-dvd1.iso)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 22:32:58 -0000 On Thu, Jun 25, 2009 at 10:25:36PM +0200, Juergen Lock wrote: > I wanted to try a head snapshot iso today and it failed to boot: > http://people.freebsd.org/~nox/20090623-JPSNAP-amd64-bootpanic1.jpg > http://people.freebsd.org/~nox/20090623-JPSNAP-amd64-bootpanic2.jpg > (I tried to get a serial console but couldn't get this box' serial > port working for some reason... ): > > As you can see in the jpegs it panic'd at pmap_extract+0x106, which > I _think_ is in line 963: (unfortunately there's no kernel.symbols on > the iso) > pdep = pmap_pde(pmap, va); > (see > http://fxr.watson.org/fxr/source/amd64/amd64/pmap.c#L963 > ), and that got invoked from isa_dmarangecheck+0x98: > http://fxr.watson.org/fxr/source/amd64/isa/isa_dma.c#L374 > [...] After I realized ppc_isa_attach() belongs to the parallel port driver which is unused on this box I was able to work around this issue by disabling it in the bios. But the dmesg I posted already points at the next problem... > [...] > start_init: trying /sbin/init > start_init: trying /sbin/oinit > start_init: trying /sbin/init.bak > start_init: trying /rescue/init > start_init: trying /stand/sysinstall > ata5: CONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000001 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: DISCONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000001 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: CONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000001 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: DISCONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000000 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: CONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000000 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: DISCONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000001 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: CONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > ata5: SATA connect timeout status=00000001 > ata5: AHCI reset done: phy reset found no device > ata5: reinit done .. > ata5: DISCONNECT requested > ata5: reiniting channel .. > ata5: AHCI reset... > ata5: hardware reset ... > [...] i.e. ata5 isnt probed correctly anymore (its an optical drive), and meanwhile I discovered there's an irq storm on irq 22 too (shared between atapci0 and fwohci0), causing one cpu to be at near 100%. This doesn't seem to occur with a 20090315 snapshot so _maybe_ its related to this commit: mav 2009-03-30 22:18:38 UTC FreeBSD src repository Modified files: sys/dev/ata ata-pci.c ata-pci.h ata-sata.c sys/dev/ata/chipsets ata-ahci.c ata-intel.c ata-jmicron.c ata-marvell.c ata-nvidia.c ata-promise.c ata-siliconimage.c ata-sis.c ata-via.c Log: SVN rev 190581 on 2009-03-30 22:18:38Z by mav Integrate user/mav/ata branch: Add ch_suspend/ch_resume methods for PCI controllers and implement them for AHCI. Refactor AHCI channel initialization according to it. Fix Port Multipliers operation. It is far from perfect yet, but works now. Tested with JMicron JMB363 AHCI + SiI 3726 PMP pair. Previous version was also tested with SiI 4726 PMP. Hardware sponsored by: Vitsch Electronics / VEHosting.nl (I first tried manually reverting commit 191568 in the 20090623 kernel as this box has an amd/ati sb600, but that seemed to make no difference.) While doing that I discovered another problem tho: I installed onto an usb key for testing, and booting that panic'd in tdq_notify+0x4e with a pagefault due to a null pointer here: movzbl 0x27a(%rax),%edx (it was trying to read from 0x27a; the backtrace was almost empty as this seems to be part of the scheduler - I can post the backtrace too if anyone's interested.) I then got it to boot into single user, and from there got into multiuser, and then discovered the ata issue... The good news is the new usb stack seems to like my printer better! (I didn't actually test printing itself but at least it got detected at boot, which on 7-stable it doesn't, I always have to plug it into another port atm after boot before I can use it...) Ok that should be enough for now. Cheers, :) Juergen PS: ata5 related parts of stable dmesg: ... ata5: on atapci0 ata5: SATA connect time=0ms ata5: SIGNATURE: eb140101 ata5: ahci_reset devices=0x4 ata5: [MPSAFE] ata5: [ITHREAD] ... ata5-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire ata5: device_reset timeout=660us acd1: DVDR drive at ata5 as master acd1: read 5512KB/s (5512KB/s) write 5512KB/s (5512KB/s), 16384KB buffer, SATA150 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd1: Writes: CDR, CDRW, DVDR, test write, burnproof acd1: Audio: play, 2 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc ... ...and the other optical drive that also gets detected on head (this dmesg still from stable:) ... ata3: on atapci0 ata3: SATA connect time=0ms ata3: SIGNATURE: eb140101 ata3: ahci_reset devices=0x4 ata3: [MPSAFE] ata3: [ITHREAD] ... ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire ata3: device_reset timeout=120us acd0: DVDR drive at ata3 as master acd0: read 6890KB/s (6890KB/s) write 5511KB/s (6890KB/s), 2000KB buffer, SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ... ..so maybe (wild guess!) UDMA100 is related? Here is the head dmesg related to that drive for comparison: ... ata3: on atapci0 ata3: AHCI reset... ata3: hardware reset ... ata3: SATA connect time=10ms status=00000113 ata3: ready wait time=183ms ata3: software reset port 15... ata3: ahci_issue_cmd timeout: 3000 of 3000ms, status=00000001 ata3: port is not ready (timeout 0ms) tfd = 00000180 ata3: software reset clear timeout ata3: software reset port 0... ata3: ready wait time=0ms ata3: SIGNATURE: eb140101 ata3: AHCI reset done: devices=00010000 ata3: [MPSAFE] ata3: [ITHREAD] ... ata3: Identifying devices: 00010000 ata3: New devices: 00010000 ata3-master: pio=PIO4 wdma=WDMA2 udma=UDMA66 cable=40 wire ata3: device_reset timeout=120us uhub3: 6 ports with 6 removable, self powered uhub6: 6 ports with 6 removable, self powered acd0: DVDR drive at ata3 as master acd0: read 17583KB/s (17583KB/s) write 5410KB/s (5410KB/s), 2000KB buffer, +SATA150 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: DVD 120mm data disc From owner-freebsd-current@FreeBSD.ORG Sat Jun 27 14:42:20 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD144106567E; Sat, 27 Jun 2009 14:42:20 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 31C818FC20; Sat, 27 Jun 2009 14:42:19 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 18CE91E00202; Sat, 27 Jun 2009 16:42:19 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5REbKCv028516; Sat, 27 Jun 2009 16:37:20 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5REbJqN028515; Sat, 27 Jun 2009 16:37:19 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 27 Jun 2009 16:37:19 +0200 To: "Sean C. Farley" Message-ID: <20090627143719.GA28318@triton.kn-bremen.de> References: <20090606162235.GA49444@triton.kn-bremen.de> <43784537@ipt.ru> <66988167@ipt.ru> <747dc8f30906261255s1ecc1420x574ded3be835b448@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 29 Jun 2009 00:51:11 +0000 Cc: Renato Botelho , Boris Samorodov , freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, Juergen Lock Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 14:42:21 -0000 On Fri, Jun 26, 2009 at 03:33:15PM -0500, Sean C. Farley wrote: > On Fri, 26 Jun 2009, Renato Botelho wrote: > > > On Fri, Jun 26, 2009 at 4:32 PM, Boris Samorodov wrote: > >> OK, thanks! I should have missed you previous post. > >> > >> Here is a port for tests. This shar should be run at /usr/ports/www: > >> ftp://ftp.ipt.ru/pub/linux/linux-f10-flashplugin10.shar > >> > >> Note: the port is only hand-written and tested to build/install/deinstall. > > > > I tried it and got this message: > > > > *** NSPlugin Wrapper *** ERROR: NPP_New() wait for reply: Message timeout > > > > My environment: > > > > FreeBSD botelhor.bplab.local 8.0-CURRENT FreeBSD 8.0-CURRENT #73 > > r194284: Wed Jun 24 19:09:04 BRT 2009 > > root@botelhor.bplab.local:/usr/obj/usr/src/sys/GARGA i386 > > > > linux-f10-atk-1.24.0 > > linux-f10-cairo-1.8.0 > > linux-f10-curl-7.19.4_1 > > linux-f10-expat-2.0.1 > > linux-f10-flashplugin-10.0r22 > > linux-f10-fontconfig-2.6.0 > > linux-f10-gtk2-2.14.7 > > linux-f10-jpeg-6b > > linux-f10-libssh2-0.18 > > linux-f10-nspr-4.7.3 > > linux-f10-nss-3.12.2.0 > > linux-f10-openssl-0.9.8g > > linux-f10-pango-1.22.3 > > linux-f10-png-1.2.35 > > linux-f10-sqlite3-3.5.9 > > linux-f10-tiff-3.8.2 > > linux-f10-xorg-libs-7.4 > > linux_base-f10-10 > > nspluginwrapper-1.2.2_2 > > > > I deinstalled linux-f8, cleaned compat/linux and reinstalled everything. > > Assuming it is the issue with missing dependencies for libcurl, we also > need port(s) for liblber and libldap since f10's libcurl depends upon > them. liblber is in the same rpm with libldap (I used openldap-2.4.12-1.fc10.i386.rpm as I said), and as I said we also need libsasl2 (libldap depends on it) which is in cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm . > I had to manually extract a couple of RPM's to get them. Here is > the ldd output of libcurl for me: > > # /compat/linux/bin/sh /compat/linux/usr/bin/ldd /compat/linux/usr/lib/libcurl.so.4.1.1 > libidn.so.11 => /lib/libidn.so.11 (0x20073000) > libssh2.so.1 => /usr/lib/libssh2.so.1 (0x200a5000) > libldap-2.4.so.2 => /usr/lib/libldap-2.4.so.2 (0x200c7000) > librt.so.1 => /lib/librt.so.1 (0x20109000) > libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x20113000) > libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x20141000) > libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x201e1000) > libcom_err.so.2 => /lib/libcom_err.so.2 (0x20206000) > libz.so.1 => /lib/libz.so.1 (0x20209000) > libssl3.so => /lib/libssl3.so (0x2021d000) > libsmime3.so => /lib/libsmime3.so (0x2024e000) > libnss3.so => /lib/libnss3.so (0x20275000) > libplds4.so => /lib/libplds4.so (0x203bb000) > libplc4.so => /lib/libplc4.so (0x203bf000) > libnspr4.so => /lib/libnspr4.so (0x203c4000) > libpthread.so.0 => /lib/libpthread.so.0 (0x203fe000) > libdl.so.2 => /lib/libdl.so.2 (0x20418000) > libc.so.6 => /lib/libc.so.6 (0x2041d000) > libssl.so.7 => /lib/libssl.so.7 (0x20596000) > libcrypto.so.7 => /lib/libcrypto.so.7 (0x205e1000) > liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x20735000) > libresolv.so.2 => /lib/libresolv.so.2 (0x20744000) > libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x2075b000) > /lib/ld-linux.so.2 (0x00000000) > libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x20775000) > libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x2077f000) > libnssutil3.so => /lib/libnssutil3.so (0x20782000) > libcrypt.so.1 => /lib/libcrypt.so.1 (0x2079b000) > libselinux.so.1 => /lib/libselinux.so.1 (0x207cf000) Same here with the following ports I just tested here: (thanx to bsam for the linux-f10-flashplugin10 port and to Peter Jeremy for the original linux-f10-openldap and linux-f10-cyrus-sasl2 ports!) First a patch for bsd.linux-apps.mk, then the shar, please test and comment :) Index: Mk/bsd.linux-apps.mk @@ -70,7 +70,8 @@ _LINUX_APPS_ALL+= # 2.6.16 components -_LINUX_26_APPS= libidn libssh2 nspr nss sqlite3 tcl84 tk84 +_LINUX_26_APPS= cyrus-sasl2 libidn libssh2 nspr nss openldap \ + sqlite3 tcl84 tk84 _LINUX_APPS_ALL+= ${_LINUX_26_APPS} @@ -137,6 +138,11 @@ curl_DETECT= ${curl${LINUX_DIST_SUFFIX:S/-/_/}_FILE} curl_PORT= ${PORTSDIR}/ftp/linux${LINUX_DIST_SUFFIX}-curl +# no cyrus-sasl2_FILE, cyrus-sasl2_f8_FILE +cyrus-sasl2_f10_FILE= ${LINUXBASE}/usr/lib/libsasl2.so.2.0.22 +cyrus-sasl2_DETECT= ${cyrus-sasl2${LINUX_DIST_SUFFIX:S/-/_/}_FILE} +cyrus-sasl2_PORT= ${PORTSDIR}/security/linux${LINUX_DIST_SUFFIX}-cyrus-sasl2 + dri_FILE= ${LINUXBASE}/usr/X11R6/lib/libGL.so.1 dri_f8_FILE= ${LINUXBASE}/usr/lib/libGL.so.1 dri_f10_FILE= ${LINUXBASE}/usr/lib/libGL.so.1.2 @@ -307,6 +313,11 @@ mikmod_DETECT= ${mikmod${LINUX_DIST_SUFFIX:S/-/_/}_FILE} mikmod_PORT= ${PORTSDIR}/audio/linux${LINUX_DIST_SUFFIX}-mikmod +# no openldap_FILE, openldap_f8_FILE +openldap_f10_FILE= ${LINUXBASE}/usr/lib/libldap-2.4.so.2.2.0 +openldap_DETECT= ${openldap${LINUX_DIST_SUFFIX:S/-/_/}_FILE} +openldap_PORT= ${PORTSDIR}/net/linux${LINUX_DIST_SUFFIX}-openldap + openmotif_FILE= ${LINUXBASE}/usr/X11R6/lib/libXm.so.3.0.3 openmotif_f8_FILE= ${LINUXBASE}/usr/lib/libXm.so.4.0.2 openmotif_f10_FILE= ${LINUXBASE}/usr/X11R6/lib/libXm.so.3.0.3 # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # net/linux-f10-openldap/ # net/linux-f10-openldap/Makefile # net/linux-f10-openldap/distinfo.i386 # security/linux-f10-cyrus-sasl2/ # security/linux-f10-cyrus-sasl2/Makefile # security/linux-f10-cyrus-sasl2/distinfo.i386 # www/linux-f10-flashplugin10/ # www/linux-f10-flashplugin10/Makefile # www/linux-f10-flashplugin10/distinfo # www/linux-f10-flashplugin10/pkg-descr # www/linux-f10-flashplugin10/pkg-plist # echo c - net/linux-f10-openldap/ mkdir -p net/linux-f10-openldap/ > /dev/null 2>&1 echo x - net/linux-f10-openldap/Makefile sed 's/^X//' >net/linux-f10-openldap/Makefile << '17a12d65b66950d2cbc504ac86a37255' X# New ports collection makefile for: net/linux-f10-openldap X# Date created: 2009-06-07 X# Whom: peter X# X# $FreeBSD$ X# X XPORTNAME= openldap XPORTVERSION= 2.4.12 XCATEGORIES= net linux XPKGNAMEPREFIX= linux-f10- XDISTNAME= ${PORTNAME}-${PORTVERSION}-${RPMVERSION} X X.if defined(PACKAGE_BUILDING) XSRC_DISTFILES= ${PORTNAME}-${PORTVERSION}-${RPMVERSION}.src.rpm XALWAYS_KEEP_DISTFILES= YES X.endif X XMAINTAINER= emulation@FreeBSD.org XCOMMENT= Lightweight Directory Access Protocol libraries (Linux Fedora 10) X X#CONFLICTS= X XUSE_LINUX_RPM= yes XLINUX_DIST_VER= 10 XRPMVERSION= 1.fc10 XUSE_LDCONFIG= yes XDESCR= ${.CURDIR}/../openldap24-server/pkg-descr X XPLIST_DIRS= etc/openldap/cacerts etc/openldap XPLIST_FILES= etc/openldap/ldap.conf usr/lib/liblber-2.4.so.2 usr/lib/liblber-2.4.so.2.2.0 usr/lib/libldap-2.4.so.2 usr/lib/libldap-2.4.so.2.2.0 usr/lib/libldap_r-2.4.so.2 usr/lib/libldap_r-2.4.so.2.2.0 XDOCSDIR= usr/share/doc/${PORTNAME}-${PORTVERSION} XPORTDOCS= ANNOUNCEMENT CHANGES COPYRIGHT LICENSE README XMANPREFIX= ${PREFIX}/usr/share XMAN5= ldap.conf.5 ldif.5 XMANCOMPRESSED= yes X X.include 17a12d65b66950d2cbc504ac86a37255 echo x - net/linux-f10-openldap/distinfo.i386 sed 's/^X//' >net/linux-f10-openldap/distinfo.i386 << 'f422178bbd4668750265f4e584e91c0e' XMD5 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = e3ea12058a8cdc54d6f270c802c92a00 XSHA256 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = 2a71dcfdbfb1dc9b4e056c951518474d5958147c033f3584dc06e784fd67d567 XSIZE (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = 323504 f422178bbd4668750265f4e584e91c0e echo c - security/linux-f10-cyrus-sasl2/ mkdir -p security/linux-f10-cyrus-sasl2/ > /dev/null 2>&1 echo x - security/linux-f10-cyrus-sasl2/Makefile sed 's/^X//' >security/linux-f10-cyrus-sasl2/Makefile << '4fc58bcf97a8889077c61da23cb55faa' X# New ports collection makefile for: security/linux-f10-cyrus-sasl2 X# Date created: 2009-06-07 X# Whom: peter X# X# $FreeBSD$ X# X XPORTNAME= cyrus-sasl2 XPORTVERSION= 2.1.22 XCATEGORIES= security linux XPKGNAMEPREFIX= linux-f10- XDISTNAME= cyrus-sasl-lib-${PORTVERSION}-${RPMVERSION} X X.if defined(PACKAGE_BUILDING) XSRC_DISTFILES= cyrus-sasl-lib-${PORTVERSION}-${RPMVERSION}.src.rpm XALWAYS_KEEP_DISTFILES= YES X.endif X XMAINTAINER= emulation@FreeBSD.org XCOMMENT= RFC 2222 SASL (Simple Authentication and Security Layer) (Linux Fedora 10) X X#CONFLICTS= X XUSE_LINUX_RPM= yes XLINUX_DIST_VER= 10 XRPMVERSION= 19.fc10 XUSE_LDCONFIG= yes XBRANDELF_FILES= usr/sbin/sasldblistusers2 usr/sbin/saslpasswd2 XDESCR= ${.CURDIR}/../${PORTNAME}/pkg-descr X XPLIST_DIRS= etc/sasl2 usr/lib/sasl2 XPLIST_FILES= usr/lib/libsasl2.so.2 usr/lib/libsasl2.so.2.0.22 usr/lib/sasl2/libanonymous.so usr/lib/sasl2/libanonymous.so.2 usr/lib/sasl2/libanonymous.so.2.0.22 usr/lib/sasl2/libsasldb.so usr/lib/sasl2/libsasldb.so.2 usr/lib/sasl2/libsasldb.so.2.0.22 usr/sbin/sasldblistusers2 usr/sbin/saslpasswd2 XDOCSDIR= usr/share/doc/cyrus-sasl-lib-${PORTVERSION} XPORTDOCS= AUTHORS COPYING NEWS README advanced.html appconvert.html components.html gssapi.html index.html install.html macosx.html mechanisms.html options.html plugprog.html programming.html readme.html sysadmin.html upgrading.html windows.html X X.include 4fc58bcf97a8889077c61da23cb55faa echo x - security/linux-f10-cyrus-sasl2/distinfo.i386 sed 's/^X//' >security/linux-f10-cyrus-sasl2/distinfo.i386 << '9c7e54bf867023e1f8fcaa16319c72f4' XMD5 (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = 5a4ee3c84ec9581723fd56b658eec994 XSHA256 (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = ae8da4ee07615519c657ddbe3b8c128a2e81f00a4db0da17b7369dabe03ed6d2 XSIZE (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = 145305 9c7e54bf867023e1f8fcaa16319c72f4 echo c - www/linux-f10-flashplugin10/ mkdir -p www/linux-f10-flashplugin10/ > /dev/null 2>&1 echo x - www/linux-f10-flashplugin10/Makefile sed 's/^X//' >www/linux-f10-flashplugin10/Makefile << '5455d901d257b50d731e64397ea6df2f' X# New ports collection makefile for: www/linux-f10-flashplugin10 X# Date created: 2009-06-26 X# Whom: bsam X# Based on: www/linux-f8-flashplugin10 by nox@ X# X# $FreeBSD$ X# X XPORTNAME= flashplugin XPORTVERSION= 10.0r22 XCATEGORIES= www multimedia linux XMASTER_SITES= http://fpdownload.macromedia.com/get/flashplayer/current/:plugin \ X ftp://ftp.ipt.ru/pub/download/:suplib XPKGNAMEPREFIX= linux-f10- XDISTFILES= install_flash_player_10_linux.tar.gz:plugin \ X linux-f10-flashsupport-9.0.1.i386.tar.gz:suplib XDIST_SUBDIR= ${PORTNAME}/${PORTVERSION} X XMAINTAINER= emulation@FreeBSD.org XCOMMENT= Adobe Flash Player NPAPI Plugin X XONLY_FOR_ARCHS= amd64 i386 XUSE_LINUX= yes XUSE_LINUX_APPS= openssl curl cyrus-sasl2 libssh2 nspr nss openldap X XRESTRICTED= Redistribution not allowed XRESTRICTED_FILES= ${DISTFILES:Nlinux-f10-flashsupport*:C/:[^:]+$//} X XNO_BUILD= yes XWRKSRC= ${WRKDIR}/install_flash_player_10_linux X XUSE_NPAPI= linux-* XNPAPI_FILES= libflashplayer.so X XCONFLICTS= linux-flashplugin-7* linux-flashplugin-9* linux-f8-flashplugin10-* X Xpost-install: X @${INSTALL_PROGRAM} ${WRKDIR}/libflashsupport.so ${LINUXBASE}/usr/lib X X.include X.include "${PORTSDIR}/www/linux-mplayer-plugin/Makefile.npapi" X.include 5455d901d257b50d731e64397ea6df2f echo x - www/linux-f10-flashplugin10/distinfo sed 's/^X//' >www/linux-f10-flashplugin10/distinfo << '1f552e2e0c05a396106217e48ff92103' XMD5 (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = 23e4c2b844db0f87ff62084178aa2b1f XSHA256 (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = cd29f166c87fecc943e88fe951bb61c56728fab12b4bf343badafa73ea95394e XSIZE (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = 3994294 XMD5 (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 6e416c81497f65065d78dae1e0acad0d XSHA256 (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 4a309b1a326bd2212cc72480628659e5a7fd61d9e0572cb7350c206f030955bf XSIZE (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 3455 1f552e2e0c05a396106217e48ff92103 echo x - www/linux-f10-flashplugin10/pkg-descr sed 's/^X//' >www/linux-f10-flashplugin10/pkg-descr << '57a1420ff5e8cb1b77c71ecb3a15c599' XThis is the official Flash Player from Adobe. This plugin enables Xyou to see .swf and .spl files on the 'net from your Opera, Mozilla or XFirefox sessions. X XPlease see the Adobe home page for more information. X XFreeBSD Flash License Agreement: X http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/96374 X XWWW: http://www.adobe.com/ 57a1420ff5e8cb1b77c71ecb3a15c599 echo x - www/linux-f10-flashplugin10/pkg-plist sed 's/^X//' >www/linux-f10-flashplugin10/pkg-plist << '9254ee58cdc375ce93f8fc3b1afc9e77' X@cwd /compat/linux Xusr/lib/libflashsupport.so X@cwd 9254ee58cdc375ce93f8fc3b1afc9e77 exit From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 00:44:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0F319106566C for ; Mon, 29 Jun 2009 00:44:54 +0000 (UTC) (envelope-from nhoyle@hoyletech.com) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by mx1.freebsd.org (Postfix) with ESMTP id CF7A58FC08 for ; Mon, 29 Jun 2009 00:44:53 +0000 (UTC) (envelope-from nhoyle@hoyletech.com) Received: from [192.168.1.10] (pool-96-231-140-65.washdc.fios.verizon.net [96.231.140.65]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MKpCa-1ML4n92qqC-000CHU; Sun, 28 Jun 2009 20:32:19 -0400 Message-ID: <4A480B8C.1060708@hoyletech.com> Date: Sun, 28 Jun 2009 20:32:12 -0400 From: Nathanael Hoyle User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Rick Macklem References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19C1ctppmWifb7SoHsEFW3XglbxdKhFVYx+NCE ZowGOP4PcyJnGxQm5vjyVET45YZlyGps3ZIua2c6d8pdWlj1hK W+gzRSV3Gx1sc7Z0e9crhnFS367sNp7 X-Mailman-Approved-At: Mon, 29 Jun 2009 00:51:59 +0000 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 00:44:54 -0000 Rick Macklem wrote: > I just noticed that when I do the following: > - start a large write to an NFS mounted fs > - network partition the server (unplug a net cable) > - do a "umount -f " on the machine > > that it gets stuck trying to write dirty blocks to the server. > > I had, in the past, assumed that a "umount -f" of an NFS mount would be > used to get rid of an NFS mount on an unresponsive server and that loss > of "writes in progress" would be expected to happen. > > Does that sound correct? (In other words, an I seeing a bug or a > feature?) > > Thanks in advance for any info, rick > ps: I have a simple "fix" if this is a bug, but I wanted to check before > submitting a patch. I think the answer is probably "it's a feature, not a bug", but that depends on your NFS mount options which you didn't give. I'd suggest you read up on NFS soft versus hard mounts. I think you're seeing the latter and expecting the former behavior. The first hit I found Googling seems pretty decent, though taken from Linux docs should still apply: http://tldp.org/HOWTO/NFS-HOWTO/client.html Under section 4.3.1 "Soft vs. Hard Mounting" there's a basic description. Best of luck, -Nathanael From owner-freebsd-current@FreeBSD.ORG Sat Jun 27 21:38:15 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 461DE1065670; Sat, 27 Jun 2009 21:38:15 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 87ECB8FC20; Sat, 27 Jun 2009 21:38:14 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id B03941E00218; Sat, 27 Jun 2009 23:38:13 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5RLZYWq047357; Sat, 27 Jun 2009 23:35:34 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5RLZXHR047356; Sat, 27 Jun 2009 23:35:33 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 27 Jun 2009 23:35:33 +0200 To: Boris Samorodov Message-ID: <20090627213533.GA46429@triton.kn-bremen.de> References: <20090606162235.GA49444@triton.kn-bremen.de> <43784537@ipt.ru> <66988167@ipt.ru> <747dc8f30906261255s1ecc1420x574ded3be835b448@mail.gmail.com> <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33059629@ipt.ru> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 29 Jun 2009 00:52:12 +0000 Cc: Renato Botelho , freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, Juergen Lock , "Sean C. Farley" Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 21:38:15 -0000 On Sat, Jun 27, 2009 at 08:10:10PM +0400, Boris Samorodov wrote: > Juergen Lock writes: > > On Fri, Jun 26, 2009 at 03:33:15PM -0500, Sean C. Farley wrote: > >> On Fri, 26 Jun 2009, Renato Botelho wrote: > >> > >> > On Fri, Jun 26, 2009 at 4:32 PM, Boris Samorodov wrote: > >> >> OK, thanks! I should have missed you previous post. > >> >> > >> >> Here is a port for tests. This shar should be run at /usr/ports/www: > >> >> ftp://ftp.ipt.ru/pub/linux/linux-f10-flashplugin10.shar > >> >> > >> >> Note: the port is only hand-written and tested to build/install/deinstall. > >> > > >> > I tried it and got this message: > >> > > >> > *** NSPlugin Wrapper *** ERROR: NPP_New() wait for reply: Message timeout > >> > > >> > My environment: > >> > > >> > FreeBSD botelhor.bplab.local 8.0-CURRENT FreeBSD 8.0-CURRENT #73 > >> > r194284: Wed Jun 24 19:09:04 BRT 2009 > >> > root@botelhor.bplab.local:/usr/obj/usr/src/sys/GARGA i386 > >> > > >> > linux-f10-atk-1.24.0 > >> > linux-f10-cairo-1.8.0 > >> > linux-f10-curl-7.19.4_1 > >> > linux-f10-expat-2.0.1 > >> > linux-f10-flashplugin-10.0r22 > >> > linux-f10-fontconfig-2.6.0 > >> > linux-f10-gtk2-2.14.7 > >> > linux-f10-jpeg-6b > >> > linux-f10-libssh2-0.18 > >> > linux-f10-nspr-4.7.3 > >> > linux-f10-nss-3.12.2.0 > >> > linux-f10-openssl-0.9.8g > >> > linux-f10-pango-1.22.3 > >> > linux-f10-png-1.2.35 > >> > linux-f10-sqlite3-3.5.9 > >> > linux-f10-tiff-3.8.2 > >> > linux-f10-xorg-libs-7.4 > >> > linux_base-f10-10 > >> > nspluginwrapper-1.2.2_2 > >> > > >> > I deinstalled linux-f8, cleaned compat/linux and reinstalled everything. > >> > >> Assuming it is the issue with missing dependencies for libcurl, we also > >> need port(s) for liblber and libldap since f10's libcurl depends upon > >> them. > > > > liblber is in the same rpm with libldap (I used > > openldap-2.4.12-1.fc10.i386.rpm as I said), and as I said we > > also need libsasl2 (libldap depends on it) which is in > > cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm . > > > >> I had to manually extract a couple of RPM's to get them. Here is > >> the ldd output of libcurl for me: > >> > >> # /compat/linux/bin/sh /compat/linux/usr/bin/ldd /compat/linux/usr/lib/libcurl.so.4.1.1 > >> libidn.so.11 => /lib/libidn.so.11 (0x20073000) > >> libssh2.so.1 => /usr/lib/libssh2.so.1 (0x200a5000) > >> libldap-2.4.so.2 => /usr/lib/libldap-2.4.so.2 (0x200c7000) > >> librt.so.1 => /lib/librt.so.1 (0x20109000) > >> libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x20113000) > >> libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x20141000) > >> libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x201e1000) > >> libcom_err.so.2 => /lib/libcom_err.so.2 (0x20206000) > >> libz.so.1 => /lib/libz.so.1 (0x20209000) > >> libssl3.so => /lib/libssl3.so (0x2021d000) > >> libsmime3.so => /lib/libsmime3.so (0x2024e000) > >> libnss3.so => /lib/libnss3.so (0x20275000) > >> libplds4.so => /lib/libplds4.so (0x203bb000) > >> libplc4.so => /lib/libplc4.so (0x203bf000) > >> libnspr4.so => /lib/libnspr4.so (0x203c4000) > >> libpthread.so.0 => /lib/libpthread.so.0 (0x203fe000) > >> libdl.so.2 => /lib/libdl.so.2 (0x20418000) > >> libc.so.6 => /lib/libc.so.6 (0x2041d000) > >> libssl.so.7 => /lib/libssl.so.7 (0x20596000) > >> libcrypto.so.7 => /lib/libcrypto.so.7 (0x205e1000) > >> liblber-2.4.so.2 => /usr/lib/liblber-2.4.so.2 (0x20735000) > >> libresolv.so.2 => /lib/libresolv.so.2 (0x20744000) > >> libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x2075b000) > >> /lib/ld-linux.so.2 (0x00000000) > >> libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0x20775000) > >> libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x2077f000) > >> libnssutil3.so => /lib/libnssutil3.so (0x20782000) > >> libcrypt.so.1 => /lib/libcrypt.so.1 (0x2079b000) > >> libselinux.so.1 => /lib/libselinux.so.1 (0x207cf000) > > > > Same here with the following ports I just tested here: (thanx to bsam > > for the linux-f10-flashplugin10 port and to Peter Jeremy for the > > original linux-f10-openldap and linux-f10-cyrus-sasl2 ports!) > > > > First a patch for bsd.linux-apps.mk, then the shar, please test > > and comment :) > > Good work! Here are some comments. > > > Index: Mk/bsd.linux-apps.mk > > @@ -70,7 +70,8 @@ > > _LINUX_APPS_ALL+= > > > > # 2.6.16 components > > -_LINUX_26_APPS= libidn libssh2 nspr nss sqlite3 tcl84 tk84 > > +_LINUX_26_APPS= cyrus-sasl2 libidn libssh2 nspr nss openldap \ > > + sqlite3 tcl84 tk84 > > > > _LINUX_APPS_ALL+= ${_LINUX_26_APPS} > > > > @@ -137,6 +138,11 @@ > > curl_DETECT= ${curl${LINUX_DIST_SUFFIX:S/-/_/}_FILE} > > curl_PORT= ${PORTSDIR}/ftp/linux${LINUX_DIST_SUFFIX}-curl > > Since linux-f10 curl requires cyrus-sasl2 and openldap I'd add here: > ----- > . if ${LINUX_DIST_SUFFIX} == "-f10" > curl_DEPENDS=cyrus-sasl2 openldap > . endif > ----- > > Also apropriate changes should go to ftp/linux-f10-curl port. > Right. > > +# no cyrus-sasl2_FILE, cyrus-sasl2_f8_FILE > > +cyrus-sasl2_f10_FILE= ${LINUXBASE}/usr/lib/libsasl2.so.2.0.22 > > +cyrus-sasl2_DETECT= ${cyrus-sasl2${LINUX_DIST_SUFFIX:S/-/_/}_FILE} > > +cyrus-sasl2_PORT= ${PORTSDIR}/security/linux${LINUX_DIST_SUFFIX}-cyrus-sasl2 > > + > > dri_FILE= ${LINUXBASE}/usr/X11R6/lib/libGL.so.1 > > dri_f8_FILE= ${LINUXBASE}/usr/lib/libGL.so.1 > > dri_f10_FILE= ${LINUXBASE}/usr/lib/libGL.so.1.2 > > @@ -307,6 +313,11 @@ > > mikmod_DETECT= ${mikmod${LINUX_DIST_SUFFIX:S/-/_/}_FILE} > > mikmod_PORT= ${PORTSDIR}/audio/linux${LINUX_DIST_SUFFIX}-mikmod > > > > +# no openldap_FILE, openldap_f8_FILE > > +openldap_f10_FILE= ${LINUXBASE}/usr/lib/libldap-2.4.so.2.2.0 > > +openldap_DETECT= ${openldap${LINUX_DIST_SUFFIX:S/-/_/}_FILE} > > +openldap_PORT= ${PORTSDIR}/net/linux${LINUX_DIST_SUFFIX}-openldap > > + > > openmotif_FILE= ${LINUXBASE}/usr/X11R6/lib/libXm.so.3.0.3 > > openmotif_f8_FILE= ${LINUXBASE}/usr/lib/libXm.so.4.0.2 > > openmotif_f10_FILE= ${LINUXBASE}/usr/X11R6/lib/libXm.so.3.0.3 > > > > # This is a shell archive. Save it in a file, remove anything before > > # this line, and then unpack it by entering "sh file". Note, it may > > # create directories; files and directories will be owned by you and > > # have default permissions. > > # > > # This archive contains: > > # > > # net/linux-f10-openldap/ > > # net/linux-f10-openldap/Makefile > > # net/linux-f10-openldap/distinfo.i386 > > # security/linux-f10-cyrus-sasl2/ > > # security/linux-f10-cyrus-sasl2/Makefile > > # security/linux-f10-cyrus-sasl2/distinfo.i386 > > # www/linux-f10-flashplugin10/ > > # www/linux-f10-flashplugin10/Makefile > > # www/linux-f10-flashplugin10/distinfo > > # www/linux-f10-flashplugin10/pkg-descr > > # www/linux-f10-flashplugin10/pkg-plist > > # > > echo c - net/linux-f10-openldap/ > > mkdir -p net/linux-f10-openldap/ > /dev/null 2>&1 > > echo x - net/linux-f10-openldap/Makefile > > sed 's/^X//' >net/linux-f10-openldap/Makefile << '17a12d65b66950d2cbc504ac86a37255' > > X# New ports collection makefile for: net/linux-f10-openldap > > X# Date created: 2009-06-07 > > X# Whom: peter > > X# > > X# $FreeBSD$ > > X# > > X > > XPORTNAME= openldap > > XPORTVERSION= 2.4.12 > > XCATEGORIES= net linux > > XPKGNAMEPREFIX= linux-f10- > > XDISTNAME= ${PORTNAME}-${PORTVERSION}-${RPMVERSION} > > X > > X.if defined(PACKAGE_BUILDING) > > XSRC_DISTFILES= ${PORTNAME}-${PORTVERSION}-${RPMVERSION}.src.rpm > > XALWAYS_KEEP_DISTFILES= YES > > X.endif > > Well, those <.if, .endif> actually are not needed as bsd.linux-rpm.mk > should itself take care of the case. If it doesn't, please tell me. > Ah, then a bunch of other ports can be changed too... (I guess Peter just went by existing examples :) > > X > > XMAINTAINER= emulation@FreeBSD.org > > XCOMMENT= Lightweight Directory Access Protocol libraries (Linux Fedora 10) > > X > > X#CONFLICTS= > > X > > XUSE_LINUX_RPM= yes > > XLINUX_DIST_VER= 10 > > XRPMVERSION= 1.fc10 > > XUSE_LDCONFIG= yes > > XDESCR= ${.CURDIR}/../openldap24-server/pkg-descr > > X > > XPLIST_DIRS= etc/openldap/cacerts etc/openldap > > I'd say only etc/openldap is needed (see below). > > > XPLIST_FILES= etc/openldap/ldap.conf usr/lib/liblber-2.4.so.2 usr/lib/liblber-2.4.so.2.2.0 usr/lib/libldap-2.4.so.2 usr/lib/libldap-2.4.so.2.2.0 usr/lib/libldap_r-2.4.so.2 usr/lib/libldap_r-2.4.so.2.2.0 > > XDOCSDIR= usr/share/doc/${PORTNAME}-${PORTVERSION} > > XPORTDOCS= ANNOUNCEMENT CHANGES COPYRIGHT LICENSE README > > XMANPREFIX= ${PREFIX}/usr/share > > XMAN5= ldap.conf.5 ldif.5 > > XMANCOMPRESSED= yes > > At my port's propotype I have this: > ----- > # do not install any openldap configuration directories/files > post-extract: > ${RM} -rf ${WRKSRC}/etc > > # use a native openldap configuration directories/files > post-install: > ${LN} -sf ${LOCALBASE}/etc/openldap ${PREFIX}/etc > ----- > > This should work for managing the port via ports system but not with > packages. > Good idea, but actually the post-install target isn't really needed since the linuxolator /compat/linux search magic should already dtrt here. (I.e. if the dir doesn't exits it should fall back to the one outside of /compat/linux.) > > X > > X.include > > 17a12d65b66950d2cbc504ac86a37255 > > echo x - net/linux-f10-openldap/distinfo.i386 > > sed 's/^X//' >net/linux-f10-openldap/distinfo.i386 << 'f422178bbd4668750265f4e584e91c0e' > > XMD5 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = e3ea12058a8cdc54d6f270c802c92a00 > > XSHA256 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = 2a71dcfdbfb1dc9b4e056c951518474d5958147c033f3584dc06e784fd67d567 > > XSIZE (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = 323504 > > The following commands would do the right thing (no src distinfo for > now): > ----- > % cd > % sudo make fetch PACKAGE_BUILDING=YES > % sudo make makesum PACKAGE_BUILDING=YES > ----- > Done. (Actually makesum depends on fetch :) > > f422178bbd4668750265f4e584e91c0e > > echo c - security/linux-f10-cyrus-sasl2/ > > mkdir -p security/linux-f10-cyrus-sasl2/ > /dev/null 2>&1 > > echo x - security/linux-f10-cyrus-sasl2/Makefile > > sed 's/^X//' >security/linux-f10-cyrus-sasl2/Makefile << '4fc58bcf97a8889077c61da23cb55faa' > > X# New ports collection makefile for: security/linux-f10-cyrus-sasl2 > > X# Date created: 2009-06-07 > > X# Whom: peter > > X# > > X# $FreeBSD$ > > X# > > X > > XPORTNAME= cyrus-sasl2 > > XPORTVERSION= 2.1.22 > > XCATEGORIES= security linux > > XPKGNAMEPREFIX= linux-f10- > > XDISTNAME= cyrus-sasl-lib-${PORTVERSION}-${RPMVERSION} > > X > > X.if defined(PACKAGE_BUILDING) > > XSRC_DISTFILES= cyrus-sasl-lib-${PORTVERSION}-${RPMVERSION}.src.rpm > > XALWAYS_KEEP_DISTFILES= YES > > X.endif > > This is not right. I propose to add (somewhere further) instead > of the last four lines: > ----- > SRC_DISTFILES=cyrus-sasl-${PORTVERSION}-${RPMVERSION}.src.rpm > ----- > Done. > > X > > XMAINTAINER= emulation@FreeBSD.org > > XCOMMENT= RFC 2222 SASL (Simple Authentication and Security Layer) (Linux Fedora 10) > > X > > X#CONFLICTS= > > X > > XUSE_LINUX_RPM= yes > > XLINUX_DIST_VER= 10 > > XRPMVERSION= 19.fc10 > > XUSE_LDCONFIG= yes > > XBRANDELF_FILES= usr/sbin/sasldblistusers2 usr/sbin/saslpasswd2 > > XDESCR= ${.CURDIR}/../${PORTNAME}/pkg-descr > > X > > XPLIST_DIRS= etc/sasl2 usr/lib/sasl2 > > XPLIST_FILES= usr/lib/libsasl2.so.2 usr/lib/libsasl2.so.2.0.22 usr/lib/sasl2/libanonymous.so usr/lib/sasl2/libanonymous.so.2 usr/lib/sasl2/libanonymous.so.2.0.22 usr/lib/sasl2/libsasldb.so usr/lib/sasl2/libsasldb.so.2 usr/lib/sasl2/libsasldb.so.2.0.22 usr/sbin/sasldblistusers2 usr/sbin/saslpasswd2 > > XDOCSDIR= usr/share/doc/cyrus-sasl-lib-${PORTVERSION} > > XPORTDOCS= AUTHORS COPYING NEWS README advanced.html appconvert.html components.html gssapi.html index.html install.html macosx.html mechanisms.html options.html plugprog.html programming.html readme.html sysadmin.html upgrading.html windows.html > > X > > X.include > > 4fc58bcf97a8889077c61da23cb55faa > > echo x - security/linux-f10-cyrus-sasl2/distinfo.i386 > > sed 's/^X//' >security/linux-f10-cyrus-sasl2/distinfo.i386 << '9c7e54bf867023e1f8fcaa16319c72f4' > > XMD5 (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = 5a4ee3c84ec9581723fd56b658eec994 > > XSHA256 (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = ae8da4ee07615519c657ddbe3b8c128a2e81f00a4db0da17b7369dabe03ed6d2 > > XSIZE (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = 145305 > > 9c7e54bf867023e1f8fcaa16319c72f4 > > The same comment about distinfo as for net/linux-f10-openldap. > Yup. > > echo c - www/linux-f10-flashplugin10/ > > mkdir -p www/linux-f10-flashplugin10/ > /dev/null 2>&1 > > echo x - www/linux-f10-flashplugin10/Makefile > > sed 's/^X//' >www/linux-f10-flashplugin10/Makefile << '5455d901d257b50d731e64397ea6df2f' > > X# New ports collection makefile for: www/linux-f10-flashplugin10 > > This port should be probably first repocopied from > www/linux-f8-flashplugin10 and then committed. > True... I'll do the PR. > > X# Date created: 2009-06-26 > > X# Whom: bsam > > X# Based on: www/linux-f8-flashplugin10 by nox@ > > X# > > X# $FreeBSD$ > > X# > > X > > XPORTNAME= flashplugin > > XPORTVERSION= 10.0r22 > > XCATEGORIES= www multimedia linux > > XMASTER_SITES= http://fpdownload.macromedia.com/get/flashplayer/current/:plugin \ > > X ftp://ftp.ipt.ru/pub/download/:suplib > > XPKGNAMEPREFIX= linux-f10- > > XDISTFILES= install_flash_player_10_linux.tar.gz:plugin \ > > X linux-f10-flashsupport-9.0.1.i386.tar.gz:suplib > > XDIST_SUBDIR= ${PORTNAME}/${PORTVERSION} > > X > > XMAINTAINER= emulation@FreeBSD.org > > XCOMMENT= Adobe Flash Player NPAPI Plugin > > X > > XONLY_FOR_ARCHS= amd64 i386 > > XUSE_LINUX= yes > > XUSE_LINUX_APPS= openssl curl cyrus-sasl2 libssh2 nspr nss openldap > > X > > XRESTRICTED= Redistribution not allowed > > XRESTRICTED_FILES= ${DISTFILES:Nlinux-f10-flashsupport*:C/:[^:]+$//} > > X > > XNO_BUILD= yes > > XWRKSRC= ${WRKDIR}/install_flash_player_10_linux > > X > > XUSE_NPAPI= linux-* > > XNPAPI_FILES= libflashplayer.so > > X > > XCONFLICTS= linux-flashplugin-7* linux-flashplugin-9* linux-f8-flashplugin10-* > > X > > Xpost-install: > > X @${INSTALL_PROGRAM} ${WRKDIR}/libflashsupport.so ${LINUXBASE}/usr/lib > > X > > X.include > > X.include "${PORTSDIR}/www/linux-mplayer-plugin/Makefile.npapi" > > X.include > > 5455d901d257b50d731e64397ea6df2f > > echo x - www/linux-f10-flashplugin10/distinfo > > sed 's/^X//' >www/linux-f10-flashplugin10/distinfo << '1f552e2e0c05a396106217e48ff92103' > > XMD5 (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = 23e4c2b844db0f87ff62084178aa2b1f > > XSHA256 (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = cd29f166c87fecc943e88fe951bb61c56728fab12b4bf343badafa73ea95394e > > XSIZE (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = 3994294 > > XMD5 (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 6e416c81497f65065d78dae1e0acad0d > > XSHA256 (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 4a309b1a326bd2212cc72480628659e5a7fd61d9e0572cb7350c206f030955bf > > XSIZE (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 3455 > > 1f552e2e0c05a396106217e48ff92103 > > echo x - www/linux-f10-flashplugin10/pkg-descr > > sed 's/^X//' >www/linux-f10-flashplugin10/pkg-descr << '57a1420ff5e8cb1b77c71ecb3a15c599' > > XThis is the official Flash Player from Adobe. This plugin enables > > Xyou to see .swf and .spl files on the 'net from your Opera, Mozilla or > > XFirefox sessions. > > X > > XPlease see the Adobe home page for more information. > > X > > XFreeBSD Flash License Agreement: > > X http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/96374 > > X > > XWWW: http://www.adobe.com/ > > 57a1420ff5e8cb1b77c71ecb3a15c599 > > echo x - www/linux-f10-flashplugin10/pkg-plist > > sed 's/^X//' >www/linux-f10-flashplugin10/pkg-plist << '9254ee58cdc375ce93f8fc3b1afc9e77' > > X@cwd /compat/linux > > Xusr/lib/libflashsupport.so > > X@cwd > > 9254ee58cdc375ce93f8fc3b1afc9e77 > > exit > > There may be something more, but I don't see it right now. Thanks for > all involved! It's a good team work. New patch and shar below: Index: Mk/bsd.linux-apps.mk @@ -70,7 +70,8 @@ _LINUX_APPS_ALL+= # 2.6.16 components -_LINUX_26_APPS= libidn libssh2 nspr nss sqlite3 tcl84 tk84 +_LINUX_26_APPS= cyrus-sasl2 libidn libssh2 nspr nss openldap \ + sqlite3 tcl84 tk84 _LINUX_APPS_ALL+= ${_LINUX_26_APPS} @@ -136,6 +137,14 @@ curl_f10_FILE= ${LINUXBASE}/usr/lib/libcurl.so.4.1.1 curl_DETECT= ${curl${LINUX_DIST_SUFFIX:S/-/_/}_FILE} curl_PORT= ${PORTSDIR}/ftp/linux${LINUX_DIST_SUFFIX}-curl +. if ${LINUX_DIST_SUFFIX} == "-f10" +curl_DEPENDS= cyrus-sasl2 openldap +. endif + +# no cyrus-sasl2_FILE, cyrus-sasl2_f8_FILE +cyrus-sasl2_f10_FILE= ${LINUXBASE}/usr/lib/libsasl2.so.2.0.22 +cyrus-sasl2_DETECT= ${cyrus-sasl2${LINUX_DIST_SUFFIX:S/-/_/}_FILE} +cyrus-sasl2_PORT= ${PORTSDIR}/security/linux${LINUX_DIST_SUFFIX}-cyrus-sasl2 dri_FILE= ${LINUXBASE}/usr/X11R6/lib/libGL.so.1 dri_f8_FILE= ${LINUXBASE}/usr/lib/libGL.so.1 @@ -307,6 +316,11 @@ mikmod_DETECT= ${mikmod${LINUX_DIST_SUFFIX:S/-/_/}_FILE} mikmod_PORT= ${PORTSDIR}/audio/linux${LINUX_DIST_SUFFIX}-mikmod +# no openldap_FILE, openldap_f8_FILE +openldap_f10_FILE= ${LINUXBASE}/usr/lib/libldap-2.4.so.2.2.0 +openldap_DETECT= ${openldap${LINUX_DIST_SUFFIX:S/-/_/}_FILE} +openldap_PORT= ${PORTSDIR}/net/linux${LINUX_DIST_SUFFIX}-openldap + openmotif_FILE= ${LINUXBASE}/usr/X11R6/lib/libXm.so.3.0.3 openmotif_f8_FILE= ${LINUXBASE}/usr/lib/libXm.so.4.0.2 openmotif_f10_FILE= ${LINUXBASE}/usr/X11R6/lib/libXm.so.3.0.3 Index: ftp/linux-f10-curl/Makefile @@ -24,6 +24,7 @@ CONFLICTS= linux-curl-[0-9]* linux-f8-curl-[0-9]* USE_LINUX_RPM= yes +USE_LINUX_APPS= cyrus-sasl2 openldap LINUX_DIST_VER= 10 RPMVERSION= 5.fc10 USE_LDCONFIG= yes # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # net/linux-f10-openldap/ # net/linux-f10-openldap/Makefile # net/linux-f10-openldap/distinfo.i386 # security/linux-f10-cyrus-sasl2/ # security/linux-f10-cyrus-sasl2/Makefile # security/linux-f10-cyrus-sasl2/distinfo.i386 # www/linux-f10-flashplugin10/ # www/linux-f10-flashplugin10/Makefile # www/linux-f10-flashplugin10/distinfo # www/linux-f10-flashplugin10/pkg-descr # www/linux-f10-flashplugin10/pkg-plist # echo c - net/linux-f10-openldap/ mkdir -p net/linux-f10-openldap/ > /dev/null 2>&1 echo x - net/linux-f10-openldap/Makefile sed 's/^X//' >net/linux-f10-openldap/Makefile << '17a12d65b66950d2cbc504ac86a37255' X# New ports collection makefile for: net/linux-f10-openldap X# Date created: 2009-06-07 X# Whom: peter X# X# $FreeBSD$ X# X XPORTNAME= openldap XPORTVERSION= 2.4.12 XCATEGORIES= net linux XPKGNAMEPREFIX= linux-f10- XDISTNAME= ${PORTNAME}-${PORTVERSION}-${RPMVERSION} X XSRC_DISTFILES= ${PORTNAME}-${PORTVERSION}-${RPMVERSION}.src.rpm X XMAINTAINER= emulation@FreeBSD.org XCOMMENT= Lightweight Directory Access Protocol libraries (Linux Fedora 10) X X#CONFLICTS= X XUSE_LINUX_RPM= yes XLINUX_DIST_VER= 10 XRPMVERSION= 1.fc10 XUSE_LDCONFIG= yes XDESCR= ${.CURDIR}/../openldap24-server/pkg-descr X XPLIST_FILES= etc/openldap/ldap.conf usr/lib/liblber-2.4.so.2 usr/lib/liblber-2.4.so.2.2.0 usr/lib/libldap-2.4.so.2 usr/lib/libldap-2.4.so.2.2.0 usr/lib/libldap_r-2.4.so.2 usr/lib/libldap_r-2.4.so.2.2.0 XDOCSDIR= usr/share/doc/${PORTNAME}-${PORTVERSION} XPORTDOCS= ANNOUNCEMENT CHANGES COPYRIGHT LICENSE README XMANPREFIX= ${PREFIX}/usr/share XMAN5= ldap.conf.5 ldif.5 XMANCOMPRESSED= yes X X# do not install any openldap configuration directories/files Xpost-extract: X ${RM} -rf ${WRKSRC}/etc X X.include 17a12d65b66950d2cbc504ac86a37255 echo x - net/linux-f10-openldap/distinfo.i386 sed 's/^X//' >net/linux-f10-openldap/distinfo.i386 << 'f422178bbd4668750265f4e584e91c0e' XMD5 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = e3ea12058a8cdc54d6f270c802c92a00 XSHA256 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = 2a71dcfdbfb1dc9b4e056c951518474d5958147c033f3584dc06e784fd67d567 XSIZE (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = 323504 XMD5 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.src.rpm) = f28ec039fad4f81abc6df09c5542bdaa XSHA256 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.src.rpm) = 84bff280805bf046849d96ba80bd6b0d0da895da07f0e6d6efde2667b4ff1e1c XSIZE (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.src.rpm) = 16905121 f422178bbd4668750265f4e584e91c0e echo c - security/linux-f10-cyrus-sasl2/ mkdir -p security/linux-f10-cyrus-sasl2/ > /dev/null 2>&1 echo x - security/linux-f10-cyrus-sasl2/Makefile sed 's/^X//' >security/linux-f10-cyrus-sasl2/Makefile << '4fc58bcf97a8889077c61da23cb55faa' X# New ports collection makefile for: security/linux-f10-cyrus-sasl2 X# Date created: 2009-06-07 X# Whom: peter X# X# $FreeBSD$ X# X XPORTNAME= cyrus-sasl2 XPORTVERSION= 2.1.22 XCATEGORIES= security linux XPKGNAMEPREFIX= linux-f10- XDISTNAME= cyrus-sasl-lib-${PORTVERSION}-${RPMVERSION} X XSRC_DISTFILES= cyrus-sasl-${PORTVERSION}-${RPMVERSION}.src.rpm X XMAINTAINER= emulation@FreeBSD.org XCOMMENT= RFC 2222 SASL (Simple Authentication and Security Layer) (Linux Fedora 10) X X#CONFLICTS= X XUSE_LINUX_RPM= yes XLINUX_DIST_VER= 10 XRPMVERSION= 19.fc10 XUSE_LDCONFIG= yes XBRANDELF_FILES= usr/sbin/sasldblistusers2 usr/sbin/saslpasswd2 XDESCR= ${.CURDIR}/../${PORTNAME}/pkg-descr X XPLIST_DIRS= etc/sasl2 usr/lib/sasl2 XPLIST_FILES= usr/lib/libsasl2.so.2 usr/lib/libsasl2.so.2.0.22 usr/lib/sasl2/libanonymous.so usr/lib/sasl2/libanonymous.so.2 usr/lib/sasl2/libanonymous.so.2.0.22 usr/lib/sasl2/libsasldb.so usr/lib/sasl2/libsasldb.so.2 usr/lib/sasl2/libsasldb.so.2.0.22 usr/sbin/sasldblistusers2 usr/sbin/saslpasswd2 XDOCSDIR= usr/share/doc/cyrus-sasl-lib-${PORTVERSION} XPORTDOCS= AUTHORS COPYING NEWS README advanced.html appconvert.html components.html gssapi.html index.html install.html macosx.html mechanisms.html options.html plugprog.html programming.html readme.html sysadmin.html upgrading.html windows.html X X.include 4fc58bcf97a8889077c61da23cb55faa echo x - security/linux-f10-cyrus-sasl2/distinfo.i386 sed 's/^X//' >security/linux-f10-cyrus-sasl2/distinfo.i386 << '9c7e54bf867023e1f8fcaa16319c72f4' XMD5 (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = 5a4ee3c84ec9581723fd56b658eec994 XSHA256 (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = ae8da4ee07615519c657ddbe3b8c128a2e81f00a4db0da17b7369dabe03ed6d2 XSIZE (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = 145305 XMD5 (rpm/i386/fedora/10/cyrus-sasl-2.1.22-19.fc10.src.rpm) = f66997139328e0446b1635b4c59c5cd4 XSHA256 (rpm/i386/fedora/10/cyrus-sasl-2.1.22-19.fc10.src.rpm) = 70f087f10f7a6c62a30befadef9904c03543aa20ae890889b2a08a04382e6963 XSIZE (rpm/i386/fedora/10/cyrus-sasl-2.1.22-19.fc10.src.rpm) = 1661687 9c7e54bf867023e1f8fcaa16319c72f4 echo c - www/linux-f10-flashplugin10/ mkdir -p www/linux-f10-flashplugin10/ > /dev/null 2>&1 echo x - www/linux-f10-flashplugin10/Makefile sed 's/^X//' >www/linux-f10-flashplugin10/Makefile << '5455d901d257b50d731e64397ea6df2f' X# New ports collection makefile for: www/linux-f10-flashplugin10 X# Date created: 2009-06-26 X# Whom: bsam X# Based on: www/linux-f8-flashplugin10 by nox@ X# X# $FreeBSD$ X# X XPORTNAME= flashplugin XPORTVERSION= 10.0r22 XCATEGORIES= www multimedia linux XMASTER_SITES= http://fpdownload.macromedia.com/get/flashplayer/current/:plugin \ X ftp://ftp.ipt.ru/pub/download/:suplib XPKGNAMEPREFIX= linux-f10- XDISTFILES= install_flash_player_10_linux.tar.gz:plugin \ X linux-f10-flashsupport-9.0.1.i386.tar.gz:suplib XDIST_SUBDIR= ${PORTNAME}/${PORTVERSION} X XMAINTAINER= emulation@FreeBSD.org XCOMMENT= Adobe Flash Player NPAPI Plugin X XONLY_FOR_ARCHS= amd64 i386 XUSE_LINUX= yes XUSE_LINUX_APPS= openssl curl cyrus-sasl2 libssh2 nspr nss openldap X XRESTRICTED= Redistribution not allowed XRESTRICTED_FILES= ${DISTFILES:Nlinux-f10-flashsupport*:C/:[^:]+$//} X XNO_BUILD= yes XWRKSRC= ${WRKDIR}/install_flash_player_10_linux X XUSE_NPAPI= linux-* XNPAPI_FILES= libflashplayer.so X XCONFLICTS= linux-flashplugin-7* linux-flashplugin-9* linux-f8-flashplugin10-* X Xpost-install: X @${INSTALL_PROGRAM} ${WRKDIR}/libflashsupport.so ${LINUXBASE}/usr/lib X X.include X.include "${PORTSDIR}/www/linux-mplayer-plugin/Makefile.npapi" X.include 5455d901d257b50d731e64397ea6df2f echo x - www/linux-f10-flashplugin10/distinfo sed 's/^X//' >www/linux-f10-flashplugin10/distinfo << '1f552e2e0c05a396106217e48ff92103' XMD5 (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = 23e4c2b844db0f87ff62084178aa2b1f XSHA256 (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = cd29f166c87fecc943e88fe951bb61c56728fab12b4bf343badafa73ea95394e XSIZE (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = 3994294 XMD5 (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 6e416c81497f65065d78dae1e0acad0d XSHA256 (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 4a309b1a326bd2212cc72480628659e5a7fd61d9e0572cb7350c206f030955bf XSIZE (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 3455 1f552e2e0c05a396106217e48ff92103 echo x - www/linux-f10-flashplugin10/pkg-descr sed 's/^X//' >www/linux-f10-flashplugin10/pkg-descr << '57a1420ff5e8cb1b77c71ecb3a15c599' XThis is the official Flash Player from Adobe. This plugin enables Xyou to see .swf and .spl files on the 'net from your Opera, Mozilla or XFirefox sessions. X XPlease see the Adobe home page for more information. X XFreeBSD Flash License Agreement: X http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/96374 X XWWW: http://www.adobe.com/ 57a1420ff5e8cb1b77c71ecb3a15c599 echo x - www/linux-f10-flashplugin10/pkg-plist sed 's/^X//' >www/linux-f10-flashplugin10/pkg-plist << '9254ee58cdc375ce93f8fc3b1afc9e77' X@cwd /compat/linux Xusr/lib/libflashsupport.so X@cwd 9254ee58cdc375ce93f8fc3b1afc9e77 exit From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 08:29:05 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FB2F10656C4; Sun, 28 Jun 2009 08:29:05 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id AE3CE8FC08; Sun, 28 Jun 2009 08:29:04 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 63C821E0021A; Sun, 28 Jun 2009 10:29:03 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5S8R2D4035168; Sun, 28 Jun 2009 10:27:02 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5S8R2QA035167; Sun, 28 Jun 2009 10:27:02 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 28 Jun 2009 10:27:02 +0200 To: Boris Samorodov Message-ID: <20090628082701.GA34665@triton.kn-bremen.de> References: <20090606162235.GA49444@triton.kn-bremen.de> <43784537@ipt.ru> <66988167@ipt.ru> <747dc8f30906261255s1ecc1420x574ded3be835b448@mail.gmail.com> <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <88413085@ipt.ru> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Mon, 29 Jun 2009 00:52:40 +0000 Cc: Renato Botelho , freebsd-emulation@FreeBSD.org, freebsd-current@FreeBSD.org, Juergen Lock , "Sean C. Farley" Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 08:29:05 -0000 On Sun, Jun 28, 2009 at 02:36:02AM +0400, Boris Samorodov wrote: > Juergen Lock writes: > > On Sat, Jun 27, 2009 at 08:10:10PM +0400, Boris Samorodov wrote: > >> Juergen Lock writes: > > >> > X# New ports collection makefile for: net/linux-f10-openldap > >> > X# Date created: 2009-06-07 > >> > X# Whom: peter > >> > X# > >> > X# $FreeBSD$ > >> > X# > >> > X > >> > XPORTNAME= openldap > >> > XPORTVERSION= 2.4.12 > >> > XCATEGORIES= net linux > >> > XPKGNAMEPREFIX= linux-f10- > >> > XDISTNAME= ${PORTNAME}-${PORTVERSION}-${RPMVERSION} > >> > X > >> > X.if defined(PACKAGE_BUILDING) > >> > XSRC_DISTFILES= ${PORTNAME}-${PORTVERSION}-${RPMVERSION}.src.rpm > >> > XALWAYS_KEEP_DISTFILES= YES > >> > X.endif > >> > >> Well, those <.if, .endif> actually are not needed as bsd.linux-rpm.mk > >> should itself take care of the case. If it doesn't, please tell me. > >> > > Ah, then a bunch of other ports can be changed too... (I guess Peter > > just went by existing examples :) > > I should have been more verbose here. The whole if-endif case was > not needed because SRC_DISTFILES=${DISTNAME}.src.rpm. This is true for > net/linux-f10-openldap. But for security/linux-f10-cyrus-sasl2 it is not > true and SRC_DISTFILES should be defined at Makefile. > Aah, okay. :) > >> > X > >> > XMAINTAINER= emulation@FreeBSD.org > >> > XCOMMENT= Lightweight Directory Access Protocol libraries (Linux Fedora 10) > >> > X > >> > X#CONFLICTS= > >> > X > >> > XUSE_LINUX_RPM= yes > >> > XLINUX_DIST_VER= 10 > >> > XRPMVERSION= 1.fc10 > >> > XUSE_LDCONFIG= yes > >> > XDESCR= ${.CURDIR}/../openldap24-server/pkg-descr > >> > X > >> > XPLIST_DIRS= etc/openldap/cacerts etc/openldap > >> > >> I'd say only etc/openldap is needed (see below). > >> > >> > XPLIST_FILES= etc/openldap/ldap.conf usr/lib/liblber-2.4.so.2 usr/lib/liblber-2.4.so.2.2.0 usr/lib/libldap-2.4.so.2 usr/lib/libldap-2.4.so.2.2.0 usr/lib/libldap_r-2.4.so.2 usr/lib/libldap_r-2.4.so.2.2.0 > >> > XDOCSDIR= usr/share/doc/${PORTNAME}-${PORTVERSION} > >> > XPORTDOCS= ANNOUNCEMENT CHANGES COPYRIGHT LICENSE README > >> > XMANPREFIX= ${PREFIX}/usr/share > >> > XMAN5= ldap.conf.5 ldif.5 > >> > XMANCOMPRESSED= yes > >> > >> At my port's propotype I have this: > >> ----- > >> # do not install any openldap configuration directories/files > >> post-extract: > >> ${RM} -rf ${WRKSRC}/etc > >> > >> # use a native openldap configuration directories/files > >> post-install: > >> ${LN} -sf ${LOCALBASE}/etc/openldap ${PREFIX}/etc > >> ----- > >> > >> This should work for managing the port via ports system but not with > >> packages. > >> > > Good idea, but actually the post-install target isn't really needed > > since the linuxolator /compat/linux search magic should already dtrt > > here. (I.e. if the dir doesn't exits it should fall back to the one > > outside of /compat/linux.) > > The linuxulator magic will work if a linux program search not > only at /etc/openldap but also at /usr/local/etc/openldap. > I guess it won't happen. > Ooops, indeed, I should have read your patch more closely... > The linuxulator do a search for a /some/path/file at: > . /compat/linux/some/path/file, if not found > . /some/path/file, if not found > . /compat/linux/some/path/file. > > Anyway, we are talking here about correct linux openldap work. > But for the sake of linux-f10-flashplugin10 imho it's not > critical. > Anyway, fixed now. > [...] > > Index: ftp/linux-f10-curl/Makefile > > Seems like PORTREVISION should be bumped. > > [...] I guess you are right. New patch and shar: Index: Mk/bsd.linux-apps.mk @@ -70,7 +70,8 @@ _LINUX_APPS_ALL+= # 2.6.16 components -_LINUX_26_APPS= libidn libssh2 nspr nss sqlite3 tcl84 tk84 +_LINUX_26_APPS= cyrus-sasl2 libidn libssh2 nspr nss openldap \ + sqlite3 tcl84 tk84 _LINUX_APPS_ALL+= ${_LINUX_26_APPS} @@ -136,6 +137,14 @@ curl_f10_FILE= ${LINUXBASE}/usr/lib/libcurl.so.4.1.1 curl_DETECT= ${curl${LINUX_DIST_SUFFIX:S/-/_/}_FILE} curl_PORT= ${PORTSDIR}/ftp/linux${LINUX_DIST_SUFFIX}-curl +. if ${LINUX_DIST_SUFFIX} == "-f10" +curl_DEPENDS= cyrus-sasl2 openldap +. endif + +# no cyrus-sasl2_FILE, cyrus-sasl2_f8_FILE +cyrus-sasl2_f10_FILE= ${LINUXBASE}/usr/lib/libsasl2.so.2.0.22 +cyrus-sasl2_DETECT= ${cyrus-sasl2${LINUX_DIST_SUFFIX:S/-/_/}_FILE} +cyrus-sasl2_PORT= ${PORTSDIR}/security/linux${LINUX_DIST_SUFFIX}-cyrus-sasl2 dri_FILE= ${LINUXBASE}/usr/X11R6/lib/libGL.so.1 dri_f8_FILE= ${LINUXBASE}/usr/lib/libGL.so.1 @@ -307,6 +316,11 @@ mikmod_DETECT= ${mikmod${LINUX_DIST_SUFFIX:S/-/_/}_FILE} mikmod_PORT= ${PORTSDIR}/audio/linux${LINUX_DIST_SUFFIX}-mikmod +# no openldap_FILE, openldap_f8_FILE +openldap_f10_FILE= ${LINUXBASE}/usr/lib/libldap-2.4.so.2.2.0 +openldap_DETECT= ${openldap${LINUX_DIST_SUFFIX:S/-/_/}_FILE} +openldap_PORT= ${PORTSDIR}/net/linux${LINUX_DIST_SUFFIX}-openldap + openmotif_FILE= ${LINUXBASE}/usr/X11R6/lib/libXm.so.3.0.3 openmotif_f8_FILE= ${LINUXBASE}/usr/lib/libXm.so.4.0.2 openmotif_f10_FILE= ${LINUXBASE}/usr/X11R6/lib/libXm.so.3.0.3 --- ftp/linux-f10-curl/Makefile.1 2009-06-27 22:55:17.000000000 +0200 +++ ftp/linux-f10-curl/Makefile 2009-06-28 10:14:22.000000000 +0200 @@ -7,7 +7,7 @@ PORTNAME= curl PORTVERSION= 7.19.4 -PORTREVISION= 1 +PORTREVISION= 2 CATEGORIES= ftp linux PKGNAMEPREFIX= linux-f10- DISTFILES= curl-${PORTVERSION}-${RPMVERSION}.i386.rpm \ @@ -24,6 +24,7 @@ CONFLICTS= linux-curl-[0-9]* linux-f8-curl-[0-9]* USE_LINUX_RPM= yes +USE_LINUX_APPS= cyrus-sasl2 openldap LINUX_DIST_VER= 10 RPMVERSION= 5.fc10 USE_LDCONFIG= yes # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # net/linux-f10-openldap/ # net/linux-f10-openldap/Makefile # net/linux-f10-openldap/distinfo.i386 # security/linux-f10-cyrus-sasl2/ # security/linux-f10-cyrus-sasl2/Makefile # security/linux-f10-cyrus-sasl2/distinfo.i386 # www/linux-f10-flashplugin10/ # www/linux-f10-flashplugin10/Makefile # www/linux-f10-flashplugin10/distinfo # www/linux-f10-flashplugin10/pkg-descr # www/linux-f10-flashplugin10/pkg-plist # echo c - net/linux-f10-openldap/ mkdir -p net/linux-f10-openldap/ > /dev/null 2>&1 echo x - net/linux-f10-openldap/Makefile sed 's/^X//' >net/linux-f10-openldap/Makefile << '17a12d65b66950d2cbc504ac86a37255' X# New ports collection makefile for: net/linux-f10-openldap X# Date created: 2009-06-07 X# Whom: peter X# X# $FreeBSD$ X# X XPORTNAME= openldap XPORTVERSION= 2.4.12 XCATEGORIES= net linux XPKGNAMEPREFIX= linux-f10- XDISTNAME= ${PORTNAME}-${PORTVERSION}-${RPMVERSION} X XMAINTAINER= emulation@FreeBSD.org XCOMMENT= Lightweight Directory Access Protocol libraries (Linux Fedora 10) X X#CONFLICTS= X XUSE_LINUX_RPM= yes XLINUX_DIST_VER= 10 XRPMVERSION= 1.fc10 XUSE_LDCONFIG= yes XDESCR= ${.CURDIR}/../openldap24-server/pkg-descr X XPLIST_FILES= usr/lib/liblber-2.4.so.2 usr/lib/liblber-2.4.so.2.2.0 usr/lib/libldap-2.4.so.2 usr/lib/libldap-2.4.so.2.2.0 usr/lib/libldap_r-2.4.so.2 usr/lib/libldap_r-2.4.so.2.2.0 XDOCSDIR= usr/share/doc/${PORTNAME}-${PORTVERSION} XPORTDOCS= ANNOUNCEMENT CHANGES COPYRIGHT LICENSE README XMANPREFIX= ${PREFIX}/usr/share XMAN5= ldap.conf.5 ldif.5 XMANCOMPRESSED= yes X X# do not install any openldap configuration directories/files Xpost-extract: X ${RM} -rf ${WRKSRC}/etc X X# use a native openldap configuration directories/files Xpost-install: X ${LN} -sf ${LOCALBASE}/etc/openldap ${PREFIX}/etc X X.include 17a12d65b66950d2cbc504ac86a37255 echo x - net/linux-f10-openldap/distinfo.i386 sed 's/^X//' >net/linux-f10-openldap/distinfo.i386 << 'f422178bbd4668750265f4e584e91c0e' XMD5 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = e3ea12058a8cdc54d6f270c802c92a00 XSHA256 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = 2a71dcfdbfb1dc9b4e056c951518474d5958147c033f3584dc06e784fd67d567 XSIZE (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.i386.rpm) = 323504 XMD5 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.src.rpm) = f28ec039fad4f81abc6df09c5542bdaa XSHA256 (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.src.rpm) = 84bff280805bf046849d96ba80bd6b0d0da895da07f0e6d6efde2667b4ff1e1c XSIZE (rpm/i386/fedora/10/openldap-2.4.12-1.fc10.src.rpm) = 16905121 f422178bbd4668750265f4e584e91c0e echo c - security/linux-f10-cyrus-sasl2/ mkdir -p security/linux-f10-cyrus-sasl2/ > /dev/null 2>&1 echo x - security/linux-f10-cyrus-sasl2/Makefile sed 's/^X//' >security/linux-f10-cyrus-sasl2/Makefile << '4fc58bcf97a8889077c61da23cb55faa' X# New ports collection makefile for: security/linux-f10-cyrus-sasl2 X# Date created: 2009-06-07 X# Whom: peter X# X# $FreeBSD$ X# X XPORTNAME= cyrus-sasl2 XPORTVERSION= 2.1.22 XCATEGORIES= security linux XPKGNAMEPREFIX= linux-f10- XDISTNAME= cyrus-sasl-lib-${PORTVERSION}-${RPMVERSION} X XSRC_DISTFILES= cyrus-sasl-${PORTVERSION}-${RPMVERSION}.src.rpm X XMAINTAINER= emulation@FreeBSD.org XCOMMENT= RFC 2222 SASL (Simple Authentication and Security Layer) (Linux Fedora 10) X X#CONFLICTS= X XUSE_LINUX_RPM= yes XLINUX_DIST_VER= 10 XRPMVERSION= 19.fc10 XUSE_LDCONFIG= yes XBRANDELF_FILES= usr/sbin/sasldblistusers2 usr/sbin/saslpasswd2 XDESCR= ${.CURDIR}/../${PORTNAME}/pkg-descr X XPLIST_DIRS= etc/sasl2 usr/lib/sasl2 XPLIST_FILES= usr/lib/libsasl2.so.2 usr/lib/libsasl2.so.2.0.22 usr/lib/sasl2/libanonymous.so usr/lib/sasl2/libanonymous.so.2 usr/lib/sasl2/libanonymous.so.2.0.22 usr/lib/sasl2/libsasldb.so usr/lib/sasl2/libsasldb.so.2 usr/lib/sasl2/libsasldb.so.2.0.22 usr/sbin/sasldblistusers2 usr/sbin/saslpasswd2 XDOCSDIR= usr/share/doc/cyrus-sasl-lib-${PORTVERSION} XPORTDOCS= AUTHORS COPYING NEWS README advanced.html appconvert.html components.html gssapi.html index.html install.html macosx.html mechanisms.html options.html plugprog.html programming.html readme.html sysadmin.html upgrading.html windows.html X X.include 4fc58bcf97a8889077c61da23cb55faa echo x - security/linux-f10-cyrus-sasl2/distinfo.i386 sed 's/^X//' >security/linux-f10-cyrus-sasl2/distinfo.i386 << '9c7e54bf867023e1f8fcaa16319c72f4' XMD5 (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = 5a4ee3c84ec9581723fd56b658eec994 XSHA256 (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = ae8da4ee07615519c657ddbe3b8c128a2e81f00a4db0da17b7369dabe03ed6d2 XSIZE (rpm/i386/fedora/10/cyrus-sasl-lib-2.1.22-19.fc10.i386.rpm) = 145305 XMD5 (rpm/i386/fedora/10/cyrus-sasl-2.1.22-19.fc10.src.rpm) = f66997139328e0446b1635b4c59c5cd4 XSHA256 (rpm/i386/fedora/10/cyrus-sasl-2.1.22-19.fc10.src.rpm) = 70f087f10f7a6c62a30befadef9904c03543aa20ae890889b2a08a04382e6963 XSIZE (rpm/i386/fedora/10/cyrus-sasl-2.1.22-19.fc10.src.rpm) = 1661687 9c7e54bf867023e1f8fcaa16319c72f4 echo c - www/linux-f10-flashplugin10/ mkdir -p www/linux-f10-flashplugin10/ > /dev/null 2>&1 echo x - www/linux-f10-flashplugin10/Makefile sed 's/^X//' >www/linux-f10-flashplugin10/Makefile << '5455d901d257b50d731e64397ea6df2f' X# New ports collection makefile for: www/linux-f10-flashplugin10 X# Date created: 2009-06-26 X# Whom: bsam X# Based on: www/linux-f8-flashplugin10 by nox@ X# X# $FreeBSD$ X# X XPORTNAME= flashplugin XPORTVERSION= 10.0r22 XCATEGORIES= www multimedia linux XMASTER_SITES= http://fpdownload.macromedia.com/get/flashplayer/current/:plugin \ X ftp://ftp.ipt.ru/pub/download/:suplib XPKGNAMEPREFIX= linux-f10- XDISTFILES= install_flash_player_10_linux.tar.gz:plugin \ X linux-f10-flashsupport-9.0.1.i386.tar.gz:suplib XDIST_SUBDIR= ${PORTNAME}/${PORTVERSION} X XMAINTAINER= emulation@FreeBSD.org XCOMMENT= Adobe Flash Player NPAPI Plugin X XONLY_FOR_ARCHS= amd64 i386 XUSE_LINUX= yes XUSE_LINUX_APPS= openssl curl cyrus-sasl2 libssh2 nspr nss openldap X XRESTRICTED= Redistribution not allowed XRESTRICTED_FILES= ${DISTFILES:Nlinux-f10-flashsupport*:C/:[^:]+$//} X XNO_BUILD= yes XWRKSRC= ${WRKDIR}/install_flash_player_10_linux X XUSE_NPAPI= linux-* XNPAPI_FILES= libflashplayer.so X XCONFLICTS= linux-flashplugin-7* linux-flashplugin-9* linux-f8-flashplugin10-* X Xpost-install: X @${INSTALL_PROGRAM} ${WRKDIR}/libflashsupport.so ${LINUXBASE}/usr/lib X X.include X.include "${PORTSDIR}/www/linux-mplayer-plugin/Makefile.npapi" X.include 5455d901d257b50d731e64397ea6df2f echo x - www/linux-f10-flashplugin10/distinfo sed 's/^X//' >www/linux-f10-flashplugin10/distinfo << '1f552e2e0c05a396106217e48ff92103' XMD5 (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = 23e4c2b844db0f87ff62084178aa2b1f XSHA256 (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = cd29f166c87fecc943e88fe951bb61c56728fab12b4bf343badafa73ea95394e XSIZE (flashplugin/10.0r22/install_flash_player_10_linux.tar.gz) = 3994294 XMD5 (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 6e416c81497f65065d78dae1e0acad0d XSHA256 (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 4a309b1a326bd2212cc72480628659e5a7fd61d9e0572cb7350c206f030955bf XSIZE (flashplugin/10.0r22/linux-f10-flashsupport-9.0.1.i386.tar.gz) = 3455 1f552e2e0c05a396106217e48ff92103 echo x - www/linux-f10-flashplugin10/pkg-descr sed 's/^X//' >www/linux-f10-flashplugin10/pkg-descr << '57a1420ff5e8cb1b77c71ecb3a15c599' XThis is the official Flash Player from Adobe. This plugin enables Xyou to see .swf and .spl files on the 'net from your Opera, Mozilla or XFirefox sessions. X XPlease see the Adobe home page for more information. X XFreeBSD Flash License Agreement: X http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/96374 X XWWW: http://www.adobe.com/ 57a1420ff5e8cb1b77c71ecb3a15c599 echo x - www/linux-f10-flashplugin10/pkg-plist sed 's/^X//' >www/linux-f10-flashplugin10/pkg-plist << '9254ee58cdc375ce93f8fc3b1afc9e77' X@cwd /compat/linux Xusr/lib/libflashsupport.so X@cwd 9254ee58cdc375ce93f8fc3b1afc9e77 exit From owner-freebsd-current@FreeBSD.ORG Sun Jun 28 14:25:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98750106564A for ; Sun, 28 Jun 2009 14:25:22 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.digiware.nl [80.255.245.173]) by mx1.freebsd.org (Postfix) with ESMTP id 581068FC19 for ; Sun, 28 Jun 2009 14:25:22 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id EE73C153435; Sun, 28 Jun 2009 16:09:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfmHQlCCRdKS; Sun, 28 Jun 2009 16:09:47 +0200 (CEST) Received: from [192.168.2.10] (vaio [192.168.2.10]) by mail.digiware.nl (Postfix) with ESMTP id D8E6B153434; Sun, 28 Jun 2009 16:09:47 +0200 (CEST) Message-ID: <4A4779AF.1020303@digiware.nl> Date: Sun, 28 Jun 2009 16:09:51 +0200 From: Willem Jan Withagen Organization: Digiware Management User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Aisaka Taiga References: <4A476C7C.3020605@withagen.nl> <4A477576.6030701@haruhiism.net> In-Reply-To: <4A477576.6030701@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 29 Jun 2009 00:53:44 +0000 Cc: current@freebsd.org Subject: Re: 7.2-stable upgrade changes disknames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 14:25:22 -0000 Aisaka Taiga wrote: > Willem Jan Withagen wrote: >> Tried UPGRADING, but could not find any suggestions that this was to >> be expected. Could also not find any previous suggestions for this. >> After which I got complaints that ad0s1a no longer existed. >> Al of a sudden it was called ad0a... >> In essence not a serious problem if one is a little fluent in FreeBSD, >> but could prove a source of a lot of questions, once 8.0 is released. > This isn't related to -current changes. > The naming scheme of ad0s1a refers to a classic DOS partition table with > a FreeBSD slice as DOS partition 0, and the FreeBSD root partition as > the first (a) partition inside the slice. > ad0a device name stands for a dangerously dedicated disk with no > partition table whatsoever; i.e. it's like doing not "fdisk /dev/ad0 ; > bsdlabel {params} /dev/ad0s1", but going "bsdlabel /dev/ad0" without > creating a DOS-style partition table. > > In your case it might mean some data corruption within the partition table. > What does fdisk /dev/ad0 report? You are correct that I installed "dangerously", since I do not want anything else on this disk: Asterbsd# fdisk /dev/ad0 ******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=38792 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=38792 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 0, size 39102336 (19092 Meg), flag 80 (active) beg: cyl 0/ head 0/ sector 1; end: cyl 1023/ head 1/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: But the fstab was also installed by sysinstall from 7.2. So probably you are right that this is not specific a 8.0 problem. On 7.2 this used to work(tm), on 8.0 boot start complaining. So somewhere a (unwanted) flexibility got deleted And I have to manually fix my /etc/fstab to what is factual correct. And that was what my message was about: It can/will(??) bite a lot more users. With similar remarks and/or questions. --WjW From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 01:00:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71FD5106566C for ; Mon, 29 Jun 2009 01:00:49 +0000 (UTC) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 464C38FC08 for ; Mon, 29 Jun 2009 01:00:49 +0000 (UTC) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (kan@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5T10nQG043565 for ; Mon, 29 Jun 2009 01:00:49 GMT (envelope-from kan@freefall.freebsd.org) Received: (from kan@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5T10nAd043558 for current@freebsd.org; Mon, 29 Jun 2009 01:00:49 GMT (envelope-from kan) Date: Mon, 29 Jun 2009 01:00:49 +0000 From: Alexander Kabaev To: current@freebsd.org Message-ID: <20090629010048.GA37786@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: HEADS-UP: hold your updates X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 01:00:49 -0000 Hi, Revision 195151 I committed does break shared libraries and is relatively hard to recover from. Please hold your updates. The fix is being tested and will be committed shortly. -- Alexander Kabaev From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 01:05:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECBD310656A6 for ; Mon, 29 Jun 2009 01:05:11 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id A5D528FC08 for ; Mon, 29 Jun 2009 01:05:11 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: by yxe11 with SMTP id 11so3318054yxe.3 for ; Sun, 28 Jun 2009 18:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ZSx7nuKOFgWMGrjb+Hj6BznGwxhiyr1KyNG4fRrVxsU=; b=kU4P4vYXlhcMUtNJB160gscuMiFmXh9Th8kr5gAl1PjgX7G2pAw44clcUWaAplRAHB XHgSTJlgJ58TTvpczwk/GApecBNC/Sm1M/HfnR+TV4V+kxukkW9zbzUkjBxlEwvuxdPM 1lAVP2H5qytKyh0459n0v9anAZ/BxpFCERtbA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=OaXwzENJEWG/QuJtwSMDWjx511rqmCFUIS01VG/SXpaQtPE7HnSAMCzbjkW0nasBHX rCBWoKtgCX7Ebs1tKsAJXAgusmRPEU500kCrJQXi4YzWzFIUFYn6vDZdZoNKN7vHL17M SQRPVmoPj7t1JaCZ/19Lo1O37cXakoL16oF6c= MIME-Version: 1.0 Received: by 10.151.47.16 with SMTP id z16mr774984ybj.4.1246235858076; Sun, 28 Jun 2009 17:37:38 -0700 (PDT) In-Reply-To: <45d874490906281642r470089e2sc5b770f239f428e2@mail.gmail.com> References: <45d874490906281642r470089e2sc5b770f239f428e2@mail.gmail.com> Date: Sun, 28 Jun 2009 19:37:38 -0500 Message-ID: From: Alan Cox To: "Sean P. Dew" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: segment alignment in AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 01:05:12 -0000 On Sun, Jun 28, 2009 at 6:42 PM, Sean P. Dew wrote: > Hi, > > Why is a loadable segment aligned to 1 MB on AMD64 while the pagezie is > still 4K for a user application. Is there anyway to change it back to 4K, > It > is not making sense to me is because if my file segment is around 400K, we > are wasting 1 MB of virtual address space ( granted it is not a lot for > X64). I am trying to find out the reason. I am posting the readelf output > of a .so. Any help is appreciated. > You'll find this question discussed in the mailing list archives on more than one occasion. Here is one such message: http://lists.freebsd.org/pipermail/freebsd-amd64/2007-September/010260.html To be a little more explicit, it is done to increase the likelihood that the entire code segment of a large program can be mapped using 2 MB page mappings. Moreover, to be able to do so without wasting any physical memory on padding. Although we have the necessary 2 MB page support in the virtual memory system, the kernel's image activator hasn't been modified to take advantage of this. Only a few programs with large code and data segments, e.g., emacs, will benefit. Regards, Alan From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 01:39:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98BC51065670 for ; Mon, 29 Jun 2009 01:39:36 +0000 (UTC) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6BABA8FC0A for ; Mon, 29 Jun 2009 01:39:36 +0000 (UTC) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (kan@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n5T1daET070975 for ; Mon, 29 Jun 2009 01:39:36 GMT (envelope-from kan@freefall.freebsd.org) Received: (from kan@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n5T1dapC070974 for current@freebsd.org; Mon, 29 Jun 2009 01:39:36 GMT (envelope-from kan) Date: Mon, 29 Jun 2009 01:39:36 +0000 From: Alexander Kabaev To: current@freebsd.org Message-ID: <20090629013936.GA70965@freefall.freebsd.org> References: <20090629010048.GA37786@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090629010048.GA37786@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: HEADS-UP: hold your updates X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 01:39:36 -0000 On Mon, Jun 29, 2009 at 01:00:49AM +0000, Alexander Kabaev wrote: > Hi, > > Revision 195151 I committed does break shared libraries and is > relatively hard to recover from. Please hold your updates. > > The fix is being tested and will be committed shortly. > Hi, I backed the change out for the time being. Apologies for the inconvenience. -- Alexander Kabaev From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 01:53:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1384D106566C for ; Mon, 29 Jun 2009 01:53:08 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from tydfam.jp (ns.tydfam.jp [61.197.228.42]) by mx1.freebsd.org (Postfix) with ESMTP id B548A8FC13 for ; Mon, 29 Jun 2009 01:53:07 +0000 (UTC) (envelope-from ken@tydfam.jp) Received: from localhost (tyd3.sub.tydfam.jp [192.168.1.3]) by tydfam.jp (8.14.2/8.14.2) with ESMTP id n5T1r8kv094634; Mon, 29 Jun 2009 10:53:09 +0900 (JST) (envelope-from ken@tydfam.jp) Date: Mon, 29 Jun 2009 10:50:29 +0900 (JST) Message-Id: <20090629.105029.598552788769583654.ken@tydfam.jp> To: pluknet@gmail.com From: ken In-Reply-To: References: <200906252320.32544.doconnor@gsoft.com.au> <20090628.214417.598552788769548331.ken@tydfam.jp> X-Mailer: Mew version 6.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=9.5 tests=ALL_TRUSTED autolearn=failed version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on daemon.sub.tydfam.jp Cc: freebsd-current@freebsd.org, admin@kkip.pl Subject: Re: 8.0-current cannot find disk!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 01:53:08 -0000 Strange, kernel -> kernel.old and kernel is mint compiled one from scratch. And sys/sys/param.h source code used to compile kernel says; #undef __FreeBSD_version #define __FreeBSD_version 800100 /* Master, propagated to newvers */ I think that there are no room to contaminate with 7.2 libraries/modules as far as kernel and its modules concern. From: pluknet > > It points to You might have incompatible kernel modules left after 7.2. > 20090419: > The layout of struct malloc_type, used by modules to register new > memory allocation types, has changed. Most modules will need to > be rebuilt or panics may be experienced. > Bump __FreeBSD_version to 800081. > From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 03:43:55 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B35391065670 for ; Mon, 29 Jun 2009 03:43:55 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6B2378FC13 for ; Mon, 29 Jun 2009 03:43:55 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id DA8E778F7F; Mon, 29 Jun 2009 07:43:52 +0400 (MSD) Message-ID: <4A48388B.8070005@haruhiism.net> Date: Mon, 29 Jun 2009 07:44:11 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Goran Lowkrantz References: <20090628125847.GP48776@hoeg.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Alexander Best , freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 03:43:55 -0000 Goran Lowkrantz wrote: > Clean CURRENT as of this morning, patches: > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1032: error: > 'AHCI_DMA_ENTRIES' undeclared (first use in this function) > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1032: error: (Each > undeclared identifier is reported only once > /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1032: error: for each > function it appears in.) > *** Error code 1 Examining ahci.c, ahci.h, and ata-all.h: appears that AHCI_DMA_ENTRIES is superceded by AHCI_SG_ENTRIES judging by the name of the struct{} and the #define inside it. In ata-all.h: struct ata_ahci_cmd_tab { u_int8_t cfis[64]; u_int8_t acmd[32]; u_int8_t reserved[32]; #define ATA_AHCI_DMA_ENTRIES 64 struct ata_ahci_dma_prd prd_tab[ATA_AHCI_DMA_ENTRIES]; } __packed; In ahci.h: struct ahci_cmd_tab { u_int8_t cfis[64]; u_int8_t acmd[32]; u_int8_t reserved[32]; struct ahci_dma_prd prd_tab[AHCI_SG_ENTRIES]; } __packed; And AHCI_SG_ENTRIES is defined as #define AHCI_SG_ENTRIES (roundup(btoc(MAXPHYS) + 1, 8)) Kernel builds fine for me after "sed 's/AHCI_DMA_ENTRIES/AHCI_SG_ENTRIES/' /usr/src/sys/dev/ahci/ahci.c" (only one occurrence of that macro, aside from the .h file, anyway). -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 04:53:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BABA4106564A; Mon, 29 Jun 2009 04:53:05 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from dglawrence.com (75-148-92-17-Oregon.hfc.comcastbusiness.net [75.148.92.17]) by mx1.freebsd.org (Postfix) with ESMTP id 936088FC0C; Mon, 29 Jun 2009 04:53:05 +0000 (UTC) (envelope-from dg@dglawrence.com) Received: from tnn.dglawrence.com (localhost [127.0.0.1]) by dglawrence.com (8.14.1/8.14.1) with ESMTP id n5T4r5K7093361; Sun, 28 Jun 2009 21:53:05 -0700 (PDT) (envelope-from dg@dglawrence.com) Received: (from dg@localhost) by tnn.dglawrence.com (8.14.1/8.14.1/Submit) id n5T4r4AK093302; Sun, 28 Jun 2009 21:53:04 -0700 (PDT) (envelope-from dg@dglawrence.com) X-Authentication-Warning: tnn.dglawrence.com: dg set sender to dg@dglawrence.com using -f Date: Sun, 28 Jun 2009 21:53:04 -0700 From: David G Lawrence To: Rick Macklem Message-ID: <20090629045304.GI39302@tnn.dglawrence.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (dglawrence.com [127.0.0.1]); Sun, 28 Jun 2009 21:53:05 -0700 (PDT) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 04:53:06 -0000 > I just noticed that when I do the following: > - start a large write to an NFS mounted fs > - network partition the server (unplug a net cable) > - do a "umount -f " on the machine > > that it gets stuck trying to write dirty blocks to the server. > > I had, in the past, assumed that a "umount -f" of an NFS mount would be > used to get rid of an NFS mount on an unresponsive server and that loss > of "writes in progress" would be expected to happen. > > Does that sound correct? (In other words, an I seeing a bug or a > feature?) > > Thanks in advance for any info, rick > ps: I have a simple "fix" if this is a bug, but I wanted to check before > submitting a patch. I would say that you are seeing a bug. -f is supposed to mean "force", of course. Any buffers or outstanding transactions should be terminated immediately. Oh, and most of us know that you, as one of the NFS developers in the past, well-know the difference between hard and soft NFS mounts. ;-) -DG David G. Lawrence President Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500 Pave the road of life with opportunities. From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 04:55:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C2611065670 for ; Mon, 29 Jun 2009 04:55:11 +0000 (UTC) (envelope-from nakaji@jp.FreeBSD.org) Received: from d4407.kankyo-u.ac.jp (unknown [IPv6:2001:3e0:a84:2::2]) by mx1.freebsd.org (Postfix) with ESMTP id CA2378FC1E for ; Mon, 29 Jun 2009 04:55:10 +0000 (UTC) (envelope-from nakaji@jp.FreeBSD.org) Received: from roddy.4407.kankyo-u.ac.jp.kankyo-u.ac.jp (localhost [IPv6:::1]) by d4407.kankyo-u.ac.jp (8.14.3/8.14.3) with ESMTP id n5T4L41B045242; Mon, 29 Jun 2009 13:21:12 +0900 (JST) (envelope-from nakaji@jp.freebsd.org) From: NAKAJI Hiroyuki To: Hans Petter Selasky Organization: Japan FreeBSD User's Group References: <86y6rh1dkh.fsf@ra333.heimat.gr.jp> <200906250927.55432.hselasky@c2i.net> Date: Mon, 29 Jun 2009 13:21:04 +0900 In-Reply-To: <200906250927.55432.hselasky@c2i.net> (Hans Petter Selasky's message of "Thu, 25 Jun 2009 09:27:54 +0200") Message-ID: <87eit3sma7.fsf@roddy.4407.kankyo-u.ac.jp> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org Subject: Re: USB HDD is not detected before /etc/rc starts, and fsck fails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 04:55:11 -0000 >>>>> In <200906250927.55432.hselasky@c2i.net> >>>>> Hans Petter Selasky wrote: > It's not USB's fault. We are already waiting for devices to enumerate (See > Root Mount waiting for messages), but obviously your device is not ready at > the moment the USB is probed. Thanks. I'll check if the device can be ready earlier. -- NAKAJI Hiroyuki From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 05:26:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45A6B106566C for ; Mon, 29 Jun 2009 05:26:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f191.google.com (mail-px0-f191.google.com [209.85.216.191]) by mx1.freebsd.org (Postfix) with ESMTP id 113FC8FC0A for ; Mon, 29 Jun 2009 05:26:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by pxi29 with SMTP id 29so3207256pxi.3 for ; Sun, 28 Jun 2009 22:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=KVXTRH3CqNLh/18hs67SQ54rhV9vvzyKERgihskcQDI=; b=vfP5suoNsBOWbDa/dyhJo8varILqF8eahv1/fHLRytEzaPWyJkL1CNQZ4ixOKQuSh2 s5JSrYyC5kKGW6395yfRsBM+s/03e5m2yITzqifVXSXY+RjQOmJuFjgcC/yM0BgV2cq7 2Xevss9cQycF1tpnQ6/eO4K957+s0Y7ojR28g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=pya5CljLx+1NKcngyZxpB9dS9VFI1DvNzKAFRz1wGF+t10j3hdfZsvSxa9sIAtWaaG 2y4lON86ukoKDn7RJU7xCeRDy9ISuspzxyh0UHG/yi2cR6lQ1eKyigSUZcWvjsDLorpd HS0jL6cPq+o8iAEMoViteqXl2I8xltCmudpOk= Received: by 10.114.168.15 with SMTP id q15mr10924061wae.56.1246253172579; Sun, 28 Jun 2009 22:26:12 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id b39sm18125821rvf.8.2009.06.28.22.26.10 (version=SSLv3 cipher=RC4-MD5); Sun, 28 Jun 2009 22:26:11 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Mon, 29 Jun 2009 14:23:30 +0900 From: Pyun YongHyeon Date: Mon, 29 Jun 2009 14:23:30 +0900 To: current@freebsd.org Message-ID: <20090629052330.GC1268@michelle.cdnetworks.co.kr> References: <20090615121623.GA1479@roadrunner.spoerlein.net> <20090615125154.GG78415@michelle.cdnetworks.co.kr> <20090616093334.GB31709@acme.spoerlein.net> <20090616101740.GI78415@michelle.cdnetworks.co.kr> <20090627171110.GP31709@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090627171110.GP31709@acme.spoerlein.net> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: ale(4): Problems with tso, rxcsum and/or txcsum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 05:26:13 -0000 On Sat, Jun 27, 2009 at 07:11:11PM +0200, Ulrich Sp??rlein wrote: > Sorry for the long delay, I only now got around testing this more > thoroughly. > > On Tue, 16.06.2009 at 19:17:40 +0900, Pyun YongHyeon wrote: > > On Tue, Jun 16, 2009 at 11:33:34AM +0200, Ulrich Sp??rlein wrote: > > > On Mon, 15.06.2009 at 21:51:54 +0900, Pyun YongHyeon wrote: > > > > On Mon, Jun 15, 2009 at 02:16:23PM +0200, Ulrich Sp??rlein wrote: > > > > > Hello Pyun, > > > > > > > > > > I have connection problems with the onboard GigE of an Asus P5Q board, using a recent 8-CURRENT > > > > > > > > > > ale0: port 0xdc00-0xdc7f mem 0xfe9c0000-0xfe9fffff irq 17 at device 0.0 on pci2 > > > > > ale0: 960 Tx FIFO, 1024 Rx FIFO > > > > > ale0: Using 1 MSI messages. > > > > > ale0: 4GB boundary crossed, switching to 32bit DMA addressing mode. > > > > > miibus0: on ale0 > > > > > ale0: Ethernet address: 00:24:8c:36:3e:10 > > > > > ale0: [FILTER] > > > > > ale0: link state changed to UP > > > > > > > > > > ale0@pci0:2:0:0: class=0x020000 card=0x82261043 chip=0x10261969 rev=0xb0 hdr=0x00 > > > > > vendor = 'Attansic (Now owned by Atheros)' > > > > > device = 'PCI-E ETHERNET CONTROLLER (AR8121/AR8113 )' > > > > > class = network > > > > > subclass = ethernet > > > > > > > > > > ale0: flags=8843 metric 0 mtu 1500 > > > > > options=311b > > > > > ether 00:24:8c:36:3e:10 > > > > > inet 192.168.0.146 netmask 0xffffff00 broadcast 192.168.0.255 > > > > > media: Ethernet autoselect (100baseTX ) > > > > > status: active > > > > > > > > > > When transferring data to the machine at ~10MB/s (100Mbit network only) the ssh > > > > > connection will die after a couple of minutes with > > > > > > > > > > Disconnecting: Bad packet length 1592360521. > > > > > > > > > > After disabling tso, txcsum and rxcsum the connection seems to be > > > > > stable, though. I fail to figure out a pattern, though. Do I need to > > > > > > > > Hmm, I think this is the second report that could be related with > > > > Rx checksum offloading. If disabling Rx checksum fix the issue, I > > > > have to disable it by default until I understand what's going on. > > > > > > I really need to disable tso, rxcsum *and* txcsum to make this card work > > > stable. :/ > > > > Hmm, let's see which offload was broken. Disabling all offloads > > make it hard to find broken one. > > Ok, disabling -rxcsum will make the connection stable. But when I enable > rxcsum again, it is also stable! It looks like it is not turned on > again. To sum it up: > > 1. doing nothing: ssh connection drops after a couple of minutes > 2. ifconfig ale0 -rxcsum: ssh runs stable for dozens of minutes > 3. ifconfig ale0 rxcsum: ssh runs stable for dozens of minutes (wtf?) > > > > There is one other weirdness, though, regarding tso. I have been using a > > > netcat-blast test, where I "upload" /dev/zero to another machine, and > > > "download" it from the same machine. > > Scrap all my previous findings regarding this issue. I re-ran the test > with three machines. So ale0 would download from machine A and upload to > machine B. No matter how I hard I try, I can always saturate the 100MBit > Ethernet in full duplex. Don't know how the previous numbers came about. > Yeah, I still can't reproduce the issue you've mentioned but I think it's better to disable Rx checksum offload at this time. If I manage to find root cause of issue I would enable it again with proper workarounds. > Thanks for your patience, but it looks like the rxcsum is indeed fishy > on this chip revision. > Committed to HEAD(r195153). You can still enable Rx checksum offload with ifconfig(8) but it is disabled by default. Thanks for reporting! From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 05:45:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD9131065676 for ; Mon, 29 Jun 2009 05:45:31 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 8611C8FC0A for ; Mon, 29 Jun 2009 05:45:30 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: (qmail 45412 invoked from network); 29 Jun 2009 05:19:07 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 29 Jun 2009 05:19:07 -0000 Message-ID: <4A484E03.2080308@acm.poly.edu> Date: Mon, 29 Jun 2009 01:15:47 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.19 (X11/20090108) MIME-Version: 1.0 To: Aragon Gouveia References: <4A4751ED.8020002@phat.za.net> <20090628181105.GA98246@onelab2.iet.unipi.it> <4A47C1DF.2020908@phat.za.net> In-Reply-To: <4A47C1DF.2020908@phat.za.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo , current@freebsd.org Subject: Re: recent boot0 changes dropped a partition type? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 05:45:32 -0000 Aragon Gouveia wrote: > Hi, > > Luigi Rizzo wrote: >> yes it was removed to save space, i am more than happy to replace 0xb >> with 0xc if the latter turns out to be more popular. >> >> So far we have the following (all the rest is basically commented >> out because we need space for other stuff): >> >> 131 linux >> 165 FreeBSD >> 166 [Open]BSD >> 169 [Net]BSD >> 6 Win [FAT16 >= 32MB] >> 7 Win [NTFS] >> 11 Win [FAT32] >> >> Suggestions for replacements are welcome > > From my bit of research now, it looks like types 6 and 11 should be > changed. Their modern equivalents are 0xE and 0xC respectively. I > think the only Redmond systems that still use 0x6 and 0xB pre-date > Windows XP. I'm basing my opinions on personal experience and: > > http://www.win.tue.nl/~aeb/partitions/partition_types-1.html > http://en.wikipedia.org/wiki/File_Allocation_Table > > The only caveat I see is: > > http://support.microsoft.com/kb/151414 > > But with limited space we probably should just decide to not worry > about anything older than Windows XP... > > > Thanks, > Aragon > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" Just wanted to chime in and say that I currently happily dual boot between FreeBSD 7.2 and Windows 2000, and would vote for continuing to be able to do so. -Boris From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 07:33:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 818C01065674; Mon, 29 Jun 2009 07:33:18 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: from mail-gx0-f210.google.com (mail-gx0-f210.google.com [209.85.217.210]) by mx1.freebsd.org (Postfix) with ESMTP id 0E4238FC08; Mon, 29 Jun 2009 07:33:17 +0000 (UTC) (envelope-from venkiece2005@gmail.com) Received: by gxk6 with SMTP id 6so5007507gxk.19 for ; Mon, 29 Jun 2009 00:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=bNNrjSbPlhnqL8GO1unoZh80ZMCKfWp1HwMcTExvLZM=; b=qjrR1lkVGHq4tbHtqDznxbETVNRgtLG/Vg3S3V0vs6tV75Dmm11yHraY589G/OVIuX Zg9gqwD6nBpZEB2jQkFz+9K0xbpcJQHAiyl5JotI/YBy68WHrJHWBiXUyorh2en+QAvO fg6EMd6+ZZUyV2Isdhs410bSOOV4kHa8C7o8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=maO+k150/xXjQh7miTV5PsVBdwvCgjP3NW5aH3zWK4ZOps2pA3mHJa8JvAnpTGh1u3 OYew8IXTvXQq0Dcvh+io0R9HyEHeUZnL2jpcK//xdEqKGlkeRJ0r0rZ3wvOgFHRgzX/q dixurjH+Uxi8OR22FeagFC9OGAuPIx6i26d9Y= MIME-Version: 1.0 Received: by 10.151.83.17 with SMTP id k17mr3298326ybl.125.1246260797487; Mon, 29 Jun 2009 00:33:17 -0700 (PDT) In-Reply-To: <6d53329e0906182148k57b36ab6n6ddf1124ad4dfd6c@mail.gmail.com> References: <6d53329e0906160229j2fdba518h84b13652153a32f6@mail.gmail.com> <6d53329e0906182148k57b36ab6n6ddf1124ad4dfd6c@mail.gmail.com> Date: Mon, 29 Jun 2009 13:03:17 +0530 Message-ID: <6d53329e0906290033g54895993iae826416e9d08f4@mail.gmail.com> From: venki kaps To: kan@FreeBSD.org, netbsd-users@netbsd.org, freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Fwd: [libc] dlclose gives "invalid shared object handle" without pthread combination. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 07:33:18 -0000 Hi, Ref: http://www.mail-archive.com/svn-src-all@freebsd.org/msg10960.html Log: Allow order of initialization of loaded shared objects to be altered through their .init code. This might happen if init vector calls dlopen on its own and that dlopen causes some not yet initialized object to be initialized earlier as part of that dlopened DAG. Do not reset module reference counts to zero on final fini vector run when process is exiting. Just add an additional parameter to force fini vector invocation regardless of current reference count value if object was not destructed yet. This allows dlclose called from fini vector to proceed normally instead of failing with handle validation error. Query: ------- I have one question regarding " Do not reset module reference counts to zero on final fini vector run when process is exiting". Observation: --------------- The above issue normally happened when object is destructed and gives handl= e validation error. I have expected this is related to dl_refcount issue when process is exitin= g. Am just giving some more explanation regarding this issue: When i tested in the my Linux environment it shows the dl_reference count is 1 when dlopen and 0 when dlclose. In this test when the main dlclose invokes, the reference count is decremen= ted to zero But still other dependent objects are present and for these objects dl_reference count is required with one(1) to close the handle successfully= . As per dl* scenario, the dl_reference count has to be incremented by one(1) for the main object(main executable) as well as other ELF dependencies object. Now, I have invoked dl_reference count is incremented by one(1) for main ob= ject handle in _rtld_map_object function which is called by _rtld(). rtld Changes: --------------- _rtld(): /* Load the main program. */ Location: src/libexec/ld.elf_so/rtld.c: _rtld_objmain =3D _rtld_map_object(obj_name, fd, NULL); _rtld_map_object(): / * * Map a shared object into memory. The argument is a file descriptor, * which must be open on the object and positioned at its beginning. * The return value is a pointer to a newly-allocated Obj_Entry structure * for the shared object. Returns NULL on failure. */ --- a/src/libexec/ld.elf_so/map_object.c +++ b/src/libexec/ld.elf_so/map_object.c @@ -181,6 +181,10 @@ _rtld_map_object(const char *path, int f phdr =3D (Elf_Phdr *) ((caddr_t)ehdr + ehdr->e_phoff); phlimit =3D phdr + ehdr->e_phnum; nsegs =3D 0; + + /* + * And it was opened directly If trying to open + * the link map for the main executable. So the dl_recount + * must be the main dlopen one. + */ + ++obj->dl_refcount; + while (phdr < phlimit) { switch (phdr->p_type) { case PT_INTERP: After the above changes, [libc] dlclose does not give "invalid shared object handle" with/without pthread combination Since the dl_reference count is 2 instead of 1 for main object handle and 1 instead of 0 for other dependent objects. Could you give opinion about the above issue? Thanks & Regards, Venkappa ---------- Forwarded message ---------- From: venki kaps Date: Fri, Jun 19, 2009 at 10:18 AM Subject: [libc] dlclose gives "invalid shared object handle" without pthread combination. To: gnats-bugs@netbsd.org Hi, I am using the NetBSD implementation of rtld(src/libexec/ld.elf_so/) for ARM/MIPS and =A0have been porting NetBSD source in the Linux environment with our own pthread library. system environment: Compiler: arm-linux-gcc-4.3.3 OS: Linux Kernel: 2.6.29 I have C++ static constructor/destructor issue with my rtld. Problem Report: "ld.elf_so does not execute .init/.fini functions in order" and [libc] dlclose gives "invalid shared object handle" when called through the fini function of ano= ther module. The similar NetBSD/freeBSD issues are found from the following References: [1] http://gnats.netbsd.org/37347 [2] http://updraft3.jp.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/42956 The above issues are already commited in NetBSD-5-0-RELEASE. I have ported NetBSD-5-0-RELEASE rtld and tested Ref[1] provided static constructor/destructor test and did not find any issues with shared pthread combination but noticed [libc] dlclose gives "invalid shared object handle" without pthread combination. The static constructor/destructor test results: It should be : -------------- $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor While currently I get: ---------------------- with pthreads: $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor without pthreads: $ ./foobar foo_ctor bar_ctor tar_ctor main_ctor dep1_ctor dep2_ctor dll_ctor dll_dtor dep2_dtor dep1_dtor main_dtor tar_dtor bar_dtor foo_dtor Invalid shared object handle 0xbdbed400 This gives a "invalid shared object handle" message because the refcount field (obj->dl_refcount) for the handle is zero. it never even calls dlerr() in dlcose but __dlclose(void *handle) source sequence, int dlclose(void *handle) { =A0 =A0 =A0 Obj_Entry *root =3D _rtld_dlcheck(handle); =A0 =A0 =A0 if (root =3D=3D NULL) =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1; =A0 =A0 =A0 _rtld_debug.r_state =3D RT_DELETE; =A0 =A0 =A0 _rtld_debug_state(); =A0 =A0 =A0 --root->dl_refcount; =A0 =A0 =A0 _rtld_unload_object(root, true); =A0 =A0 =A0 _rtld_debug.r_state =3D RT_CONSISTENT; =A0 =A0 =A0 _rtld_debug_state(); =A0 =A0 =A0 return 0; } static Obj_Entry * _rtld_dlcheck(void *handle) { =A0 =A0 =A0 Obj_Entry *obj; =A0 =A0 =A0 for (obj =3D _rtld_objlist; obj !=3D NULL; obj =3D obj->next) =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (obj =3D=3D (Obj_Entry *) handle) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 break; =A0 =A0 =A0 xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); =A0 =A0 =A0 if (obj =3D=3D NULL || obj->dl_refcount =3D=3D 0) { =A0 =A0 =A0 =A0 =A0 =A0 =A0 xwarnx("Invalid shared object handle %p", handl= e); =A0 =A0 =A0 =A0 =A0 =A0 =A0 return NULL; =A0 =A0 =A0 } =A0 =A0 =A0 return obj; } I have printed =A0xprintf("obj->dl_refcount is %d\n",obj->dl_refcount); =A0obj->dl_refcount is getting zero(0). So due to "obj->dl_refcount =3D=3D 0" the error "invalid shared object handle" is showing. I have little bit confused about dlclose destructor with/without pthreads. I have some queries: 1) Is it required any changes apart from the NetBSD-5-0-RELEASE/{Ref[1],[2]= }? 2) Are any changes required in thread-stub? 3) i do not know why this error is coming even though all the =A0 constructor/destructor sequences are completed. 4) is it rtld_exit/fini/static C++ destructor/dlcose sequence problem? =A0(OR) =A0is it crtstuff/exit/atexit/cxa_finalize/cxa_atexit sequence problem? Could anyone provide any inputs to the my issue? Thanks in advance. Thanks & Regards, Venkappa From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 08:21:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 678E01065670 for ; Mon, 29 Jun 2009 08:21:40 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id E2FC28FC08 for ; Mon, 29 Jun 2009 08:21:39 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247058338; Mon, 29 Jun 2009 11:21:36 +0300 Message-ID: <4A48798A.5070604@FreeBSD.org> Date: Mon, 29 Jun 2009 11:21:30 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Kamigishi Rei References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> In-Reply-To: <1246260183.00133237.1246247402@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Goran Lowkrantz , freebsd-current@freebsd.org, Alexander Best Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 08:21:40 -0000 Kamigishi Rei wrote: > Goran Lowkrantz wrote: >> Clean CURRENT as of this morning, patches: >> /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1032: error: >> 'AHCI_DMA_ENTRIES' undeclared (first use in this function) >> /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1032: error: (Each >> undeclared identifier is reported only once >> /usr/src/sys/modules/ahci/../../dev/ahci/ahci.c:1032: error: for each >> function it appears in.) >> *** Error code 1 > > Kernel builds fine for me after "sed > 's/AHCI_DMA_ENTRIES/AHCI_SG_ENTRIES/' /usr/src/sys/dev/ahci/ahci.c" > (only one occurrence of that macro, aside from the .h file, anyway). You are right. Thank you. Committed to P4. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 08:27:24 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85751106564A for ; Mon, 29 Jun 2009 08:27:24 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3DFA18FC0C for ; Mon, 29 Jun 2009 08:27:24 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 6742678F7F; Mon, 29 Jun 2009 12:27:22 +0400 (MSD) Message-ID: <4A487AEA.7040906@haruhiism.net> Date: Mon, 29 Jun 2009 12:27:22 +0400 From: Aisaka Taiga User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Willem Jan Withagen References: <4A476C7C.3020605@withagen.nl> <4A477576.6030701@haruhiism.net> <4A4779AF.1020303@digiware.nl> In-Reply-To: <4A4779AF.1020303@digiware.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: 7.2-stable upgrade changes disknames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 08:27:24 -0000 Willem Jan Withagen wrote: > On 7.2 this used to work(tm), on 8.0 boot start complaining. > So somewhere a (unwanted) flexibility got deleted > And I have to manually fix my /etc/fstab to what is factual correct. > And that was what my message was about: > It can/will(??) bite a lot more users. > With similar remarks and/or questions. To be honest, I'm quite amused that it actually worked for you, because if you use a dangerously dedicated disk you, basically, don't need a partition table at all as the slice 'table' (bsdlabel) takes care of everything. And if there's no partition table, there can be no adXs1a boot device - even in 7.2. If you got your fstab from sysinstall, I don't really know how did you manage to migrate to a DDD without modifying fstab, because sysinstall has no clue about the existence of DDDs. To get a system running on a DDD you would basically need to install BTX (using fdisk), label the drive with bsdlabel, and then dump/restore or tar c | tar x the filesystems. But according to you, until -CURRENT you had a working partition table (hence adXs1a working). And make installworld should never bother with partition tables. (This is really weird.) -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 08:31:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C9051065673; Mon, 29 Jun 2009 08:31:52 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 52FD28FC0C; Mon, 29 Jun 2009 08:31:52 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 0F0BD78FA9; Mon, 29 Jun 2009 12:31:51 +0400 (MSD) Message-ID: <4A487BF7.8060103@haruhiism.net> Date: Mon, 29 Jun 2009 12:31:51 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexander Motin References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> In-Reply-To: <4A48798A.5070604@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Goran Lowkrantz , freebsd-current@freebsd.org, Alexander Best Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 08:31:52 -0000 Alexander Motin wrote: >> Kernel builds fine for me after "sed >> 's/AHCI_DMA_ENTRIES/AHCI_SG_ENTRIES/' /usr/src/sys/dev/ahci/ahci.c" >> (only one occurrence of that macro, aside from the .h file, anyway). > You are right. Thank you. Committed to P4. On a side note: the two secondary patches mentioned in the discussion (camcontrol and the other one) do not apply cleanly to r195137, even though the files' contents match. I had to edit the files manually, however, kernel still panics in xpt during boot right after the AHCI bus poll. I didn't remove atapicam from the kernel configuration, because according to your post with that patch earlier the patch should have fixed that behaviour. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 09:04:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2DBE106564A for ; Mon, 29 Jun 2009 09:04:34 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id A47488FC08 for ; Mon, 29 Jun 2009 09:04:34 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:4cb0:c97d:951c:1ed8] (unknown [IPv6:2001:7b8:3a7:0:4cb0:c97d:951c:1ed8]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id B9E0B5C42; Mon, 29 Jun 2009 11:04:33 +0200 (CEST) Message-ID: <4A4883A2.9020004@andric.com> Date: Mon, 29 Jun 2009 11:04:34 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1pre) Gecko/20090627 Shredder/3.0b3pre MIME-Version: 1.0 To: Aisaka Taiga References: <4A476C7C.3020605@withagen.nl> <4A477576.6030701@haruhiism.net> <4A4779AF.1020303@digiware.nl> <4A487AEA.7040906@haruhiism.net> In-Reply-To: <4A487AEA.7040906@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Willem Jan Withagen , current@freebsd.org Subject: Re: 7.2-stable upgrade changes disknames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 09:04:35 -0000 On 2009-06-29 10:27, Aisaka Taiga wrote: >> And I have to manually fix my /etc/fstab to what is factual correct. >> And that was what my message was about: >> It can/will(??) bite a lot more users. >> With similar remarks and/or questions. > To be honest, I'm quite amused that it actually worked for you, because > if you use a dangerously dedicated disk you, basically, don't need a > partition table at all as the slice 'table' (bsdlabel) takes care of > everything. And if there's no partition table, there can be no adXs1a > boot device - even in 7.2. It seems sysinstall creates DDD's with a strange bit of inconsistency. If you install on e.g. /dev/ad0, it forces you to create a (bogus?) slice /dev/ad0s1, the corresponding entries in /dev are also created, and the newly installed system's fstab also uses ad0s1a, ad0s1b, etc. However, the disklabel and the partition table will overlap. In some cases, I have seen *both* ad0s1a and ad0a existing at the same time in /dev... Sometime, during Marcel Moolenaars work on removing GEOM_MBR and GEOM_BSD, and replacing them with GEOM_PART_MBR and GEOM_PART_BSD, respectively, this arrangement got modified, so suddenly the 's1' part wasn't recognized anymore, and you just got ad0a, ad0b, and so on. In my case, simply doing "bsdlabel -B /dev/ad0s1", the label's boot code would be overwritten with a default version, which contains a sort of bogus partition table, having a fourth slice of 50000 sectors. Apparently this leads to FreeBSD then recognizing the disk as not having any slices anymore, so the disk will just be using ad0[a-z] from that point forward. You'll definitely need to fix your fstab and possibly /boot/loader.conf, /etc/rc.conf and so on... Note that sysinstall in -CURRENT can't even create a DDD anymore, since it tries to newfs a first slice, which doesn't exist. :) From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 09:05:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 461E11065687; Mon, 29 Jun 2009 09:05:21 +0000 (UTC) (envelope-from freebsd.work@gmail.com) Received: from mail-yx0-f181.google.com (mail-yx0-f181.google.com [209.85.210.181]) by mx1.freebsd.org (Postfix) with ESMTP id CC9A88FC2D; Mon, 29 Jun 2009 09:05:20 +0000 (UTC) (envelope-from freebsd.work@gmail.com) Received: by yxe11 with SMTP id 11so3621746yxe.3 for ; Mon, 29 Jun 2009 02:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=EGpIuYrPQXXsZH30xGkRylFJ19/f21MxbfNCZevNnsk=; b=tWhlVL2NRA1/zckviHF+CqktzXAcg8MAyHTAcuGmgo8rY+UFe6NwzkLNNR85185W74 N4CIVF/q/lxTUmof2NLsZnlgD31l9oK3w3OzLnH9byrZBV9zFiEp9A4G9q87BNyN9afu NG6/94nCXZmuPBpOYOURbG08QiZvhdHLNBaOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=eIcGT+ss5t48ZLLzYS4oW1r1OOILQt3tR1DBBdBZUTrFGlnlxFKPVbL0XXvkrnRhbD pXNwo05/xjOPxQekrRM7gP9sSJ/vnjdY9glbQMsFL6JQVK3zSuzcSGeQiriKSrX91nkg t5L5K5SQqswHwn6rAc0m/8fr1l3V3FwAKNK74= MIME-Version: 1.0 Received: by 10.231.14.129 with SMTP id g1mr604091iba.16.1246266319569; Mon, 29 Jun 2009 02:05:19 -0700 (PDT) In-Reply-To: References: <45d874490906281642r470089e2sc5b770f239f428e2@mail.gmail.com> Date: Mon, 29 Jun 2009 02:05:19 -0700 Message-ID: <45d874490906290205h41c6d08ajfdc0d4cf012f5389@mail.gmail.com> From: "Sean P. Dew" To: alc@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: segment alignment in AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 09:05:21 -0000 I applied this patch to modify the MAXPAGE size to 4K instead of 1 MB. Do I need to rebuild the toolchain? I have not been able to execute the genscripts.sh for generating the ld scripts. I tried to run the "make" in /usr/src/gnu/usr.bin/binutils/ld/ but got the following error. Any help is appreciated. Thanks a million libintl.h: No such file or directory Thanks Sean Index: /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh =================================================================== RCS file: /usr/ncvs/src/contrib/binutils/ld/emulparams/elf_x86_64.sh,v retrieving revision 1.1.1.6 diff -u -r1.1.1.6 elf_x86_64.sh --- /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh 16 Jun 2004 05:45:40 -0000 1.1.1.6 +++ /usr/src/contrib/binutils/ld/emulparams/elf_x86_64.sh 7 Sep 2007 00:20:31 -0000 @@ -2,7 +2,7 @@ ELFSIZE=64 OUTPUT_FORMAT="elf64-x86-64" TEXT_START_ADDR=0x400000 -MAXPAGESIZE=0x100000 +MAXPAGESIZE=0x1000 COMMONPAGESIZE=0x1000 NONPAGED_TEXT_START_ADDR=0x400000 ARCH="i386:x86-64" ------------------------------------------------------------------------------------------------------------------ On Sun, Jun 28, 2009 at 5:37 PM, Alan Cox wrote: > On Sun, Jun 28, 2009 at 6:42 PM, Sean P. Dew wrote: > >> Hi, >> >> Why is a loadable segment aligned to 1 MB on AMD64 while the pagezie is >> still 4K for a user application. Is there anyway to change it back to 4K, >> It >> is not making sense to me is because if my file segment is around 400K, we >> are wasting 1 MB of virtual address space ( granted it is not a lot for >> X64). I am trying to find out the reason. I am posting the readelf output >> of a .so. Any help is appreciated. >> > > You'll find this question discussed in the mailing list archives on more > than one occasion. Here is one such message: > > http://lists.freebsd.org/pipermail/freebsd-amd64/2007-September/010260.html > > To be a little more explicit, it is done to increase the likelihood that > the entire code segment of a large program can be mapped using 2 MB page > mappings. Moreover, to be able to do so without wasting any physical memory > on padding. Although we have the necessary 2 MB page support in the virtual > memory system, the kernel's image activator hasn't been modified to take > advantage of this. Only a few programs with large code and data segments, > e.g., emacs, will benefit. > > Regards, > Alan > > From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 09:39:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AACFD1065670; Mon, 29 Jun 2009 09:39:02 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 644F78FC08; Mon, 29 Jun 2009 09:39:02 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MLDKC-0003Lo-T9; Mon, 29 Jun 2009 10:39:01 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MLDKA-00003g-Jf; Mon, 29 Jun 2009 10:38:55 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n5T9cr66044237; Mon, 29 Jun 2009 10:38:53 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n5T9crfU044236; Mon, 29 Jun 2009 10:38:53 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Mon, 29 Jun 2009 10:38:53 +0100 From: Anton Shterenlikht To: Marcel Moolenaar Message-ID: <20090629093853.GA44061@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.4 X-Spam-Level: - Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 09:39:03 -0000 On Thu, Jun 25, 2009 at 09:41:13AM -0700, Marcel Moolenaar wrote: > > On Jun 25, 2009, at 4:02 AM, Anton Shterenlikht wrote: > > dev_taste(DEV,mirror/gm0) > > g_part_taste(PART,mirror/gm0) > > > > GEOM: mirror/gm0: the secondary GPT table is corrupt or invalid. > > GEOM: mirror/gm0: using the primary only -- recovery suggested. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > You created the mirror after the GPT, which means you destroyed > the GPT backup header. gmirror uses the last sector on the disk > for metadata and that by itself is a cause for various problems. So, gmirror cannot be used on ia64 to mirror the boot disk? Because on ia64 the last sector always contains secondary GPT. I take it the RAID1 section, 19.4, in FBSD user manual, was written with i386 or alpha architecture in mind. > It's better to use gmirror per partition. how? Is it in the manual? any link? > > #echo 'geom_mirror_load="YES"' >> /boot/loader.conf > > Is /boot a symlink for /efi/boot? yes, lrwxr-xr-x 1 root wheel 8 Jun 25 10:44 boot -> efi/boot > > And when the system is rebooted, there is no /dev/mirror anymore. > > You could run into a race condition between GPT and gmirror and > GPT winning (again the result of gmirror using the last sector > on a disk for metadata). > > Alternatively, make sure gmirror got loaded at boot. # kldstat Id Refs Address Size Name 1 3 0xe000000004000000 ff9c08 kernel 2 1 0xe000000004ffa000 3c830 geom_mirror.ko # It's not that I desperately need to mirror a boot disk, it just that gmirror looked so easy in the manual, I wanted to give it a go. Perhaps I can just do a block copy to the second disk, say once a day, and have it as a backup. Could you also possibly comment on gvinum on ia64? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 09:56:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A1A21065674 for ; Mon, 29 Jun 2009 09:56:13 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 9AE858FC13 for ; Mon, 29 Jun 2009 09:56:12 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fxm18 with SMTP id 18so1764774fxm.43 for ; Mon, 29 Jun 2009 02:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=mIVQI17NOExRbSRmRK8ELiJp93MjRgCudWH9N7wy2HM=; b=U1BYC7EDyenimIek8btf+9DK3MyF1ds5RUCH4Vr8NJWTbXxKG5+pX5cQCS1t9Vd596 YNbRVK5fluod8lMJQLVvMENGFjYL87LwY6LTKcRhaM7jfLwZsPwy0rkss5TvEKzdKLtc qADjTnZcga9B78RMovkPy9SQxF1aXICpZCwao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=EuWYtjmT4hlxQVMEHFcjLCQZZN0Vfs+i4Mc9LYpeXy5xnc9ApubaNa0CEB+fKdyqHS f6hVmZRJprkN66cwU9bMQmWS6feblBRBiUMMT8Lf6rcGsaEmDHvU+0cstA7VTEL3OZJL lojFzyUq8PTrEVJcvYCjZPi1E0Vji1Yhalnb0= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.113.9 with SMTP id y9mr4272783fap.19.1246269371623; Mon, 29 Jun 2009 02:56:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Jun 2009 11:56:11 +0200 X-Google-Sender-Auth: f51c70cf27ded9c1 Message-ID: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> From: Attilio Rao To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 09:56:13 -0000 2009/6/29 Rick Macklem : > I just noticed that when I do the following: > - start a large write to an NFS mounted fs > - network partition the server (unplug a net cable) > - do a "umount -f " on the machine > > that it gets stuck trying to write dirty blocks to the server. > > I had, in the past, assumed that a "umount -f" of an NFS mount would be > used to get rid of an NFS mount on an unresponsive server and that loss > of "writes in progress" would be expected to happen. > > Does that sound correct? (In other words, an I seeing a bug or a feature?) While that should be real in principle (immediate shutdown of the fs operation and unmounting of the partition) it is totally impossible to have it completely unsleeping, so it can happen that also umount -f sleeps / delays for some times (example: vflush). Currently, umount -f is one of the most complicated thing to handle in our VFS because it puts as requirement that vnodes can be reclaimed in any moment, adding complexity and possibility for races. What's the fix for your problem? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 10:06:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBCD91065675 for ; Mon, 29 Jun 2009 10:06:47 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3B9E28FC0C for ; Mon, 29 Jun 2009 10:06:46 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247063475; Mon, 29 Jun 2009 13:06:43 +0300 Message-ID: <4A48922D.5090507@FreeBSD.org> Date: Mon, 29 Jun 2009 13:06:37 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Kamigishi Rei References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> In-Reply-To: <4A487BF7.8060103@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Goran Lowkrantz , freebsd-current@freebsd.org, Alexander Best Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 10:06:48 -0000 Kamigishi Rei wrote: > Alexander Motin wrote: >>> Kernel builds fine for me after "sed >>> 's/AHCI_DMA_ENTRIES/AHCI_SG_ENTRIES/' /usr/src/sys/dev/ahci/ahci.c" >>> (only one occurrence of that macro, aside from the .h file, anyway). >> You are right. Thank you. Committed to P4. > On a side note: the two secondary patches mentioned in the discussion > (camcontrol and the other one) do not apply cleanly to r195137, even > though the files' contents match. I had to edit the files manually, > however, kernel still panics in xpt during boot right after the AHCI bus > poll. > I didn't remove atapicam from the kernel configuration, because > according to your post with that patch earlier the patch should have > fixed that behaviour. Sorry, my fault, it is the different bug, due to disabled invariants I have missed two locking issues. Here is regenerated patch, including this fix and all previous fixes and improvements: http://people.freebsd.org/~mav/cam-ata.20090629.patch -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 10:47:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0A55C1065686 for ; Mon, 29 Jun 2009 10:47:15 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from mail.math.leidenuniv.nl (84e5e739.math.leidenuniv.nl [132.229.231.57]) by mx1.freebsd.org (Postfix) with ESMTP id AF2FC8FC23 for ; Mon, 29 Jun 2009 10:47:14 +0000 (UTC) (envelope-from info@martenvijn.nl) Received: from [132.229.231.13] (polaris.math.leidenuniv.nl [132.229.231.13]) by mail.math.leidenuniv.nl (Postfix) with ESMTP id 05C016E9DD for ; Mon, 29 Jun 2009 12:31:35 +0200 (CEST) From: Marten Vijn To: freebsd-current@freebsd.org Content-Type: text/plain Date: Mon, 29 Jun 2009 12:31:35 +0200 Message-Id: <1246271495.11479.29.camel@polaris> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 7bit Subject: some help wished on pr 135961 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 10:47:16 -0000 pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=135961 Yesterday I had a chat session with gavin (#bugbusters) There seems to be a problem with the boot0 loader with pcengines boards from CF-card: - WRAP 1C - WRAP 2E - ALIX 1C (- maybe Soekris NET4826) The failiure occurs just before or after STARTING BTX loader help wished: - help to create verbose (debugging) loader (boot0) - new debug strategies? - create fixes. - If you live in Leiden, the Netherlands, maybe hands-on hacking. possible related issues: - failing boot0cfg -s (only works on -s1 setting -s2|3|4 boots s1 - slow /failing PXEboot thanks, Marten -- Marten Vijn linux 2.0.18 OpenBSD 3.6 FreeBSD 4.6 http://martenvijn.nl http://opencommunitycamp.org http://wifisoft.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 10:50:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F9A11065687 for ; Mon, 29 Jun 2009 10:50:19 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 626EF8FC25 for ; Mon, 29 Jun 2009 10:50:18 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (host86-150-123-187.range86-150.btcentralplus.com [86.150.123.187]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n5TAFCKl046839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Jun 2009 20:15:14 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A48942A.7030307@freebsd.org> Date: Mon, 29 Jun 2009 11:15:06 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------030109010401070505010604" X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_50,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Subject: "filesystem goof: vop_panic[vop_revoke]" panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 10:50:19 -0000 This is a multi-part message in MIME format. --------------030109010401070505010604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, My laptop panicked whilst shutting down yesterday. The shutdown sequence seemed to terminate kde4/X correctly but got wedged prior to completing the rest as seen on the console. Details below... uname -a: FreeBSD lstewart-laptop 8.0-CURRENT FreeBSD 8.0-CURRENT #35 r195046: Fri Jun 26 12:28:02 BST 2009 lstewart@lstewart-laptop:/usr/obj/usr/src/sys/LAPTOP amd64 Backtrace: at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff8084cb11 in trap (frame=0xffffff8058eb76a0) at /usr/src/sys/amd64/amd64/trap.c:613 #7 0xffffffff80832f33 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #8 0xffffffff805a736d in kdb_enter (why=0xffffffff80943489 "panic", msg=0xa
) at cpufunc.h:63 #9 0xffffffff8057791b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:558 #10 0xffffffff805f6108 in vop_panic (ap=Variable "ap" is not available. ) at /usr/src/sys/kern/vfs_default.c:175 #11 0xffffffff8054dee7 in exit1 (td=0xffffff00049c9720, rv=1) at vnode_if.h:523 #12 0xffffffff8057927f in sigexit (td=0xffffff00049c9720, sig=0) at /usr/src/sys/kern/kern_sig.c:2726 #13 0xffffffff80579e7f in postsig (sig=1491826128) at /usr/src/sys/kern/kern_sig.c:2617 #14 0xffffffff805b422c in ast (framep=0xffffff8058eb7c90) at /usr/src/sys/kern/subr_trap.c:225 #15 0xffffffff80833de9 in doreti_ast () at /usr/src/sys/amd64/amd64/exception.S:623 I don't see much useful info in any of the frames, but then I have no idea what to look for. Any thoughts and/or further info required? Cheers, Lawrence --------------030109010401070505010604 Content-Type: text/plain; name="core.txt.7" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="core.txt.7" lstewart-laptop dumped core - see /var/crash/vmcore.7 Mon Jun 29 08:47:59 BST 2009 FreeBSD lstewart-laptop 8.0-CURRENT FreeBSD 8.0-CURRENT #35 r195046: Fri Jun 26 12:28:02 BST 2009 lstewart@lstewart-laptop:/usr/obj/usr/src/sys/LAPTOP amd64 panic: filesystem goof: vop_panic[vop_revoke] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: filesystem goof: vop_panic[vop_revoke]VNASSERT failed cpuid = 1 0xffffff00048afb10: KDB: enter: panictag devfs, type VCHR Physical memory: 2905 MB Dumping 1425 MB: 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from /boot/kernel/snd_hda.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_hda.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kernel/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/atapicam.ko...Reading symbols from /boot/kernel/atapicam.ko.symbols...done. done. Loaded symbols for /boot/kernel/atapicam.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/i915.ko...Reading symbols from /boot/kernel/i915.ko.symbols...done. done. Loaded symbols for /boot/kernel/i915.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel/drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:223 #1 0xffffffff801d1c3c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801d1f71 in db_command (last_cmdp=0xffffffff80bcd3a0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801d21c0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801d4169 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff805a7195 in kdb_trap (type=3, code=0, tf=0xffffff8058eb76a0) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff8084cb11 in trap (frame=0xffffff8058eb76a0) at /usr/src/sys/amd64/amd64/trap.c:613 #7 0xffffffff80832f33 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #8 0xffffffff805a736d in kdb_enter (why=0xffffffff80943489 "panic", msg=0xa
) at cpufunc.h:63 #9 0xffffffff8057791b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:558 #10 0xffffffff805f6108 in vop_panic (ap=Variable "ap" is not available. ) at /usr/src/sys/kern/vfs_default.c:175 #11 0xffffffff8054dee7 in exit1 (td=0xffffff00049c9720, rv=1) at vnode_if.h:523 #12 0xffffffff8057927f in sigexit (td=0xffffff00049c9720, sig=0) at /usr/src/sys/kern/kern_sig.c:2726 #13 0xffffffff80579e7f in postsig (sig=1491826128) at /usr/src/sys/kern/kern_sig.c:2617 #14 0xffffffff805b422c in ast (framep=0xffffff8058eb7c90) at /usr/src/sys/kern/subr_trap.c:225 #15 0xffffffff80833de9 in doreti_ast () at /usr/src/sys/amd64/amd64/exception.S:623 #16 0x0000000000000490 in ?? () #17 0x00007fffffffed3c in ?? () #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000800b03800 in ?? () #21 0x000000000000000c in ?? () #22 0x0000000000000007 in ?? () #23 0x0000000000000490 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x00000000ffffffff in ?? () #27 0x0000000000000001 in ?? () #28 0x00007fffffffede8 in ?? () #29 0x0000000000000000 in ?? () #30 0x00007fffffffefa3 in ?? () #31 0x001b00130000000c in ?? () #32 0x0000000800a9c680 in ?? () #33 0x003b003b00000001 in ?? () #34 0x0000000000000002 in ?? () #35 0x00000008009ead8a in ?? () #36 0x0000000000000043 in ?? () #37 0x0000000000000206 in ?? () #38 0x00007fffffffec48 in ?? () #39 0x000000000000003b in ?? () #40 0x00000000010b1000 in ?? () #41 0x0000000000000000 in ?? () #42 0xffffffff80c24a70 in sleepq_chains () #43 0xffffffff80c0a040 in tdq_cpu () #44 0xffffff00023fa720 in ?? () #45 0xffffff8058eb76e0 in ?? () #46 0xffffff8058eb7698 in ?? () #47 0xffffff00049c9720 in ?? () #48 0xffffffff8059aba0 in sched_switch (td=0x490, newtd=0x1, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1858 Previous frame inner to this frame (corrupt stack?) (kgdb) ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 -68 0 0 0 - DLs ?? 140156:48.00 [kernel] 0 1 0 0 61 0 2180 0 - RLs ?? 232440:43.00 [init] 0 2 0 0 -8 0 0 0 - DL ?? 251283:19.00 [g_event] 0 3 0 0 -8 0 0 0 - DL ?? 760499:50.00 [g_up] 0 4 0 0 -8 0 0 0 - DL ?? 613554:26.00 [g_down] 0 5 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thrd] 0 6 0 0 -16 0 0 0 waitin DL ?? 448:00.00 [sctp_itera 0 7 0 0 76 0 0 0 psleep DL ?? 4228:49.00 [pagedaemon 0 8 0 0 76 0 0 0 psleep DL ?? 99:45.00 [vmdaemon] 0 9 0 0 76 0 0 0 pgzero DL ?? 128:27.00 [pagezero] 0 10 0 0 -16 0 0 0 audit_ DL ?? 0:00.00 [audit] 0 11 0 0 171 0 0 0 - RL ?? 1738824481:20.00 [idle] 0 12 0 0 -21 0 0 0 - WL ?? 26691379:59.00 [intr] 0 13 0 0 -16 0 0 0 - DL ?? 99258:43.00 [yarrow] 0 14 0 0 -16 0 0 0 tzpoll DL ?? 13959:31.00 [acpi_therm 0 15 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus0] 0 16 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus0] 0 17 0 0 -64 0 0 0 wmsg DL ?? 13132:56.00 [usbus0] 0 18 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus0] 0 19 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus1] 0 20 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus1] 0 21 0 0 -64 0 0 0 wmsg DL ?? 22181:29.00 [usbus1] 0 22 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus1] 0 23 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus2] 0 24 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus2] 0 25 0 0 -64 0 0 0 wmsg DL ?? 20464:23.00 [usbus2] 0 26 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus2] 0 27 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus3] 0 28 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus3] 0 29 0 0 -64 0 0 0 wmsg DL ?? 16220:45.00 [usbus3] 0 30 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus3] 0 31 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus4] 0 32 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus4] 0 33 0 0 -64 0 0 0 wmsg DL ?? 12409:01.00 [usbus4] 0 34 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus4] 0 35 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus5] 0 36 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus5] 0 37 0 0 -64 0 0 0 wmsg DL ?? 247212:56.00 [usbus5] 0 38 0 0 -64 0 0 0 wmsg DL ?? 3568:29.00 [usbus5] 0 39 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus6] 0 40 0 0 -68 0 0 0 wmsg DL ?? 0:00.00 [usbus6] 0 41 0 0 -64 0 0 0 wmsg DL ?? 20956:08.00 [usbus6] 0 42 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus6] 0 43 0 0 -64 0 0 0 wmsg DL ?? 0:00.00 [usbus7] 0 44 0 0 -68 0 0 0 wmsg DL ?? 45173:48.00 [usbus7] 0 45 0 0 -64 0 0 0 wmsg DL ?? 727273:52.00 [usbus7] 0 46 0 0 -64 0 0 0 wmsg DL ?? 145912:12.00 [usbus7] 0 47 0 0 76 0 0 0 psleep DL ?? 4886:42.00 [bufdaemon] 0 48 0 0 44 0 0 0 syncer DL ?? 55758:37.00 [syncer] 0 49 0 0 44 0 0 0 vlruwt DL ?? 4319:42.00 [vnlru] 0 50 0 0 44 0 0 0 sdflus DL ?? 10391:09.00 [softdepflu 0 51 0 0 76 0 0 0 flowcl DL ?? 534:48.00 [flowcleane 0 141 1 0 76 0 1708 0 pause Ds ?? 12485:33.00 [adjkerntz] 0 593 1 0 44 0 2176 0 select Ds ?? 267115:55.00 [devd] 0 708 1 0 1 0 4836 0 select Ds ?? 366804:12.00 [syslogd] 0 904 1 0 44 0 4836 0 select Ds ?? 1872660:18.00 [powerd] 0 962 1 0 44 0 5984 0 select Ds ?? 8889:11.00 [moused] 556 985 1 0 44 0 6036 0 select Ds ?? 1318495:09.00 [dbus-daemo 0 1032 1 0 76 0 23960 0 select Ds ?? 48667:44.00 [sshd] 0 1039 1 0 44 0 9892 0 select Ds ?? 103909:17.00 [sendmail] 25 1043 1 0 44 0 9892 0 pause Ds ?? 69721:31.00 [sendmail] 0 1054 1 0 44 0 5892 0 nanslp Ds ?? 117210:55.00 [cron] 0 1106 1 0 -84 0 0 0 - ZW ?? 0:00.00 0 1107 1 0 44 0 0 0 - RE ?? 663256:39.00 [login] 0 1108 1 0 76 0 4832 0 - Rs+ ?? 87492:53.00 [getty] 0 1109 1 0 76 0 4832 0 ttyin Ds+ ?? 84491:38.00 [getty] 0 1110 1 0 76 0 4832 0 ttyin Ds+ ?? 90172:57.00 [getty] 0 1111 1 0 76 0 4832 0 ttyin Ds+ ?? 87203:19.00 [getty] 0 1112 1 0 76 0 4832 0 ttyin Ds+ ?? 91103:43.00 [getty] 0 1113 1 0 76 0 4832 0 ttyin Ds+ ?? 86430:59.00 [getty] 560 1118 1 0 44 0 42052 0 select Ds ?? 8700718:57.00 [hald] 0 1121 1 0 44 0 43688 0 n Ds ?? 663660:33.00 [console-ki 0 1122 1118 0 76 0 35896 0 select D ?? 1833253:13.00 [hald-runne 0 1127 1122 0 76 0 38828 0 kqread D ?? 829270:52.00 [hald-addon 0 1154 1122 0 44 0 10468 0 select D ?? 600841:44.00 [hald-addon 0 1168 1107 0 46 0 9248 0 - R+ ?? 660838:09.00 [csh] 0 1182 1 0 76 0 15864 0 pause D ?? 420683:47.00 [kdm-bin] 0 1279 1 0 44 0 8968 0 select Ds ?? 74916:13.00 [wpa_suppli 0 1289 1 0 76 0 3748 0 select Ds ?? 130058:01.00 [dhclient] 65 1323 1 0 45 0 3748 0 select Ds ?? 11582:54.00 [dhclient] 1001 1435 1 0 44 0 47396 0 select D ?? 67565:52.00 [akonadi_co 1001 1438 1435 0 48 0 56728 0 select D ?? 175536:47.00 [akonadiser 1001 1440 1438 0 76 0 6200 0 wait D ?? 0:00.00 [sh] 1001 1458 1440 0 44 0 142200 0 ucond D ?? 2985583:04.00 [mysqld] 1001 1545 1 0 44 0 130900 0 select Ds ?? 4676284:26.00 [pulseaudio 1001 1547 1545 0 44 0 58488 0 select D ?? 1158519:08.00 [gconf-help 1001 1570 1 0 44 0 32108 0 select D ?? 0:00.00 [gam_server 0 1673 1182 0 -84 0 0 0 - ZW ?? 0:00.00 0 1674 1 0 -84 0 0 0 - ZW ?? 0:00.00 ------------------------------------------------------------------------ vmstat -s 0 cpu context switches 0 device interrupts 0 software interrupts 0 traps 0 system calls 0 kernel threads created 0 fork() calls 0 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 0 vnode pager pageins 0 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 3594 pages reactivated 0 copy-on-write faults 0 copy-on-write optimized faults 0 zero fill pages zeroed 0 zero fill pages prezeroed 0 intransit blocking page faults 0 total VM faults taken 0 pages affected by kernel thread creation 0 pages affected by fork() 0 pages affected by vfork() 0 pages affected by rfork() 6183 pages cached 0 pages freed 0 pages freed by daemon 556606 pages freed by exiting processes 45188 pages active 28257 pages inactive 2300 pages in VM cache 80468 pages wired down 566809 pages free 4096 bytes per page 68711351 total name lookups cache hits (99% pos + 0% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) CAM SIM 3 1K - 3 256 cdev 12 3K - 12 256 CAM periph 4 1K - 12 16,32,64,128,256 sigio 1 1K - 4 64 filedesc 94 52K - 1789 16,512,1024,2048 kenv 72 11K - 76 16,32,64,128 kqueue 16 17K - 178 256,512,2048 proc-args 36 3K - 1352 16,32,64,128,256 CAM XPT 25 7K - 3691 32,64,128,256,1024 ithread 74 12K - 76 32,128,256 acpidev 79 5K - 79 64 ata_generic 1 1K - 1 1024 KTRACE 100 13K - 100 128 linker 179 256K - 233 16,32,64,128,256,512,2048,4096 lockf 55 7K - 1584 64,128 ip6ndp 5 1K - 5 64,128 temp 31 19K - 27868 16,32,64,128,256,512,1024,2048,4096 devbuf 20089 36831K - 20458 16,32,64,128,256,512,1024,2048,4096 kbdmux 6 10K - 6 16,512,1024,2048,4096 module 419 53K - 419 128 mtx_pool 1 8K - 1 osd 2 1K - 2 16,64 subproc 270 447K - 1857 512,4096 proc 2 16K - 2 session 28 4K - 59 128 pgrp 30 4K - 67 128 cred 42 7K - 144868 64,256 uidinfo 9 3K - 18 128,2048 plimit 14 4K - 374 256 sysctltmp 0 0K - 2761 16,32,64,128,256 sysctloid 3515 174K - 3608 16,32,64,128 sysctl 0 0K - 1514 16,32,64 callout 1 512K - 1 umtx 296 37K - 296 128 vimage 15 1K - 15 64 p1003.1b 1 1K - 1 16 SWAP 2 1097K - 2 64 ad_driver 1 1K - 1 32 bus-sc 72 345K - 3220 16,32,64,128,256,512,1024,2048,4096 bus 1137 99K - 8021 16,32,64,128,256,512,1024 devstat 8 17K - 8 32,4096 eventhandler 73 6K - 73 64,128 ar_driver 0 0K - 6 512,2048 kobj 296 1184K - 359 4096 Per-cpu 1 1K - 1 32 rman 238 29K - 645 16,32,128 sbuf 0 0K - 923 16,32,64,128,256,512,1024,2048,4096 stack 0 0K - 2 256 taskqueue 15 2K - 15 16,32,128 Unitno 15 1K - 401 32,64 Witness 1 128K - 1 iov 0 0K - 646025 16,64,128,256,512 select 112 14K - 112 128 ioctlops 0 0K - 3501210 16,32,64,128,256,512,1024,4096 msg 4 30K - 4 2048,4096 sem 4 11K - 4 512,1024 shm 1 20K - 15 2048 tty 19 19K - 31 1024,2048 pts 0 0K - 10 256 mbuf_tag 0 0K - 26 32,64 shmfd 13 13K - 13 64,128,1024 pcb 20 157K - 224 16,32,128,1024,2048,4096 soname 22 3K - 1741 16,32,64,128 biobuf 6 12K - 18 2048 vfscache 1 1024K - 1 cl_savebuf 0 0K - 85 64,128 vfs_hash 1 512K - 1 vnodes 2 1K - 2 256 vnodemarker 0 0K - 641 512 mount 69 4K - 113 16,32,64,128,256 BPF 13 74K - 14 16,128,512,4096 ether_multi 19 1K - 30 16,32,64 ifaddr 196 18K - 197 32,64,128,256,512,4096 ifnet 5 9K - 5 256,2048 clone 5 20K - 5 4096 arpcom 2 1K - 2 16 lltable 12 5K - 12 256,512 pci_link 16 2K - 16 16,32,128 ddb_capture 1 48K - 1 acpi_perf 2 1K - 2 128 routetbl 22 37K - 102 32,64,128,256,512,1024 80211vap 1 4K - 1 4096 80211crypto 3 1K - 4 128,512 80211com 1 8K - 1 80211nodeie 8 2K - 13 32,64,128,256 80211node 1 12K - 2 80211scan 8 9K - 8 512,2048,4096 igmp 4 1K - 4 256 entropy 1024 64K - 1024 64 in_multi 2 1K - 3 256 sctp_iter 0 0K - 3 256 sctp_ifn 2 1K - 2 128 sctp_ifa 4 1K - 4 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 3 16 hostcache 1 28K - 1 syncache 1 96K - 1 scsi_cd 0 0K - 3 16 in6_multi 12 2K - 12 32,256 mld 4 1K - 4 128 NFS FHA 1 2K - 1 2048 rpc 2 9K - 2 256 audit_evclass 171 6K - 210 32 savedino 0 0K - 162 256 newdirblk 1 1K - 2 64 dirrem 45 3K - 2310 64 mkdir 0 0K - 36 64 diradd 31 2K - 2324 64 freefile 13 1K - 1167 64 freeblks 16 4K - 1177 256 freefrag 0 0K - 578 64 allocindir 656 82K - 2215 128 indirdep 1 1K - 31 64 allocdirect 50 13K - 2057 256 bmsafemap 8 1K - 159 128 newblk 1 1K - 4273 64,512 inodedep 95 536K - 1519 256 pagedep 23 131K - 173 128 ufs_dirhash 192 38K - 198 16,32,64,128,256,512 ufs_mount 12 38K - 12 512,2048,4096 UMAHash 2 2K - 4 512,1024 USBdev 98 36K - 461 64,128,512,1024 vm_pgdata 2 129K - 2 128 USB 90 100K - 97 16,32,64,128,512,2048 acpica 2608 230K - 197156 16,32,64,128,256,512,1024,2048,4096 DEVFS1 128 64K - 149 512 DEVFS3 154 39K - 176 256 DEVFS 26 1K - 27 16,128 io_apic 1 2K - 1 2048 DEVFSP 2 1K - 367 64 memdesc 1 4K - 6 32,4096 msi 3 1K - 3 128 nexusdev 3 1K - 3 16 pfs_nodes 20 5K - 20 256 agp 1 1K - 3 32,128 atkbddev 2 1K - 2 64 acpitask 1 2K - 1 2048 GEOM 84 22K - 609 16,32,64,128,256,512,1024,2048 CAM dev queue 3 1K - 3 128 isadev 7 1K - 7 128 CAM queue 10 1K - 38 16,32 acpisem 17 3K - 17 128 mixer 2 8K - 2 4096 feeder 23 3K - 223 32,128 hdac 7 20K - 7 64,128,256,1024,2048,4096 ata_cam 1 1K - 1 1024 linux 12 1K - 12 64 drm_drawable 0 0K - 4 16,64 drm_ctxbitmap 1 4K - 1 4096 drm_agplists 1 1K - 1 128 drm_buflists 0 0K - 2 32 drm_files 0 0K - 3 64 drm_maps 1 1K - 10 128 drm_magic 0 0K - 1 32 drm_driver 4 5K - 5 32,64,512,4096 drm_sarea 1 1K - 2 16,32 ------------------------------------------------------------------------ vmstat -z ITEM SIZE LIMIT USED FREE REQUESTS FAILURES UMA Kegs: 208, 0, 87, 15, 87, 0 UMA Zones: 256, 0, 87, 3, 87, 0 UMA Slabs: 568, 0, 948, 4, 12125, 0 UMA RCntSlabs: 568, 0, 380, 5, 380, 0 UMA Hash: 256, 0, 2, 13, 4, 0 16 Bucket: 152, 0, 74, 1, 74, 0 32 Bucket: 280, 0, 79, 5, 79, 1 64 Bucket: 536, 0, 85, 6, 85, 328 128 Bucket: 1048, 0, 259, 2, 259, 75130 VM OBJECT: 216, 0, 4834, 9098, 50809, 0 MAP: 232, 0, 7, 25, 7, 0 KMAP ENTRY: 120, 115072, 54, 101, 30985, 0 MAP ENTRY: 120, 0, 1685, 16915, 248126, 0 DP fakepg: 112, 0, 0, 74349, 75359, 0 mt_zone: 2056, 0, 285, 20, 285, 0 16: 16, 0, 1914, 438, 3442094, 0 32: 32, 0, 2814, 317, 206800, 0 64: 64, 0, 10637, 395, 428560, 0 128: 128, 0, 7254, 257, 377779, 0 256: 256, 0, 1449, 231, 81391, 0 512: 512, 0, 641, 108, 6965, 0 1024: 1024, 0, 94, 158, 25658, 0 2048: 2048, 0, 63, 55, 2290, 0 4096: 4096, 0, 474, 88, 5814, 0 Files: 80, 0, 266, 859, 31932, 0 TURNSTILE: 136, 0, 297, 23, 297, 0 umtx pi: 96, 0, 0, 0, 0, 0 MAC labels: 40, 0, 0, 0, 0, 0 PROC: 1120, 0, 88, 92, 1675, 0 THREAD: 912, 0, 232, 64, 393, 0 SLEEPQUEUE: 80, 0, 297, 22, 297, 0 VMSPACE: 392, 0, 34, 96, 1625, 0 cpuset: 72, 0, 2, 98, 2, 0 audit_record: 5024, 0, 0, 0, 0, 0 mbuf_packet: 256, 0, 258, 393, 185752, 0 mbuf: 256, 0, 1, 394, 636444, 0 mbuf_cluster: 2048, 25600, 640, 12, 640, 0 mbuf_jumbo_page: 4096, 12800, 0, 54, 191984, 0 mbuf_jumbo_9k: 9216, 19200, 0, 0, 0, 0 mbuf_jumbo_16k: 16384, 12800, 0, 0, 0, 0 mbuf_ext_refcnt: 4, 0, 0, 0, 0, 0 g_bio: 232, 0, 0, 1680, 71388, 0 ttyinq: 160, 0, 90, 270, 690, 0 ttyoutq: 256, 0, 48, 132, 344, 0 ata_request: 312, 0, 1, 479, 285480, 0 ata_composite: 336, 0, 0, 0, 0, 0 VNODE: 472, 0, 7325, 75, 8543, 0 VNODEPOLL: 112, 0, 48, 84, 48, 0 S VFS Cache: 108, 0, 7452, 171, 32349, 0 L VFS Cache: 328, 0, 133, 47, 489, 0 NAMEI: 1024, 0, 0, 48, 10017754, 0 NFSMOUNT: 608, 0, 0, 0, 0, 0 NFSNODE: 648, 0, 0, 0, 0, 0 DIRHASH: 1024, 0, 345, 31, 349, 0 pipe: 728, 0, 33, 187, 1498, 0 ksiginfo: 112, 0, 166, 890, 167, 0 itimer: 344, 0, 0, 0, 0, 0 KNOTE: 120, 0, 52, 103, 239, 0 socket: 680, 25602, 48, 342, 2747, 0 unpcb: 240, 25600, 40, 360, 680, 0 ipq: 56, 819, 0, 0, 0, 0 udp_inpcb: 304, 25608, 3, 33, 1990, 0 udpcb: 16, 25704, 3, 333, 1990, 0 tcp_inpcb: 304, 25608, 6, 42, 69, 0 tcpcb: 728, 25600, 3, 37, 69, 0 tcptw: 72, 5150, 3, 147, 9, 0 syncache: 144, 15366, 0, 0, 0, 0 hostcache: 136, 15372, 6, 78, 17, 0 tcpreass: 40, 1680, 0, 252, 13, 0 sackhole: 32, 0, 0, 0, 0, 0 sctp_ep: 1216, 25602, 0, 0, 0, 0 sctp_asoc: 2176, 40000, 0, 0, 0, 0 sctp_laddr: 48, 80064, 0, 216, 3, 0 sctp_raddr: 592, 80004, 0, 0, 0, 0 sctp_chunk: 144, 400010, 0, 0, 0, 0 sctp_readq: 104, 400032, 0, 0, 0, 0 sctp_stream_msg_out: 96, 400026, 0, 0, 0, 0 sctp_asconf: 40, 400008, 0, 0, 0, 0 sctp_asconf_ack: 48, 400032, 0, 0, 0, 0 ripcb: 304, 25608, 0, 0, 0, 0 rtentry: 200, 0, 8, 49, 10, 0 selfd: 56, 0, 178, 704, 11969875, 0 ip4flow: 56, 4158, 13, 302, 223, 0 ip6flow: 80, 4140, 0, 0, 0, 0 SWAPMETA: 288, 116519, 0, 0, 0, 0 Mountpoints: 752, 0, 5, 5, 5, 0 FFS inode: 168, 0, 7235, 91, 8437, 0 FFS1 dinode: 128, 0, 0, 0, 0, 0 FFS2 dinode: 256, 0, 7235, 70, 8402, 0 ------------------------------------------------------------------------ vmstat -i interrupt total rate irq1: atkbd0 3016 9 irq9: acpi0 1406 4 irq12: psm0 51129 160 irq19: uhci2 ehci* 17850 56 irq23: uhci3 ehci1 166495 523 cpu0: timer 996260 3132 irq257: hdac0 2962 9 cpu1: timer 996218 3132 irq258: 83563 262 Total 2318899 7292 ------------------------------------------------------------------------ pstat -T 266/12328 files 0M/8191M swap space ------------------------------------------------------------------------ pstat -s Device 512-blocks Used Avail Capacity /dev/ad4s2b 16776960 0 16776960 0% ------------------------------------------------------------------------ iostat iostat: kvm_read(_tk_nin): invalid address (0x0) iostat: disabling TTY statistics iostat: kvm_getcptime: invalid address (0x0) iostat: disabling CPU time statistics ad4 cd0 pass0 KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s 26.86 54 1.42 0.00 0 0.00 0.00 7 0.00 ------------------------------------------------------------------------ ipcs -a Message Queues: T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Shared Memory: T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME Semaphores: T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME ------------------------------------------------------------------------ ipcs -T msginfo: msgmax: 16384 (max characters in a message) msgmni: 40 (# of message queues) msgmnb: 2048 (max characters in a message queue) msgtql: 40 (max # of messages in system) msgssz: 8 (size of a message segment) msgseg: 2048 (# of message segments in system) shminfo: shmmax: 67108864 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 192 (max number of shared memory identifiers) shmseg: 128 (max shared memory segments per process) shmall: 32768 (max amount of shared memory in pages) seminfo: semmap: 30 (# of entries in semaphore map) semmni: 10 (# of semaphore identifiers) semmns: 60 (# of semaphores in system) semmnu: 30 (# of undo structures in system) semmsl: 60 (max # of semaphores per id) semopm: 100 (max # of operations per semop call) semume: 10 (max # of undo entries per process) semusz: 152 (size in bytes of undo structure) semvmx: 32767 (semaphore maximum value) semaem: 16384 (adjust on exit max value) ------------------------------------------------------------------------ nfsstat Client Info: Rpc Counts: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Rpc Info: TimedOut Invalid X Replies Retries Requests 0 0 0 0 0 Cache Info: Attr Hits Misses Lkup Hits Misses BioR Hits Misses BioW Hits Misses 0 0 0 0 0 0 0 0 BioRLHits Misses BioD Hits Misses DirE Hits Misses 0 0 0 0 0 0 Server Info: Getattr Setattr Lookup Readlink Read Write Create Remove 0 0 0 0 0 0 0 0 Rename Link Symlink Mkdir Rmdir Readdir RdirPlus Access 0 0 0 0 0 0 0 0 Mknod Fsstat Fsinfo PathConf Commit 0 0 0 0 0 Server Ret-Failed 0 Server Faults 0 Server Cache Stats: Inprog Idem Non-idem Misses 0 0 0 0 Server Write Gathering: WriteOps WriteRPC Opsaved 0 0 0 ------------------------------------------------------------------------ netstat -s netstat: /boot/kernel/kernel: no namelist ------------------------------------------------------------------------ netstat -m netstat: /boot/kernel/kernel: no namelist ------------------------------------------------------------------------ netstat -id netstat: /boot/kernel/kernel: no namelist ------------------------------------------------------------------------ netstat -anr netstat: /boot/kernel/kernel: no namelist ------------------------------------------------------------------------ netstat -anA netstat: /boot/kernel/kernel: no namelist ------------------------------------------------------------------------ netstat -aL netstat: /boot/kernel/kernel: no namelist ------------------------------------------------------------------------ fstat USER CMD PID FD MOUNT INUM MODE SZ|DV R/W lstewart gam_server 1570 root / 2 drwxr-xr-x 512 r lstewart gam_server 1570 wd /usr 847873 drwxr-xr-x 2560 r lstewart gam_server 1570 text /usr 11336399 -r-xr-xr-x 253742 r lstewart gam_server 1570 0 /dev 28 crw-rw-rw- null r lstewart gam_server 1570 1 /dev 28 crw-rw-rw- null w lstewart gam_server 1570 2 /dev 28 crw-rw-rw- null w lstewart gam_server 1570 4* local stream ffffff0087fa21e0 lstewart gam_server 1570 5* pipe ffffff008788c5b0 <-> ffffff008788c708 0 rw lstewart gam_server 1570 6* pipe ffffff008788c708 <-> ffffff008788c5b0 0 rw lstewart gconf-helper 1547 root / 2 drwxr-xr-x 512 r lstewart gconf-helper 1547 wd / 2 drwxr-xr-x 512 r lstewart gconf-helper 1547 text /usr 12650624 -r-xr-xr-x 15564 r lstewart gconf-helper 1547 0 /dev 28 crw-rw-rw- null r lstewart gconf-helper 1547 1* pipe ffffff0087a9d708 <-> ffffff0087a9d5b0 0 rw lstewart gconf-helper 1547 2 /dev 28 crw-rw-rw- null w lstewart gconf-helper 1547 3* local stream ffffff000c15a000 lstewart gconf-helper 1547 4* pipe ffffff000c1452d8 <-> ffffff000c145430 0 rw lstewart gconf-helper 1547 5* pipe ffffff000c145430 <-> ffffff000c1452d8 0 rw lstewart gconf-helper 1547 6* pipe ffffff000c145000 <-> ffffff000c145158 0 rw lstewart gconf-helper 1547 7* pipe ffffff000c145158 <-> ffffff000c145000 0 rw lstewart gconf-helper 1547 8* pipe ffffff0087b3a000 <-> ffffff0087b3a158 0 rw lstewart gconf-helper 1547 9* pipe ffffff0087b3a158 <-> ffffff0087b3a000 0 rw lstewart gconf-helper 1547 11* local stream ffffff000c7b6780 lstewart pulseaudio 1545 root / 2 drwxr-xr-x 512 r lstewart pulseaudio 1545 wd / 2 drwxr-xr-x 512 r lstewart pulseaudio 1545 text /usr 11334908 -r-sr-xr-x 87728 r lstewart pulseaudio 1545 0 /dev 28 crw-rw-rw- null r lstewart pulseaudio 1545 1 /dev 28 crw-rw-rw- null w lstewart pulseaudio 1545 2 /dev 28 crw-rw-rw- null w lstewart pulseaudio 1545 3* pipe ffffff0087f8e5b0 <-> ffffff0087f8e708 0 rw lstewart pulseaudio 1545 4* pipe ffffff0087f8e708 <-> ffffff0087f8e5b0 0 rw lstewart pulseaudio 1545 5* pipe ffffff0087f8e888 <-> ffffff0087f8e9e0 0 rw lstewart pulseaudio 1545 6* pipe ffffff0087f8e9e0 <-> ffffff0087f8e888 0 rw lstewart pulseaudio 1545 8* pipe ffffff000c146000 <-> ffffff000c146158 0 rw lstewart pulseaudio 1545 9* pipe ffffff000c146158 <-> ffffff000c146000 0 rw lstewart pulseaudio 1545 11* pipe ffffff0087a9d5b0 <-> ffffff0087a9d708 0 rw lstewart pulseaudio 1545 12 /usr 847960 -rw------- 13770 rw lstewart pulseaudio 1545 13 /usr 847962 -rw------- 13174 rw lstewart pulseaudio 1545 14* local stream ffffff0087a723c0 <-> ffffff0087a722d0 lstewart pulseaudio 1545 16* pipe ffffff000c79d2d8 <-> ffffff000c79d430 0 rw lstewart pulseaudio 1545 17* pipe ffffff000c79d430 <-> ffffff000c79d2d8 0 rw lstewart pulseaudio 1545 18* pipe ffffff000c79d000 <-> ffffff000c79d158 0 rw lstewart pulseaudio 1545 19* pipe ffffff000c79d158 <-> ffffff000c79d000 0 rw lstewart pulseaudio 1545 20* pipe ffffff000c79cb60 <-> ffffff000c79ccb8 0 rw lstewart pulseaudio 1545 21* pipe ffffff000c79ccb8 <-> ffffff000c79cb60 0 rw lstewart pulseaudio 1545 22* pipe ffffff000c79c888 <-> ffffff000c79c9e0 0 rw lstewart pulseaudio 1545 23* pipe ffffff000c79c9e0 <-> ffffff000c79c888 0 rw lstewart pulseaudio 1545 24 /dev 93 crw-rw-rw- mixer0 rw lstewart pulseaudio 1545 25* local stream ffffff000c7b60f0 lstewart pulseaudio 1545 26* local stream ffffff000c7b5e10 lstewart mysqld 1458 root / 2 drwxr-xr-x 512 r lstewart mysqld 1458 wd /usr 1086941 drwxr-xr-x 1024 r lstewart mysqld 1458 text /usr 11331259 -r-xr-xr-x 5771146 r lstewart mysqld 1458 0* pipe ffffff0087b385b0 <-> ffffff0087b38708 0 rw lstewart mysqld 1458 1 /usr 1084441 -rw-rw---- 411 rw lstewart mysqld 1458 2 /usr 1084441 -rw-rw---- 411 rw lstewart mysqld 1458 3 /usr 1088116 -rw-rw---- 12028978 w lstewart mysqld 1458 4 /dev 28 crw-rw-rw- null rw lstewart mysqld 1458 5 /usr 1088185 -rw-rw---- 133 rw lstewart mysqld 1458 6 /usr 12581279 drwxr-xr-x 512 r lstewart mysqld 1458 7 /usr 1088255 -rw-rw---- 10485760 rw lstewart mysqld 1458 8 /var 400657 -rw------- 0 rw lstewart mysqld 1458 9 /var 400666 -rw------- 0 rw lstewart mysqld 1458 10 /var 400668 -rw------- 0 rw lstewart mysqld 1458 11 /var 400618 -rw------- 0 rw lstewart mysqld 1458 12 /usr 1088378 -rw-rw---- 67108864 rw lstewart mysqld 1458 13 /usr 1088500 -rw-rw---- 67108864 rw lstewart mysqld 1458 14 /usr 1085827 -rw-rw---- 98 w lstewart mysqld 1458 15 /var 400696 -rw------- 0 rw lstewart mysqld 1458 16 /usr 1113734 -rw-rw---- 98304 rw lstewart mysqld 1458 17* local stream ffffff0087fa20f0 lstewart mysqld 1458 18 /usr 1113605 -rw-rw---- 114688 rw lstewart mysqld 1458 20 /usr 1111817 -rw-rw---- 98304 rw lstewart mysqld 1458 21 /usr 1111888 -rw-rw---- 114688 rw lstewart mysqld 1458 22 /usr 1112131 -rw-rw---- 114688 rw lstewart mysqld 1458 23 /usr 1112180 -rw-rw---- 114688 rw lstewart mysqld 1458 24 /usr 1112865 -rw-rw---- 114688 rw lstewart mysqld 1458 25 /usr 1113281 -rw-rw---- 114688 rw lstewart mysqld 1458 26 /usr 1113445 -rw-rw---- 114688 rw lstewart mysqld 1458 27 /usr 1113730 -rw-rw---- 98304 rw lstewart mysqld 1458 28 /usr 1113738 -rw-rw---- 98304 rw lstewart sh 1440 root / 2 drwxr-xr-x 512 r lstewart sh 1440 wd / 2 drwxr-xr-x 512 r lstewart sh 1440 text / 753693 -r-xr-xr-x 445829 r lstewart sh 1440 0* pipe ffffff0087b385b0 <-> ffffff0087b38708 0 rw lstewart sh 1440 1* pipe ffffff0087b38430 <-> ffffff0087b382d8 0 rw lstewart sh 1440 2* pipe ffffff0087b38158 <-> ffffff0087b38000 0 rw lstewart sh 1440 4 /dev 28 crw-rw-rw- null rw lstewart sh 1440 6 /usr 12581279 drwxr-xr-x 512 r lstewart sh 1440 10 /usr 11329460 -r-xr-xr-x 13078 r lstewart akonadiserver 1438 root / 2 drwxr-xr-x 512 r lstewart akonadiserver 1438 wd / 2 drwxr-xr-x 512 r lstewart akonadiserver 1438 text /usr 11517041 -rwxr-xr-x 58544 r lstewart akonadiserver 1438 0* pipe ffffff0087b3ab60 <-> ffffff0087b3acb8 0 rw lstewart akonadiserver 1438 1* pipe ffffff0087b3a9e0 <-> ffffff0087b3a888 0 rw lstewart akonadiserver 1438 2* pipe ffffff0087b3a708 <-> ffffff0087b3a5b0 0 rw lstewart akonadiserver 1438 3* pipe ffffff0087b392d8 <-> ffffff0087b39430 0 rw lstewart akonadiserver 1438 4 /dev 28 crw-rw-rw- null rw lstewart akonadiserver 1438 5* pipe ffffff0087b39430 <-> ffffff0087b392d8 0 rw lstewart akonadiserver 1438 6 /usr 12581279 drwxr-xr-x 512 r lstewart akonadiserver 1438 7* pipe ffffff0087b39000 <-> ffffff0087b39158 0 rw lstewart akonadiserver 1438 8* pipe ffffff0087b39158 <-> ffffff0087b39000 0 rw lstewart akonadiserver 1438 9* local stream ffffff0087861c30 lstewart akonadiserver 1438 10* local stream ffffff000c1595a0 lstewart akonadiserver 1438 12* pipe ffffff0087b38888 <-> ffffff0087b389e0 0 rw lstewart akonadiserver 1438 13* pipe ffffff0087b389e0 <-> ffffff0087b38888 0 rw lstewart akonadiserver 1438 15* pipe ffffff0087b38708 <-> ffffff0087b385b0 0 rw lstewart akonadiserver 1438 16* pipe ffffff0087b382d8 <-> ffffff0087b38430 0 rw lstewart akonadiserver 1438 18* pipe ffffff0087b38000 <-> ffffff0087b38158 0 rw lstewart akonadiserver 1438 20* pipe ffffff00876b1888 <-> ffffff00876b19e0 0 rw lstewart akonadiserver 1438 21* pipe ffffff00876b19e0 <-> ffffff00876b1888 0 rw lstewart akonadi_control 1435 root / 2 drwxr-xr-x 512 r lstewart akonadi_control 1435 wd / 2 drwxr-xr-x 512 r lstewart akonadi_control 1435 text /usr 11517630 -rwxr-xr-x 208464 r lstewart akonadi_control 1435 0 /dev 28 crw-rw-rw- null rw lstewart akonadi_control 1435 1 /dev 28 crw-rw-rw- null rw lstewart akonadi_control 1435 2 /dev 28 crw-rw-rw- null rw lstewart akonadi_control 1435 3* pipe ffffff00877cb888 <-> ffffff00877cb9e0 0 rw lstewart akonadi_control 1435 4 /dev 28 crw-rw-rw- null rw lstewart akonadi_control 1435 5* pipe ffffff00877cb9e0 <-> ffffff00877cb888 0 rw lstewart akonadi_control 1435 6 /usr 12581279 drwxr-xr-x 512 r lstewart akonadi_control 1435 7* pipe ffffff008725b888 <-> ffffff008725b9e0 0 rw lstewart akonadi_control 1435 8* pipe ffffff008725b9e0 <-> ffffff008725b888 0 rw lstewart akonadi_control 1435 11* pipe ffffff008710fb60 <-> ffffff008710fcb8 0 rw lstewart akonadi_control 1435 12* pipe ffffff008710fcb8 <-> ffffff008710fb60 0 rw lstewart akonadi_control 1435 13 /usr 11529599 -rwxr-xr-x 114072 r lstewart akonadi_control 1435 15* pipe ffffff0087b3b000 <-> ffffff0087b3b158 0 rw lstewart akonadi_control 1435 16* pipe ffffff0087b3b158 <-> ffffff0087b3b000 0 rw lstewart akonadi_control 1435 18* pipe ffffff0087b3acb8 <-> ffffff0087b3ab60 0 rw lstewart akonadi_control 1435 19* pipe ffffff0087b3a888 <-> ffffff0087b3a9e0 0 rw lstewart akonadi_control 1435 20 /usr 11529575 -rwxr-xr-x 106584 r lstewart akonadi_control 1435 21* pipe ffffff0087b3a5b0 <-> ffffff0087b3a708 0 rw lstewart akonadi_control 1435 22 /usr 11529595 -rwxr-xr-x 119840 r lstewart akonadi_control 1435 23* pipe ffffff00873c0b60 <-> ffffff00873c0cb8 0 rw lstewart akonadi_control 1435 24* pipe ffffff00873c0cb8 <-> ffffff00873c0b60 0 rw lstewart akonadi_control 1435 25 /usr 11529587 -rwxr-xr-x 117800 r lstewart akonadi_control 1435 26 /usr 11529589 -rwxr-xr-x 110616 r lstewart akonadi_control 1435 27 /usr 11529573 -rwxr-xr-x 75040 r lstewart akonadi_control 1435 28 /usr 11529585 -rwxr-xr-x 45056 r lstewart akonadi_control 1435 29 /usr 11529577 -rwxr-xr-x 70248 r lstewart akonadi_control 1435 30 /usr 11529601 -rwxr-xr-x 41904 r lstewart akonadi_control 1435 31 /usr 11529607 -rwxr-xr-x 382464 r lstewart akonadi_control 1435 32 /usr 11529605 -rwxr-xr-x 329248 r lstewart akonadi_control 1435 33 /usr 11529597 -rwxr-xr-x 29848 r lstewart akonadi_control 1435 34 /usr 11529579 -rwxr-xr-x 123008 r lstewart akonadi_control 1435 35 /usr 11529603 -rwxr-xr-x 16624 r lstewart akonadi_control 1435 36 /usr 11529583 -rwxr-xr-x 37744 r lstewart akonadi_control 1435 37 /usr 11529581 -rwxr-xr-x 106696 r lstewart akonadi_control 1435 39* pipe ffffff000c146b60 <-> ffffff000c146cb8 0 rw lstewart akonadi_control 1435 40* pipe ffffff000c146cb8 <-> ffffff000c146b60 0 rw lstewart akonadi_control 1435 41 /usr 11587589 drwxr-xr-x 1024 r _dhcp dhclient 1323 root /var 141312 dr-xr-xr-x 512 r _dhcp dhclient 1323 wd /var 141312 dr-xr-xr-x 512 r _dhcp dhclient 1323 jail /var 141312 dr-xr-xr-x 512 r _dhcp dhclient 1323 text / 635988 -r-xr-xr-x 258207 r _dhcp dhclient 1323 0 /dev 28 crw-rw-rw- null rw _dhcp dhclient 1323 1 /dev 28 crw-rw-rw- null rw _dhcp dhclient 1323 2 /dev 28 crw-rw-rw- null rw _dhcp dhclient 1323 3* local dgram ffffff004d8171e0 <-> ffffff00048e7960 _dhcp dhclient 1323 5* route raw 0 ffffff004d815550 _dhcp dhclient 1323 6* pipe ffffff00047da9e0 <-> ffffff00047da888 0 rw _dhcp dhclient 1323 7 /var 94347 ---------- 736 w _dhcp dhclient 1323 8 /dev 13 crw------- bpf rw root dhclient 1289 root / 2 drwxr-xr-x 512 r root dhclient 1289 wd / 329728 drwxr-xr-x 1536 r root dhclient 1289 text / 635988 -r-xr-xr-x 258207 r root dhclient 1289 0 /dev 28 crw-rw-rw- null rw root dhclient 1289 1 /dev 28 crw-rw-rw- null rw root dhclient 1289 2 /dev 28 crw-rw-rw- null rw root dhclient 1289 3* local dgram ffffff004d8171e0 <-> ffffff00048e7960 root dhclient 1289 5* pipe ffffff00047da888 <-> ffffff00047da9e0 0 rw root wpa_supplicant 1279 root / 2 drwxr-xr-x 512 r root wpa_supplicant 1279 wd / 2 drwxr-xr-x 512 r root wpa_supplicant 1279 text /usr 8384660 -r-xr-xr-x 1229643 r root wpa_supplicant 1279 0 /dev 28 crw-rw-rw- null rw root wpa_supplicant 1279 1 /dev 28 crw-rw-rw- null rw root wpa_supplicant 1279 2 /dev 28 crw-rw-rw- null rw root wpa_supplicant 1279 3* internet dgram udp ffffff00048e3d10 root wpa_supplicant 1279 4* route raw 0 ffffff004d815000 root wpa_supplicant 1279 5 /dev 13 crw------- bpf rw root wpa_supplicant 1279 6* local dgram ffffff004d8172d0 root kdm-bin 1182 root / 2 drwxr-xr-x 512 r root kdm-bin 1182 wd / 329728 drwxr-xr-x 1536 r root kdm-bin 1182 text /usr 11531509 -rwxr-xr-x 142520 r root kdm-bin 1182 0 /dev 28 crw-rw-rw- null r root kdm-bin 1182 1 /var 447520 -rw-r--r-- 614627 w root kdm-bin 1182 2 /var 447520 -rw-r--r-- 614627 w root kdm-bin 1182 3 /var 70687 -rw-r--r-- 5 rw root kdm-bin 1182 4* pipe ffffff000482b000 <-> ffffff000482b158 0 rw root kdm-bin 1182 5* pipe ffffff000482b158 <-> ffffff000482b000 0 rw root csh 1168 root / 2 drwxr-xr-x 512 r root csh 1168 wd / 329728 drwxr-xr-x 1536 r root csh 1168 text / 753691 -r-xr-xr-x 1166991 r root csh 1168 15 - - bad - root csh 1168 16 - - bad - root csh 1168 17 - - bad - root csh 1168 18 - - bad - root csh 1168 19 - - bad - root hald-addon-storage 1154 root / 2 drwxr-xr-x 512 r root hald-addon-storage 1154 wd /usr 11328529 drwxr-xr-x 2560 r root hald-addon-storage 1154 text /usr 11334582 -r-xr-xr-x 19794 r root hald-addon-storage 1154 0 /dev 28 crw-rw-rw- null r root hald-addon-storage 1154 1 /dev 28 crw-rw-rw- null rw root hald-addon-storage 1154 2 /dev 28 crw-rw-rw- null rw root hald-addon-storage 1154 3* local stream ffffff000499ce10 <-> ffffff000499cd20 root hald-addon-storage 1154 4* local stream ffffff000499c3c0 <-> ffffff000499c4b0 root hald-addon-mouse-s 1127 root / 2 drwxr-xr-x 512 r root hald-addon-mouse-s 1127 wd /usr 11328529 drwxr-xr-x 2560 r root hald-addon-mouse-s 1127 text /usr 11334583 -r-xr-xr-x 15899 r root hald-addon-mouse-s 1127 0 /dev 28 crw-rw-rw- null r root hald-addon-mouse-s 1127 1 /dev 28 crw-rw-rw- null rw root hald-addon-mouse-s 1127 2 /dev 28 crw-rw-rw- null rw root hald-addon-mouse-s 1127 3* local stream ffffff00048e70f0 <-> ffffff00048e6000 root hald-runner 1122 root / 2 drwxr-xr-x 512 r root hald-runner 1122 wd / 2 drwxr-xr-x 512 r root hald-runner 1122 text /usr 11334586 -r-xr-xr-x 26841 r root hald-runner 1122 0 /dev 28 crw-rw-rw- null r root hald-runner 1122 1 /dev 28 crw-rw-rw- null rw root hald-runner 1122 2 /dev 28 crw-rw-rw- null rw root hald-runner 1122 3* local stream ffffff00048e6960 <-> ffffff00048e6a50 root console-kit-daemon 1121 root / 2 drwxr-xr-x 512 r root console-kit-daemon 1121 wd / 2 drwxr-xr-x 512 r root console-kit-daemon 1121 text /usr 11334387 -r-xr-xr-x 171254 r root console-kit-daemon 1121 0 /dev 28 crw-rw-rw- null rw root console-kit-daemon 1121 1 /dev 28 crw-rw-rw- null rw root console-kit-daemon 1121 2 /dev 28 crw-rw-rw- null rw root console-kit-daemon 1121 3* pipe ffffff00047e42d8 <-> ffffff00047e4430 0 rw root console-kit-daemon 1121 4 /dev 28 crw-rw-rw- null rw root console-kit-daemon 1121 5* pipe ffffff00047e4430 <-> ffffff00047e42d8 0 rw root console-kit-daemon 1121 6 /usr 11447071 drwxr-xr-x 512 r root console-kit-daemon 1121 7* pipe ffffff00047e4b60 <-> ffffff00047e4cb8 0 rw root console-kit-daemon 1121 8* pipe ffffff00047e4cb8 <-> ffffff00047e4b60 0 rw root console-kit-daemon 1121 9* local stream ffffff00048e73c0 <-> ffffff00048e72d0 root console-kit-daemon 1121 10 /var 447540 -rw-r--r-- 94874 w root console-kit-daemon 1121 11 /usr 11823494 -r--r--r-- 403 r root console-kit-daemon 1121 12 /dev 4 crw------- console r root console-kit-daemon 1121 14 /usr 11447535 drwxr-xr-x 512 r root console-kit-daemon 1121 15 /var 423947 -rw-rw-r-- 0 r root console-kit-daemon 1121 18* local dgram ffffff004d817000 <-> ffffff00048e7960 haldaemo hald 1118 root / 2 drwxr-xr-x 512 r haldaemo hald 1118 wd / 2 drwxr-xr-x 512 r haldaemo hald 1118 text /usr 11334585 -r-xr-xr-x 356456 r haldaemo hald 1118 0 /dev 28 crw-rw-rw- null rw haldaemo hald 1118 1 /dev 28 crw-rw-rw- null rw haldaemo hald 1118 2 /dev 28 crw-rw-rw- null rw haldaemo hald 1118 5* pipe ffffff000482b2d8 <-> ffffff000482b430 0 rw haldaemo hald 1118 6* pipe ffffff000482b430 <-> ffffff000482b2d8 0 rw haldaemo hald 1118 7* local stream ffffff00048e62d0 haldaemo hald 1118 8* local stream ffffff00048e61e0 <-> ffffff00048e60f0 haldaemo hald 1118 9* local stream ffffff00048e6870 haldaemo hald 1118 10* local stream ffffff00048e6a50 <-> ffffff00048e6960 haldaemo hald 1118 12 /dev 32 crw-r--r-- pci rw haldaemo hald 1118 13 /dev 36 crw------- ata r haldaemo hald 1118 14 /dev 82 crw------- xpt0 rw haldaemo hald 1118 16 /usr 11823494 -r--r--r-- 403 r haldaemo hald 1118 17 /usr 11447535 drwxr-xr-x 512 r haldaemo hald 1118 18 /var 423947 -rw-rw-r-- 0 r haldaemo hald 1118 19 /usr 11588148 drwxr-xr-x 512 r haldaemo hald 1118 20 /usr 11588150 drwxr-xr-x 512 r haldaemo hald 1118 21 /usr 11588149 drwxr-xr-x 512 r haldaemo hald 1118 22 /usr 11588151 drwxr-xr-x 512 r haldaemo hald 1118 23 /usr 11588127 drwxr-xr-x 512 r haldaemo hald 1118 24 /usr 11588130 drwxr-xr-x 512 r haldaemo hald 1118 25 /usr 11588128 drwxr-xr-x 512 r haldaemo hald 1118 26 /usr 11588129 -r--r--r-- 1656 r haldaemo hald 1118 27 /usr 11588133 drwxr-xr-x 512 r haldaemo hald 1118 28 /usr 11588134 drwxr-xr-x 512 r haldaemo hald 1118 29 /usr 11588146 drwxr-xr-x 512 r haldaemo hald 1118 30 /usr 11588135 drwxr-xr-x 512 r haldaemo hald 1118 31 /usr 11588145 -r--r--r-- 1609 r haldaemo hald 1118 32 /usr 11588144 -r--r--r-- 19472 r haldaemo hald 1118 33 /usr 11588143 -r--r--r-- 1214 r haldaemo hald 1118 34 /usr 11588142 -r--r--r-- 541 r haldaemo hald 1118 35 /usr 11588141 -r--r--r-- 913 r haldaemo hald 1118 36 /usr 11588140 -r--r--r-- 1153 r haldaemo hald 1118 37 /usr 11588139 -r--r--r-- 4038 r haldaemo hald 1118 38 /usr 11588155 -r--r--r-- 257 r haldaemo hald 1118 39 /usr 11588138 -r--r--r-- 1352 r haldaemo hald 1118 40 /usr 11588136 -r--r--r-- 795 r haldaemo hald 1118 41 /usr 11588137 -r--r--r-- 720 r haldaemo hald 1118 42 /usr 11588147 drwxr-xr-x 512 r haldaemo hald 1118 43* local stream ffffff00048e6b40 <-> ffffff00048e6c30 haldaemo hald 1118 44* local stream ffffff00048e6000 <-> ffffff00048e70f0 haldaemo hald 1118 45* local stream ffffff000499cd20 <-> ffffff000499ce10 root getty 1113 root / 2 drwxr-xr-x 512 r root getty 1113 wd / 2 drwxr-xr-x 512 r root getty 1113 text /usr 14696478 -r-xr-xr-x 71280 r root getty 1113 0 /dev 52 crw------- ttyv7 rw root getty 1113 1 /dev 52 crw------- ttyv7 rw root getty 1113 2 /dev 52 crw------- ttyv7 rw root getty 1112 root / 2 drwxr-xr-x 512 r root getty 1112 wd / 2 drwxr-xr-x 512 r root getty 1112 text /usr 14696478 -r-xr-xr-x 71280 r root getty 1112 0 /dev 51 crw------- ttyv6 rw root getty 1112 1 /dev 51 crw------- ttyv6 rw root getty 1112 2 /dev 51 crw------- ttyv6 rw root getty 1111 root / 2 drwxr-xr-x 512 r root getty 1111 wd / 2 drwxr-xr-x 512 r root getty 1111 text /usr 14696478 -r-xr-xr-x 71280 r root getty 1111 0 /dev 50 crw------- ttyv5 rw root getty 1111 1 /dev 50 crw------- ttyv5 rw root getty 1111 2 /dev 50 crw------- ttyv5 rw root getty 1110 root / 2 drwxr-xr-x 512 r root getty 1110 wd / 2 drwxr-xr-x 512 r root getty 1110 text /usr 14696478 -r-xr-xr-x 71280 r root getty 1110 0 /dev 49 crw------- ttyv4 rw root getty 1110 1 /dev 49 crw------- ttyv4 rw root getty 1110 2 /dev 49 crw------- ttyv4 rw root getty 1109 root / 2 drwxr-xr-x 512 r root getty 1109 wd / 2 drwxr-xr-x 512 r root getty 1109 text /usr 14696478 -r-xr-xr-x 71280 r root getty 1109 0 /dev 48 crw------- ttyv3 rw root getty 1109 1 /dev 48 crw------- ttyv3 rw root getty 1109 2 /dev 48 crw------- ttyv3 rw root getty 1108 root / 2 drwxr-xr-x 512 r root getty 1108 wd / 2 drwxr-xr-x 512 r root getty 1108 text /usr 14696478 -r-xr-xr-x 71280 r root getty 1108 0 /dev 47 crw------- ttyv2 rw root getty 1108 1 /dev 47 crw------- ttyv2 rw root getty 1108 2 /dev 47 crw------- ttyv2 rw root cron 1054 root / 2 drwxr-xr-x 512 r root cron 1054 wd /var 117760 drwxr-x--- 512 r root cron 1054 text /usr 8384817 -r-xr-xr-x 126750 r root cron 1054 0 /dev 28 crw-rw-rw- null rw root cron 1054 1 /dev 28 crw-rw-rw- null rw root cron 1054 2 /dev 28 crw-rw-rw- null rw root cron 1054 3 /var 70696 -rw------- 4 w smmsp sendmail 1043 root / 2 drwxr-xr-x 512 r smmsp sendmail 1043 wd /var 565254 drwxrwx--- 512 r smmsp sendmail 1043 text /usr 14696489 -r-xr-sr-x 2636342 r smmsp sendmail 1043 0 /dev 28 crw-rw-rw- null r smmsp sendmail 1043 1 /dev 28 crw-rw-rw- null w smmsp sendmail 1043 2 /dev 28 crw-rw-rw- null w smmsp sendmail 1043 3* local dgram ffffff00048e74b0 <-> ffffff00048e7a50 smmsp sendmail 1043 4 /var 565256 -rw------- 50 w root sendmail 1039 root / 2 drwxr-xr-x 512 r root sendmail 1039 wd /var 565251 drwxr-xr-x 512 r root sendmail 1039 text /usr 14696489 -r-xr-sr-x 2636342 r root sendmail 1039 0 /dev 28 crw-rw-rw- null r root sendmail 1039 1 /dev 28 crw-rw-rw- null w root sendmail 1039 2 /dev 28 crw-rw-rw- null w root sendmail 1039 3* local dgram ffffff00048e63c0 <-> ffffff00048e7960 root sendmail 1039 4* internet stream tcp ffffff0004ada2d8 root sendmail 1039 5 /var 70695 -rw------- 79 w root sshd 1032 root / 2 drwxr-xr-x 512 r root sshd 1032 wd / 2 drwxr-xr-x 512 r root sshd 1032 text /usr 8384527 -r-xr-xr-x 864049 r root sshd 1032 0 /dev 28 crw-rw-rw- null rw root sshd 1032 1 /dev 28 crw-rw-rw- null rw root sshd 1032 2 /dev 28 crw-rw-rw- null rw root sshd 1032 3* internet6 stream tcp ffffff0004a7b000 root sshd 1032 4* internet stream tcp ffffff0004a70b60 messageb dbus-daemon 985 root / 2 drwxr-xr-x 512 r messageb dbus-daemon 985 wd / 2 drwxr-xr-x 512 r messageb dbus-daemon 985 text /usr 11330972 -r-xr-xr-x 433696 r messageb dbus-daemon 985 0 /dev 28 crw-rw-rw- null rw messageb dbus-daemon 985 1 /dev 28 crw-rw-rw- null rw messageb dbus-daemon 985 2 /dev 28 crw-rw-rw- null rw messageb dbus-daemon 985 3* local stream ffffff00048e64b0 messageb dbus-daemon 985 4 /dev 28 crw-rw-rw- null rw messageb dbus-daemon 985 6 /usr 11447071 drwxr-xr-x 512 r messageb dbus-daemon 985 7* local stream ffffff00048e7870 <-> ffffff00048e7780 messageb dbus-daemon 985 8* local stream ffffff00048e7780 <-> ffffff00048e7870 messageb dbus-daemon 985 9* local stream ffffff00048e60f0 <-> ffffff00048e61e0 messageb dbus-daemon 985 10* local stream ffffff000499c4b0 <-> ffffff000499c3c0 messageb dbus-daemon 985 11* local stream ffffff00048e72d0 <-> ffffff00048e73c0 messageb dbus-daemon 985 15* local dgram ffffff004d817e10 <-> ffffff00048e7a50 messageb dbus-daemon 985 23* local stream ffffff0087a722d0 <-> ffffff0087a723c0 root moused 962 root / 2 drwxr-xr-x 512 r root moused 962 wd / 2 drwxr-xr-x 512 r root moused 962 text /usr 8384892 -r-xr-xr-x 88219 r root moused 962 0 /dev 28 crw-rw-rw- null rw root moused 962 1 /dev 28 crw-rw-rw- null rw root moused 962 2 /dev 28 crw-rw-rw- null rw root moused 962 3 /dev 43 crw-rw-rw- psm0 rw root moused 962 4 /dev 61 crw------- consolectl rw root moused 962 5 /var 70689 -rw------- 3 w root powerd 904 root / 2 drwxr-xr-x 512 r root powerd 904 wd / 2 drwxr-xr-x 512 r root powerd 904 text /usr 8384932 -r-xr-xr-x 35478 r root powerd 904 0 /dev 28 crw-rw-rw- null rw root powerd 904 1 /dev 28 crw-rw-rw- null rw root powerd 904 2 /dev 28 crw-rw-rw- null rw root powerd 904 3 /var 70686 -rw------- 3 w root powerd 904 4* local stream ffffff00048e6690 <-> ffffff00048e65a0 root syslogd 708 root / 2 drwxr-xr-x 512 r root syslogd 708 wd / 2 drwxr-xr-x 512 r root syslogd 708 text /usr 8384639 -r-xr-xr-x 103506 r root syslogd 708 0 /dev 28 crw-rw-rw- null rw root syslogd 708 1 /dev 28 crw-rw-rw- null rw root syslogd 708 2 /dev 28 crw-rw-rw- null rw root syslogd 708 3 /var 70680 -rw------- 3 w root syslogd 708 4* local dgram ffffff00048e7a50 root syslogd 708 5* local dgram ffffff00048e7960 root syslogd 708 6* internet6 dgram udp ffffff00048e3260 root syslogd 708 7* internet dgram udp ffffff00048e3130 root syslogd 708 8 /dev 30 crw------- klog r root syslogd 708 10 /dev 4 crw------- console w root syslogd 708 11 /var 447517 -rw-r--r-- 1725 w root syslogd 708 12 /var 447499 -rw------- 70 w root syslogd 708 13 /var 447503 -rw------- 68698 w root syslogd 708 14 /var 447508 -rw-r----- 5136 w root syslogd 708 15 /var 447495 -rw-r--r-- 70 w root syslogd 708 16 /var 447500 -rw------- 70 w root syslogd 708 17 /var 447512 -rw------- 6357 w root syslogd 708 18 /var 447494 -rw------- 1183 w root syslogd 708 19 /var 447498 -rw-r----- 70 w root devd 593 root / 2 drwxr-xr-x 512 r root devd 593 wd / 2 drwxr-xr-x 512 r root devd 593 text / 635938 -r-xr-xr-x 2195345 r root devd 593 0 /dev 28 crw-rw-rw- null rw root devd 593 1 /dev 28 crw-rw-rw- null rw root devd 593 2 /dev 28 crw-rw-rw- null rw root devd 593 3 / 989539 drwxr-xr-x 512 r root devd 593 4 /dev 7 crw------- devctl r root devd 593 5* local stream ffffff00048e6d20 root devd 593 6 /var 70674 -rw------- 3 w root devd 593 7* local stream ffffff00048e65a0 <-> ffffff00048e6690 root devd 593 8* local stream ffffff00048e6c30 <-> ffffff00048e6b40 root adjkerntz 141 root / 2 drwxr-xr-x 512 r root adjkerntz 141 wd / 2 drwxr-xr-x 512 r root adjkerntz 141 text / 635917 -r-xr-xr-x 22310 r root adjkerntz 141 0 /dev 28 crw-rw-rw- null rw root adjkerntz 141 1 /dev 28 crw-rw-rw- null rw root adjkerntz 141 2 /dev 28 crw-rw-rw- null rw root init 1 root / 2 drwxr-xr-x 512 r root init 1 wd / 2 drwxr-xr-x 512 r root init 1 text / 636000 -r-xr-xr-x 3284189 r root kernel 0 root / 2 drwxr-xr-x 512 r root kernel 0 wd / 2 drwxr-xr-x 512 r ------------------------------------------------------------------------ dmesg Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #35 r195046: Fri Jun 26 12:28:02 BST 2009 lstewart@lstewart-laptop:/usr/obj/usr/src/sys/LAPTOP WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Duo CPU U9400 @ 1.40GHz (1396.51-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x10676 Stepping = 6 Features=0xbfebfbff Features2=0x8e3fd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 3221225472 (3072 MB) avail memory = 2944716800 (2808 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] ACPI Error: Package List length (C) larger than NumElements count (4), truncated 20090521 dsobject-590 acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, b6890000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xd808-0xd80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xcff8-0xcfff mem 0xff400000-0xff7fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 131068k stolen memory agp0: aperture size is 256M vgapci1: mem 0xffc00000-0xffcfffff at device 2.1 on pci0 pci0: at device 3.0 (no driver attached) em0: port 0xcf80-0xcf9f mem 0xff9c0000-0xff9dffff,0xff9fe000-0xff9fefff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1c:7e:81:4a:bd uhci0: port 0xcf60-0xcf7f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x0010 usbus0: on uhci0 uhci1: port 0xcf40-0xcf5f irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x0010 usbus1: on uhci1 uhci2: port 0xcf20-0xcf3f irq 19 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x0010 usbus2: on uhci2 ehci0: mem 0xff9fd000-0xff9fd3ff irq 19 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 hdac0: mem 0xff9f8000-0xff9fbfff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20090624_0136 hdac0: [ITHREAD] pcib1: irq 17 at device 28.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: irq 19 at device 28.3 on pci0 pci2: on pcib2 uhci3: port 0x9fe0-0x9fff irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x0010 usbus4: on uhci3 uhci4: port 0x9f80-0x9f9f irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x0010 usbus5: on uhci4 uhci5: port 0x9f60-0x9f7f irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] uhci5: LegSup = 0x0010 usbus6: on uhci5 ehci1: mem 0xff9fc000-0xff9fc3ff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib3: at device 30.0 on pci0 pci4: on pcib3 pci4: at device 11.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x9f58-0x9f5f,0x9f54-0x9f57,0x9f48-0x9f4f,0x9f44-0x9f47,0x9f20-0x9f3f mem 0xff9f7000-0xff9f77ff irq 19 at device 31.2 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.20 controller with 4 1.5Gbps ports, PM not supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] acpi_lid0: on acpi0 battery0: on acpi0 acpi_button0: on acpi0 acpi_acad0: 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 GlidePoint, device ID 0 atrtc0: port 0x70-0x71 irq 8 on acpi0 cpu0: on acpi0 ACPI Warning: Incorrect checksum in table [ASF!] - C8, should be 5E 20090521 tbutils-275 est0: on cpu0 cpu1: on acpi0 est1: on cpu1 orm0: at iomem 0xc0000-0xcffff,0xd0000-0xd0fff,0xd1000-0xd3fff,0xe8000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: cannot reserve I/O port range Timecounters tick every 10.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ad4: 190782MB at ata2-master SATA150 ACPI Warning: \\_SB_.BAT1._BIF: Return Package type mismatch at index 12 - found Integer, expected String 20090521 nspredef-1058 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 hdac0: HDA Codec #0: Realtek ALC262 pcm0: at cad 0 nid 1 on hdac0 pcm1: at cad 0 nid 1 on hdac0 SMP: AP CPU #1 Launched! WARNING: WITNESS option enabled, expect reduced performance. GEOM: ad4s2: geometry does not match label (255h,63s != 16h,63s). uhub1: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered Root mount waiting for: usbus7 ugen7.2: at usbus7 rum0: on usbus7 rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 Root mount waiting for: usbus7 ugen7.3: at usbus7 Root mount waiting for: usbus7 ugen7.4: at usbus7 umass0: on usbus7 umass0: 8070i (ATAPI) over Bulk-Only; quirks = 0x0000 Root mount waiting for: usbus7 umass0:1:0:-1: Attached to scbus1 Root mount waiting for: usbus7 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:29,0 (probe0:umass-sim0:0:0:0): Power on, reset, or bus device reset occurred (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) Trying to mount root from ufs:/dev/ad4s2a (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): NOT READY asc:3a,1 (probe0:umass-sim0:0:0:0): Medium not present - tray closed (probe0:umass-sim0:0:0:0): Unretryable error cd0 at umass-sim0 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 40.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Entropy harvesting: interrupts ethernet point_to_point kickstart . /dev/ad4s2a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad4s2a: clean, 4570204 free (740 frags, 571183 blocks, 0.0% fragmentation) /dev/ad4s2e: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad4s2e: clean, 2521111 free (207 frags, 315113 blocks, 0.0% fragmentation) /dev/ad4s2f: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad4s2f: clean, 51942866 free (402042 frags, 6442603 blocks, 0.6% fragmentation) ugen5.2: at usbus5 /dev/ad4s2d: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad4s2d: clean, 1663327 free (2207 frags, 207640 blocks, 0.1% fragmentation) em0: no link ... . . . . . . . . . . . giving up Starting Network: lo0 em0. Additional ABI support: linux . lock order reversal: 1st 0xffffff803b1a6880 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2558 2nd 0xffffff00048b6c00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_add() at ufsdirhash_add+0x19 ufs_direnter() at ufs_direnter+0x88b ufs_mkdir() at ufs_mkdir+0x623 VOP_MKDIR_APV() at VOP_MKDIR_APV+0x93 kern_mkdirat() at kern_mkdirat+0x298 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (136, FreeBSD ELF64, mkdir), rip = 0x800729d9c, rsp = 0x7fffffffec88, rbp = 0x7fffffffef66 --- Starting hald. Configuring syscons: keymap blanktime . Local package initialization: (skipping /usr/local/etc/rc.d/usbpwrconfig.sh, not executable) . Mon Jun 29 00:21:18 BST 2009 Jun 29 00:21:25 lstewart-laptop login: ROOT LOGIN (root) ON ttyv1 drm0: on vgapci0 lock order reversal: 1st 0xffffffff80e1d760 msi (msi) @ /usr/src/sys/amd64/amd64/msi.c:295 2nd 0xffffffff80dd85e0 intr sources (intr sources) @ /usr/src/sys/amd64/amd64/intr_machdep.c:444 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 intr_next_cpu() at intr_next_cpu+0x3c msi_alloc() at msi_alloc+0xd7 pci_alloc_msi_method() at pci_alloc_msi_method+0x18b vga_pci_alloc_msi() at vga_pci_alloc_msi+0x95 drm_attach() at drm_attach+0x6f7 device_attach() at device_attach+0x69 bus_generic_driver_added() at bus_generic_driver_added+0x65 devclass_driver_added() at devclass_driver_added+0x69 driver_module_handler() at driver_module_handler+0x16a module_register_init() at module_register_init+0x7d linker_load_module() at linker_load_module+0x9a2 kern_kldload() at kern_kldload+0xac kldload() at kldload+0x84 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (304, FreeBSD ELF64, kldload), rip = 0x80199cb4c, rsp = 0x7fffffffe718, rbp = 0x9 --- info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] AGP at 0xe0000000 256MB info: [drm] Initialized i915 1.6.0 20080730 drm0: [ITHREAD] wlan0: Ethernet address: 00:22:b0:51:9e:63 wlan0: link state changed to UP rum0: need multicast update callback rum0: need multicast update callback rum0: need multicast update callback drm0: [ITHREAD] Jun 29 00:22:28 lstewart-laptop dbus-daemon: Would reject message, 1 matched rules; type="method_call", sender=":1.6" (uid=1001 pid=1388 comm=") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.ConsoleKit" (uid=0 pid=1121 comm=")) lock order reversal: 1st 0xffffff000c43d048 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1088 2nd 0xffffff004dee6448 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:4092 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xcf3 ffs_lock() at ffs_lock+0x8c VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 knlist_remove_kq() at knlist_remove_kq+0x67 knote_fdclose() at knote_fdclose+0x177 kern_close() at kern_close+0xe9 syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xd0 --- syscall (6, FreeBSD ELF64, close), rip = 0x80109df5c, rsp = 0x7fffffffdf88, rbp = 0x80242d550 --- pid 1407 (nepomukservicestub), uid 1001: exited on signal 10 (core dumped) Jun 29 01:02:19 lstewart-laptop shutdown: power-down by root: panic: filesystem goof: vop_panic[vop_revoke]VNASSERT failed cpuid = 1 0xffffff00048afb10: KDB: enter: panictag devfs, type VCHR Physical memory: 2905 MB Dumping 1425 MB: 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2 ------------------------------------------------------------------------ kernel config config: File /boot/kernel/kernel doesn't contain configuration file. Either unsupported, or not compiled with INCLUDE_CONFIG_FILE --------------030109010401070505010604 Content-Type: text/plain; name="info.7" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="info.7" Dump header from device /dev/ad4s2b Architecture: amd64 Architecture Version: 2 Dump Length: 1494847488B (1425 MB) Blocksize: 512 Dumptime: Mon Jun 29 01:02:21 2009 Hostname: lstewart-laptop Magic: FreeBSD Kernel Dump Version String: FreeBSD 8.0-CURRENT #35 r195046: Fri Jun 26 12:28:02 BST 2009 lstewart@lstewart-laptop:/usr/obj/usr/src/sys/LAPTOP Panic String: filesystem goof: vop_panic[vop_revoke] Dump Parity: 4141901905 Bounds: 7 Dump Status: good --------------030109010401070505010604-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 10:55:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA00A1065708; Mon, 29 Jun 2009 10:55:58 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id 79E788FC1C; Mon, 29 Jun 2009 10:55:58 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n5TAtvUj016915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2009 12:55:57 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n5TAtu3q016914; Mon, 29 Jun 2009 12:55:56 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Mon, 29 Jun 2009 12:55:56 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Scott Long Message-ID: <20090629105556.GB72094@acme.spoerlein.net> Mail-Followup-To: Scott Long , Alexander Motin , freebsd-current@freebsd.org References: <4A4517BE.9040504@FreeBSD.org> <200906271419.49329.pieter@degoeje.nl> <4A464EED.3070700@FreeBSD.org> <4A465F8C.4030901@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A465F8C.4030901@samsco.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 10:55:59 -0000 On Sat, 27.06.2009 at 12:06:04 -0600, Scott Long wrote: > Alexander Motin wrote: > > This is not a problem. ATA disks does not have SCSI INQUIRY command. > > They use own IDENTIFY instead. inquiry should work for ATAPI devices, as > > they are SCSI deep inside. > > This is really the big missing piece in camcontrol; we need to add > support for getting the IDENT info and getting/setting various > attributes, as well as sending ATA commands over passthrough. Hi Scott, not sure if this is related, but I always wondered why tools like smartctl never work with USB attached ATA disks. Is it missing support in our drivers and smartctl or is it simply impossible? Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 11:15:36 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6B141065711 for ; Mon, 29 Jun 2009 11:15:36 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout3.freenet.de (mout3.freenet.de [IPv6:2001:748:100:40::2:5]) by mx1.freebsd.org (Postfix) with ESMTP id 728858FC1E for ; Mon, 29 Jun 2009 11:15:36 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.15] (helo=5.mx.freenet.de) by mout3.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MLEpj-00055b-45; Mon, 29 Jun 2009 13:15:35 +0200 Received: from td279.t.pppool.de ([89.55.210.121]:10545 helo=ernst.jennejohn.org) by 5.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1MLEpi-00009U-S2; Mon, 29 Jun 2009 13:15:35 +0200 Date: Mon, 29 Jun 2009 13:15:34 +0200 From: Gary Jennejohn To: Martin Smith Message-ID: <20090629131534.2d764f72@ernst.jennejohn.org> In-Reply-To: <4A473976.6030807@rakupottery.org.uk> References: <20090611194557.GC98175@bsdcrew.de> <4A473976.6030807@rakupottery.org.uk> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 11:15:50 -0000 On Sun, 28 Jun 2009 10:35:50 +0100 Martin Smith wrote: > Martin Wilke wrote: [snip what miwi wrote] > Well ,I have got it up and running on a stable of 26 June, managed to > set up a vdi, no problem, but it will not see the cd drive. > It (vbox) says the cd drive is always secondary master, but I only have > one ata channel so it is primary master. The dropdown list just does > not drop down. > Is there a workaround for this, or have I missed something stupid? > I saw this too and had to start hald in order for VirtualBox to see the real DVD/CD drives, even though I'd compiled VirtualBox without hald support. BTW I'm running -current, but the problem probably has the same solution under -stable. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 11:24:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A77B3106566C for ; Mon, 29 Jun 2009 11:24:07 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 2C00E8FC14 for ; Mon, 29 Jun 2009 11:24:06 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247067595; Mon, 29 Jun 2009 14:24:03 +0300 Message-ID: <4A48A44C.3030303@FreeBSD.org> Date: Mon, 29 Jun 2009 14:23:56 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Scott Long , =?UTF-8?B?VWxyaWNoIFNww7ZybGVpbg==?= , freebsd-current@freebsd.org References: <4A4517BE.9040504@FreeBSD.org> <200906271419.49329.pieter@degoeje.nl> <4A464EED.3070700@FreeBSD.org> <4A465F8C.4030901@samsco.org> <20090629105556.GB72094@acme.spoerlein.net> In-Reply-To: <20090629105556.GB72094@acme.spoerlein.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 11:24:07 -0000 Ulrich Spörlein wrote: > On Sat, 27.06.2009 at 12:06:04 -0600, Scott Long wrote: >> Alexander Motin wrote: >>> This is not a problem. ATA disks does not have SCSI INQUIRY command. >>> They use own IDENTIFY instead. inquiry should work for ATAPI devices, as >>> they are SCSI deep inside. >> This is really the big missing piece in camcontrol; we need to add >> support for getting the IDENT info and getting/setting various >> attributes, as well as sending ATA commands over passthrough. > > not sure if this is related, but I always wondered why tools like > smartctl never work with USB attached ATA disks. Is it missing support > in our drivers and smartctl or is it simply impossible? I don't know much about USB storages and protocols used there, but I think it is the ATA->SCSI protocol conversion done by ATA->USB adapter limits functionality. If this is correct: http://en.wikipedia.org/wiki/USB_mass_storage_device_class , it is impossible to avoid this conversion in common case. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 11:27:21 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C3A01065672; Mon, 29 Jun 2009 11:27:21 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from mtaout02-winn.ispmail.ntl.com (mtaout02-winn.ispmail.ntl.com [81.103.221.48]) by mx1.freebsd.org (Postfix) with ESMTP id 53EF48FC24; Mon, 29 Jun 2009 11:27:20 +0000 (UTC) (envelope-from ianjhart@ntlworld.com) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090629112718.BLTI6611.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Mon, 29 Jun 2009 12:27:18 +0100 Received: from cpc1-cove3-0-0-cust909.sol2.cable.ntl.com ([86.20.31.142]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090629112718.YHSX13254.aamtaout01-winn.ispmail.ntl.com@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com>; Mon, 29 Jun 2009 12:27:18 +0100 X-Virus-Scanned: amavisd-new at cpc2-cove3-0-0-cust311.sol2.cable.ntl.com Received: from localhost (localhost [127.0.0.1]) by cpc1-cove3-0-0-cust909.sol2.cable.ntl.com (8.14.3/8.14.3) with ESMTP id n5TBR3Lv053235; Mon, 29 Jun 2009 12:27:03 +0100 (BST) (envelope-from ianjhart@cpc1-cove3-0-0-cust909.sol2.cable.ntl.com) Received: from localhost (localhost [127.0.0.1]) by 10.248.192.16 (Horde Framework) with HTTP; Mon, 29 Jun 2009 12:27:02 +0100 Message-ID: <20090629122702.32737fcqksjhqqcc@10.248.192.16> Date: Mon, 29 Jun 2009 12:27:02 +0100 From: Ian J Hart To: Stanislav Sedov References: <20090626123727.18824c9jkz72dw8w@10.248.192.16> <20090626212244.783465ae.stas@FreeBSD.org> <20090626203459.20716tepaezxqggs@webmail> <20090626234357.29486c7a.stas@FreeBSD.org> In-Reply-To: <20090626234357.29486c7a.stas@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.3.3 / FreeBSD-7.2 X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=failed version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on cpc1-cove3-0-0-cust909.sol2.cable.ntl.com X-Cloudmark-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=NLZqzBF-AAAA:8 a=ZQhiscKslIqu4WwPsScA:9 a=DFpEtt3EMKfmt8QzWlsCBVyFw68A:4 a=SV7veod9ZcQA:10 a=_dQi-Dcv4p4A:10 Cc: freebsd-current@FreeBSD.org, Ian J Hart Subject: Re: AMD errata 169 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 11:27:21 -0000 Quoting Stanislav Sedov : > Content-Type: text/plain; charset=US-ASCII > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri, 26 Jun 2009 20:34:59 +0100 > Ian J Hart mentioned: > >> I only have cheesy KVM access. If it locks I'll have to wait until >> Monday to power cycle, so I might wait until Sunday night. >> > > It's a pretty straightforward fix, so it shouldn't break anything. > Of course, more care won't hurt in any case. :-) > > Have a nice holiday! > -- > Stanislav Sedov > ST4096-RIPE > Okay, that seems to work now (tested on CURRENT). -- ian j hart ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 11:35:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6ADC110656C0; Mon, 29 Jun 2009 11:35:07 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id E98978FC12; Mon, 29 Jun 2009 11:35:06 +0000 (UTC) (envelope-from rbgarga@gmail.com) Received: by qw-out-2122.google.com with SMTP id 5so632014qwd.7 for ; Mon, 29 Jun 2009 04:35:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=5e+IiV8adRCNtuV8/cq50L3u1Ndop/vVXFsBkk4Ldxs=; b=w+cOGVa07wzBOnb1W0nxaQ/YIWqimRJUlwjB1DpnLC5eDznCgc2QUgC1CSpmZviaik HIsaQxc4CZQEVnp+xNa7Qd+k7rDs0r4Z0vD/nKUXW3+X8Mn9dpp1GgF2LeS4Q/l/m7Rj Dng0SammD9DHViUD9ev/oLe63Y/I6yzjtmLQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=djTkyQDR8ALe9Z8dHtZfx6UazsdoI6O00gm413/IgCphjWZubmBsnqMkuQhapzYg59 F1L8OXdsk54czvKCxdiSrhGs4m95ZWe02y3fCD+7AzHccnhZW48St3Me4k4RUqYUzg1q t4M1twYKn9ZR++yCQbJekQfATpS4nUeAP9Rr8= MIME-Version: 1.0 Received: by 10.220.46.15 with SMTP id h15mr3794967vcf.107.1246275306089; Mon, 29 Jun 2009 04:35:06 -0700 (PDT) In-Reply-To: <20090628141008.GA3841@triton.kn-bremen.de> References: <747dc8f30906261255s1ecc1420x574ded3be835b448@mail.gmail.com> <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> From: Renato Botelho Date: Mon, 29 Jun 2009 08:34:46 -0300 Message-ID: <747dc8f30906290434y77f11bf1i5911ea1efe29fab5@mail.gmail.com> To: Juergen Lock Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Boris Samorodov , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, "Sean C. Farley" Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 11:35:07 -0000 On Sun, Jun 28, 2009 at 11:10 AM, Juergen Lock wrot= e: > On Sun, Jun 28, 2009 at 04:40:20PM +0400, Boris Samorodov wrote: >> Juergen Lock writes: >> >> > =A0New patch and shar: >> >> No more comments from me, thanks! > > Ok. =A0Has anyone tested this yet tho? =A0(Besides me in a vm... :) Working fine here. 8.0-current i386 --=20 Renato Botelho From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 11:45:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FBE1106566C for ; Mon, 29 Jun 2009 11:45:20 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 0893C8FC08 for ; Mon, 29 Jun 2009 11:45:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n5TBjGfS027363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2009 14:45:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n5TBjGSU002278; Mon, 29 Jun 2009 14:45:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n5TBjGD9002277; Mon, 29 Jun 2009 14:45:16 +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, 29 Jun 2009 14:45:16 +0300 From: Kostik Belousov To: Lawrence Stewart Message-ID: <20090629114516.GY2884@deviant.kiev.zoral.com.ua> References: <4A48942A.7030307@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FkhOn4hPPRcnTymj" Content-Disposition: inline In-Reply-To: <4A48942A.7030307@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: "filesystem goof: vop_panic[vop_revoke]" panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 11:45:20 -0000 --FkhOn4hPPRcnTymj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2009 at 11:15:06AM +0100, Lawrence Stewart wrote: > Hi All, >=20 > My laptop panicked whilst shutting down yesterday. The shutdown sequence= =20 > seemed to terminate kde4/X correctly but got wedged prior to completing= =20 > the rest as seen on the console. Details below... >=20 > uname -a: > FreeBSD lstewart-laptop 8.0-CURRENT FreeBSD 8.0-CURRENT #35 r195046: Fri= =20 > Jun 26 12:28:02 BST 2009=20 > lstewart@lstewart-laptop:/usr/obj/usr/src/sys/LAPTOP amd64 >=20 >=20 >=20 > Backtrace: >=20 > at /usr/src/sys/kern/subr_kdb.c:534 > #6 0xffffffff8084cb11 in trap (frame=3D0xffffff8058eb76a0) at=20 > /usr/src/sys/amd64/amd64/trap.c:613 >=20 > #7 0xffffffff80832f33 in calltrap () at=20 > /usr/src/sys/amd64/amd64/exception.S:223 >=20 > #8 0xffffffff805a736d in kdb_enter (why=3D0xffffffff80943489 "panic", > msg=3D0xa
) at cpufunc.h:63 >=20 > #9 0xffffffff8057791b in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:558 >=20 > #10 0xffffffff805f6108 in vop_panic (ap=3DVariable "ap" is not available. > ) at /usr/src/sys/kern/vfs_default.c:175 >=20 > #11 0xffffffff8054dee7 in exit1 (td=3D0xffffff00049c9720, rv=3D1) at=20 > vnode_if.h:523 >=20 > #12 0xffffffff8057927f in sigexit (td=3D0xffffff00049c9720, sig=3D0) > at /usr/src/sys/kern/kern_sig.c:2726 >=20 > #13 0xffffffff80579e7f in postsig (sig=3D1491826128) at=20 > /usr/src/sys/kern/kern_sig.c:2617 >=20 > #14 0xffffffff805b422c in ast (framep=3D0xffffff8058eb7c90) at=20 > /usr/src/sys/kern/subr_trap.c:225 >=20 > #15 0xffffffff80833de9 in doreti_ast () at=20 > /usr/src/sys/amd64/amd64/exception.S:623 >=20 Are you able to reproduce the issue ? Please try the patch. diff --git a/sys/kern/kern_exit.c b/sys/kern/kern_exit.c index ae060da..c00b4f4 100644 --- a/sys/kern/kern_exit.c +++ b/sys/kern/kern_exit.c @@ -334,10 +334,11 @@ exit1(struct thread *td, int rv) tty_unlock(tp); } =20 - if (ttyvp !=3D NULL && ttyvp->v_type !=3D VBAD) { + if (ttyvp !=3D NULL) { sx_xunlock(&proctree_lock); - VOP_LOCK(ttyvp, LK_EXCLUSIVE); - VOP_REVOKE(ttyvp, REVOKEALL); + vn_lock(ttyvp, LK_EXCLUSIVE | LK_RETRY); + if (ttyvp->v_type !=3D VBAD) + VOP_REVOKE(ttyvp, REVOKEALL); VOP_UNLOCK(ttyvp, 0); sx_xlock(&proctree_lock); } --FkhOn4hPPRcnTymj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpIqUsACgkQC3+MBN1Mb4jnMwCgp7KSDZtep8g5MLHOtSG9i+9d cA4AoKJLcCP38l4o3aLihZv19tL8vYVg =XgLl -----END PGP SIGNATURE----- --FkhOn4hPPRcnTymj-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 12:21:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DE8B106566C; Mon, 29 Jun 2009 12:21:04 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id B7F728FC21; Mon, 29 Jun 2009 12:21:03 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 6E4F878FA0; Mon, 29 Jun 2009 16:21:01 +0400 (MSD) Message-ID: <4A48B1AD.2050201@haruhiism.net> Date: Mon, 29 Jun 2009 16:21:01 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexander Motin References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> In-Reply-To: <4A48922D.5090507@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Goran Lowkrantz , freebsd-current@freebsd.org, Alexander Best Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 12:21:04 -0000 Alexander Motin wrote: > Sorry, my fault, it is the different bug, due to disabled invariants I > have missed two locking issues. Here is regenerated patch, including > this fix and all previous fixes and improvements: > http://people.freebsd.org/~mav/cam-ata.20090629.patch > Thanks a lot. Works now (FreeBSD 8.0-CURRENT #6 r195153M: Mon Jun 29 20:43:14 JST 2009), going to have it run under some heavy load (webserver running @ 20-70Mbps avg) for stability tests: ahci0: port 0xde00-0xde07,0xdf00-0xdf03,0xe000-0xe007,0xe100-0xe103,0xe200-0xe21f mem 0xf11a5000-0xf11a57ff irq 19 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.20 controller with 6 3Gbps ports, PM supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] ada0 at ahcich0 bus 0 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing Enabled ada1 at ahcich1 bus 0 target 0 lun 0 ada1: ATA/ATAPI-8 SATA 2.x device ada1: 300.000MB/s transfers ada1: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing Enabled ada2 at ahcich2 bus 0 target 0 lun 0 ada2: ATA/ATAPI-8 SATA 2.x device ada2: 300.000MB/s transfers ada2: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada2: Native Command Queueing Enabled ada3 at ahcich3 bus 0 target 0 lun 0 ada3: ATA/ATAPI-8 SATA 2.x device ada3: 300.000MB/s transfers ada3: 476938MB (976771055 512 byte sectors: 16H 63S/T 16383C) ada3: Native Command Queueing Enabled ada4 at ahcich4 bus 0 target 0 lun 0 ada4: ATA/ATAPI-8 SATA 2.x device ada4: 300.000MB/s transfers ada4: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) ada4: Native Command Queueing Enabled ada5 at ahcich5 bus 0 target 0 lun 0 ada5: ATA/ATAPI-8 SATA 2.x device ada5: 300.000MB/s transfers ada5: 715404MB (1465149168 512 byte sectors: 16H 63S/T 16383C) ada5: Native Command Queueing Enabled From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 12:54:19 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEE4A1065673; Mon, 29 Jun 2009 12:54:19 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (cl-43.dus-01.de.sixxs.net [IPv6:2a01:198:200:2a::2]) by mx1.freebsd.org (Postfix) with ESMTP id F3AE68FC17; Mon, 29 Jun 2009 12:54:18 +0000 (UTC) (envelope-from uqs@spoerlein.net) Received: from acme.spoerlein.net (localhost.spoerlein.net [127.0.0.1]) by acme.spoerlein.net (8.14.3/8.14.3) with ESMTP id n5TCsHWE019421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2009 14:54:17 +0200 (CEST) (envelope-from uqs@spoerlein.net) Received: (from uqs@localhost) by acme.spoerlein.net (8.14.3/8.14.3/Submit) id n5TCsHCo019420; Mon, 29 Jun 2009 14:54:17 +0200 (CEST) (envelope-from uqs@spoerlein.net) Date: Mon, 29 Jun 2009 14:54:17 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Alexander Motin Message-ID: <20090629125417.GC72094@acme.spoerlein.net> Mail-Followup-To: Alexander Motin , freebsd-current@FreeBSD.org References: <4A4517BE.9040504@FreeBSD.org> <200906271419.49329.pieter@degoeje.nl> <4A464EED.3070700@FreeBSD.org> <4A465F8C.4030901@samsco.org> <20090629105556.GB72094@acme.spoerlein.net> <4A48A44C.3030303@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A48A44C.3030303@FreeBSD.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 12:54:20 -0000 On Mon, 29.06.2009 at 14:23:56 +0300, Alexander Motin wrote: > Ulrich Spörlein wrote: > > On Sat, 27.06.2009 at 12:06:04 -0600, Scott Long wrote: > >> Alexander Motin wrote: > >>> This is not a problem. ATA disks does not have SCSI INQUIRY command. > >>> They use own IDENTIFY instead. inquiry should work for ATAPI devices, as > >>> they are SCSI deep inside. > >> This is really the big missing piece in camcontrol; we need to add > >> support for getting the IDENT info and getting/setting various > >> attributes, as well as sending ATA commands over passthrough. > > > > not sure if this is related, but I always wondered why tools like > > smartctl never work with USB attached ATA disks. Is it missing support > > in our drivers and smartctl or is it simply impossible? > > I don't know much about USB storages and protocols used there, but I > think it is the ATA->SCSI protocol conversion done by ATA->USB adapter > limits functionality. If this is correct: > http://en.wikipedia.org/wiki/USB_mass_storage_device_class > , it is impossible to avoid this conversion in common case. Thanks for the link! I guess my next external HDD will have an eSATA interface then :/ Cheers, Ulrich Spörlein -- http://www.dubistterrorist.de/ From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 13:25:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E12C71065674; Mon, 29 Jun 2009 13:25:19 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 970608FC17; Mon, 29 Jun 2009 13:25:18 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 109C578F7F; Mon, 29 Jun 2009 17:25:17 +0400 (MSD) Message-ID: <4A48C0BC.3030104@haruhiism.net> Date: Mon, 29 Jun 2009 17:25:16 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexander Motin References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> In-Reply-To: <4A48922D.5090507@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Goran Lowkrantz , freebsd-current@freebsd.org, Alexander Best Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 13:25:20 -0000 Alexander Motin wrote: > Sorry, my fault, it is the different bug, due to disabled invariants I > have missed two locking issues. Here is regenerated patch, including > this fix and all previous fixes and improvements: > http://people.freebsd.org/~mav/cam-ata.20090629.patch OK, a question about the module: sometimes I'm getting loads (20+) of messages like ahcich1: ALL SLOTS BUSY! Is it purely informational or does it indicate a problem? (I'm using Intel Q35+ICH9 in AHCI mode.) Also, experienced a fatal trap 12 (page fault while in kernel mode) once after the patch but couldn't get a reliable dump (though I doubt the problem is in ahci.ko - looks like another problem in tcp stack, yet again). P.S. Could you please change "Native Command Queueing Enabled" to "Native Command Queueing enabled" ;) just for better looks, as many of FreeBSD's kernel messages lack proper capitalization and such. Thanks ;) -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 14:18:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D1CA1065673 for ; Mon, 29 Jun 2009 14:18:14 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 7C4368FC1E for ; Mon, 29 Jun 2009 14:18:13 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247075567; Mon, 29 Jun 2009 17:18:09 +0300 Message-ID: <4A48CD19.8080606@FreeBSD.org> Date: Mon, 29 Jun 2009 17:18:01 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Kamigishi Rei References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> In-Reply-To: <4A48C0BC.3030104@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:18:14 -0000 Kamigishi Rei wrote: > Alexander Motin wrote: >> Sorry, my fault, it is the different bug, due to disabled invariants I >> have missed two locking issues. Here is regenerated patch, including >> this fix and all previous fixes and improvements: >> http://people.freebsd.org/~mav/cam-ata.20090629.patch > > OK, a question about the module: sometimes I'm getting loads (20+) of > messages like > > ahcich1: ALL SLOTS BUSY! > > Is it purely informational or does it indicate a problem? (I'm using > Intel Q35+ICH9 in AHCI mode.) It is bad. It must never happen. It means that driver got more commands then it has empty slots available. Results can be unpredictable. How have you manage it? Were there any other messages around? > P.S. Could you please change "Native Command Queueing Enabled" to > "Native Command Queueing enabled" ;) just for better looks, as many of > FreeBSD's kernel messages lack proper capitalization and such. Thanks ;) Better looks - better works! :) Done. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 14:22:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 518281065672 for ; Mon, 29 Jun 2009 14:22:06 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 2AC128FC1B for ; Mon, 29 Jun 2009 14:22:04 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (c149.al.cl.cam.ac.uk [128.232.110.149]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n5TELsPu051378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 00:21:57 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A48CE02.5000200@freebsd.org> Date: Mon, 29 Jun 2009 15:21:54 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Kamigishi Rei References: <4A45ABB1.7040506@haruhiism.net> In-Reply-To: <4A45ABB1.7040506@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-current@freebsd.org Subject: Re: r194546 amd64: kernel panic in tcp_sack.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:22:06 -0000 Hi, Kamigishi Rei wrote: > Hello, hope you're having a nice day, > > I've been testing my system mostly to check if ZFS in -current is > stable, however so far I've been getting kernel panics in every other > area except ZFS. This time it's tcp_sack.c according to the panic > message, inside [intr]. lol, handy! > > fujibayashi@ameagari ~ % uname -a > FreeBSD ameagari.fujibayashi.jp 8.0-CURRENT FreeBSD 8.0-CURRENT #1 > r194546: Thu Jun 25 19:44:18 JST 2009 > root@ameagari.fujibayashi.jp:/usr/src/sys/amd64/compile/Ameagari amd64 > > panic: tcp_sack_globalholes >= 0 > cpuid = 0 > KDB: enter: panic > [thread pid 12 tid 100005] > Stopped at kdb_enter+0x3d: movq $0,0x682580(%rip) > db> bt > Tracing pid 12 tid 100005 td 0xffffff0001320000 > kdb_enter() at kdb_enter+0x3d > panic() at panic+0x17b > tcp_sackhole_remove() at tcp_sackhole_remove+0xc7 > tcp_free_sackholes() at tcp_free_sackholes+0x48 > tcp_timer_rexmt() at tcp_timer_rexmt+0xb3 > softclock() at softclock+0x291 > intr_event_execute_handlers() at intr_event_execute_handlers+0x68 > ithread_loop() at ithread_loop+0xb2 > fork_exit() at fork_exit+0x12a > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xffffff8000026d40, rbp = 0 --- > db > > I'm not intimately familiar with our SACK implementation, and these things are often extremely painful to track down. First step: is the panic reproducible? > No core saved - when I tried to get it to save the core, it just raised > fatal trap 12 (page fault) and got a general protection fault afterwards. > Any ideas? How did you try to get it to save the core? A dump would be very useful to have around. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 14:31:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 759BD1065674 for ; Mon, 29 Jun 2009 14:31:14 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id E9E4B8FC0C for ; Mon, 29 Jun 2009 14:31:13 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247076398; Mon, 29 Jun 2009 17:31:10 +0300 Message-ID: <4A48D02A.4050605@FreeBSD.org> Date: Mon, 29 Jun 2009 17:31:06 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Kamigishi Rei References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> In-Reply-To: <4A48CD19.8080606@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:31:14 -0000 Alexander Motin wrote: > Kamigishi Rei wrote: >> Alexander Motin wrote: >>> Sorry, my fault, it is the different bug, due to disabled invariants >>> I have missed two locking issues. Here is regenerated patch, >>> including this fix and all previous fixes and improvements: >>> http://people.freebsd.org/~mav/cam-ata.20090629.patch >> >> OK, a question about the module: sometimes I'm getting loads (20+) of >> messages like >> >> ahcich1: ALL SLOTS BUSY! >> >> Is it purely informational or does it indicate a problem? (I'm using >> Intel Q35+ICH9 in AHCI mode.) > > It is bad. It must never happen. It means that driver got more commands > then it has empty slots available. Results can be unpredictable. > > How have you manage it? Were there any other messages around? I think I have found possible bug triggering condition. Apply this patch please: --- ahci.c.prev 2009-06-29 12:48:45.000000000 +0300 +++ ahci.c 2009-06-29 17:25:29.000000000 +0300 @@ -986,7 +986,7 @@ ahci_begin_transaction(device_t dev, uni if (ch->slot[tag].state == AHCI_SLOT_EMPTY) break; } while (tag != ch->lastslot); - if (tag == ch->lastslot) + if (ch->slot[tag].state != AHCI_SLOT_EMPTY) device_printf(ch->dev, "ALL SLOTS BUSY!\n"); ch->lastslot = tag; /* Occupy chosen slot. */ -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 14:35:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAAB2106564A; Mon, 29 Jun 2009 14:35:37 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 60EA08FC0A; Mon, 29 Jun 2009 14:35:37 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id E619978FA0; Mon, 29 Jun 2009 18:35:34 +0400 (MSD) Message-ID: <4A48D136.3050309@haruhiism.net> Date: Mon, 29 Jun 2009 18:35:34 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexander Motin References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> In-Reply-To: <4A48CD19.8080606@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:35:38 -0000 Alexander Motin wrote: >> ahcich1: ALL SLOTS BUSY! >> Is it purely informational or does it indicate a problem? (I'm using >> Intel Q35+ICH9 in AHCI mode.) > It is bad. It must never happen. It means that driver got more > commands then it has empty slots available. Results can be unpredictable. > How have you manage it? Were there any other messages around? No other messages. Going to try your patch from the followup message. Basically, I did nothing out of the ordinary. I'm running mysqld, postgres, and two lighttpds in jails, one of the lighttpds is serving huge media files. The messages appeared mostly during "make buildworld" for one of the GEOM_MIRROR drives (/usr/obj operations probably) and for one of raidz1 drives (where /usr/src resides). -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 14:36:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD02A1065695; Mon, 29 Jun 2009 14:36:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 6B17F8FC26; Mon, 29 Jun 2009 14:36:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAC9uSEqDaFvK/2dsb2JhbADONYI2AYFWBQ X-IronPort-AV: E=Sophos;i="4.42,309,1243828800"; d="scan'208";a="37743957" Received: from fraser.cs.uoguelph.ca ([131.104.91.202]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 29 Jun 2009 10:36:27 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id 8CC22109C25E; Mon, 29 Jun 2009 10:36:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at fraser.cs.uoguelph.ca Received: from fraser.cs.uoguelph.ca ([127.0.0.1]) by localhost (fraser.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGfVInBG8Jlz; Mon, 29 Jun 2009 10:36:27 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by fraser.cs.uoguelph.ca (Postfix) with ESMTP id EFE00109C257; Mon, 29 Jun 2009 10:36:26 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5TEchd07187; Mon, 29 Jun 2009 10:38:43 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 29 Jun 2009 10:38:43 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Attilio Rao In-Reply-To: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> Message-ID: References: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:36:29 -0000 On Mon, 29 Jun 2009, Attilio Rao wrote: > 2009/6/29 Rick Macklem : >> I just noticed that when I do the following: >> - start a large write to an NFS mounted fs >> - network partition the server (unplug a net cable) >> - do a "umount -f " on the machine >> >> that it gets stuck trying to write dirty blocks to the server. >> >> I had, in the past, assumed that a "umount -f" of an NFS mount would be >> used to get rid of an NFS mount on an unresponsive server and that loss >> of "writes in progress" would be expected to happen. >> >> Does that sound correct? (In other words, an I seeing a bug or a feature?) > > While that should be real in principle (immediate shutdown of the fs > operation and unmounting of the partition) it is totally impossible to > have it completely unsleeping, so it can happen that also umount -f > sleeps / delays for some times (example: vflush). > Currently, umount -f is one of the most complicated thing to handle in > our VFS because it puts as requirement that vnodes can be reclaimed in > any moment, adding complexity and possibility for races. > Yes, agreed. And I like to leave that stuff to more clever chaps than I:-) > What's the fix for your problem? > Well, when I tested it I found that it got stuck in two places, both calls to VFS_SYNC(). The first was a sync(); right at the beginning of umount.c. - All I did for that one is move it to after the code that handles option processing and change it to if ((fflag & MNT_FORCE) == 0) sync(); so that it isn't done for the "-f" case. (I believe the sync(); call at the beginning of umount is only a performance optimization, so I don't think not doing it for "-f" should break anything.) - the second happened just before the VFS_UNMOUNT() call in the umount(2) system call. The code looks like: if (((mp->mnt_flag & MNT_RDONLY) || (error = VFS_SYNC(mp, MNT_WAIT)) == 0) || (flags & MNT_FORCE) != 0) - Although it was tempting to reverse the order of VFS_SYNC() and the test for MNT_FORCE, I thought that might have a negative impact on other file systems, since it avoided doing the VFS_SYNC(), so... - Instead, I just put a check for MNTK_UNMOUNTF at the beginning of nfs_sync(), so that it returns EBUSY for this case instead of getting stuck trying to flush(). Assuming that I'm right w.r.t. the "sync();" at the beginning of umount.c, it simply ensures that the umount command thread makes it as far as VFS_UNMOUNT()->nfs_unmount(), so that the forced dismount proceeds. It kills RPCs in progress before doing the vflush() and, since no new RPCs can be done once MNTK_UNMOUNTF is set (it is checked at the beginning of a request), the vflush() won't actually flush anything to the server. As such, "umount -f" is pretty well guaranteed to throw away the dirty buffers. I believe this is correct behaviour, but it would mean that a user/sysadmin that uses "umount -f" for cases where the server is still functioning, but slow, will lose data when they probably don't expect to. Does this help? rick ps: During simple testing, it has worked ok. It waits about 1 minute for the RPC threads to shut down, but the "umount -f" does complete after that happens. It the consensus seems to be that patching this is a good idea, I'll get some more testing done. From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 14:48:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5E59106566C for ; Mon, 29 Jun 2009 14:48:09 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id ED4038FC1E for ; Mon, 29 Jun 2009 14:48:08 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247077243; Mon, 29 Jun 2009 17:48:04 +0300 Message-ID: <4A48D421.7070303@FreeBSD.org> Date: Mon, 29 Jun 2009 17:48:01 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Lucius Windschuh References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <90a5caac0906290736q79d6cb52s1479849b18dd1f94@mail.gmail.com> In-Reply-To: <90a5caac0906290736q79d6cb52s1479849b18dd1f94@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:48:10 -0000 Lucius Windschuh wrote: > I am seeing concatenated messages every now and then, despite using > options PRINTF_BUFR_SIZE=256 > in my kernel config. This occurs only with you ahci driver: > > ada0 at ahcich0 bus 0 target 0 lun 0ahcich1: ahci_ch_intr ERROR is > 40000001 cs 00000040 ss 00000000 rs 00000040 tfd 6451 serr 00000000 "ahcich1: ahci_ch_intr ERROR ..." is a bit paranoid error reporting temporary left for debugging. It is OK for CD without a disk, as some commands, such as "get capacity", return ATA error status in such case. Concatenation issue is probably not a bug here, as many of CAM messages printed with several printfs each. So printf buffering unable to help with it. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 14:50:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 580161065707 for ; Mon, 29 Jun 2009 14:50:12 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 066738FC28 for ; Mon, 29 Jun 2009 14:50:12 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id AD8AB78F7F; Mon, 29 Jun 2009 18:50:10 +0400 (MSD) Message-ID: <4A48D4A2.8010207@haruhiism.net> Date: Mon, 29 Jun 2009 18:50:10 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lawrence Stewart References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> In-Reply-To: <4A48CE02.5000200@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: r194546 amd64: kernel panic in tcp_sack.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:50:12 -0000 Lawrence Stewart wrote: > I'm not intimately familiar with our SACK implementation, and these > things are often extremely painful to track down. First step: is the > panic reproducible? So far I couldn't reproduce it, but I think the fact that I couldn't reproduce it has something to do with frequent reboots due to buildworld/buildkernel lately because of other problems. > How did you try to get it to save the core? A dump would be very > useful to have around. Since I'm not much of an expert in the kernel debugger, I tried to let it continue with the panic, i.e. typed 'continue' which produced a fatal trap 12 right after "Dumping XXXX MB: (~3 values were here)". -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 14:53:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6987C1065674 for ; Mon, 29 Jun 2009 14:53:13 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id DE85C8FC20 for ; Mon, 29 Jun 2009 14:53:12 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247077414; Mon, 29 Jun 2009 17:53:08 +0300 Message-ID: <4A48D551.5090509@FreeBSD.org> Date: Mon, 29 Jun 2009 17:53:05 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Kamigishi Rei References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> <4A48D136.3050309@haruhiism.net> In-Reply-To: <4A48D136.3050309@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:53:13 -0000 Kamigishi Rei wrote: > Alexander Motin wrote: >>> ahcich1: ALL SLOTS BUSY! >>> Is it purely informational or does it indicate a problem? (I'm using >>> Intel Q35+ICH9 in AHCI mode.) >> It is bad. It must never happen. It means that driver got more >> commands then it has empty slots available. Results can be unpredictable. >> How have you manage it? Were there any other messages around? > No other messages. Going to try your patch from the followup message. > Basically, I did nothing out of the ordinary. I'm running mysqld, > postgres, and two lighttpds in jails, one of the lighttpds is serving > huge media files. > The messages appeared mostly during "make buildworld" for one of the > GEOM_MIRROR drives (/usr/obj operations probably) and for one of raidz1 > drives (where /usr/src resides). It could be not a real bug, but incorrect diagnostic, in situation, when the last of 32 submitted command finishes first. NCQ in practice. :) -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 15:01:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AEEC10656C5 for ; Mon, 29 Jun 2009 15:01:18 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-px0-f191.google.com (mail-px0-f191.google.com [209.85.216.191]) by mx1.freebsd.org (Postfix) with ESMTP id D0A8B8FC13 for ; Mon, 29 Jun 2009 15:01:17 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by pxi29 with SMTP id 29so3485615pxi.3 for ; Mon, 29 Jun 2009 08:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=IQR36ChXcHi8Y95lZwf98ILAJ8AcdAOQiqLLL+yWGc4=; b=BS2yhPLrXIiZmqpJb9hDsisbQJKGkbHPoD+OUMQS1NxTNM0IaJqVUaOCPlPXiWMeqY r6fUIv8S8IQdXBuUiIAEfhtExviGTemOCdSMHxi+rBIRZF/Y2oBt7AevC7zTVt9G7z0Y DzxxnmqNFcIzSqvoMsa+ZGhEW349C1q1XiODM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=xNYJVBwIN9AWaPir56dH05yQgcMfVPx95Q7ScvzIQAz1WMLv1hywUTEpx9EhgI6EmQ 9fV6a6nKJ/4L26IG2wnNsP5JDLT372j59vG0PLM/Klgi/bJrniOXWt8sSheVonxCfMS+ 8qKQguiDBp1Phg516NmGQjVo5mw1yFRoKS/9k= MIME-Version: 1.0 Received: by 10.142.80.3 with SMTP id d3mr73922wfb.13.1246286210334; Mon, 29 Jun 2009 07:36:50 -0700 (PDT) In-Reply-To: <4A48C0BC.3030104@haruhiism.net> References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> Date: Mon, 29 Jun 2009 16:36:50 +0200 Message-ID: <90a5caac0906290736q79d6cb52s1479849b18dd1f94@mail.gmail.com> From: Lucius Windschuh To: Alexander Motin , freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:01:18 -0000 2009/6/29 Kamigishi Rei : > P.S. Could you please change "Native Command Queueing Enabled" to "Native > Command Queueing enabled" ;) just for better looks, as many of FreeBSD's > kernel messages lack proper capitalization and such. Thanks ;) "Native Command Queueing enabled\n", perhaps? I am seeing concatenated messages every now and then, despite using options PRINTF_BUFR_SIZE=256 in my kernel config. This occurs only with you ahci driver: ada0 at ahcich0 bus 0 target 0 lun 0ahcich1: ahci_ch_intr ERROR is 40000001 cs 00000040 ss 00000000 rs 00000040 tfd 6451 serr 00000000 or: ada0: ATA/ATAPI-8 SATA 1.xahcich1: ahci_ch_intr ERROR is 40000001 cs 00000040 ss 00000000 rs 00000040 tfd 6451 serr 00000000 The appended error message occurs on every access to the empty cd0 device: ahcich1: ahci_ch_intr ERROR is 40000001 cs 00000200 ss 00000000 rs 00000200 tfd 2451 serr 00000000 ahcich1 is the port to which my internal DVD burner (cd0) is attached. The controller itself: ahci0@pci0:0:31:2: class=0x010601 card=0x20f817aa chip=0x29298086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) Mobile SATA AHCI Controller' class = mass storage subclass = SATA Sniplet of dmesg: (probe0:ahcich0:0:0:0): SIGNATURE: 0000 (probe1:ahcich1:0:0:0): SIGNATURE: eb14 ada0 at ahcich0 bus 0 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 1.xahcich1: ahci_ch_intr ERROR is 40000001 cs 00000040 ss 00000000 rs 00000040 tfd 6451 serr 00000000 (cd0:ahcich1:0:0:0): Retrying Command GEOM: new disk cd0 GEOM: new disk ada0 device ada0: Serial Number 081119FC1223NPG3SRBC(cd0:ahcich1:0:0:0): error 6 (cd0:ahcich1:0:0:0): Unretryable Error cd0 at ahcich1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: Serial Number M1589HK3233 cd0: 150.000MB/s transfers cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, or bus device reset occurred ada0: 150.000MB/s transfers ada0: 152627MB (312581808 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing Enabled pass0 at ahcich0 bus 0 target 0 lun 0ahcich1: ahci_ch_intr ERROR is 40000001 cs 00000200 ss 00000000 rs 00000200 tfd 2451 serr 00000000 (cd0:ahcich1:0:0:0): Retrying Command pass0: ATA/ATAPI-8 SATA 1.x device pass0: Serial Number 081119FC1223NPG3SRBC pass0: 150.000MB/s transfers(cd0:ahcich1:0:0:0): error 6 (cd0:ahcich1:0:0:0): Unretryable Error pass1 at ahcich1 bus 0 target 0 lun 0 pass1: Removable CD-ROM SCSI-0 device pass1: Serial Number M1589HK3233 pass1: 150.000MB/s transfers SMP: AP CPU #1 Launched! ID: 0x01000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010200 err: 0x00010000 pcm: 0x00000400 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 1 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 1 vector 49 ioapic0: routing intpin 17 (PCI IRQ 17) to lapic 1 vector 50 ioapic0: routing intpin 19 (PCI IRQ 19) to lapic 1 vector 51 ioapic0: routing intpin 21 a(hcich1: PCI IRQ 21ahci_ch_intr ERROR is 40000001 cs 00002000 ss 00000000 rs 00002000 tfd 2451 serr 00000000) to lapic 1 vector 52 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 1 vector 53 msi: Assigning MSI IRQ 258 to local APIC 1 vector 54 WARNING: WITNESS option enabled, expect reduced performance.(cd0: ahcich1:0:0:0): Retrying Command (cd0:ahcich1:0:0:0): error 6 (cd0:ahcich1:0:0:0): Unretryable Error ahcich1: ahci_ch_intr ERROR is 40000001 cs 00020000 ss 00000000 rs 00020000 tfd 2451 serr 00000000 (cd0:ahcich1:0:0:0): Retrying Command (cd0:ahcich1:0:0:0): error 6 (cd0:ahcich1:0:0:0): Unretryable Error scsi_cd.c::ioctl cmd=4400648b error=25 ahcich1: ahci_ch_intr ERROR is 40000001 cs 00200000 ss 00000000 rs 00200000 tfd 2451 serr 00000000 (cd0:ahcich1:0:0:0): Retrying Command (cd0:ahcich1:0:0:0): error 6 (cd0:ahcich1:0:0:0): Unretryable Error Any more hints I can give you? Lucius From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 15:14:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C29E106564A for ; Mon, 29 Jun 2009 15:14:04 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id D3CA68FC1C for ; Mon, 29 Jun 2009 15:14:03 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (c149.al.cl.cam.ac.uk [128.232.110.149]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n5TFDsbg052301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 01:13:56 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A48DA31.5010900@freebsd.org> Date: Mon, 29 Jun 2009 16:13:53 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Kamigishi Rei References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> In-Reply-To: <4A48D4A2.8010207@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-current@freebsd.org Subject: Re: r194546 amd64: kernel panic in tcp_sack.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:14:04 -0000 Kamigishi Rei wrote: > Lawrence Stewart wrote: >> I'm not intimately familiar with our SACK implementation, and these >> things are often extremely painful to track down. First step: is the >> panic reproducible? > So far I couldn't reproduce it, but I think the fact that I couldn't > reproduce it has something to do with frequent reboots due to > buildworld/buildkernel lately because of other problems. Ok. I'm working on a patch to address a different TCP/SACK issue, but it may in fact be partially relevant to the cause of your panic... can't promise when I'll be able to take a close look at this but I'm aware of it now so that's a start. If you run into it again or find the trigger for the panic, please let me know. >> How did you try to get it to save the core? A dump would be very >> useful to have around. > Since I'm not much of an expert in the kernel debugger, I tried to let > it continue with the panic, i.e. typed 'continue' which produced a fatal > trap 12 right after "Dumping XXXX MB: (~3 values were here)". Next time from the ddb prompt, try typing "call doadump" instead of "continue". That will hopefully get you a usable core dump which would be handy. After it finishes dumping the core type "reset" to reboot the machine. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 15:15:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2939110656B1; Mon, 29 Jun 2009 15:15:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id C048C8FC0C; Mon, 29 Jun 2009 15:15:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI93SEqDaFvL/2dsb2JhbADPDoQNBYE3 X-IronPort-AV: E=Sophos;i="4.42,309,1243828800"; d="scan'208";a="37749025" Received: from nile.cs.uoguelph.ca ([131.104.91.203]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 29 Jun 2009 11:15:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id 0BF828D4116; Mon, 29 Jun 2009 11:15:05 -0400 (EDT) X-Virus-Scanned: amavisd-new at nile.cs.uoguelph.ca Received: from nile.cs.uoguelph.ca ([127.0.0.1]) by localhost (nile.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoLeBH0J7Zfy; Mon, 29 Jun 2009 11:15:03 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id 7F0ED8D4072; Mon, 29 Jun 2009 11:15:03 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5TFHKe12786; Mon, 29 Jun 2009 11:17:20 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 29 Jun 2009 11:17:20 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Nathanael Hoyle In-Reply-To: <4A480B8C.1060708@hoyletech.com> Message-ID: References: <4A480B8C.1060708@hoyletech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:15:09 -0000 On Sun, 28 Jun 2009, Nathanael Hoyle wrote: > I think the answer is probably "it's a feature, not a bug", but that depends > on your NFS mount options which you didn't give. I'd suggest you read up on > NFS soft versus hard mounts. I think you're seeing the latter and expecting > the former behavior. > Well, part of the problem is that I'm working on a client that includes NFSv4 and, at least for NFSv4, getting "intr" or "soft" mounts to work correctly is nearly impossible. Since NFSv4 includes lock state operations that must be strictly serialized and the state maintained in a consistent way, you can't just "terminate" an RPC involving these Ops without breaking all state handling. Also, I/O system calls generally aren't expected to fail with EINTR and many (most??) apps. get broken by this happening. Personally, I believe that "hard" mounts plus the use of "umount -f" to get rid of mounts against unresponsive servers is the preferred way to go and the first step in this direction would be getting "umount -f" to work for the above case (plus agreement that the semantics of "umount -f" include "loss of recently written data"). There was a thread on this a few months ago, which I cant find, but there is pr129760 w.r.t. FreeBSD locking up upon a "umount -f". (Btw, I believe that Mac OS X has adopted this concept. It pops up a "disconnect mount" window for unresponsive servers and does essentially a "umount -f" if the user clicks "ok".) > The first hit I found Googling seems pretty decent, though taken from Linux > docs should still apply: > > http://tldp.org/HOWTO/NFS-HOWTO/client.html > > Under section 4.3.1 "Soft vs. Hard Mounting" there's a basic description. > There was a time when SunOS/Solaris was considered the "gold standard" for NFS (but I suppose this is the Linux era;-). My recollection might be fuzzy, but I don't think SunOS had a "umount -f" in those days and I think "intr" was introduced after their first release, as an improvement over "soft", since NFS servers got really slow when running on 1985 hardware. Solaris10 does have a "umount -f" and the man page notes that data related to open files can be lost when it is used. (This would basically be the semantic "umount -f" on FreeBSD will have if the "sync"s aren't done.) rick From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 15:17:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32A8F1065675 for ; Mon, 29 Jun 2009 15:17:35 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id D6C598FC19 for ; Mon, 29 Jun 2009 15:17:34 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n5TEg6kG092853; Mon, 29 Jun 2009 09:42:06 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n5TEg65G092852; Mon, 29 Jun 2009 09:42:06 -0500 (CDT) (envelope-from brooks) Date: Mon, 29 Jun 2009 09:42:06 -0500 From: Brooks Davis To: Mel Flynn Message-ID: <20090629144205.GA83592@lor.one-eyed-alien.net> References: <200906271948.54745.mel.flynn+fbsd.current@mailing.thruhere.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline In-Reply-To: <200906271948.54745.mel.flynn+fbsd.current@mailing.thruhere.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Mon, 29 Jun 2009 09:42:06 -0500 (CDT) Cc: freebsd-current@freebsd.org Subject: Re: Interface dependencies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:17:35 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 27, 2009 at 07:48:54PM -0800, Mel Flynn wrote: > Hi, >=20 > maybe I'm overlooking something, so I thought I'd ask. > As far as I can tell, there is no way to specify interface dependencies, = so I=20 > have an issue I cannot seem to solve: > - Create a lagg0 that has em and wlan0 at boot time, because wlan0 takes = too=20 > long to be configured - and the default network_interfaces=3DAUTO sorts= =20 > alphabetically which is not making matters easier. The interfaces should be in the order they are probed/created. No sorting should be performed beyond moving lo0 to the front in the default case. > I've been trying to use hacks, but I think interfaces really need=20 > dependencies. Like ifconfig_lagg0_require=3D"wlan0 em0", which would firs= t=20 > configure wlan0, wait for it to be availabe, then em0 and finally lagg0. >=20 > Is there something available, is it a known issue and ENOTIME to fix or a= m I=20 > missing something else? There isn't a feature to add dependencies, but there probably should be. I'm not sure that's really what the problem is there though. > At present, my rc.conf entries are: > # Need to do this manually to prevent alphabetical sorting. > network_interfaces=3D"wpi0 lo0 em0" > cloned_interfaces=3D"lagg0" > wlans_wpi0=3D"wlan0" > ifconfig_wpi0=3D"ether 00:16:36:f2:3b:84" > ifconfig_wlan0=3D"WPA" > ifconfig_em0=3D"up" > ifconfig_lagg0=3D"laggproto failover laggport em0" > ifconfig_lagg0_alias0=3D"laggport wlan0" > ifconfig_lagg0_alias1=3D"inet 192.168.2.50 netmask 255.255.255.0" >=20 > And this gives me a lagg0 at boottime without wlan0, since the interface = don't=20 > exist. I also cannot add inet commands to laggport commands, thus the ali= as=20 > trick is already needed, yet the delay caused by running separate command= s=20 > does not seem to be enough to have wlan0 available. wlan0 should exist by the time lagg0 is created because it's created and configured synchronously when wpi0 is configured. I know other people are using lagg this way so I'm a bit confused as to what's wrong. Enabling verbose start up and examining the output might be telling. -- Brooks > --=20 > Mel > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >=20 --qDbXVdCdHGoSgWSk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKSNK8XY6L6fI4GtQRAmLcAJ0QTa0uli7dmGqQsrnflpB/HlrezgCeMpz4 smSks3Ht3g8L+Rz8K8lOxF4= =f9tQ -----END PGP SIGNATURE----- --qDbXVdCdHGoSgWSk-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 15:25:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4120110656D7; Mon, 29 Jun 2009 15:25:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E8D958FC16; Mon, 29 Jun 2009 15:25:27 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n5TFPJce047491; Mon, 29 Jun 2009 09:25:19 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A48DCDF.9010104@samsco.org> Date: Mon, 29 Jun 2009 09:25:19 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Scott Long , Alexander Motin , freebsd-current@freebsd.org References: <4A4517BE.9040504@FreeBSD.org> <200906271419.49329.pieter@degoeje.nl> <4A464EED.3070700@FreeBSD.org> <4A465F8C.4030901@samsco.org> <20090629105556.GB72094@acme.spoerlein.net> In-Reply-To: <20090629105556.GB72094@acme.spoerlein.net> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:25:28 -0000 Ulrich Spörlein wrote: > On Sat, 27.06.2009 at 12:06:04 -0600, Scott Long wrote: >> Alexander Motin wrote: >>> This is not a problem. ATA disks does not have SCSI INQUIRY command. >>> They use own IDENTIFY instead. inquiry should work for ATAPI devices, as >>> they are SCSI deep inside. >> This is really the big missing piece in camcontrol; we need to add >> support for getting the IDENT info and getting/setting various >> attributes, as well as sending ATA commands over passthrough. > > Hi Scott, > > not sure if this is related, but I always wondered why tools like > smartctl never work with USB attached ATA disks. Is it missing support > in our drivers and smartctl or is it simply impossible? > The possibility depends on several hardware and software factors. If the USB disk enclosure was speaking ATA all the way up to the umass driver, then it could be possible to add some extra intelligence to the driver to make SMART work. However, if the enclosure chip is speaking anything else, then probably not. As an alternative, you might try to the ata-usb module instead and see if that works. Scott From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 15:27:30 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 08E581065696 for ; Mon, 29 Jun 2009 15:27:30 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from mail.digiware.nl (mail.digiware.nl [80.255.245.173]) by mx1.freebsd.org (Postfix) with ESMTP id BBE838FC15 for ; Mon, 29 Jun 2009 15:27:29 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 3A6A8153434; Mon, 29 Jun 2009 17:27:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW-3qLOIJ34v; Mon, 29 Jun 2009 17:27:26 +0200 (CEST) Received: from [192.168.254.10] (unknown [192.168.254.10]) by mail.digiware.nl (Postfix) with ESMTP id EF1D6153433; Mon, 29 Jun 2009 17:27:25 +0200 (CEST) Message-ID: <4A48DD61.6070104@withagen.nl> Date: Mon, 29 Jun 2009 17:27:29 +0200 From: Willem Jan Withagen User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Aisaka Taiga References: <4A476C7C.3020605@withagen.nl> <4A477576.6030701@haruhiism.net> <4A4779AF.1020303@digiware.nl> <4A487AEA.7040906@haruhiism.net> In-Reply-To: <4A487AEA.7040906@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: 7.2-stable upgrade changes disknames X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:27:30 -0000 Aisaka Taiga wrote: > Willem Jan Withagen wrote: >> On 7.2 this used to work(tm), on 8.0 boot start complaining. >> So somewhere a (unwanted) flexibility got deleted >> And I have to manually fix my /etc/fstab to what is factual correct. >> And that was what my message was about: >> It can/will(??) bite a lot more users. >> With similar remarks and/or questions. > To be honest, I'm quite amused that it actually worked for you, because > if you use a dangerously dedicated disk you, basically, don't need a > partition table at all as the slice 'table' (bsdlabel) takes care of > everything. And if there's no partition table, there can be no adXs1a > boot device - even in 7.2. > If you got your fstab from sysinstall, I don't really know how did you > manage to migrate to a DDD without modifying fstab, because sysinstall > has no clue about the existence of DDDs. To get a system running on a > DDD you would basically need to install BTX (using fdisk), label the > drive with bsdlabel, and then dump/restore or tar c | tar x the > filesystems. > But according to you, until -CURRENT you had a working partition table > (hence adXs1a working). And make installworld should never bother with > partition tables. > (This is really weird.) Although I'm know to always choose the options that will trigger edge cases. This was a fast en no-brainer install, hence a DDD install. So now the question boils down to: how many people did install DDD and were abusing the feature that it also mimiced a sliced disk?? Those are the users that are going to run into a non-booting upgrade. So how many users use a DDD install? And the second question: Does this warrant at least a notification in the UPGRADING file? From dimitry's answer I understand that it really used to function as a I described, and that it was more incidental that things worked the way sysinstall left them after booting. --WjW From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 15:57:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8058C106564A for ; Mon, 29 Jun 2009 15:57:11 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 13C268FC15 for ; Mon, 29 Jun 2009 15:57:10 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=g-C9pX_LWiRSm7mCtqcA:9 a=7cC2e8qtNlZbNYCHoxCOPSDBu7cA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 213717204 for freebsd-current@freebsd.org; Mon, 29 Jun 2009 17:57:09 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 29 Jun 2009 17:56:41 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906291756.42099.hselasky@c2i.net> Subject: False positive VGA PCI device detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 15:57:11 -0000 Hi, I'm not sure if my ISDN adapter has been collecting dust for too long or what, but I was surprised about the following: vgapci1@pci0:1:8:0: class=0x038000 card=0x2bd01397 chip=0x2bd01397 rev=0x02 hdr=0x00 vendor = 'Cologne Chip Designs GmbH' device = 'HFC-S PCI A ISDN 2BDS0 ISDN HDLC FIFO Controller' class = display Kernel: i386 FreeBSD-8-current as of today --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 16:05:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 542281065670 for ; Mon, 29 Jun 2009 16:05:40 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 0F1FD8FC0C for ; Mon, 29 Jun 2009 16:05:39 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from [192.168.1.4] (adsl-156-4-82.bna.bellsouth.net [70.156.4.82]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id n5TG5ZDG073374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2009 12:05:35 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) From: Robert Noland To: Hans Petter Selasky In-Reply-To: <200906291756.42099.hselasky@c2i.net> References: <200906291756.42099.hselasky@c2i.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-/bMHD0CKBnDFHgIAVLbO" Organization: FreeBSD Date: Mon, 29 Jun 2009 11:05:30 -0500 Message-Id: <1246291530.1759.47.camel@balrog.2hip.net> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: freebsd-current@freebsd.org Subject: Re: False positive VGA PCI device detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 16:05:40 -0000 --=-/bMHD0CKBnDFHgIAVLbO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-06-29 at 17:56 +0200, Hans Petter Selasky wrote: > Hi, >=20 > I'm not sure if my ISDN adapter has been collecting dust for too long or = what,=20 > but I was surprised about the following: >=20 > vgapci1@pci0:1:8:0: class=3D0x038000 card=3D0x2bd01397 chip=3D0x2bd01= 397=20 > rev=3D0x02 hdr=3D0x00 > vendor =3D 'Cologne Chip Designs GmbH' > device =3D 'HFC-S PCI A ISDN 2BDS0 ISDN HDLC FIFO Controller' > class =3D display Why is the pci class coming up as a display? That is why it is attaching. robert. > Kernel: i386 FreeBSD-8-current as of today >=20 > --HPS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 Robert Noland FreeBSD --=-/bMHD0CKBnDFHgIAVLbO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEABECAAYFAkpI5koACgkQM4TrQ4qfROOPwACfQnvaUIii3QuaEWmCcyWhK0vy J6QAn0D/0Zjgq7K10OBXQODqJc5Mh2iC =b01J -----END PGP SIGNATURE----- --=-/bMHD0CKBnDFHgIAVLbO-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 16:29:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39AD3106566C for ; Mon, 29 Jun 2009 16:29:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 938488FC19 for ; Mon, 29 Jun 2009 16:29:27 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=dJ6xPsu-cwQA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=Vdoadj7FawURheJg2nsA:9 a=L9mGhiOPT2O6Lclgia-n-TFBY2MA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1268238987; Mon, 29 Jun 2009 18:29:26 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 29 Jun 2009 18:28:56 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906291756.42099.hselasky@c2i.net> <1246291530.1759.47.camel@balrog.2hip.net> In-Reply-To: <1246291530.1759.47.camel@balrog.2hip.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906291828.57512.hselasky@c2i.net> Cc: Robert Noland Subject: Re: False positive VGA PCI device detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 16:29:28 -0000 On Monday 29 June 2009 18:05:30 Robert Noland wrote: > On Mon, 2009-06-29 at 17:56 +0200, Hans Petter Selasky wrote: > > Hi, > > > > I'm not sure if my ISDN adapter has been collecting dust for too long or > > what, but I was surprised about the following: > > > > vgapci1@pci0:1:8:0: class=0x038000 card=0x2bd01397 chip=0x2bd01397 > > rev=0x02 hdr=0x00 > > vendor = 'Cologne Chip Designs GmbH' > > device = 'HFC-S PCI A ISDN 2BDS0 ISDN HDLC FIFO Controller' > > class = display > > Why is the pci class coming up as a display? That is why it is > attaching. I have no idea. I simply inserted the card into the box. I looked at the vga_pci.c and there seems to be several VGA PCI classes. One old and one new. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 16:47:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C1B4B106564A for ; Mon, 29 Jun 2009 16:47:38 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id BCD708FC0A for ; Mon, 29 Jun 2009 16:47:37 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n5TGCR6b083408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Jun 2009 11:12:28 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n5TGCRU6004825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Jun 2009 11:12:27 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n5TGCQNP004821; Mon, 29 Jun 2009 11:12:26 -0500 (CDT) (envelope-from dan) Date: Mon, 29 Jun 2009 11:12:25 -0500 From: Dan Nelson To: Scott Long Message-ID: <20090629161225.GJ76275@dan.emsphone.com> References: <4A4517BE.9040504@FreeBSD.org> <200906271419.49329.pieter@degoeje.nl> <4A464EED.3070700@FreeBSD.org> <4A465F8C.4030901@samsco.org> <20090629105556.GB72094@acme.spoerlein.net> <4A48DCDF.9010104@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4A48DCDF.9010104@samsco.org> X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Mon, 29 Jun 2009 11:12:28 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: Alexander Motin , freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 16:47:39 -0000 In the last episode (Jun 29), Scott Long said: > Ulrich Spörlein wrote: > > On Sat, 27.06.2009 at 12:06:04 -0600, Scott Long wrote: > >> Alexander Motin wrote: > >>> This is not a problem. ATA disks does not have SCSI INQUIRY command. > >>> They use own IDENTIFY instead. inquiry should work for ATAPI devices, > >>> as they are SCSI deep inside. > >> This is really the big missing piece in camcontrol; we need to add > >> support for getting the IDENT info and getting/setting various > >> attributes, as well as sending ATA commands over passthrough. > > > > not sure if this is related, but I always wondered why tools like > > smartctl never work with USB attached ATA disks. Is it missing support > > in our drivers and smartctl or is it simply impossible? > > The possibility depends on several hardware and software factors. If the > USB disk enclosure was speaking ATA all the way up to the umass driver, > then it could be possible to add some extra intelligence to the driver to > make SMART work. However, if the enclosure chip is speaking anything > else, then probably not. As an alternative, you might try to the ata-usb > module instead and see if that works. It also depends heavily on which USB bridge chip is in your external enclosure. See these links for a table of known good/bad enclosures: http://smartmontools.wiki.sourceforge.net/USB http://smartmontools.wiki.sourceforge.net/overview_USB-Support -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 17:06:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9ACA61065675 for ; Mon, 29 Jun 2009 17:06:25 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from cp-out2.libero.it (cp-out2.libero.it [212.52.84.102]) by mx1.freebsd.org (Postfix) with ESMTP id 32F788FC1F for ; Mon, 29 Jun 2009 17:06:25 +0000 (UTC) (envelope-from barbara.xxx1975@libero.it) Received: from libero.it (192.168.17.12) by cp-out2.libero.it (8.5.107) id 4A44B87D00245C9A for freebsd-current@freebsd.org; Mon, 29 Jun 2009 19:06:24 +0200 Date: Mon, 29 Jun 2009 19:06:23 +0200 Message-Id: MIME-Version: 1.0 X-Sensitivity: 3 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable From: "barbara" To: "freebsd-current" X-XaM3-API-Version: 4.3 (R1) (B3pl25) X-SenderIP: 87.3.184.40 Subject: ata cable on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 17:06:26 -0000 Hi, sorry for asking again but nothing changed in the meanwhile. # uname -a FreeBSD satanasso.local.net 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Feb 2= 1 05:58:23 CEST 2009 root at satanasso.local.net:/usr/obj/usr/src/sys/SAT= ANASSO i386 In my dmesg I have: atapci2: port 0x1f0-0x1f7,0x3f6,0x170-0x17= 7,0x376,0xfc00-0xfc0f at device 15.1 on pci0 ata0: on atapci2 ... ad0: DMA limited to UDMA33, device found non-ATA66 cable ad0: 152627MB at ata0-master UDMA33 ... ad1: 117246MB at ata0-slave UDMA133 # atacontrol info ata0 Master: ad0 ATA/ATAPI revision 7 Slave: ad1 ATA/ATAPI revision 7 So, if ad0 and ad1 are both attached with the same cable, why ad0 should = be limited while ad1 is not? On 7-STABLE, I have: ad0: 152627MB at ata0-master UDMA100 which seems correct. I've also replaced the cable with a brand new one, with the same results.= So, what's wrong? Anyone knows what could be the problem? I wonder if I should be worried about my HW. Thanks Barbara From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 17:55:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93D61106566C for ; Mon, 29 Jun 2009 17:55:03 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2AB8FC15 for ; Mon, 29 Jun 2009 17:55:02 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=FX71IqPRD0gA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=nhcUl4RjOkunimaTTzYA:9 a=YvzOHj9fYW2u5l71a14A:7 a=5p-KKcKfaNxnYHrdDbmRhvUsiFwA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1269617465 for freebsd-current@freebsd.org; Mon, 29 Jun 2009 18:55:00 +0200 Received-SPF: softfail receiver=mailfe04.swip.net; client-ip=62.113.132.61; envelope-from=hselasky@freebsd.org From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 29 Jun 2009 18:54:32 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906291854.33113.hselasky@freebsd.org> Subject: Contigmalloc regression seen on latest 7.x and 8.x branches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 17:55:03 -0000 Hi, I know there has been some changes in the contigmalloc area this year. It appears to me like if a bug has sneaked in. My PCI driver is trying to allocate 32K aligned to 32K. I've added some debug prints to isolate the failing case: contigmalloc: size=0x00008000, flag=2, low=0x00000000 high=0xffffffff alignment=0x00008000 boundary=0x00000000 contigmalloc: ret=0xe5af2000 bus_dmamem_alloc failed to align memory properly. > uname -a FreeBSD xxxx 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Mon Jun 29 18:43:03 CEST 2009 xxx@xxx:/usr/obj/usr/8-current/src/sys/custom i386 It should be quite trivial to reproduce. Simply make a KLD that calls contigmalloc() with the parameters given above. Anyone have any patches? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 18:44:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 168C01065686 for ; Mon, 29 Jun 2009 18:44:52 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id E8C128FC14 for ; Mon, 29 Jun 2009 18:44:51 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n5TIipIJ013413 for ; Mon, 29 Jun 2009 11:44:51 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n5TIipl2013412 for freebsd-current@freebsd.org; Mon, 29 Jun 2009 11:44:51 -0700 (PDT) (envelope-from sgk) Date: Mon, 29 Jun 2009 11:44:51 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20090629184451.GA13281@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: NFS breaks building kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 18:44:52 -0000 Am I missing something obvious? r193272 was committed on 20090601 (over 28 days ago), and I haven't seen anyone else report this build failure. hpc:root:exit:[220] cd /usr/src hpc:root:exit:[221] svn update hpc:root:exit:[222] make buildworld (completes as expected) hpc:root:exit:[223] make buildkernel cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=opteron -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/nfsclient/nfs_socket.c cc1: warnings being treated as errors /usr/src/sys/nfsclient/nfs_socket.c: In function 'nfs_clnt_match_xid': /usr/src/sys/nfsclient/nfs_socket.c:830: warning: 'return' with no value, in function returning non-void hpc:root:exit:[224] svn blame /usr/src/sys/nfsclient/nfs_socket.c | head -840 193272 jhb static int 138496 ps nfs_clnt_match_xid(struct socket *so, 138496 ps struct nfsmount *nmp, 138496 ps struct mbuf *mrep) 138496 ps { 138496 ps struct mbuf *md; 138496 ps caddr_t dpos; 138496 ps u_int32_t rxid, *tl; 138496 ps struct nfsreq *rep; 138496 ps int error; 138496 ps 1541 rgrimes /* 1541 rgrimes * Search for any mbufs that are not a multiple of 4 bytes long 1541 rgrimes * or with m_data not longword aligned. 1541 rgrimes * These could cause pointer alignment problems, so copy them to 1541 rgrimes * well aligned mbufs. 1541 rgrimes */ 138496 ps if (nfs_realign(&mrep, 5 * NFSX_UNSIGNED) == ENOMEM) { 138496 ps m_freem(mrep); 138496 ps nfsstats.rpcinvalid++; 138496 ps return; 138496 ps } From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 19:06:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CDB710656D8; Mon, 29 Jun 2009 19:06:09 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id 9A49C8FC38; Mon, 29 Jun 2009 19:06:08 +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 fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n5THrCej027527; Tue, 30 Jun 2009 03:53:12 +1000 Received: from c122-107-127-32.carlnfd1.nsw.optusnet.com.au (c122-107-127-32.carlnfd1.nsw.optusnet.com.au [122.107.127.32]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n5THr8k7025295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 03:53:09 +1000 Date: Tue, 30 Jun 2009 03:53:09 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Rick Macklem In-Reply-To: Message-ID: <20090630010035.E37426@delplex.bde.org> References: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 29 Jun 2009 19:21:47 +0000 Cc: Attilio Rao , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 19:06:09 -0000 On Mon, 29 Jun 2009, Rick Macklem wrote: > On Mon, 29 Jun 2009, Attilio Rao wrote: >> >> While that should be real in principle (immediate shutdown of the fs >> operation and unmounting of the partition) it is totally impossible to >> have it completely unsleeping, so it can happen that also umount -f >> sleeps / delays for some times (example: vflush). >> Currently, umount -f is one of the most complicated thing to handle in >> our VFS because it puts as requirement that vnodes can be reclaimed in >> any moment, adding complexity and possibility for races. >> > Yes, agreed. And I like to leave that stuff to more clever chaps than I:-) > >> What's the fix for your problem? >> > Well, when I tested it I found that it got stuck in two places, both > calls to VFS_SYNC(). The first was a > sync(); > right at the beginning of umount.c. > - All I did for that one is move it to after the code that handles > option processing and change it to > if ((fflag & MNT_FORCE) == 0) > sync(); > so that it isn't done for the "-f" case. (I believe the sync(); call > at the beginning of umount is only a performance optimization, so I > don't think not doing it for "-f" should break anything.) OK. This sync() is probably actually a performance pessimization, since it syncs all file systems while the internal sync in umount(2) only syncs the one being unmounted. > - the second happened just before the VFS_UNMOUNT() call in the > umount(2) system call. The code looks like: > if (((mp->mnt_flag & MNT_RDONLY) || > (error = VFS_SYNC(mp, MNT_WAIT)) == 0) || (flags & MNT_FORCE) != > 0) > - Although it was tempting to reverse the order of VFS_SYNC() and the > test for MNT_FORCE, I thought that might have a negative impact on > other file systems, since it avoided doing the VFS_SYNC(), so... > > - Instead, I just put a check for MNTK_UNMOUNTF at the beginning of > nfs_sync(), so that it returns EBUSY for this case instead of getting > stuck trying to flush(). OK. This sync is probably an optimization for correctness, since it arranges to do as much as possible without forcing. I checked ffs_mount() and found 2 large bugs, one related: - in the only case that tends to cause problems, namely the non-readonly case, ffs_unmount() does a suspend which calls VOP_SYNC(..., MNT_SUSPEND), but after errors from this sync it checks neither MNT_FORCE nor error == ENXIO. I think the usual effect is the same as if the top-level unmount() didn't check MNT_FORCE after suspend failure: in problematic cases, we have an unrecoverable write, due to the device going away or just an i/o error, and this error has probably already occured (only in rare cases will it be triggered by unmount). Then MNT_FORCE is essentially unused, and the ENXIO hack is not reached either, and unmount usually fails. - the UFS_EXTATTR case destroys infrastructure before committing to succeeding. It used to be just broken on failure. Now it uses a hack to recover (call a constructor) on failure, but the recovery code is not reached in the usual case of failure -- when the suspension fails. ffs_unmount() still seems to have no support for handling unrecoverable write errors (short of you converting them to ENXIO by removing the media). MNT_FORCE only meant FORCECLOSE for it. I see that old nfs was similar, and you are now making MNT_FORCE stronger. I thought that umount(8)'s man page documented -f being strongly forceful, but checking it shows that it only documents a weak force like that of FORCECLOSE (but not precisely enough). Perhaps a different flag should be used for strong forcefulness. Weak forcefulness is still useful and used for mount -f -u -- for remount we would never want errors in the file system itself ignored. This use also shows that the generic FORCECLOSE code must not ignore errors. > Assuming that I'm right w.r.t. the "sync();" at the beginning of umount.c, > it simply ensures that the umount command thread makes it as far as > VFS_UNMOUNT()->nfs_unmount(), so that the forced dismount proceeds. It > kills RPCs in progress before doing the vflush() and, since no new RPCs > can be done once MNTK_UNMOUNTF is set (it is checked at the beginning of > a request), the vflush() won't actually flush anything to the server. > > As such, "umount -f" is pretty well guaranteed to throw away the dirty > buffers. I believe this is correct behaviour, This is how I think ffs_mount() should work too -- It should be responsible for throwing away the dirty buffers, while nothing else should discard them. Now the discarding seems to be done by falling through to g_vfs_done(), except g_vfs_done() is not reached in most cases (see above). I don't like this -- at best we lose the opportunity to print ffs-specific details about what was discarded. Falling through only works for ENXIO anyway -- on other errors we should discard the unwritable buffers in an fs-specific manner so as to write as many of the writable buffers as possible. > but it would mean that a > user/sysadmin that uses "umount -f" for cases where the server is still > functioning, but slow, will lose data when they probably don't expect to. A new flag would help for this. Bruce From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 19:30:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9921D1065676 for ; Mon, 29 Jun 2009 19:30:47 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id F3E898FC0A for ; Mon, 29 Jun 2009 19:30:46 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=XeHGSSaKqpQA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=ybTnKnmfmk7bjazL_lwA:9 a=jHbX2T028v__F4fu8mEA:7 a=TRiYQsOG6fvM-EEu8ySSv10iUCoA:4 a=PQXiHq2M1sqlfDBX:21 a=F-4mQ6ChX0iEY96d:21 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1275329800; Mon, 29 Jun 2009 21:30:44 +0200 From: Hans Petter Selasky To: Alan Cox , freebsd-current@freebsd.org Date: Mon, 29 Jun 2009 21:30:15 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906292005.18629.hselasky@c2i.net> <4A4907AE.1080303@cs.rice.edu> In-Reply-To: <4A4907AE.1080303@cs.rice.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906292130.16718.hselasky@c2i.net> Cc: Subject: Re: Contigmalloc regression seen on latest 7.x and 8.x branches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 19:30:48 -0000 On Monday 29 June 2009 20:27:58 Alan Cox wrote: > > "ret" is a virtual address. What is the underlying physical address? Hi, It looks like the physical address is correct according to my printouts. The regression issue boils down to misleading printouts from the following files, which should/can then be removed: /usr/8-current/src/sys/amd64/amd64/busdma_machdep.c: printf("bus_dmamem_alloc failed to align memory properly.\n"); /usr/8-current/src/sys/i386/i386/busdma_machdep.c: printf("bus_dmamem_alloc failed to align memory properly.\n"); /usr/8-current/src/sys/ia64/ia64/busdma_machdep.c: printf("bus_dmamem_alloc failed to align memory properly.\n"); contigmalloc: size=0x00008000, flag=2, low=0x00000000 high=0xffffffff alignment=0x00008000 boundary= 0x00000000 contigmalloc: ret=0xe5af2000 contigmalloc: vtophys(ret)=0x01670000 contigmalloc: vtophys(ret)=0x01671000 contigmalloc: vtophys(ret)=0x01672000 contigmalloc: vtophys(ret)=0x01673000 contigmalloc: vtophys(ret)=0x01674000 contigmalloc: vtophys(ret)=0x01675000 contigmalloc: vtophys(ret)=0x01676000 contigmalloc: vtophys(ret)=0x01677000 bus_dmamem_alloc failed to align memory properly. bus_dmamem_alloc = 0 pg->physaddr = 0x01670000, nseg=1 bus_dmamap_load = 0 0x01670000, 0xe5af2000 ihfc1: port 0xa400-0xa407 mem 0xf5004000-0xf50040ff irq 18 at devi ce 8.0 on pci1 ihfc1: [ITHREAD] ihfc1: Attaching I4B controller 1. ihfc1: Creating /dev/ihfc1.X. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 19:42:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9B8A1065674 for ; Mon, 29 Jun 2009 19:42:22 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id B06668FC19 for ; Mon, 29 Jun 2009 19:42:22 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n5TJgMaF068863 for ; Mon, 29 Jun 2009 12:42:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n5TJgM1n068853 for freebsd-current@freebsd.org; Mon, 29 Jun 2009 12:42:22 -0700 (PDT) (envelope-from sgk) Date: Mon, 29 Jun 2009 12:42:22 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20090629194222.GA31358@troutmask.apl.washington.edu> References: <20090629184451.GA13281@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090629184451.GA13281@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Subject: Re: NFS breaks building kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 19:42:23 -0000 On Mon, Jun 29, 2009 at 11:44:51AM -0700, Steve Kargl wrote: > Am I missing something obvious? r193272 was committed on 20090601 > (over 28 days ago), and I haven't seen anyone else report this > build failure. > r193272 simply can't be correct. 1.168 ! jhb 125: static int nfs_clnt_tcp_soupcall(struct socket *so, void *arg, int waitflag); 1.116 ps 950: static void 951: nfs_clnt_tcp_soupcall(struct socket *so, void *arg, int waitflag) -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 19:51:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAEED106564A for ; Mon, 29 Jun 2009 19:51:09 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from mx.egr.msu.edu (surfnturf.egr.msu.edu [35.9.37.164]) by mx1.freebsd.org (Postfix) with ESMTP id C101E8FC16 for ; Mon, 29 Jun 2009 19:51:09 +0000 (UTC) (envelope-from mcdouga9@egr.msu.edu) Received: from localhost (localhost [127.0.0.1]) by mx.egr.msu.edu (Postfix) with ESMTP id 4328047D97; Mon, 29 Jun 2009 15:51:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at egr.msu.edu Received: from mx.egr.msu.edu ([127.0.0.1]) by localhost (surfnturf.egr.msu.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXx6xUEP7jKG; Mon, 29 Jun 2009 15:51:09 -0400 (EDT) Received: from [35.9.44.65] (daemon.egr.msu.edu [35.9.44.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mcdouga9) by mx.egr.msu.edu (Postfix) with ESMTPSA id 1F63947D94; Mon, 29 Jun 2009 15:51:08 -0400 (EDT) Message-ID: <4A491B2C.40808@egr.msu.edu> Date: Mon, 29 Jun 2009 15:51:08 -0400 From: Adam McDougall User-Agent: Thunderbird 2.0.0.22 (X11/20090625) MIME-Version: 1.0 To: Hans Petter Selasky References: <200906291756.42099.hselasky@c2i.net> <1246291530.1759.47.camel@balrog.2hip.net> <200906291828.57512.hselasky@c2i.net> In-Reply-To: <200906291828.57512.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: False positive VGA PCI device detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 19:51:10 -0000 Hans Petter Selasky wrote: > On Monday 29 June 2009 18:05:30 Robert Noland wrote: > >> On Mon, 2009-06-29 at 17:56 +0200, Hans Petter Selasky wrote: >> >>> Hi, >>> >>> I'm not sure if my ISDN adapter has been collecting dust for too long or >>> what, but I was surprised about the following: >>> >>> vgapci1@pci0:1:8:0: class=0x038000 card=0x2bd01397 chip=0x2bd01397 >>> rev=0x02 hdr=0x00 >>> vendor = 'Cologne Chip Designs GmbH' >>> device = 'HFC-S PCI A ISDN 2BDS0 ISDN HDLC FIFO Controller' >>> class = display >>> >> Why is the pci class coming up as a display? That is why it is >> attaching. >> > > I have no idea. I simply inserted the card into the box. I looked at the > vga_pci.c and there seems to be several VGA PCI classes. One old and one new. > > --HPS > > I have seen things like this happen when the card was not seated in the PCI slot well or there was something wrong with the slot. I've seen Intel nics come up as an invalid product ID or even a "non-vga display device". Maybe that is what happened since you said you just inserted it? From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 20:15:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C05B10656C2 for ; Mon, 29 Jun 2009 20:15:05 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe09.tele2.se [212.247.155.1]) by mx1.freebsd.org (Postfix) with ESMTP id C17FD8FC14 for ; Mon, 29 Jun 2009 20:15:04 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=dJ6xPsu-cwQA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=aRuJoHwZHG4bbRuFLlUA:9 a=ecRMPh1z0f_Q9_bGVZAA:7 a=ZRxuAyq-LTxE7HpEoEa5vFYa-q8A:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe09.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 923632594; Mon, 29 Jun 2009 22:00:03 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 29 Jun 2009 21:59:35 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906291756.42099.hselasky@c2i.net> <200906291828.57512.hselasky@c2i.net> <4A491B2C.40808@egr.msu.edu> In-Reply-To: <4A491B2C.40808@egr.msu.edu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906292159.36218.hselasky@c2i.net> Cc: Adam McDougall Subject: Re: False positive VGA PCI device detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 20:15:05 -0000 On Monday 29 June 2009 21:51:08 Adam McDougall wrote: > Hans Petter Selasky wrote: > > On Monday 29 June 2009 18:05:30 Robert Noland wrote: > >> On Mon, 2009-06-29 at 17:56 +0200, Hans Petter Selasky wrote: > >>> Hi, > >>> > >>> I'm not sure if my ISDN adapter has been collecting dust for too long > >>> or what, but I was surprised about the following: > >>> > >>> vgapci1@pci0:1:8:0: class=0x038000 card=0x2bd01397 chip=0x2bd01397 > >>> rev=0x02 hdr=0x00 > >>> vendor = 'Cologne Chip Designs GmbH' > >>> device = 'HFC-S PCI A ISDN 2BDS0 ISDN HDLC FIFO Controller' > >>> class = display > >> > >> Why is the pci class coming up as a display? That is why it is > >> attaching. > > > > I have no idea. I simply inserted the card into the box. I looked at the > > vga_pci.c and there seems to be several VGA PCI classes. One old and one > > new. > > > > --HPS > > I have seen things like this happen when the card was not seated in the > PCI slot well or there was something wrong with the slot. I've seen > Intel nics come up as an invalid product ID or even a "non-vga display > device". Maybe that is what happened since you said you just inserted it? Right. After a re-plug it looks normal, and it works - cool :-) ihfc1@pci0:1:8:0: class=0x028000 card=0x2bd01397 chip=0x2bd01397 rev=0x02 hdr=0x00 vendor = 'Cologne Chip Designs GmbH' device = 'HFC-S PCI A ISDN 2BDS0 ISDN HDLC FIFO Controller' class = network Sorry for spamming. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 20:15:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FFCA1065674; Mon, 29 Jun 2009 20:15:36 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 166678FC2C; Mon, 29 Jun 2009 20:15:36 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n5TKFZOK062307; Mon, 29 Jun 2009 13:15:35 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n5TKFZBX062306; Mon, 29 Jun 2009 13:15:35 -0700 (PDT) (envelope-from sgk) Date: Mon, 29 Jun 2009 13:15:35 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20090629201535.GA34777@troutmask.apl.washington.edu> References: <20090629184451.GA13281@troutmask.apl.washington.edu> <20090629194222.GA31358@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090629194222.GA31358@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2.3i Cc: Subject: Revision r193272 hoses kernel builds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 20:15:36 -0000 On Mon, Jun 29, 2009 at 12:42:22PM -0700, Steve Kargl wrote: > On Mon, Jun 29, 2009 at 11:44:51AM -0700, Steve Kargl wrote: > > Am I missing something obvious? r193272 was committed on 20090601 > > (over 28 days ago), and I haven't seen anyone else report this > > build failure. > > > > r193272 simply can't be correct. > > 1.168 ! jhb 125: static int nfs_clnt_tcp_soupcall(struct socket *so, void *arg, int waitflag); > > 1.116 ps 950: static void > 951: nfs_clnt_tcp_soupcall(struct socket *so, void *arg, int waitflag) > Making what appears to be the obvious fixes to nfsclient/nfs_sockets.c leads to a failure in /usr/src/sys/nfsserver/nfs_srvsock.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=opteron -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/nfsserver/nfs_srvsock.c cc1: warnings being treated as errors /usr/src/sys/nfsserver/nfs_srvsock.c: In function 'nfsrv_rcv': /usr/src/sys/nfsserver/nfs_srvsock.c:530: warning: control reaches end of non-void function *** Error code 1 -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 20:16:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1337D106568D for ; Mon, 29 Jun 2009 20:16:53 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id BAAAF8FC15 for ; Mon, 29 Jun 2009 20:16:52 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKK9SEqDaFvJ/2dsb2JhbADOCoQNBYkA X-IronPort-AV: E=Sophos;i="4.42,311,1243828800"; d="scan'208";a="39719446" Received: from ganges.cs.uoguelph.ca ([131.104.91.201]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 29 Jun 2009 16:16:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 422A5FB8012; Mon, 29 Jun 2009 16:16:51 -0400 (EDT) X-Virus-Scanned: amavisd-new at ganges.cs.uoguelph.ca Received: from ganges.cs.uoguelph.ca ([127.0.0.1]) by localhost (ganges.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBnCyxQqxKcB; Mon, 29 Jun 2009 16:16:50 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by ganges.cs.uoguelph.ca (Postfix) with ESMTP id 2C014FB801A; Mon, 29 Jun 2009 16:16:50 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5TKJ8s26225; Mon, 29 Jun 2009 16:19:08 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 29 Jun 2009 16:19:07 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Steve Kargl In-Reply-To: <20090629184451.GA13281@troutmask.apl.washington.edu> Message-ID: References: <20090629184451.GA13281@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: NFS breaks building kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 20:16:53 -0000 On Mon, 29 Jun 2009, Steve Kargl wrote: > Am I missing something obvious? r193272 was committed on 20090601 > (over 28 days ago), and I haven't seen anyone else report this > build failure. > I believe that NFS_LEGACYRPC is no longer being supported. I don't know if nfs_socket.c can be removed yet or not. (It's entire code body is #ifdef'd NFS_LEGACYRPC, so I don't think does anything any more.) rick From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 20:18:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D1A81065676 for ; Mon, 29 Jun 2009 20:18:13 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from vps.kc8onw.net (kc8onw.net [69.31.85.203]) by mx1.freebsd.org (Postfix) with ESMTP id 05C818FC2B for ; Mon, 29 Jun 2009 20:18:12 +0000 (UTC) (envelope-from jonathan@kc8onw.net) Received: from [192.168.0.115] (ddsl-66-117-234-114.fuse.net [66.117.234.114]) by vps.kc8onw.net (Postfix) with ESMTPSA id 1C38617041 for ; Mon, 29 Jun 2009 16:18:12 -0400 (EDT) Message-ID: <4A492178.6040909@kc8onw.net> Date: Mon, 29 Jun 2009 16:18:00 -0400 From: Jonathan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4A44427E.3040309@kc8onw.net> <912B4712-A56C-41DF-9405-F19F6CC0778D@exscape.org> <4A468115.1030806@kc8onw.net> In-Reply-To: <4A468115.1030806@kc8onw.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 20:18:13 -0000 I'd like to have RAIDZ booting working on my system so I'm offering a $50 US bounty (paid via Paypal) to the first person that gets it working for me. Another person has offered an additional $50 US if the solution works for him as well. I can provide remote ssh and serial access to the system. I'm willing to sit in front of the machine while it's being worked on for as long as needed or I can follow instructions, whichever is easier. Jonathan From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 20:24:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1014F106567C for ; Mon, 29 Jun 2009 20:24:39 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id CB6EF8FC16 for ; Mon, 29 Jun 2009 20:24:38 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n5TKOc3U099385; Mon, 29 Jun 2009 13:24:38 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n5TKOcRv099374; Mon, 29 Jun 2009 13:24:38 -0700 (PDT) (envelope-from sgk) Date: Mon, 29 Jun 2009 13:24:38 -0700 From: Steve Kargl To: Rick Macklem Message-ID: <20090629202438.GA69990@troutmask.apl.washington.edu> References: <20090629184451.GA13281@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: NFS breaks building kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 20:24:39 -0000 On Mon, Jun 29, 2009 at 04:19:07PM -0400, Rick Macklem wrote: > > On Mon, 29 Jun 2009, Steve Kargl wrote: > > >Am I missing something obvious? r193272 was committed on 20090601 > >(over 28 days ago), and I haven't seen anyone else report this > >build failure. > > > I believe that NFS_LEGACYRPC is no longer being supported. > Oh, okay. I didn't see anything in src/UPDATING from the June 1 time period moving forward. > I don't know if nfs_socket.c can be removed yet or not. (It's entire > code body is #ifdef'd NFS_LEGACYRPC, so I don't think does anything > any more.) Perhaps, a #error "NFS_LEGACYRPC kernel option is deprecated" is needed. The diff below fixes the build, but I don't know if its correct. -- Steve Index: nfsclient/nfs_socket.c =================================================================== --- nfsclient/nfs_socket.c (revision 195169) +++ nfsclient/nfs_socket.c (working copy) @@ -807,7 +807,7 @@ * XXX TO DO * Make nfs_realign() non-blocking. Also make nfsm_dissect() nonblocking. */ -static int +static void nfs_clnt_match_xid(struct socket *so, struct nfsmount *nmp, struct mbuf *mrep) @@ -947,7 +947,7 @@ return (len); } -static void +static int nfs_clnt_tcp_soupcall(struct socket *so, void *arg, int waitflag) { struct nfsmount *nmp = (struct nfsmount *)arg; @@ -1085,7 +1085,7 @@ return (SU_OK); } -static void +static int nfs_clnt_udp_soupcall(struct socket *so, void *arg, int waitflag) { struct nfsmount *nmp = (struct nfsmount *)arg; Index: nfsserver/nfs_srvsock.c =================================================================== --- nfsserver/nfs_srvsock.c (revision 195169) +++ nfsserver/nfs_srvsock.c (working copy) @@ -527,6 +527,7 @@ (slp->ns_flag & (SLP_NEEDQ | SLP_DISCONN)))) nfsrv_wakenfsd(slp); NFSD_UNLOCK(); + return (SU_OK); } From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 20:41:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 382B61065677 for ; Mon, 29 Jun 2009 20:41:59 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id D0AB18FC16 for ; Mon, 29 Jun 2009 20:41:58 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from smoochies.rachie.is-a-geek.net (mailhub.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id C66F27E837; Mon, 29 Jun 2009 12:41:57 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Mon, 29 Jun 2009 12:41:55 -0800 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906271948.54745.mel.flynn+fbsd.current@mailing.thruhere.net> <20090629144205.GA83592@lor.one-eyed-alien.net> In-Reply-To: <20090629144205.GA83592@lor.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906291241.56414.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Brooks Davis Subject: Re: Interface dependencies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 20:41:59 -0000 On Monday 29 June 2009 06:42:06 Brooks Davis wrote: > On Sat, Jun 27, 2009 at 07:48:54PM -0800, Mel Flynn wrote: > > Hi, > > > > maybe I'm overlooking something, so I thought I'd ask. > > As far as I can tell, there is no way to specify interface dependencies, > > so I have an issue I cannot seem to solve: > > - Create a lagg0 that has em and wlan0 at boot time, because wlan0 takes > > too long to be configured - and the default network_interfaces=AUTO sorts > > alphabetically which is not making matters easier. > > The interfaces should be in the order they are probed/created. No > sorting should be performed beyond moving lo0 to the front in the > default case. Then my probing is probably alphabetical as a coincedence. > > I've been trying to use hacks, but I think interfaces really need > > dependencies. Like ifconfig_lagg0_require="wlan0 em0", which would first > > configure wlan0, wait for it to be availabe, then em0 and finally lagg0. > > > > Is there something available, is it a known issue and ENOTIME to fix or > > am I missing something else? > > There isn't a feature to add dependencies, but there probably should be. I'll see what I can come up, cause on 7-STABLE box I've got similar issues with a bridge if I use WPA (i.e. hostapd). It seems like the proper solution even if there is no problem ;). > I'm not sure that's really what the problem is there though. > > > At present, my rc.conf entries are: > > # Need to do this manually to prevent alphabetical sorting. > > network_interfaces="wpi0 lo0 em0" > > cloned_interfaces="lagg0" > > wlans_wpi0="wlan0" > > ifconfig_wpi0="ether 00:16:36:f2:3b:84" > > ifconfig_wlan0="WPA" > > ifconfig_em0="up" > > ifconfig_lagg0="laggproto failover laggport em0" > > ifconfig_lagg0_alias0="laggport wlan0" > > ifconfig_lagg0_alias1="inet 192.168.2.50 netmask 255.255.255.0" > > > > And this gives me a lagg0 at boottime without wlan0, since the interface > > don't exist. I also cannot add inet commands to laggport commands, thus > > the alias trick is already needed, yet the delay caused by running > > separate commands does not seem to be enough to have wlan0 available. > > wlan0 should exist by the time lagg0 is created because it's created and > configured synchronously when wpi0 is configured. I know other people > are using lagg this way so I'm a bit confused as to what's wrong. > Enabling verbose start up and examining the output might be telling. I'll revert to what it "should really be" and keep rc_debug. Meanwhile I discovered create_args and made it a bit less hacky: /etc/start_if.wpi0 sets ether to em0 ether network_interfaces="wpi0 lo0 em0" cloned_interfaces="wlan0 lagg0" create_args_wlan0="wlandev wpi0 wlanmode sta" ifconfig_wlan0="WPA" ifconfig_em0="up" ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0" ifconfig_lagg0_alias0="inet 192.168.2.50 netmask 255.255.255.0" I tried using wlanaddr in create_args_wlan0 but then ended up with a wpi0 with it's own MAC and wlan0 with the right one, which of course didn't associate. -- Mel From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 20:49:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7B28106564A for ; Mon, 29 Jun 2009 20:49:46 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 639518FC1C for ; Mon, 29 Jun 2009 20:49:45 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 39C6778F7F for ; Tue, 30 Jun 2009 00:49:44 +0400 (MSD) Message-ID: <4A4928E8.6070401@haruhiism.net> Date: Tue, 30 Jun 2009 00:49:44 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: r195153M with ahci.ko: page faults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 20:49:47 -0000 I've updated to r195153 approximately 10 hours ago, installed the AHCI CAM patch (and so far it works fine), however after the installworld and reboot the machine started throwing "fatal trap 12" every hour or so, with approximately the same reason. Disabled gmirror and got a core (however I'm still unsure if it's caused by jailed mysqld as listed here; attempting to rebuild mysqld): kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1332618 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8058ada5 stack pointer = 0x28:0xffffff80404015f0 frame pointer = 0x28:0xffffff8040401620 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 2234 (mysqld) Physical memory: 2014 MB Dumping 1309 MB: 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:223 223 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:223 #1 0xffffffff801f908c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801f93c1 in db_command (last_cmdp=0xffffffff80becce0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801f9610 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801fb5b9 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff805c9475 in kdb_trap (type=12, code=0, tf=0xffffff8040401540) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff808624ad in trap_fatal (frame=0xffffff8040401540, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:847 #7 0xffffffff80863135 in trap (frame=0xffffff8040401540) at /usr/src/sys/amd64/amd64/trap.c:345 #8 0xffffffff80849423 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #9 0xffffffff8058ada5 in _mtx_lock_sleep (m=0xffffffff80e98863, tid=18446742974585068208, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 #10 0xffffffff8058aefe in _mtx_lock_flags (m=Variable "m" is not available. ) at /usr/src/sys/kern/kern_mutex.c:203 #11 0xffffffff806475e5 in netisr_queue_internal (proto=1, m=0xffffff001ba5c700, cpuid=Variable "cpuid" is not available. ) at /usr/src/sys/net/netisr.c:829 #12 0xffffffff806476c9 in netisr_queue_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:859 #13 0xffffffff80643629 in if_simloop (ifp=0xffffff000444e800, m=0xffffff001ba5c700, af=2, hlen=0) at /usr/src/sys/net/if_loop.c:400 #14 0xffffffff80643786 in looutput (ifp=0xffffff000444e800, m=0xffffff001ba5c700, dst=0xffffff80404017a0, ro=Variable "ro" is not available. ) at /usr/src/sys/net/if_loop.c:296 #15 0xffffffff806a2767 in ip_output (m=0xffffff001ba5c700, opt=Variable "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:624 #16 0xffffffff80707dc4 in tcp_output (tp=0xffffff00175205b0) at /usr/src/sys/netinet/tcp_output.c:1188 #17 0xffffffff80714469 in tcp_usr_send (so=0xffffff001b53b550, flags=0, m=Variable "m" is not available. ) at tcp_offload.h:269 #18 0xffffffff805fd327 in sosend_generic (so=0xffffff001b53b550, addr=0x0, uio=0xffffff8040401b10, top=0xffffff0017b79500, control=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/uipc_socket.c:1257 #19 0xffffffff805e1a37 in soo_write (fp=Variable "fp" is not available. ) at /usr/src/sys/kern/sys_socket.c:102 #20 0xffffffff805daeb5 in dofilewrite (td=0xffffff0017135ab0, fd=34, fp=0xffffff00179e8b90, auio=0xffffff8040401b10, offset=Variable "offset" is not available. ) at file.h:239 #21 0xffffffff805dc490 in kern_writev (td=0xffffff0017135ab0, fd=34, auio=0xffffff8040401b10) at /usr/src/sys/kern/sys_generic.c:445 #22 0xffffffff805dc595 in write (td=Variable "td" is not available. ) at /usr/src/sys/kern/sys_generic.c:361 #23 0xffffffff808629df in syscall (frame=0xffffff8040401c90) at /usr/src/sys/amd64/amd64/trap.c:984 #24 0xffffffff808496b0 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #25 0x000000080162befc in ?? () Previous frame inner to this frame (corrupt stack?) -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 19:55:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0DEA110656A4; Mon, 29 Jun 2009 19:55:04 +0000 (UTC) (envelope-from gthiel@smapper.com) Received: from qhexrelay2.hosting.inetserver.de (fw1.hostedoffice.ag [81.20.90.82]) by mx1.freebsd.org (Postfix) with ESMTP id 82C258FC1B; Mon, 29 Jun 2009 19:55:03 +0000 (UTC) (envelope-from gthiel@smapper.com) Received: from qhexhub1.hosting.inetserver.de (unknown [10.20.10.20]) by qhexrelay2.hosting.inetserver.de (Postfix) with ESMTP id B1ED8187086; Mon, 29 Jun 2009 21:29:20 +0200 (CEST) Received: from QHEXMBOX1.hosting.inetserver.de ([10.20.10.31]) by qhexhub1.hosting.inetserver.de ([10.20.10.225]) with mapi; Mon, 29 Jun 2009 21:37:39 +0200 Content-Type: multipart/mixed; boundary="_000_0FEF727F15922F4D8349632C35EE6C276FB1A4470AQHEXMBOX1host_" From: Gunther Thiel To: "rmacklem@uoguelph.ca" , "freebsd-current@freebsd.org" Date: Mon, 29 Jun 2009 21:37:37 +0200 Thread-Topic: umount -f implementation Thread-Index: Acn4UEBr2pLuAmXgTF6/pO1Lp8OXUAAoM6Qy Message-ID: <0FEF727F15922F4D8349632C35EE6C276FB1A4470A@QHEXMBOX1.hosting.inetserver.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: <0FEF727F15922F4D8349632C35EE6C276FB1A4470A@QHEXMBOX1.hosting.inetserver.de> acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 29 Jun 2009 21:01:17 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-fs@freebsd.org" Subject: AW: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 19:55:04 -0000 --_000_0FEF727F15922F4D8349632C35EE6C276FB1A4470AQHEXMBOX1host_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gcHJhY3RpY2UsIHRoZXJlIGFyZSBzaXR1YXRpb25zIHdoZXJlIG9uZSBkb2VzIHdhbnQgdG8g Z2V0IHJpZCBvZiBhIG5vbiByZWFjaGFibGUgbW91bnBvaW50IChzcGVjaWZpY2FsbHkgZm9yIE5G Uykgd2hpY2ggYmFzaWNhbGx5IGlzIG5vdCBwb3NzaWJsZSBhcyBvZiB0b2RheS4NCg0KQSBmaXgg aW4gY2FzZSB0aGUgLWYgKG9yIGFub3RoZXIgbmV3IGZsYWcgbGlrZSkgd2VyZSBzdXBwbGllZCwg d291bGQgYmUgaGlnaGx5IGFwcHJlY2lhdGVkLg0KDQpUaGFua3MsDQpHdW50aGVyDQoNCg0KLS0N ClNtQXBwZXIgVGVjaG5vbG9naWVzIEdtYkgg4oCTICs0MyA1MzcyIDY5MTIgNjQwIOKAkyB3d3cu c21hcHBlci5jb20NCg0KLS0tLS0gT3JpZ2luYWxuYWNocmljaHQgLS0tLS0NClZvbjogb3duZXIt ZnJlZWJzZC1mc0BmcmVlYnNkLm9yZyA8b3duZXItZnJlZWJzZC1mc0BmcmVlYnNkLm9yZz4NCkFu OiBmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcgPGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9y Zz4NCkNjOiBmcmVlYnNkLWZzQGZyZWVic2Qub3JnIDxmcmVlYnNkLWZzQGZyZWVic2Qub3JnPg0K R2VzZW5kZXQ6IE1vbiBKdW4gMjkgMDI6MDA6MTMgMjAwOQpCZXRyZWZmOiB1bW91bnQgLWYgaW1w bGVtZW50YXRpb24NCg0KSSBqdXN0IG5vdGljZWQgdGhhdCB3aGVuIEkgZG8gdGhlIGZvbGxvd2lu ZzoNCi0gc3RhcnQgYSBsYXJnZSB3cml0ZSB0byBhbiBORlMgbW91bnRlZCBmcw0KLSBuZXR3b3Jr IHBhcnRpdGlvbiB0aGUgc2VydmVyICh1bnBsdWcgYSBuZXQgY2FibGUpDQotIGRvIGEgInVtb3Vu dCAtZiA8bW50cG9pbnQ+IiBvbiB0aGUgbWFjaGluZQ0KDQp0aGF0IGl0IGdldHMgc3R1Y2sgdHJ5 aW5nIHRvIHdyaXRlIGRpcnR5IGJsb2NrcyB0byB0aGUgc2VydmVyLg0KDQpJIGhhZCwgaW4gdGhl IHBhc3QsIGFzc3VtZWQgdGhhdCBhICJ1bW91bnQgLWYiIG9mIGFuIE5GUyBtb3VudCB3b3VsZCBi ZQ0KdXNlZCB0byBnZXQgcmlkIG9mIGFuIE5GUyBtb3VudCBvbiBhbiB1bnJlc3BvbnNpdmUgc2Vy dmVyIGFuZCB0aGF0IGxvc3MNCm9mICJ3cml0ZXMgaW4gcHJvZ3Jlc3MiIHdvdWxkIGJlIGV4cGVj dGVkIHRvIGhhcHBlbi4NCg0KRG9lcyB0aGF0IHNvdW5kIGNvcnJlY3Q/IChJbiBvdGhlciB3b3Jk cywgYW4gSSBzZWVpbmcgYSBidWcgb3IgYSANCmZlYXR1cmU/KQ0KDQpUaGFua3MgaW4gYWR2YW5j ZSBmb3IgYW55IGluZm8sIHJpY2sNCnBzOiBJIGhhdmUgYSBzaW1wbGUgImZpeCIgaWYgdGhpcyBp cyBhIGJ1ZywgYnV0IEkgd2FudGVkIHRvIGNoZWNrIGJlZm9yZQ0KICAgICBzdWJtaXR0aW5nIGEg cGF0Y2guDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K ZnJlZWJzZC1mc0BmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCmh0dHA6Ly9saXN0cy5mcmVlYnNk Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtZnMNClRvIHVuc3Vic2NyaWJlLCBzZW5kIGFu eSBtYWlsIHRvICJmcmVlYnNkLWZzLXVuc3Vic2NyaWJlQGZyZWVic2Qub3JnIg0K --_000_0FEF727F15922F4D8349632C35EE6C276FB1A4470AQHEXMBOX1host_-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 21:11:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48E3C1065686 for ; Mon, 29 Jun 2009 21:11:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 19DD18FC0A for ; Mon, 29 Jun 2009 21:11:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id AEE1646B7E; Mon, 29 Jun 2009 17:11:41 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [IPv6:::1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 602C98A088; Mon, 29 Jun 2009 17:11:40 -0400 (EDT) Message-ID: <4A492E0B.8070006@FreeBSD.org> Date: Mon, 29 Jun 2009 17:11:39 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Steve Kargl References: <20090629184451.GA13281@troutmask.apl.washington.edu> <20090629194222.GA31358@troutmask.apl.washington.edu> <20090629201535.GA34777@troutmask.apl.washington.edu> In-Reply-To: <20090629201535.GA34777@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 29 Jun 2009 17:11:40 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: Revision r193272 hoses kernel builds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 21:11:42 -0000 Steve Kargl wrote: > On Mon, Jun 29, 2009 at 12:42:22PM -0700, Steve Kargl wrote: >> On Mon, Jun 29, 2009 at 11:44:51AM -0700, Steve Kargl wrote: >>> Am I missing something obvious? r193272 was committed on 20090601 >>> (over 28 days ago), and I haven't seen anyone else report this >>> build failure. >>> >> r193272 simply can't be correct. >> >> 1.168 ! jhb 125: static int nfs_clnt_tcp_soupcall(struct socket *so, void *arg, int waitflag); >> >> 1.116 ps 950: static void >> 951: nfs_clnt_tcp_soupcall(struct socket *so, void *arg, int waitflag) >> > > Making what appears to be the obvious fixes to > nfsclient/nfs_sockets.c leads to a failure in > /usr/src/sys/nfsserver/nfs_srvsock.c > > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=opteron -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/nfsserver/nfs_srvsock.c > cc1: warnings being treated as errors > /usr/src/sys/nfsserver/nfs_srvsock.c: In function 'nfsrv_rcv': > /usr/src/sys/nfsserver/nfs_srvsock.c:530: warning: control reaches end of non-void function > *** Error code 1 I don't understand why this compiled fine. I tested the NFS client (my home dir was over NFS) with these changes as well. I don't know how you are getting a compile failure either. Both the nfsclient and nfsserver modules compile fine for me when built as modules. Hmm, are you using NFS_LEGACYRPC? That might explain it. The patch at http://www.FreeBSD.org/~jhb/patches/nfs_upcall.patch should fix the build, but NFS_LEGACYRPC is also slated to be removed for 8.0 I believe. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 21:18:19 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0230410656A7; Mon, 29 Jun 2009 21:18:19 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id B6FDD8FC1C; Mon, 29 Jun 2009 21:18:18 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n5TLII5u036232; Mon, 29 Jun 2009 14:18:18 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n5TLIIRA036231; Mon, 29 Jun 2009 14:18:18 -0700 (PDT) (envelope-from sgk) Date: Mon, 29 Jun 2009 14:18:18 -0700 From: Steve Kargl To: John Baldwin Message-ID: <20090629211818.GA36155@troutmask.apl.washington.edu> References: <20090629184451.GA13281@troutmask.apl.washington.edu> <20090629194222.GA31358@troutmask.apl.washington.edu> <20090629201535.GA34777@troutmask.apl.washington.edu> <4A492E0B.8070006@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A492E0B.8070006@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: Revision r193272 hoses kernel builds X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 21:18:19 -0000 On Mon, Jun 29, 2009 at 05:11:39PM -0400, John Baldwin wrote: > Steve Kargl wrote: > >On Mon, Jun 29, 2009 at 12:42:22PM -0700, Steve Kargl wrote: > >>On Mon, Jun 29, 2009 at 11:44:51AM -0700, Steve Kargl wrote: > >>>Am I missing something obvious? r193272 was committed on 20090601 > >>>(over 28 days ago), and I haven't seen anyone else report this > >>>build failure. > >>> > >>r193272 simply can't be correct. > >> > >>1.168 ! jhb 125: static int nfs_clnt_tcp_soupcall(struct socket *so, > >>void *arg, int waitflag); > >> > >>1.116 ps 950: static void > >> 951: nfs_clnt_tcp_soupcall(struct socket *so, void *arg, > >> int waitflag) > > > >Making what appears to be the obvious fixes to > >nfsclient/nfs_sockets.c leads to a failure in > >/usr/src/sys/nfsserver/nfs_srvsock.c > > > >cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -march=opteron > >-std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef > >-Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys > >-I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS > >-include opt_global.h -fno-common -finline-limit=8000 --param > >inline-unit-growth=100 --param large-function-growth=1000 > >-fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 > >-mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float > >-fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror > >/usr/src/sys/nfsserver/nfs_srvsock.c > >cc1: warnings being treated as errors > >/usr/src/sys/nfsserver/nfs_srvsock.c: In function 'nfsrv_rcv': > >/usr/src/sys/nfsserver/nfs_srvsock.c:530: warning: control reaches end of > >non-void function > >*** Error code 1 > > I don't understand why this compiled fine. I tested the NFS client (my > home dir was over NFS) with these changes as well. I don't know how you > are getting a compile failure either. Both the nfsclient and nfsserver > modules compile fine for me when built as modules. Hmm, are you using > NFS_LEGACYRPC? That might explain it. The patch at > http://www.FreeBSD.org/~jhb/patches/nfs_upcall.patch should fix the > build, but NFS_LEGACYRPC is also slated to be removed for 8.0 I believe. > Yes, I had NFS_LEGACYRPC in the kernel config file. I was updating a cluster from a build that occurred within a few days of the new RPC code, so I added the option as suggested by dfr(?). Your patch is the same as the patch I included in my reply to Rick. It appears that I must have been the only person using NFS_LEGACYRPC. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 21:28:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75293106578B for ; Mon, 29 Jun 2009 21:28:40 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9128FC2B for ; Mon, 29 Jun 2009 21:28:40 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 9EB3F78FA3 for ; Tue, 30 Jun 2009 01:28:38 +0400 (MSD) Message-ID: <4A493207.5@haruhiism.net> Date: Tue, 30 Jun 2009 01:28:39 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4A4928E8.6070401@haruhiism.net> In-Reply-To: <4A4928E8.6070401@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: r195153M with ahci.ko: page faults X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 21:28:42 -0000 Kamigishi Rei wrote: > I've updated to r195153 approximately 10 hours ago, installed the AHCI > CAM patch (and so far it works fine), however after the installworld > and reboot the machine started throwing "fatal trap 12" every hour or > so, with approximately the same reason. Disabled gmirror and got a > core (however I'm still unsure if it's caused by jailed mysqld as > listed here; attempting to rebuild mysqld): Okay it's not related to mysqld: kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x1332618 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff8058ada5 stack pointer = 0x28:0xffffff80403d45f0 frame pointer = 0x28:0xffffff80403d4620 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 64035 (python) Physical memory: 2014 MB Dumping 1737 MB: 1722 1706 1690 1674 1658 1642 1626 1610 1594 1578 1562 1546 1530 1514 1498 1482 1466 1450 1434 1418 1402 1386 1370 1354 1338 1322 1306 1290 1274 1258 1242 1226 1210 1194 1178 1162 1146 1130 1114 1098 1082 1066 1050 1034 1018 1002 986 970 954 938 922 906 890 874 858 842 826 810 794 778 762 746 730 714 698 682 666 650 634 618 602 586 570 554 538 522 506 490 474 458 442 426 410 394 378 362 346 330 314 298 282 266 250 234 218 202 186 170 154 138 122 106 90 74 58 42 26 10 #0 doadump () at pcpu.h:223 223 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:223 #1 0xffffffff801f908c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801f93c1 in db_command (last_cmdp=0xffffffff80becce0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801f9610 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801fb5b9 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff805c9475 in kdb_trap (type=12, code=0, tf=0xffffff80403d4540) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff808624ad in trap_fatal (frame=0xffffff80403d4540, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:847 #7 0xffffffff80863135 in trap (frame=0xffffff80403d4540) at /usr/src/sys/amd64/amd64/trap.c:345 #8 0xffffffff80849423 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #9 0xffffffff8058ada5 in _mtx_lock_sleep (m=0xffffffff80e98863, tid=18446742975091785728, opts=Variable "opts" is not available. ) at /usr/src/sys/kern/kern_mutex.c:407 #10 0xffffffff8058aefe in _mtx_lock_flags (m=Variable "m" is not available. ) at /usr/src/sys/kern/kern_mutex.c:203 #11 0xffffffff806475e5 in netisr_queue_internal (proto=1, m=0xffffff0004dd7b00, cpuid=Variable "cpuid" is not available. ) at /usr/src/sys/net/netisr.c:829 #12 0xffffffff806476c9 in netisr_queue_src (proto=1, source=Variable "source" is not available. ) at /usr/src/sys/net/netisr.c:859 #13 0xffffffff80643629 in if_simloop (ifp=0xffffff000444e800, m=0xffffff0004dd7b00, af=2, hlen=0) at /usr/src/sys/net/if_loop.c:400 #14 0xffffffff80643786 in looutput (ifp=0xffffff000444e800, m=0xffffff0004dd7b00, dst=0xffffff80403d47a0, ro=Variable "ro" is not available. ) at /usr/src/sys/net/if_loop.c:296 #15 0xffffffff806a2767 in ip_output (m=0xffffff0004dd7b00, opt=Variable "opt" is not available. ) at /usr/src/sys/netinet/ip_output.c:624 #16 0xffffffff80707dc4 in tcp_output (tp=0xffffff002a2b9000) at /usr/src/sys/netinet/tcp_output.c:1188 #17 0xffffffff80714469 in tcp_usr_send (so=0xffffff005d6e0d48, flags=0, m=Variable "m" is not available. ) at tcp_offload.h:269 #18 0xffffffff805fd327 in sosend_generic (so=0xffffff005d6e0d48, addr=0x0, uio=0xffffff80403d4b10, top=0xffffff004e642900, control=0x0, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/uipc_socket.c:1257 #19 0xffffffff805e1a37 in soo_write (fp=Variable "fp" is not available. ) at /usr/src/sys/kern/sys_socket.c:102 #20 0xffffffff805daeb5 in dofilewrite (td=0xffffff0035474000, fd=16, fp=0xffffff0028466960, auio=0xffffff80403d4b10, offset=Variable "offset" is not available. ) at file.h:239 #21 0xffffffff805dc490 in kern_writev (td=0xffffff0035474000, fd=16, auio=0xffffff80403d4b10) at /usr/src/sys/kern/sys_generic.c:445 #22 0xffffffff805dc595 in write (td=Variable "td" is not available. ) at /usr/src/sys/kern/sys_generic.c:361 #23 0xffffffff808629df in syscall (frame=0xffffff80403d4c90) at /usr/src/sys/amd64/amd64/trap.c:984 #24 0xffffffff808496b0 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:364 #25 0x0000000800b5cefc in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 22:46:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1DBF91065672; Mon, 29 Jun 2009 22:46:19 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 879B98FC1D; Mon, 29 Jun 2009 22:46:18 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: by qw-out-2122.google.com with SMTP id 5so867685qwd.7 for ; Mon, 29 Jun 2009 15:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PWE0w6zkzLAttHmU+39K9g+napGOnkMjBMo+VbE8eW4=; b=TxMHAzXsLoF122ztBIpGJlFeqaTlUesRxmUWAzXExqXwfS724QgVv3f01fcSLakGy9 GBK0kojuhyuuEdxmM30Ujnv50fgFkoGgjXwagDS5Vx69O8N4K2ea7yFozaqSRf8lqzGD 85TGuIVaghKinXrL4oQT6YvGTbsQCpfN+ntVw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=v3gAz6AwEkZDf+45UiIM0oP1ZHORuHELGdzZ5YDkq3Qlu9DYGz4lgIN9nd74cL+hca iie2EGmAk3MHR3rw5bTkp16y7szVidHGA1WDwI3YGr0wei3NMvRN7qLnXxqutK1znkpW jhRvVLb2yHFGwhlXr+Kgs9twbSkZ7uxXe7eno= MIME-Version: 1.0 Received: by 10.220.45.71 with SMTP id d7mr2648091vcf.5.1246315577399; Mon, 29 Jun 2009 15:46:17 -0700 (PDT) In-Reply-To: <200906271011.53436.hselasky@c2i.net> References: <49E895CB.2040407@lissyara.su> <20090418023632.GJ13564@dereel.lemis.com> <1e31c7980906262132k7571c4b8ucfde94ec94cb1d8@mail.gmail.com> <200906271011.53436.hselasky@c2i.net> Date: Mon, 29 Jun 2009 19:46:16 -0300 Message-ID: <1e31c7980906291546v643e38a2r7354b8ba3a2cd125@mail.gmail.com> From: Vinicius Abrahao To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-usb@freebsd.org, Alex Keda , freebsd-current@freebsd.org, Andrew Thompson , Greg 'groggy' Lehey Subject: Re: new usb stack - boot problem from usb hdd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 22:46:19 -0000 On Sat, Jun 27, 2009 at 5:11 AM, Hans Petter Selasky wrote: > On Saturday 27 June 2009 06:32:54 Vinicius Abrahao wrote: >> 9) What I'm doing wrong? > > I don't think this is your fault. My initial patch for this problem had a loop > in the mount root code, trying to mount the root device several times. Now > several other people did not agree about that, and made the USB enumeration > synchronous instead. That does not always work, because USB devices do not > always show up immediately when the power is turned on. I would strongly > suggest to add a flag to the mount root code in sys/kern/, allowing the mount > root code to automatically retry the medium. It is also important that the > mountroot code calls pause() and do not spin in a while loop. > > --HPS > Hi Hans, Thanks for your reply. I had lucky here, changing the external disk to other usb port, but lsusb shows me that only change is the mouse (I change the mouse port with the external hd), by the way this usb-ide adapter has power supply by usb too. > Bus /dev/usb Device /dev/ugen3.2: ID 0461:4d15 Primax Electronics, Ltd (mouse on new usb port, boot is working) < Bus /dev/usb Device /dev/ugen2.2: ID 0461:4d15 Primax Electronics, Ltd (mouse on old usb port, boot not working) Strange that usb-ide adapter get the same ugen ports... but is working now! If you need someone to test any modifications I have some time here. Thanks a lot, Vinnix / Vinicius From owner-freebsd-current@FreeBSD.ORG Mon Jun 29 23:21:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F9CE106564A for ; Mon, 29 Jun 2009 23:21:35 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: from iron2.pdx.net (iron2.pdx.net [69.64.224.71]) by mx1.freebsd.org (Postfix) with ESMTP id 14FB08FC14 for ; Mon, 29 Jun 2009 23:21:34 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: (qmail 18370 invoked from network); 29 Jun 2009 15:54:50 -0700 Received: from host-246-98.pubnet.pdx.edu (HELO ?131.252.246.98?) (131.252.246.98) by iron2.pdx.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 29 Jun 2009 15:54:50 -0700 From: Sean Bruno To: freebsd-current@FreeBSD.org Content-Type: text/plain Date: Mon, 29 Jun 2009 15:54:52 -0700 Message-Id: <1246316092.3981.11.camel@Lappy> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Cc: Subject: 8-CURRENT Firewire X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 23:21:35 -0000 -CURRENT has some slightly different Firewire code in it than 6/7. If you have an opportunity to test it with your Firewire hard drives and cameras I'd really appreciate it. Stuff that's changed: multi-speed compatible devices will acutally work. a 400/800 device is connected to a 400/800 compatible firewire card via a 400 connection will work at 400 fwcontrol understands multiple firewire cards as multiple buses now. most commands now take a -u argument to indicate the bus. Please report to the -firewire if you get a chance to test. It would be great to get positive as well as negative results. Sean From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 00:40:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31037106566C; Tue, 30 Jun 2009 00:40:05 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from atmail-6.bnguk.net (atmail-6.bnguk.net [80.74.253.20]) by mx1.freebsd.org (Postfix) with ESMTP id B98B78FC12; Tue, 30 Jun 2009 00:40:04 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from 53-233.adsl.zetnet.co.uk ([194.247.53.233] helo=mail.chrishedley.com) by atmail-6.bnguk.net with esmtp (Exim 4.69) (envelope-from ) id 1MLQiA-0008Az-JU; Tue, 30 Jun 2009 00:56:35 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.chrishedley.com (Postfix) with ESMTP id 7F6039342A; Tue, 30 Jun 2009 00:56:32 +0100 (BST) X-Virus-Scanned: amavisd-new at chrishedley.com Received: from mail.chrishedley.com ([127.0.0.1]) by localhost (mail.chrishedley.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uqWgM9SMJNjY; Tue, 30 Jun 2009 00:56:29 +0100 (BST) Received: from teapot.cbhnet (teapot.cbhnet [192.168.1.1]) by mail.chrishedley.com (Postfix) with ESMTP id 404679340F; Tue, 30 Jun 2009 00:56:29 +0100 (BST) Date: Tue, 30 Jun 2009 00:56:29 +0100 (BST) From: Chris Hedley X-X-Sender: cbh@teapot.cbhnet To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: <4A2C124A.1050707@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-amd64@freebsd.org Subject: Re: New builds won't boot (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 00:40:05 -0000 On Fri, 26 Jun 2009, Chris Hedley wrote: > On Fri, 26 Jun 2009, Chris Hedley wrote: >> On Sun, 7 Jun 2009, Tim Kientzle wrote: >>> * Latest checkout date of a kernel that does boot. >>> * Earliest checkout date of a kernel that doesn't boot. > ... >> As for the versions of the kernel, I've narrowed it down to a half-day >> window, which is hopefully useful: the cvsup-specified dates I have are >> 2009.02.18.12.00.00 (working) and 2009.02.19.00.00.00 (not working). > > Just to pontificate for a moment, I notice that there's quite a few changes > to the ATA subsystem that afternoon. This might be significant as the > Supermicro SATA controllers I use (a pair of AOC-SAT2-MV8 cards, 8 port PCI-X > things) aren't entirely trouble-free: when they're up and running they're > fine, but they don't reset on reboot, even with the current (? 1.0c, anyway) > firmware which causes problems rescanning the drives. This could be a > complete red herring, but I wondered if it may be related. I've been fiddling about with this a bit more and I'm not sure it's just a zfs problem as it seems gmirror also can't find its entries. Attempting to boot of a non-zfs partition also leads to it hanging near the end of the kernel's boot messages. Anybody got any ideas of how I can get my system or AOC-SAT2-MV8 to work with the post 18th Feb kernels? Or of any ddb wizardry to further probe it for what it might be doing while it's apparently thinking about things? Thanks in advance, Chris. From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 01:30:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE4C31065672 for ; Tue, 30 Jun 2009 01:30:29 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from mail-gx0-f210.google.com (mail-gx0-f210.google.com [209.85.217.210]) by mx1.freebsd.org (Postfix) with ESMTP id 50CF28FC14 for ; Tue, 30 Jun 2009 01:30:28 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by gxk6 with SMTP id 6so5879992gxk.19 for ; Mon, 29 Jun 2009 18:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=23P/HRiOOYXAqOQY9nx4dE6HoLEYExD4tN2IEqwsn+I=; b=q7j2lFpEEU0ysxZdBQ3aq/CvpM+IDqYTDEsWr90DwspluVaM+gOuqL4KkJ2rjiYX4c +12aGD7bQVGcP6wxGMRjkY8yImesI5fjhomLvvHXF8R8I6hFpAyK8JadLfBDxY/N4pxt wQHYSEHam1/hXYx38o7BDv/QI/PVTGqyTmg4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=sDYKQFdPw4iGPqtU22/9euFslNggHt/lMXURX+2G9/KzisPYO6zcRQXP7pXxYKUyPL 1B9DNMnlTuifJYs5JWnXTtY4uVXGf6scS3vmwB6LdWENENFwwgyEEOJN1qTLU3KF0Ydk FM/6oTs1Aj1VoJQVgbUyDiPh3zEc34XJR5hfY= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.100.11.14 with SMTP id 14mr10304053ank.81.1246325428505; Mon, 29 Jun 2009 18:30:28 -0700 (PDT) In-Reply-To: References: <4A2C124A.1050707@freebsd.org> Date: Mon, 29 Jun 2009 18:30:28 -0700 X-Google-Sender-Auth: c94f8a658a26b4f0 Message-ID: <3c1674c90906291830g1c79c80bq42ce99f44588e968@mail.gmail.com> From: Kip Macy To: Chris Hedley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: New builds won't boot (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 01:30:30 -0000 On Mon, Jun 29, 2009 at 4:56 PM, Chris Hedley wrote: > On Fri, 26 Jun 2009, Chris Hedley wrote: >> >> On Fri, 26 Jun 2009, Chris Hedley wrote: >>> >>> On Sun, 7 Jun 2009, Tim Kientzle wrote: >>>> >>>> * Latest checkout date of a kernel that does boot. >>>> * Earliest checkout date of a kernel that doesn't boot. >> >> =A0 =A0 =A0 =A0... >>> >>> As for the versions of the kernel, I've narrowed it down to a half-day >>> window, which is hopefully useful: the cvsup-specified dates I have are >>> 2009.02.18.12.00.00 (working) and 2009.02.19.00.00.00 (not working). >> >> Just to pontificate for a moment, I notice that there's quite a few >> changes to the ATA subsystem that afternoon. =A0This might be significan= t as >> the Supermicro SATA controllers I use (a pair of AOC-SAT2-MV8 cards, 8 p= ort >> PCI-X things) aren't entirely trouble-free: when they're up and running >> they're fine, but they don't reset on reboot, even with the current (? 1= .0c, >> anyway) firmware which causes problems rescanning the drives. =A0This co= uld be >> a complete red herring, but I wondered if it may be related. > > I've been fiddling about with this a bit more and I'm not sure it's just = a > zfs problem as it seems gmirror also can't find its entries. =A0Attemptin= g to > boot of a non-zfs partition also leads to it hanging near the end of the > kernel's boot messages. > > Anybody got any ideas of how I can get my system or AOC-SAT2-MV8 to work > with the post 18th Feb kernels? =A0Or of any ddb wizardry to further prob= e it > for what it might be doing while it's apparently thinking about things? > I went through the commits from that time period and identified possible candidates: svn commit: r188755 - head/sys/dev/ata Remove unused variable. svn commit: r188761 - in stable/7: lib/libc lib/libc/string lib/libc/sys sys sys/contrib/pf sys/dev/ath/ath_hal sys/d\ ev/cxgb sys/kern sys/net sys/netinet sys/netinet6 sys/sys r188144: Standardize the various prison_foo_ip[46] functions and prison_if to return zero on success and an error code otherwise. The possible error= s are EADDRNOTAVAIL if an address being checked for doesn't match the prison, and EAFNOSUPPORT if the prison doesn't have any addresses in that address family. For most callers of these functions, use the returned error code instead of e.g. a hard-coded EADDRNOTAVAIL or EINVAL. svn commit: r188763 - head/sys/dev/ata Make ch->dma.free() called symmetrically to ch->dma.alloc(). svn commit: r188765 - in head/sys/dev/ata: . chipsets Log: As soon as they called in only same one place (ata_pcichannel_attach()), join allocate() and dmainit() atapci subdriver's channel initialization methods into single ch_attach() method. As opposite to ch_attach() add new ch_detach() method to deallocate/disabl= e channel. svn commit: r188743 - head/sys/dev/aac Log: Use outbound message register 0 instead of mailbox 7 in aac_{rx,rkt}_get_fwstatus, as done in Adaptec's vendor driver as well as the Linux drivers. Submitted by: jkim, from Adaptec's driver From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 02:36:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A3821065672; Tue, 30 Jun 2009 02:36:08 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from atmail-8.bnguk.net (atmail-8.bnguk.net [80.74.253.5]) by mx1.freebsd.org (Postfix) with ESMTP id C04028FC08; Tue, 30 Jun 2009 02:36:07 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from 53-233.adsl.zetnet.co.uk ([194.247.53.233] helo=mail.chrishedley.com) by atmail-8.bnguk.net with esmtp (Exim 4.69) (envelope-from ) id 1MLTCX-0002ob-TP; Tue, 30 Jun 2009 03:36:06 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.chrishedley.com (Postfix) with ESMTP id 5C4B9920E9; Tue, 30 Jun 2009 03:36:05 +0100 (BST) X-Virus-Scanned: amavisd-new at chrishedley.com Received: from mail.chrishedley.com ([127.0.0.1]) by localhost (mail.chrishedley.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QesG4g7uU49S; Tue, 30 Jun 2009 03:36:03 +0100 (BST) Received: from teapot.cbhnet (teapot.cbhnet [192.168.1.1]) by mail.chrishedley.com (Postfix) with ESMTP id C9CD4920CD; Tue, 30 Jun 2009 03:36:02 +0100 (BST) Date: Tue, 30 Jun 2009 03:36:02 +0100 (BST) From: Chris Hedley X-X-Sender: cbh@teapot.cbhnet To: Kip Macy In-Reply-To: <3c1674c90906291830g1c79c80bq42ce99f44588e968@mail.gmail.com> Message-ID: References: <4A2C124A.1050707@freebsd.org> <3c1674c90906291830g1c79c80bq42ce99f44588e968@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: New builds won't boot (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 02:36:08 -0000 On Mon, 29 Jun 2009, Kip Macy wrote: > I went through the commits from that time period and identified > possible candidates: > > svn commit: r188755 - head/sys/dev/ata > > Remove unused variable. > > svn commit: r188761 - in stable/7: lib/libc lib/libc/string > lib/libc/sys sys sys/contrib/pf sys/dev/ath/ath_hal sys/d\ > ev/cxgb sys/kern sys/net sys/netinet sys/netinet6 sys/sys > > r188144: > Standardize the various prison_foo_ip[46] functions and prison_if to > return zero on success and an error code otherwise. The possible errors > are EADDRNOTAVAIL if an address being checked for doesn't match the > prison, and EAFNOSUPPORT if the prison doesn't have any addresses in > that address family. For most callers of these functions, use the > returned error code instead of e.g. a hard-coded EADDRNOTAVAIL or > EINVAL. > > > svn commit: r188763 - head/sys/dev/ata > Make ch->dma.free() called symmetrically to ch->dma.alloc(). > > svn commit: r188765 - in head/sys/dev/ata: . chipsets > > Log: > As soon as they called in only same one place (ata_pcichannel_attach()), > join allocate() and dmainit() atapci subdriver's channel initialization > methods into single ch_attach() method. > > > > As opposite to ch_attach() add new ch_detach() method to deallocate/disable > channel. > > svn commit: r188743 - head/sys/dev/aac > Log: > Use outbound message register 0 instead of mailbox 7 in > aac_{rx,rkt}_get_fwstatus, as done in Adaptec's vendor driver as well as > the Linux drivers. > > Submitted by: jkim, from Adaptec's driver Thanks for that--it reminded me I still have the aac drivers in my current kernel which I no longer need as I've long since removed that card, so I recompiled without and... well, still no change. But it did give me an opportunity to spot something weird which I hadn't noticed before, which is the device numbering: instead of getting the usual ad0-ad9 for my discs, the numbering was a bit peculiar, ad4, ad6 and so on, as if it were enumerating them according to each logical slot rather than doing them by discs as they're found. I thought I'd try and outwit it by setting vfs.root.mountfrom to /dev/ad4a (part of my boot gmirror set with a hopefully usable rescue subsystem on it) but all this did was cause it to renumber them again, this time starting at ad12. I think it's possible to use device.hints to force it to assign particular IDs to the discs but I'll have to wade through the documentation to figure out how it's done, assuming that's the problem, anyway. And there's still the oddity with my keyboard where it's as if the CTRL key is jammed down on newer kernels, which is another thing I need to fix if I want to use the debugger (or the console, for that matter...) So some inadvertent progress of sorts. Possibly. :) Chris. From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 05:13:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8E891065670 for ; Tue, 30 Jun 2009 05:13:42 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id 9229B8FC0A for ; Tue, 30 Jun 2009 05:13:42 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id B91692C2AD0; Tue, 30 Jun 2009 00:13:41 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MdbdDKejuXs7; Tue, 30 Jun 2009 00:13:34 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id ADA732C2A8E; Tue, 30 Jun 2009 00:13:33 -0500 (CDT) Message-ID: <4A499EFD.9080509@cs.rice.edu> Date: Tue, 30 Jun 2009 00:13:33 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Hans Petter Selasky References: <200906292005.18629.hselasky@c2i.net> <4A4907AE.1080303@cs.rice.edu> <200906292130.16718.hselasky@c2i.net> In-Reply-To: <200906292130.16718.hselasky@c2i.net> Content-Type: multipart/mixed; boundary="------------050406050609020409080608" Cc: freebsd-current@freebsd.org, Alan Cox Subject: Re: Contigmalloc regression seen on latest 7.x and 8.x branches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 05:13:43 -0000 This is a multi-part message in MIME format. --------------050406050609020409080608 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hans Petter Selasky wrote: > On Monday 29 June 2009 20:27:58 Alan Cox wrote: > >> "ret" is a virtual address. What is the underlying physical address? >> > > Hi, > > It looks like the physical address is correct according to my printouts. > > The regression issue boils down to misleading printouts from the following > files, which should/can then be removed: > > /usr/8-current/src/sys/amd64/amd64/busdma_machdep.c: > printf("bus_dmamem_alloc failed to align memory properly.\n"); > /usr/8-current/src/sys/i386/i386/busdma_machdep.c: > printf("bus_dmamem_alloc failed to align memory properly.\n"); > /usr/8-current/src/sys/ia64/ia64/busdma_machdep.c: > printf("bus_dmamem_alloc failed to align memory properly.\n"); > > contigmalloc: size=0x00008000, flag=2, low=0x00000000 high=0xffffffff > alignment=0x00008000 boundary= > 0x00000000 > contigmalloc: ret=0xe5af2000 > contigmalloc: vtophys(ret)=0x01670000 > contigmalloc: vtophys(ret)=0x01671000 > contigmalloc: vtophys(ret)=0x01672000 > contigmalloc: vtophys(ret)=0x01673000 > contigmalloc: vtophys(ret)=0x01674000 > contigmalloc: vtophys(ret)=0x01675000 > contigmalloc: vtophys(ret)=0x01676000 > contigmalloc: vtophys(ret)=0x01677000 > bus_dmamem_alloc failed to align memory properly. > bus_dmamem_alloc = 0 > pg->physaddr = 0x01670000, nseg=1 > bus_dmamap_load = 0 > 0x01670000, 0xe5af2000 > ihfc1: port 0xa400-0xa407 mem > 0xf5004000-0xf50040ff irq 18 at devi > ce 8.0 on pci1 > ihfc1: [ITHREAD] > ihfc1: Attaching I4B controller 1. > ihfc1: Creating /dev/ihfc1.X. > > After looking at r159130 and the comments in the code, I don't think it would be appropriate to remove the printf()s. However, the logic that determines whether printf() is called is flawed. I believe that the attached patch should eliminate the incorrect printf()s that you are seeing. Regards, Alan --------------050406050609020409080608 Content-Type: text/plain; name="align.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="align.patch" Index: amd64/amd64/busdma_machdep.c =================================================================== --- amd64/amd64/busdma_machdep.c (revision 195132) +++ amd64/amd64/busdma_machdep.c (working copy) @@ -527,7 +527,7 @@ CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d", __func__, dmat, dmat->flags, ENOMEM); return (ENOMEM); - } else if ((uintptr_t)*vaddr & (dmat->alignment - 1)) { + } else if (pmap_kextract((vm_offset_t)*vaddr) & (dmat->alignment - 1)) { printf("bus_dmamem_alloc failed to align memory properly.\n"); } if (flags & BUS_DMA_NOCACHE) Index: i386/i386/busdma_machdep.c =================================================================== --- i386/i386/busdma_machdep.c (revision 195132) +++ i386/i386/busdma_machdep.c (working copy) @@ -540,7 +540,7 @@ CTR4(KTR_BUSDMA, "%s: tag %p tag flags 0x%x error %d", __func__, dmat, dmat->flags, ENOMEM); return (ENOMEM); - } else if ((uintptr_t)*vaddr & (dmat->alignment - 1)) { + } else if (pmap_kextract((vm_offset_t)*vaddr) & (dmat->alignment - 1)) { printf("bus_dmamem_alloc failed to align memory properly.\n"); } if (flags & BUS_DMA_NOCACHE) Index: ia64/ia64/busdma_machdep.c =================================================================== --- ia64/ia64/busdma_machdep.c (revision 195132) +++ ia64/ia64/busdma_machdep.c (working copy) @@ -455,7 +455,7 @@ } if (*vaddr == NULL) return (ENOMEM); - else if ((uintptr_t)*vaddr & (dmat->alignment - 1)) + else if (pmap_kextract((vm_offset_t)*vaddr) & (dmat->alignment - 1)) printf("bus_dmamem_alloc failed to align memory properly.\n"); return (0); } --------------050406050609020409080608-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 09:34:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 174C51065674 for ; Tue, 30 Jun 2009 09:34:01 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 829578FC2C for ; Tue, 30 Jun 2009 09:34:00 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (host86-150-124-14.range86-150.btcentralplus.com [86.150.124.14]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n5U9XiUX078492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 19:33:52 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A49DBF1.5010907@freebsd.org> Date: Tue, 30 Jun 2009 10:33:37 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Kostik Belousov References: <4A48942A.7030307@freebsd.org> <20090629114516.GY2884@deviant.kiev.zoral.com.ua> In-Reply-To: <20090629114516.GY2884@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_20,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-current@freebsd.org Subject: Re: "filesystem goof: vop_panic[vop_revoke]" panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 09:34:01 -0000 Kostik Belousov wrote: > On Mon, Jun 29, 2009 at 11:15:06AM +0100, Lawrence Stewart wrote: >> Hi All, >> >> My laptop panicked whilst shutting down yesterday. The shutdown sequence >> seemed to terminate kde4/X correctly but got wedged prior to completing >> the rest as seen on the console. Details below... [snip] > > Are you able to reproduce the issue ? I had a second identical panic on shutdown last night after a few successful shutdowns since the first panic. So although it's not deterministically reproducible it seems something on this machine is tickling the bug semi-regularly. > Please try the patch. Will do. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 09:35:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBB6A1065670; Tue, 30 Jun 2009 09:35:46 +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 70C288FC26; Tue, 30 Jun 2009 09:35:46 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.20] (helo=10.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MLZkf-0001Sj-5H; Tue, 30 Jun 2009 11:35:45 +0200 Received: from tcc4c.t.pppool.de ([89.55.204.76]:52859 helo=ernst.jennejohn.org) by 10.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1MLZke-0007Aw-TQ; Tue, 30 Jun 2009 11:35:45 +0200 Date: Tue, 30 Jun 2009 11:35:44 +0200 From: Gary Jennejohn To: Chris Hedley Message-ID: <20090630113544.3e2bef31@ernst.jennejohn.org> In-Reply-To: References: <4A2C124A.1050707@freebsd.org> <3c1674c90906291830g1c79c80bq42ce99f44588e968@mail.gmail.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: New builds won't boot (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 09:35:47 -0000 On Tue, 30 Jun 2009 03:36:02 +0100 (BST) Chris Hedley wrote: > But it did give me an opportunity to spot something weird which I hadn't > noticed before, which is the device numbering: instead of getting the > usual ad0-ad9 for my discs, the numbering was a bit peculiar, ad4, ad6 and > so on, as if it were enumerating them according to each logical slot > rather than doing them by discs as they're found. > It does seem to number based on slot, whereby the driver for some reason acts as though SATA has master/slave disks, which of course it doesn't. You can get back to the old behavior by putting "options ATA_STATIC_ID" into your kernel config file. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 10:23:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5960106564A; Tue, 30 Jun 2009 10:23:32 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 8A3F38FC18; Tue, 30 Jun 2009 10:23:32 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 6AA4278F98; Tue, 30 Jun 2009 14:23:30 +0400 (MSD) Message-ID: <4A49E7A3.70509@haruhiism.net> Date: Tue, 30 Jun 2009 14:23:31 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexander Motin References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> <4A48D136.3050309@haruhiism.net> <4A48D551.5090509@FreeBSD.org> In-Reply-To: <4A48D551.5090509@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 10:23:33 -0000 Alexander Motin wrote: > It could be not a real bug, but incorrect diagnostic, in situation, > when the last of 32 submitted command finishes first. NCQ in practice. :) Running for > 24 hours now, no such messages yet - so probably as you stated it was just a problem of an incorrect diagnostics assumption. Thanks gods you didn't use panic("ALL SLOTS BUSY") ;) By the way: smartctl from smartmontools doesn't work with this new driver (with -d scsi or -d sat as well). How would one request SMART information from a device provided by ahci.ko (I mean, maybe it can be implemented in smartmontools easily)? -- Kamigishi Rei From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 10:36:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5902106566C for ; Tue, 30 Jun 2009 10:36:09 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 1D1CC8FC0A for ; Tue, 30 Jun 2009 10:36:08 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 247156278; Tue, 30 Jun 2009 13:36:05 +0300 Message-ID: <4A49EA94.3070109@FreeBSD.org> Date: Tue, 30 Jun 2009 13:36:04 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Kamigishi Rei References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> <4A48D136.3050309@haruhiism.net> <4A48D551.5090509@FreeBSD.org> <4A49E7A3.70509@haruhiism.net> In-Reply-To: <4A49E7A3.70509@haruhiism.net> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 10:36:10 -0000 Kamigishi Rei wrote: > Alexander Motin wrote: >> It could be not a real bug, but incorrect diagnostic, in situation, >> when the last of 32 submitted command finishes first. NCQ in practice. :) > Running for > 24 hours now, no such messages yet - so probably as you > stated it was just a problem of an incorrect diagnostics assumption. > Thanks gods you didn't use panic("ALL SLOTS BUSY") ;) Fine. That's why I don't like panic(). :) > By the way: smartctl from smartmontools doesn't work with this new > driver (with -d scsi or -d sat as well). How would one request SMART > information from a device provided by ahci.ko (I mean, maybe it can be > implemented in smartmontools easily)? smartmontools need to be updated to support the new order. It should use same CAM system calls as for -d scsi, but commands as for -d ata. I have made quick look and think should not be difficult to implement it. So if somebody wants to help - it is the place. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 11:10:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 132881065675 for ; Tue, 30 Jun 2009 11:10:24 +0000 (UTC) (envelope-from bst2006@dva.dyndns.org) Received: from dva.homeunix.org (dva.homeunix.org [89.247.128.204]) by mx1.freebsd.org (Postfix) with ESMTP id 903688FC1B for ; Tue, 30 Jun 2009 11:10:23 +0000 (UTC) (envelope-from bst2006@dva.dyndns.org) Received: from [10.0.20.2] (unknown [10.0.20.2]) by dva.homeunix.org (Postfix) with ESMTP id 0FD194F5DA; Tue, 30 Jun 2009 12:53:14 +0200 (CEST) Message-ID: <4A49EECE.20502@dva.dyndns.org> Date: Tue, 30 Jun 2009 12:54:06 +0200 From: "Boris S." User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alexander Motin References: <4A4517BE.9040504@FreeBSD.org> In-Reply-To: <4A4517BE.9040504@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 11:10:24 -0000 I'm using your 29-june patch (including the ALL_SLOTS_BUSY fix) since yesterday without any problems! I use GUID partitioned gmirror and zfs on a AMD780G based mainboard. The only irritating thing is that the zpool now shows gptid's instead of the partition names. Boris ahci0: port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb0f mem 0xfe02f000-0xfe02f3ff irq 22 at device 17.0 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfa00-0xfa0f at device 20.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] ahcich0: Poll timeout on slot 2 (probe0:ahcich0:0:0:0): SIGNATURE: 0000 ahcich1: Poll timeout on slot 2 (probe0:ahcich1:0:0:0): SIGNATURE: 0000 ahcich2: Poll timeout on slot 2 (probe0:ahcich2:0:0:0): SIGNATURE: 0000 ada0 at ahcich0 bus 0 target 0 lun 0 ada0: ATA/ATAPI-7 SATA 2.x device ada0: 300.000MB/s transfers ada0: 305244MB (625140335 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing Enabled ada1 at ahcich1 bus 0 target 0 lun 0 ada1: ATA/ATAPI-7 SATA 2.x device ada1: 300.000MB/s transfers ada1: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing Enabled ada2 at ahcich2 bus 0 target 0 lun 0 ada2: ATA/ATAPI-7 SATA 2.x device ada2: 300.000MB/s transfers ada2: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada2: Native Command Queueing Enabled GEOM_MIRROR: Device mirror/root launched (2/2). Trying to mount root from ufs:/dev/mirror/root at scbus0 target 0 lun 0 (pass0,ada0) at scbus1 target 0 lun 0 (pass1,ada1) at scbus2 target 0 lun 0 (pass2,ada2) Name Status Components mirror/root COMPLETE ada0p2 ada2p2 pool: misc state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM misc ONLINE 0 0 0 gptid/ffcef83e-f18e-11dd-8fe8-001b211c0d18 ONLINE 0 0 0 errors: No known data errors pool: tank state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 0 mirror ONLINE 0 0 0 gptid/b2dc2050-f080-11dd-8bf7-001b211c0d18 ONLINE 0 0 0 gptid/e7c19e86-f08b-11dd-b26f-001b211c0d18 ONLINE 0 0 0 errors: No known data errors From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 11:30:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C37D1065676 for ; Tue, 30 Jun 2009 11:30:24 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from mail.digiware.nl (mail.digiware.nl [80.255.245.173]) by mx1.freebsd.org (Postfix) with ESMTP id B13898FC1B for ; Tue, 30 Jun 2009 11:30:23 +0000 (UTC) (envelope-from wjw@withagen.nl) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 25072153434 for ; Tue, 30 Jun 2009 13:10:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NdlwWFdLmrt; Tue, 30 Jun 2009 13:10:35 +0200 (CEST) Received: from [212.61.27.67] (opteron [212.61.27.67]) by mail.digiware.nl (Postfix) with ESMTP id 1E716153433 for ; Tue, 30 Jun 2009 13:10:35 +0200 (CEST) Message-ID: <4A49F2A0.1080005@withagen.nl> Date: Tue, 30 Jun 2009 13:10:24 +0200 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: E8FEAE26C87DED4EB49EFF99D1C7A51DFF6929@ald-mail02.corporate.aldridge.com Content-Type: multipart/mixed; boundary="------------030305090609080602000201" Subject: From Thread: UFS/VFS lock order reversal on stock 8.0-200812-AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 11:30:24 -0000 This is a multi-part message in MIME format. --------------030305090609080602000201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit It is about the following LOR: http://sources.zabbadoz.net/freebsd/lor/261.html lock order reversal: 1st 0xc2e03e00 bufwait (bufwait) @ sys/kern/vfs_bio.c:2443 2nd 0xc3592200 dirhash (dirhash) @ sys/ufs/ufs/ufs_dirhash.c:254 Quoted from the thread about this topic from last januari: ============ Gavin@ writes: Cool. It's always good to have more people using and testing -CURRENT, I just wanted to make sure you knew what you were getting yourself in for :) > I pulled out the 'extra debugging', made world and kernel, and rebooted. > Notice the 5th line of da7's drive ID being interleaved with 'SMP: AP CPU #1 Launched!' > > I'm fairly sure this is not a good thing, if for no other reason that 'apparent garbage' in dmesg is not useful. It's not a good thing, but it's a known issue and is purely cosmetic. ============= Only in my case it seems not so harmless. I get this one on rebooting, which then freezes the process. Under 7.2 the system (although from 2002) did reboot. Could this LOR be responsible for not rebooting? If not, how do I go about in finding what does prevent the reboot. It just halts at the stage where it gives the uptime after syncing all disks. Normaly reboot follows, but there are no messages for that. And a hardware reset is required. --WjW --------------030305090609080602000201 Content-Type: text/plain; name="ASTERSD.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ASTERSD.conf" cpu I586_CPU cpu I686_CPU ident ASTERBSD # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. # Use the following to compile in values accessible to the kernel # through getenv() (or kenv(1) in userland). The format of the file # is 'variable=value', see kenv(1) # # env "GENERIC.env" makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options NFSCLIENT # Network Filesystem Client options NFSLOCKD # Network Lock Manager options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY # BSD 4.3 TTY compat (sgtty) options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options STOP_NMI # Stop CPUS using NMI instead of IPI options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options MAC # TrustedBSD MAC Framework options FLOWTABLE # per-cpu routing cache #options KDTRACE_HOOKS # Kernel DTrace hooks # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # To make an SMP kernel, the next two lines are needed device apic # I/O APIC # CPU frequency control device cpufreq # Bus support. device acpi device pci # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device uart # Generic UART driver # PCI Ethernet NICs. device de # DEC/Intel DC21x4x (``Tulip'') device em # Intel PRO/1000 Gigabit Ethernet Family device txp # 3Com 3cR990 (``Typhoon'') device vx # 3Com 3c590, 3c595 (``Vortex'') # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bge # Broadcom BCM570xx Gigabit Ethernet device dc # DEC/Intel 21143 and various workalikes device fxp # Intel EtherExpress PRO/100B (82557, 82558) device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sf # Adaptec AIC-6915 (``Starfire'') device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # BSD-style compatibility pseudo ttys device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # USB Serial devices device u3g # USB-based 3G modems (Option, Huawei, Sierra) device uark # Technologies ARK3116 based serial adapters device ubsa # Belkin F5U103 and compatible serial adapters device uftdi # For FTDI usb serial adapters device uplcom # Prolific PL-2303 serial adapters device uslcom # SI Labs CP2101/CP2102 serial adapters # is no longer in the config # options IPR_VJ device "i4bdss1" device "i4b" device "i4btrc" device "i4bctl" device "i4brbch" device "i4btel" device "i4bipr" # # If you need more than 8 units please # edit "/usr/src/sys/i4b/include/i4b_global.h", # until further. # device ihfc device sound # device pcm #if device pcm does not exist --------------030305090609080602000201 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-CURRENT #5: Mon Jun 29 21:55:30 CEST 2009 wjw@Asterbsd.digiware.nl:/usr/obj/usr/src/sys/ASTERBSD WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Duron(tm) Processor (807.19-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x631 Stepping = 1 Features=0x183f9ff AMD Features=0xc0440800,MMX+,3DNow!+,3DNow!> real memory = 402653184 (384 MB) avail memory = 512016384 (488 MB) kbd1 at kbdmux0 pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 agp0: on hostb0 agp0: aperture size is 256M pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: mem 0xf8000000-0xf8ffffff,0xfa000000-0xfbffffff irq 11 at device 0.0 on pci1 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd800-0xd80f at device 7.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] uhci0: port 0xd400-0xd41f irq 12 at device 7.2 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0xd000-0xd01f irq 12 at device 7.3 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 ihfc0: port 0xa400-0xa407 mem 0xf7800000-0xf78000ff irq 12 at device 11.0 on pci0 ihfc0: [ITHREAD] ihfc0: Attaching I4B controller 0. ihfc0: Creating /dev/ihfc0.X. rl0: port 0xa000-0xa0ff mem 0xf7000000-0xf70000ff at device 12.0 on pci0 miibus0: on rl0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:02:44:58:cc:e2 rl0: [ITHREAD] pci0: at device 14.0 (no driver attached) cpu0 on motherboard pmtimer0 on isa0 uart0: <16550 or compatible> at port 0x3f8-0x3ff irq 4 flags 0x10 pnpid PNP0501 on isa0 uart0: [FILTER] uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 pnpid PNP0501 on isa0 uart1: [FILTER] unknown: can't assign resources (memory) atrtc0: at port 0x70-0x75 irq 8 pnpid PNP0b00 on isa0 atkbdc0: at port 0x60,0x64 irq 1 pnpid PNP0303 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (memory) Timecounter "TSC" frequency 807191790 Hz quality 800 Timecounters tick every 1.000 msec i4btrc: 64 ISDN trace device(s) attached i4brbch: 8 raw B channel access device(s) attached i4btel: 8 ISDN telephony interface device(s) attached i4bipr: 8 IP over raw HDLC ISDN device(s) attached i4bctl: ISDN system control port attached capi: CAPI call control device attached, v2.11 i4b: ISDN call control device attached usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 ad0: 19092MB at ata0-master UDMA100 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 GEOM: ad0: geometry does not match label (255h,63s != 16h,63s). acd0: CDROM at ata1-slave PIO4 WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus1 usbus0 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered Trying to mount root from ufs:/dev/ad0a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted --------------030305090609080602000201-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 13:29:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53D93106566C for ; Tue, 30 Jun 2009 13:29:44 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 712528FC16 for ; Tue, 30 Jun 2009 13:29:43 +0000 (UTC) (envelope-from kosmo@semihalf.com) Received: from [10.0.0.5] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id 5E2F4C3A96; Tue, 30 Jun 2009 15:28:25 +0200 (CEST) From: Piotr =?iso-8859-2?q?Zi=EAcik?= Organization: Semihalf To: Scott Long Date: Tue, 30 Jun 2009 15:29:42 +0200 User-Agent: PLD Linux KMail/1.9.10 References: <200906251329.35200.kosmo@semihalf.com> <200906260929.40709.kosmo@semihalf.com> <4A44D4AD.8010307@samsco.org> In-Reply-To: <4A44D4AD.8010307@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200906301529.42195.kosmo@semihalf.com> Cc: freebsd-current@freebsd.org Subject: Re: [PATCH RFC]: Bus_dma eats all available memory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 13:29:44 -0000 =46riday 26 June 2009 16:01:17 Scott Long napisa=B3(a): > > Tags and maps should be allocated at driver initialization time, not > every time a request comes in. The problem here isn't the MAX() test, > it's that the MIN_ALLOC_COMP test is getting fooled because the tag > keeps on getting recycled. The correct fix is likely to move the flag > into the bounce zone object. But in general, you should not be > allocating and freeing tags and maps so often, they are meant to have a > long lifespan. > I have fixed my driver and updated patch for bus_dma. Could I ask you for=20 review ? Patch was successfully tested on ARM. diff --git a/sys/amd64/amd64/busdma_machdep.c=20 b/sys/amd64/amd64/busdma_machdep.c index 775f142..dde9159 100644 =2D-- a/sys/amd64/amd64/busdma_machdep.c +++ b/sys/amd64/amd64/busdma_machdep.c @@ -84,6 +84,7 @@ struct bounce_page { =20 int busdma_swi_pending; =20 +#define BZ_MIN_ALLOC_COMP 0x01 struct bounce_zone { STAILQ_ENTRY(bounce_zone) links; STAILQ_HEAD(bp_list, bounce_page) bounce_page_list; @@ -98,6 +99,7 @@ struct bounce_zone { bus_addr_t lowaddr; char zoneid[8]; char lowaddrid[20]; + int flags; struct sysctl_ctx_list sysctl_tree; struct sysctl_oid *sysctl_tree_top; }; @@ -201,7 +203,6 @@ dflt_lock(void *arg, bus_dma_lock_op_t op) } =20 #define BUS_DMA_COULD_BOUNCE BUS_DMA_BUS3 =2D#define BUS_DMA_MIN_ALLOC_COMP BUS_DMA_BUS4 /* * Allocate a device specific dma_tag. */ @@ -306,7 +307,7 @@ bus_dma_tag_create(bus_dma_tag_t parent, bus_size_t=20 alignment, error =3D ENOMEM; } /* Performed initial allocation */ =2D newtag->flags |=3D BUS_DMA_MIN_ALLOC_COMP; + bz->flags |=3D BZ_MIN_ALLOC_COMP; } =09 if (error !=3D 0) { @@ -417,7 +418,7 @@ bus_dmamap_create(bus_dma_tag_t dmat, int flags,=20 bus_dmamap_t *mapp) maxpages =3D MAX_BPAGES; else maxpages =3D MIN(MAX_BPAGES, Maxmem -atop(dmat->lowaddr)); =2D if ((dmat->flags & BUS_DMA_MIN_ALLOC_COMP) =3D=3D 0 + if ((bz->flags & BZ_MIN_ALLOC_COMP) =3D=3D 0 || (bz->map_count > 0 && bz->total_bpages < maxpages)) { int pages; =20 @@ -427,9 +428,9 @@ bus_dmamap_create(bus_dma_tag_t dmat, int flags,=20 bus_dmamap_t *mapp) if (alloc_bounce_pages(dmat, pages) < pages) error =3D ENOMEM; =20 =2D if ((dmat->flags & BUS_DMA_MIN_ALLOC_COMP) =3D=3D 0) { + if ((bz->flags & BZ_MIN_ALLOC_COMP) =3D=3D 0) { if (error =3D=3D 0) =2D dmat->flags |=3D BUS_DMA_MIN_ALLOC_COMP; + bz->flags |=3D BZ_MIN_ALLOC_COMP; } else { error =3D 0; } @@ -994,6 +995,7 @@ alloc_bounce_zone(bus_dma_tag_t dmat) bz->lowaddr =3D dmat->lowaddr; bz->alignment =3D MAX(dmat->alignment, PAGE_SIZE); bz->map_count =3D 0; + bz->flags =3D 0; snprintf(bz->zoneid, 8, "zone%d", busdma_zonecount); busdma_zonecount++; snprintf(bz->lowaddrid, 18, "%#jx", (uintmax_t)bz->lowaddr); diff --git a/sys/arm/arm/busdma_machdep.c b/sys/arm/arm/busdma_machdep.c index a8b2de9..bbda08b 100644 =2D-- a/sys/arm/arm/busdma_machdep.c +++ b/sys/arm/arm/busdma_machdep.c @@ -62,7 +62,6 @@ __FBSDID("$FreeBSD: src/sys/arm/arm/busdma_machdep.c,v 1.= 47=20 2009/04/23 20:24:19 =20 #define MAX_BPAGES 64 #define BUS_DMA_COULD_BOUNCE BUS_DMA_BUS3 =2D#define BUS_DMA_MIN_ALLOC_COMP BUS_DMA_BUS4 =20 struct bounce_zone; =20 @@ -104,6 +103,7 @@ struct bounce_page { =20 int busdma_swi_pending; =20 +#define BZ_MIN_ALLOC_COMP 0x01 struct bounce_zone { STAILQ_ENTRY(bounce_zone) links; STAILQ_HEAD(bp_list, bounce_page) bounce_page_list; @@ -118,6 +118,7 @@ struct bounce_zone { bus_addr_t lowaddr; char zoneid[8]; char lowaddrid[20]; + int flags; struct sysctl_ctx_list sysctl_tree; struct sysctl_oid *sysctl_tree_top; }; @@ -427,7 +428,7 @@ bus_dma_tag_create(bus_dma_tag_t parent, bus_size_t=20 alignment, error =3D ENOMEM; } /* Performed initial allocation */ =2D newtag->flags |=3D BUS_DMA_MIN_ALLOC_COMP; + bz->flags |=3D BZ_MIN_ALLOC_COMP; } else newtag->bounce_zone =3D NULL; if (error !=3D 0) @@ -523,7 +524,7 @@ bus_dmamap_create(bus_dma_tag_t dmat, int flags,=20 bus_dmamap_t *mapp) * basis up to a sane limit. */ maxpages =3D MAX_BPAGES; =2D if ((dmat->flags & BUS_DMA_MIN_ALLOC_COMP) =3D=3D 0 + if ((bz->flags & BZ_MIN_ALLOC_COMP) =3D=3D 0 || (bz->map_count > 0 && bz->total_bpages < maxpages)) { int pages; =20 @@ -533,9 +534,9 @@ bus_dmamap_create(bus_dma_tag_t dmat, int flags,=20 bus_dmamap_t *mapp) if (alloc_bounce_pages(dmat, pages) < pages) error =3D ENOMEM; =20 =2D if ((dmat->flags & BUS_DMA_MIN_ALLOC_COMP) =3D=3D 0) { + if ((bz->flags & BZ_MIN_ALLOC_COMP) =3D=3D 0) { if (error =3D=3D 0) =2D dmat->flags |=3D BUS_DMA_MIN_ALLOC_COMP; + bz->flags |=3D BZ_MIN_ALLOC_COMP; } else { error =3D 0; } @@ -1291,6 +1292,7 @@ alloc_bounce_zone(bus_dma_tag_t dmat) bz->lowaddr =3D dmat->lowaddr; bz->alignment =3D MAX(dmat->alignment, PAGE_SIZE); bz->map_count =3D 0; + bz->flags =3D 0; snprintf(bz->zoneid, 8, "zone%d", busdma_zonecount); busdma_zonecount++; snprintf(bz->lowaddrid, 18, "%#jx", (uintmax_t)bz->lowaddr); diff --git a/sys/i386/i386/busdma_machdep.c b/sys/i386/i386/busdma_machdep.c index 50c1545..4ceaa05 100644 =2D-- a/sys/i386/i386/busdma_machdep.c +++ b/sys/i386/i386/busdma_machdep.c @@ -55,7 +55,6 @@ __FBSDID("$FreeBSD: src/sys/i386/i386/busdma_machdep.c,v= =20 1.99 2009/04/23 20:24:1 =20 #define MAX_BPAGES 512 #define BUS_DMA_COULD_BOUNCE BUS_DMA_BUS3 =2D#define BUS_DMA_MIN_ALLOC_COMP BUS_DMA_BUS4 =20 struct bounce_zone; =20 @@ -89,6 +88,7 @@ struct bounce_page { =20 int busdma_swi_pending; =20 +#define BZ_MIN_ALLOC_COMP 0x01 struct bounce_zone { STAILQ_ENTRY(bounce_zone) links; STAILQ_HEAD(bp_list, bounce_page) bounce_page_list; @@ -103,6 +103,7 @@ struct bounce_zone { bus_addr_t lowaddr; char zoneid[8]; char lowaddrid[20]; + int flags; struct sysctl_ctx_list sysctl_tree; struct sysctl_oid *sysctl_tree_top; }; @@ -319,7 +320,7 @@ bus_dma_tag_create(bus_dma_tag_t parent, bus_size_t=20 alignment, error =3D ENOMEM; } /* Performed initial allocation */ =2D newtag->flags |=3D BUS_DMA_MIN_ALLOC_COMP; + bz->flags |=3D BZ_MIN_ALLOC_COMP; } =09 if (error !=3D 0) { @@ -430,7 +431,7 @@ bus_dmamap_create(bus_dma_tag_t dmat, int flags,=20 bus_dmamap_t *mapp) maxpages =3D MAX_BPAGES; else maxpages =3D MIN(MAX_BPAGES, Maxmem -atop(dmat->lowaddr)); =2D if ((dmat->flags & BUS_DMA_MIN_ALLOC_COMP) =3D=3D 0 + if ((bz->flags & BZ_MIN_ALLOC_COMP) =3D=3D 0 || (bz->map_count > 0 && bz->total_bpages < maxpages)) { int pages; =20 @@ -440,9 +441,9 @@ bus_dmamap_create(bus_dma_tag_t dmat, int flags,=20 bus_dmamap_t *mapp) if (alloc_bounce_pages(dmat, pages) < pages) error =3D ENOMEM; =20 =2D if ((dmat->flags & BUS_DMA_MIN_ALLOC_COMP) =3D=3D 0) { + if ((bz->flags & BZ_MIN_ALLOC_COMP) =3D=3D 0) { if (error =3D=3D 0) =2D dmat->flags |=3D BUS_DMA_MIN_ALLOC_COMP; + bz->flags |=3D BZ_MIN_ALLOC_COMP; } else { error =3D 0; } @@ -1012,6 +1013,7 @@ alloc_bounce_zone(bus_dma_tag_t dmat) bz->lowaddr =3D dmat->lowaddr; bz->alignment =3D MAX(dmat->alignment, PAGE_SIZE); bz->map_count =3D 0; + bz->flags =3D 0; snprintf(bz->zoneid, 8, "zone%d", busdma_zonecount); busdma_zonecount++; snprintf(bz->lowaddrid, 18, "%#jx", (uintmax_t)bz->lowaddr); =2D-=20 Best Regards, Piotr Ziecik From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 14:26:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EDD091065672; Tue, 30 Jun 2009 14:26:07 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from atmail-7.bnguk.net (atmail-7.bnguk.net [80.74.253.4]) by mx1.freebsd.org (Postfix) with ESMTP id A4B578FC13; Tue, 30 Jun 2009 14:26:07 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from 53-233.adsl.zetnet.co.uk ([194.247.53.233] helo=mail.chrishedley.com) by atmail-7.bnguk.net with esmtp (Exim 4.69) (envelope-from ) id 1MLeHd-0004So-Mi; Tue, 30 Jun 2009 15:26:05 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.chrishedley.com (Postfix) with ESMTP id 6C23D935E1; Tue, 30 Jun 2009 15:26:02 +0100 (BST) X-Virus-Scanned: amavisd-new at chrishedley.com Received: from mail.chrishedley.com ([127.0.0.1]) by localhost (mail.chrishedley.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6HM3jVonj3er; Tue, 30 Jun 2009 15:25:59 +0100 (BST) Received: from teapot.cbhnet (teapot.cbhnet [192.168.1.1]) by mail.chrishedley.com (Postfix) with ESMTP id 1ADFC935C7; Tue, 30 Jun 2009 15:25:59 +0100 (BST) Date: Tue, 30 Jun 2009 15:25:59 +0100 (BST) From: Chris Hedley X-X-Sender: cbh@teapot.cbhnet To: Gary Jennejohn In-Reply-To: <20090630113544.3e2bef31@ernst.jennejohn.org> Message-ID: References: <4A2C124A.1050707@freebsd.org> <3c1674c90906291830g1c79c80bq42ce99f44588e968@mail.gmail.com> <20090630113544.3e2bef31@ernst.jennejohn.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: New builds won't boot (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 14:26:08 -0000 On Tue, 30 Jun 2009, Gary Jennejohn wrote: > It does seem to number based on slot, whereby the driver for some reason > acts as though SATA has master/slave disks, which of course it doesn't. > > You can get back to the old behavior by putting "options ATA_STATIC_ID" > into your kernel config file. Hmm... weirdly, I noticed that /after/ putting that line into my config; maybe I should try again without it and see what happens...? I think I'll do that a bit later today and report back if there's any difference. From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 15:30:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBE631065672; Tue, 30 Jun 2009 15:30:00 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from mail.yellowspace.net (mail.yellowspace.net [80.190.200.164]) by mx1.freebsd.org (Postfix) with ESMTP id 6A0968FC1C; Tue, 30 Jun 2009 15:30:00 +0000 (UTC) (envelope-from lopez.on.the.lists@yellowspace.net) Received: from [192.168.178.22] ([93.207.111.137]) (AUTH: CRAM-MD5 lopez.on.the.lists@yellowspace.net, TLS: TLSv1/SSLv3, 128bits, AES128-SHA) by mail.yellowspace.net with esmtp; Tue, 30 Jun 2009 17:19:53 +0200 id 00495747.000000004A4A2D19.00007611 Message-Id: <0AB0471B-8C3C-422E-BFAB-49C5F89448E2@yellowspace.net> From: Lorenzo Perone To: Pawel Jakub Dawidek In-Reply-To: <20090628084957.GB4159@garage.freebsd.pl> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 17:19:52 +0200 References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <2FFFB36F-EFA3-4D92-98A3-692BA2D6F63E@mac.com> <20090628084957.GB4159@garage.freebsd.pl> X-Mailer: Apple Mail (2.935.3) Cc: freebsd-current@freebsd.org, freebsd-questions@freebsd.org Subject: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 15:30:02 -0000 Hi, > On 28.06.2009, at 10:49, Pawel Jakub Dawidek wrote: > >> .... I for one never put mirror on >> already partitioned disk. Although it is sometimes safe to use the >> last >> sector. Gjournal already looks for UFS and if UFS is in place, it >> figures out if the last sector is in use - it isn't if partition >> size is >> not multiple of UFS block size. >> does this actually also mean that gmirror used on a partition (eg mirroring two partitions of two different disks) is not recommended and is going to write its metadata always on the last sector of the disk, instead of the last sector of the partition? regards, Lorenzo From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 15:42:01 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46EEA1065674 for ; Tue, 30 Jun 2009 15:42:01 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id EFAAD8FC12 for ; Tue, 30 Jun 2009 15:42:00 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n5UFFvU5053528; Tue, 30 Jun 2009 09:15:58 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A4A2C2D.1070404@samsco.org> Date: Tue, 30 Jun 2009 09:15:57 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Alan Cox References: <200906292005.18629.hselasky@c2i.net> <4A4907AE.1080303@cs.rice.edu> <200906292130.16718.hselasky@c2i.net> <4A499EFD.9080509@cs.rice.edu> In-Reply-To: <4A499EFD.9080509@cs.rice.edu> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: Contigmalloc regression seen on latest 7.x and 8.x branches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 15:42:01 -0000 Alan Cox wrote: > > After looking at r159130 and the comments in the code, I don't think it > would be appropriate to remove the printf()s. However, the logic that > determines whether printf() is called is flawed. I believe that the > attached patch should eliminate the incorrect printf()s that you are > seeing. > If this fixes the Hans' problem, then I'm quite happy with it going into the tree. There another pending busdma fix that I need to handle, so I can shepherd this one in at the same time if you'd like. Scott From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 15:57:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3857C1065674; Tue, 30 Jun 2009 15:57:35 +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 B32088FC28; Tue, 30 Jun 2009 15:57:34 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.22] (helo=12.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #92) id 1MLfi8-0007vm-GH; Tue, 30 Jun 2009 17:57:32 +0200 Received: from tac42.t.pppool.de ([89.55.172.66]:57084 helo=ernst.jennejohn.org) by 12.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #79) id 1MLfi8-0003N5-4V; Tue, 30 Jun 2009 17:57:32 +0200 Date: Tue, 30 Jun 2009 17:57:31 +0200 From: Gary Jennejohn To: Chris Hedley Message-ID: <20090630175731.4c589f80@ernst.jennejohn.org> In-Reply-To: References: <4A2C124A.1050707@freebsd.org> <3c1674c90906291830g1c79c80bq42ce99f44588e968@mail.gmail.com> <20090630113544.3e2bef31@ernst.jennejohn.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: New builds won't boot (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 15:57:35 -0000 On Tue, 30 Jun 2009 15:25:59 +0100 (BST) Chris Hedley wrote: > On Tue, 30 Jun 2009, Gary Jennejohn wrote: > > It does seem to number based on slot, whereby the driver for some reason > > acts as though SATA has master/slave disks, which of course it doesn't. > > > > You can get back to the old behavior by putting "options ATA_STATIC_ID" > > into your kernel config file. > > Hmm... weirdly, I noticed that /after/ putting that line into my config; > maybe I should try again without it and see what happens...? I think I'll > do that a bit later today and report back if there's any difference. Ah, yes. Now that I think about it again, you're right. That's also when I started seeing it. I'm now running mav's ata-cam patches and took ATA_STATIC_ID out of my config file. I'd sort of forgotten when/why I'd done it. Sorry for the confusion. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 15:59:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 867BE106567D; Tue, 30 Jun 2009 15:59:05 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 100E78FC25; Tue, 30 Jun 2009 15:59:04 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJrTSUqDaFvL/2dsb2JhbADQFoQPBYE3 X-IronPort-AV: E=Sophos;i="4.42,317,1243828800"; d="scan'208";a="39813688" Received: from nile.cs.uoguelph.ca ([131.104.91.203]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 30 Jun 2009 11:59:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id 1E6638D4116; Tue, 30 Jun 2009 11:59:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at nile.cs.uoguelph.ca Received: from nile.cs.uoguelph.ca ([127.0.0.1]) by localhost (nile.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMeyVdoHsslR; Tue, 30 Jun 2009 11:59:03 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by nile.cs.uoguelph.ca (Postfix) with ESMTP id 01AA38D40FF; Tue, 30 Jun 2009 11:59:03 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5UG1LW11918; Tue, 30 Jun 2009 12:01:21 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 30 Jun 2009 12:01:21 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Attilio Rao In-Reply-To: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> Message-ID: References: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 15:59:06 -0000 On Mon, 29 Jun 2009, Attilio Rao wrote: > > While that should be real in principle (immediate shutdown of the fs > operation and unmounting of the partition) it is totally impossible to > have it completely unsleeping, so it can happen that also umount -f > sleeps / delays for some times (example: vflush). > Currently, umount -f is one of the most complicated thing to handle in > our VFS because it puts as requirement that vnodes can be reclaimed in > any moment, adding complexity and possibility for races. > > What's the fix for your problem? > >From other responses, it does look like pursuing this is appropriate and that current behaviour is considered a bug. I should have noted in the previous email that I suspected that my simple patch didn't handle all cases, which I have just determined via testing. Unfortunately, the thread doing "umount" can also get stuck in an msleep() while waiting for the mnt_lockref to go to 0, which happens before the VFS_UNMOUNT() call. (mnt_lockref gets incremented by various system calls that call vfs_busy().) I think I can fix this in the experimental nfsv4 client, since it has a kernel thread that can check for MNTK_UNMOUNTF being set and then kill off the RPCs in progress, but that won't help the regular client. It's starting to look like too much work for FreeBSD8, but sounds like it is worth pursuing. (Appologies to anyone that thought I would have it all fixed in a day or two.) rick From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 16:08:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F020106564A; Tue, 30 Jun 2009 16:08:02 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 8F4DC8FC17; Tue, 30 Jun 2009 16:08:01 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by bwz12 with SMTP id 12so227648bwz.43 for ; Tue, 30 Jun 2009 09:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=TDD6WF2gXafy9CTKQtZFhm7aP2oicr1uifWy2DcgTEA=; b=bYuV7FCOdCDy8tsTrXE29kHVsr+qsAI1X9Xbwu1olYI6i5vFnSXcxAkuTkVDMCGR60 78dCYBCkbtUOgeYSDFZe6XR9Ymky4CYeHgHyX9iRzEryN/XO/HHGRGFcjM50y0xhapRW Rn5FF917qFQKnbfMXHbNtu8wW3scoYvsJt8k4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=j66oOopeg0sCwNkHTfypcesmDftb8R7mZFxJ/AtiKpGiPRaLI5qF9MH87wl9D1rCpX oswUiXlPPP5D0WroM+QbA1jg22ryF7xPjIPhKxGV3s1f0exv+rTC+5JBPyDmkhQI4Cs+ HsIXUDKlPJTH98x7bQsD7OJH4VHEwS2v4W1KQ= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.223.113.136 with SMTP id a8mr5381699faq.76.1246378080211; Tue, 30 Jun 2009 09:08:00 -0700 (PDT) In-Reply-To: References: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> Date: Tue, 30 Jun 2009 18:08:00 +0200 X-Google-Sender-Auth: 1a771cec11f35e25 Message-ID: <3bbf2fe10906300908p6b0f314di25bab46b03b5933a@mail.gmail.com> From: Attilio Rao To: Rick Macklem Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:08:02 -0000 2009/6/30 Rick Macklem : > > > On Mon, 29 Jun 2009, Attilio Rao wrote: > >> >> While that should be real in principle (immediate shutdown of the fs >> operation and unmounting of the partition) it is totally impossible to >> have it completely unsleeping, so it can happen that also umount -f >> sleeps / delays for some times (example: vflush). >> Currently, umount -f is one of the most complicated thing to handle in >> our VFS because it puts as requirement that vnodes can be reclaimed in >> any moment, adding complexity and possibility for races. >> >> What's the fix for your problem? >> > From other responses, it does look like pursuing this is appropriate > and that current behaviour is considered a bug. > > I should have noted in the previous email that I suspected that my simple > patch didn't handle all cases, which I have just determined via testing. > > Unfortunately, the thread doing "umount" can also get stuck in an msleep() > while waiting for the mnt_lockref to go to 0, which happens before the > VFS_UNMOUNT() call. (mnt_lockref gets incremented by various system > calls that call vfs_busy().) Sorry for not answering and I still didn't read this thread at all, I just wanted to let you know that this msleep is skipped for the force unmount, it should just happen in a normal unmount case. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 16:39:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83844106566C; Tue, 30 Jun 2009 16:39:28 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 27E3B8FC15; Tue, 30 Jun 2009 16:39:27 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 9BF051E001F7; Tue, 30 Jun 2009 18:39:26 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5UGcfaQ028526; Tue, 30 Jun 2009 18:38:41 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5UGcfLD028525; Tue, 30 Jun 2009 18:38:41 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Tue, 30 Jun 2009 18:38:41 +0200 To: Juergen Lock Message-ID: <20090630163841.GA28338@triton.kn-bremen.de> References: <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <179b97fb0906280929u654129bfoaefa2a43f7058dc5@mail.gmail.com> <20090628165458.GA25437@dchagin.static.corbina.ru> <20090628174748.GA27292@dchagin.static.corbina.ru> <91921319@ipt.ru> <20090628212720.GA29902@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090628212720.GA29902@triton.kn-bremen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: malus.x@gmail.com, Brandon Gooch , Boris Samorodov , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Chagin Dmitry , "Sean C. Farley" Subject: nspluginwrapper patch for testing (was: Re: flash10 vs f10) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:39:28 -0000 On Sun, Jun 28, 2009 at 11:27:20PM +0200, Juergen Lock wrote: > On Mon, Jun 29, 2009 at 12:37:12AM +0400, Boris Samorodov wrote: > > Chagin Dmitry writes: > > > On Sun, Jun 28, 2009 at 12:39:09PM -0500, Sean C. Farley wrote: > > >> On Sun, 28 Jun 2009, Chagin Dmitry wrote: > > >> > > >> > On Sun, Jun 28, 2009 at 04:29:49PM +0000, Brandon Gooch wrote: > > >> > > >> *snip* > > >> > > >> >> I have. I'm using it with about the same level of success as the > > >> >> previous versions of Flash (I need to map a couple of keys to run > > >> >> `pkill npviewer.bin`). > > >> > > >> I also have a key mapping to killall npviewer.bin. > > >> > > >> > for amd64 try: compat.linux32.maxssiz=4194304 > > >> > > > >> > for i386 try: limit stacksize to 4mb or set unlimited. > > >> > > >> Thank you. I tested viewing "TXT ISLAND" on YouTube. Works at higher > > >> limits for me such as 32MB but not at my default of 64MB. > > >> > > >> Why/how does this help? At least on i386, it stops Flash from choking > > >> on YouTube videos when switching to HD or jumping within a video. > > > > > > the reason? foolish waves in a Uli head and stupid bug in flash plugin. > > > flash uses pthread_detach() after pthread_join() call. > > > glibc allows such behaviour (if stack limit < 40Mb) piece of shit... > > > .oO(Why does that remind me again of > http://developers.slashdot.org/comments.pl?sid=1063323&cid=26128419 > ?) > > > If that helps then it's a good idea to create a pkg-message for > > the port (Juergen Lock is CCed). > > Well i386 doesn't seem to have a sysctl for linux stacksize, can > ulimit be used for this too? Because I can't seem to reproduce this > problem on an i386 20090605 vbox head guest with the new ports, suddenly > flash behaves even when I click the youtube `watch in hd' button, even > multiple times... (On 7-stable amd64 with f8 the sysctl does help tho.) > > Oh and if ulimit does indeed work for the linuxulator maybe > nspluginwrapper should be patched instead? (Or at least on i386?) Ok the following seems to work here on 7-stable amd64 with the default compat.linux32.maxssiz setting, please test elsewhere too: (maintainer Cc'd.) Index: Makefile =================================================================== RCS file: /home/pcvs/ports/www/nspluginwrapper/Makefile,v retrieving revision 1.13 diff -u -p -r1.13 Makefile --- Makefile 19 Mar 2009 17:28:49 -0000 1.13 +++ Makefile 30 Jun 2009 16:31:29 -0000 @@ -7,7 +7,7 @@ PORTNAME= nspluginwrapper PORTVERSION= 1.2.2 -PORTREVISION= 2 +PORTREVISION= 3 CATEGORIES= www linux emulators MASTER_SITES= http://gwenole.beauchesne.info/projects/nspluginwrapper/files/ DISTFILES= ${DISTNAME}${EXTRACT_SUFX} ${RPMFILE} @@ -53,6 +53,8 @@ post-extract: post-patch: @${REINPLACE_CMD} -e 's,/usr/X11R6,${LOCALBASE},g' \ ${WRKSRC}/src/npw-config.c + ${RM} ${WRKSRC}/usr/lib/nspluginwrapper/i386/linux/npviewer.orig + post-install: ${MKDIR} ${LIBDIR}/i386/linux ${INSTALL_SCRIPT} ${WRKSRC}/usr/lib/nspluginwrapper/i386/linux/* \ Index: files/patch-ulimit @@ -0,0 +1,7 @@ +Index: usr/lib/nspluginwrapper/i386/linux/npviewer +@@ -1,4 +1,5 @@ + #!/bin/sh + TARGET_OS=linux + TARGET_ARCH=i386 ++ulimit -s 32768 + . /usr/local/lib/nspluginwrapper/noarch/npviewer From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 17:55:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66B41106566C for ; Tue, 30 Jun 2009 17:55:54 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id EE1D48FC12 for ; Tue, 30 Jun 2009 17:55:53 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,317,1243807200"; d="scan'208";a="217476638" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 30 Jun 2009 19:55:53 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 0756F1B07E4; Tue, 30 Jun 2009 19:55:52 +0200 (CEST) Date: Tue, 30 Jun 2009 19:55:52 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: nspluginwrapper patch for testing (was: Re: flash10 vs f10) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 17:55:54 -0000 getting this on x86: ulimit: bad limit: Operation not permitted ulimit: bad limit: Operation not permitted cheers. From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 18:00:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C03421065676 for ; Tue, 30 Jun 2009 18:00:18 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out3.uni-muenster.de (ZIVM-OUT3.UNI-MUENSTER.DE [128.176.192.18]) by mx1.freebsd.org (Postfix) with ESMTP id 55D2C8FC22 for ; Tue, 30 Jun 2009 18:00:18 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,317,1243807200"; d="scan'208";a="7217383" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay3.uni-muenster.de with ESMTP; 30 Jun 2009 20:00:17 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 48DCF1B07E4; Tue, 30 Jun 2009 20:00:17 +0200 (CEST) Date: Tue, 30 Jun 2009 20:00:17 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: nspluginwrapper patch for testing (was: Re: flash10 vs f10) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 18:00:19 -0000 ooooops. my bad. i have "stacksize=4m" in /etc/login.conf. sorry. From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 18:29:23 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A617F1065680 for ; Tue, 30 Jun 2009 18:29:23 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 661DE8FC18 for ; Tue, 30 Jun 2009 18:29:23 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id A0BAE1E001F6; Tue, 30 Jun 2009 20:29:22 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5UISBwL035829; Tue, 30 Jun 2009 20:28:11 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5UISAd0035828; Tue, 30 Jun 2009 20:28:10 +0200 (CEST) (envelope-from nox) Date: Tue, 30 Jun 2009 20:28:10 +0200 (CEST) From: Juergen Lock Message-Id: <200906301828.n5UISAd0035828@triton.kn-bremen.de> To: alexbestms@math.uni-muenster.de X-Newsgroups: local.list.freebsd.current In-Reply-To: Organization: home Cc: freebsd-current@FreeBSD.org Subject: Re: nspluginwrapper patch for testing (was: Re: flash10 vs f10) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 18:29:24 -0000 In article you write: >getting this on x86: > >ulimit: bad limit: Operation not permitted >ulimit: bad limit: Operation not permitted > Hmm did you alreadly lower the stack limit below 32M? (what does ulimit -a say?) Does flash work correctly for you, i.e. things like the youtube `watch in hd' button? If yes I guess we can just redirect the error message to /dev/null since a lower stack limit than 32M should not stop flash from working and we can't raise it easily from sh anyway... Oh and also, which FreeBSD and Linux base/nonbase versions is that? Thanx, Juergen From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 18:38:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8426106566C for ; Tue, 30 Jun 2009 18:38:51 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7C97B8FC1A for ; Tue, 30 Jun 2009 18:38:50 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,318,1243807200"; d="scan'208";a="217479031" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 30 Jun 2009 20:38:50 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id 3AB131B0741; Tue, 30 Jun 2009 20:38:50 +0200 (CEST) Date: Tue, 30 Jun 2009 20:38:49 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Juergen Lock Message-ID: In-Reply-To: <200906301828.n5UISAd0035828@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: nspluginwrapper patch for testing (was: Re: flash10 vs f10) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 18:38:52 -0000 i'm running compat.linux.osrelease: 2.6.16 and r195173 (CURRENT). yep. the warning comes up if a users stacksize is limited < 32M. flash works great and the HD button isn't causing any problems. maybe it's possible to ad something like if ulimit < 32m then don't change ulimit and prinf("not setting new ulimit due to stacksize limitation"). something like that.... cheers. Juergen Lock schrieb am 2009-06-30: > In article > > you write: > >getting this on x86: > >ulimit: bad limit: Operation not permitted > >ulimit: bad limit: Operation not permitted > Hmm did you alreadly lower the stack limit below 32M? (what does > ulimit -a > say?) Does flash work correctly for you, i.e. things like the > youtube > `watch in hd' button? If yes I guess we can just redirect the error > message to /dev/null since a lower stack limit than 32M should not > stop > flash from working and we can't raise it easily from sh anyway... > Oh and also, which FreeBSD and Linux base/nonbase versions is that? > Thanx, > Juergen From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 18:39:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD6EF106566C for ; Tue, 30 Jun 2009 18:39:25 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (mail.cs.rice.edu [128.42.1.31]) by mx1.freebsd.org (Postfix) with ESMTP id A50978FC08 for ; Tue, 30 Jun 2009 18:39:25 +0000 (UTC) (envelope-from alc@cs.rice.edu) Received: from mail.cs.rice.edu (localhost.localdomain [127.0.0.1]) by mail.cs.rice.edu (Postfix) with ESMTP id 0AFAD2C2AAC; Tue, 30 Jun 2009 13:39:25 -0500 (CDT) X-Virus-Scanned: by amavis-2.4.0 at mail.cs.rice.edu Received: from mail.cs.rice.edu ([127.0.0.1]) by mail.cs.rice.edu (mail.cs.rice.edu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0wKdO+CJ9N0v; Tue, 30 Jun 2009 13:39:17 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.cs.rice.edu (Postfix) with ESMTP id 34C9C2C2B58; Tue, 30 Jun 2009 13:39:17 -0500 (CDT) Message-ID: <4A4A5BD4.4040508@cs.rice.edu> Date: Tue, 30 Jun 2009 13:39:16 -0500 From: Alan Cox User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Scott Long References: <200906292005.18629.hselasky@c2i.net> <4A4907AE.1080303@cs.rice.edu> <200906292130.16718.hselasky@c2i.net> <4A499EFD.9080509@cs.rice.edu> <4A4A2C2D.1070404@samsco.org> In-Reply-To: <4A4A2C2D.1070404@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Alan Cox , Hans Petter Selasky Subject: Re: Contigmalloc regression seen on latest 7.x and 8.x branches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 18:39:26 -0000 Scott Long wrote: > Alan Cox wrote: >> >> After looking at r159130 and the comments in the code, I don't think >> it would be appropriate to remove the printf()s. However, the logic >> that determines whether printf() is called is flawed. I believe that >> the attached patch should eliminate the incorrect printf()s that you >> are seeing. >> > > If this fixes the Hans' problem, then I'm quite happy with it going into > the tree. There another pending busdma fix that I need to handle, so I > can shepherd this one in at the same time if you'd like. It's all yours. Thanks, Alan From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 18:42:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71DE71065678; Tue, 30 Jun 2009 18:42:56 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id EF9AB8FC08; Tue, 30 Jun 2009 18:42:55 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 215331E001F6; Tue, 30 Jun 2009 20:42:55 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5UIfkoZ039366; Tue, 30 Jun 2009 20:41:46 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5UIfk7D039365; Tue, 30 Jun 2009 20:41:46 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Tue, 30 Jun 2009 20:41:46 +0200 To: Juergen Lock Message-ID: <20090630184146.GA39346@triton.kn-bremen.de> References: <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <179b97fb0906280929u654129bfoaefa2a43f7058dc5@mail.gmail.com> <20090628165458.GA25437@dchagin.static.corbina.ru> <20090628174748.GA27292@dchagin.static.corbina.ru> <91921319@ipt.ru> <20090628212720.GA29902@triton.kn-bremen.de> <20090630163841.GA28338@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090630163841.GA28338@triton.kn-bremen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: malus.x@gmail.com, Brandon Gooch , Boris Samorodov , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Chagin Dmitry , "Sean C. Farley" Subject: Re: nspluginwrapper patch for testing (was: Re: flash10 vs f10) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 18:42:57 -0000 On Tue, Jun 30, 2009 at 06:38:41PM +0200, Juergen Lock wrote: > On Sun, Jun 28, 2009 at 11:27:20PM +0200, Juergen Lock wrote: > > On Mon, Jun 29, 2009 at 12:37:12AM +0400, Boris Samorodov wrote: > > > Chagin Dmitry writes: > > > > On Sun, Jun 28, 2009 at 12:39:09PM -0500, Sean C. Farley wrote: > > > >> On Sun, 28 Jun 2009, Chagin Dmitry wrote: > > > >> > > > >> > On Sun, Jun 28, 2009 at 04:29:49PM +0000, Brandon Gooch wrote: > > > >> > > > >> *snip* > > > >> > > > >> >> I have. I'm using it with about the same level of success as the > > > >> >> previous versions of Flash (I need to map a couple of keys to run > > > >> >> `pkill npviewer.bin`). > > > >> > > > >> I also have a key mapping to killall npviewer.bin. > > > >> > > > >> > for amd64 try: compat.linux32.maxssiz=4194304 > > > >> > > > > >> > for i386 try: limit stacksize to 4mb or set unlimited. > > > >> > > > >> Thank you. I tested viewing "TXT ISLAND" on YouTube. Works at higher > > > >> limits for me such as 32MB but not at my default of 64MB. > > > >> > > > >> Why/how does this help? At least on i386, it stops Flash from choking > > > >> on YouTube videos when switching to HD or jumping within a video. > > > > > > > > the reason? foolish waves in a Uli head and stupid bug in flash plugin. > > > > flash uses pthread_detach() after pthread_join() call. > > > > glibc allows such behaviour (if stack limit < 40Mb) piece of shit... > > > > > .oO(Why does that remind me again of > > http://developers.slashdot.org/comments.pl?sid=1063323&cid=26128419 > > ?) > > > > > If that helps then it's a good idea to create a pkg-message for > > > the port (Juergen Lock is CCed). > > > > Well i386 doesn't seem to have a sysctl for linux stacksize, can > > ulimit be used for this too? Because I can't seem to reproduce this > > problem on an i386 20090605 vbox head guest with the new ports, suddenly > > flash behaves even when I click the youtube `watch in hd' button, even > > multiple times... (On 7-stable amd64 with f8 the sysctl does help tho.) > > > > Oh and if ulimit does indeed work for the linuxulator maybe > > nspluginwrapper should be patched instead? (Or at least on i386?) > > Ok the following seems to work here on 7-stable amd64 with the default > compat.linux32.maxssiz setting, please test elsewhere too: > (maintainer Cc'd.) > New version that redirects possible error messages to /dev/null: (in case limit is already lower than 32M...) Index: Makefile =================================================================== RCS file: /home/pcvs/ports/www/nspluginwrapper/Makefile,v retrieving revision 1.13 diff -u -p -r1.13 Makefile --- Makefile 19 Mar 2009 17:28:49 -0000 1.13 +++ Makefile 30 Jun 2009 16:31:29 -0000 @@ -7,7 +7,7 @@ PORTNAME= nspluginwrapper PORTVERSION= 1.2.2 -PORTREVISION= 2 +PORTREVISION= 3 CATEGORIES= www linux emulators MASTER_SITES= http://gwenole.beauchesne.info/projects/nspluginwrapper/files/ DISTFILES= ${DISTNAME}${EXTRACT_SUFX} ${RPMFILE} @@ -53,6 +53,8 @@ post-extract: post-patch: @${REINPLACE_CMD} -e 's,/usr/X11R6,${LOCALBASE},g' \ ${WRKSRC}/src/npw-config.c + ${RM} ${WRKSRC}/usr/lib/nspluginwrapper/i386/linux/npviewer.orig + post-install: ${MKDIR} ${LIBDIR}/i386/linux ${INSTALL_SCRIPT} ${WRKSRC}/usr/lib/nspluginwrapper/i386/linux/* \ Index: files/patch-ulimit @@ -0,0 +1,7 @@ +Index: usr/lib/nspluginwrapper/i386/linux/npviewer +@@ -1,4 +1,5 @@ + #!/bin/sh + TARGET_OS=linux + TARGET_ARCH=i386 ++ulimit -s 32768 2>/dev/null + . /usr/local/lib/nspluginwrapper/noarch/npviewer From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 19:00:27 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62E2D1065680 for ; Tue, 30 Jun 2009 19:00:27 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0A98FC17 for ; Tue, 30 Jun 2009 19:00:26 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 3B3671E001FA; Tue, 30 Jun 2009 21:00:26 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n5UIwut2041374; Tue, 30 Jun 2009 20:58:56 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n5UIwuM0041373; Tue, 30 Jun 2009 20:58:56 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Tue, 30 Jun 2009 20:58:56 +0200 To: Alexander Best Message-ID: <20090630185856.GA41198@triton.kn-bremen.de> References: <200906301828.n5UISAd0035828@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@FreeBSD.org, Juergen Lock Subject: Re: nspluginwrapper patch for testing (was: Re: flash10 vs f10) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 19:00:27 -0000 On Tue, Jun 30, 2009 at 08:38:49PM +0200, Alexander Best wrote: > i'm running compat.linux.osrelease: 2.6.16 and r195173 (CURRENT). > > yep. the warning comes up if a users stacksize is limited < 32M. flash works > great and the HD button isn't causing any problems. > > maybe it's possible to ad something like > > if ulimit < 32m then don't change ulimit and prinf("not setting new ulimit due > to stacksize limitation"). > > something like that.... Well I just redirected the (possible) error message to /dev/null in the new version since the main point of this ulimit'ing is to get rid of a too high limit that can exhibit a flash bug. So If the limit is already lower that shouldn't cause a problem unless maybe when it is _very_ low indeed... Cheers, Juergen From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 19:32:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 660311065676; Tue, 30 Jun 2009 19:32:58 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id F14998FC19; Tue, 30 Jun 2009 19:32:53 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n5UJWmRF082104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Jun 2009 22:32:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n5UJWmZx054697; Tue, 30 Jun 2009 22:32:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n5UJWmsn054696; Tue, 30 Jun 2009 22:32:48 +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, 30 Jun 2009 22:32:48 +0300 From: Kostik Belousov To: Rick Macklem Message-ID: <20090630193248.GY2884@deviant.kiev.zoral.com.ua> References: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3/zQ9zHZ+bvXaNu1" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.1 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: Attilio Rao , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 19:32:58 -0000 --3/zQ9zHZ+bvXaNu1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2009 at 12:01:21PM -0400, Rick Macklem wrote: >=20 >=20 > On Mon, 29 Jun 2009, Attilio Rao wrote: >=20 > > > >While that should be real in principle (immediate shutdown of the fs > >operation and unmounting of the partition) it is totally impossible to > >have it completely unsleeping, so it can happen that also umount -f > >sleeps / delays for some times (example: vflush). > >Currently, umount -f is one of the most complicated thing to handle in > >our VFS because it puts as requirement that vnodes can be reclaimed in > >any moment, adding complexity and possibility for races. > > > >What's the fix for your problem? > > > >From other responses, it does look like pursuing this is appropriate > and that current behaviour is considered a bug. >=20 > I should have noted in the previous email that I suspected that my simple= =20 > patch didn't handle all cases, which I have just determined via testing. >=20 > Unfortunately, the thread doing "umount" can also get stuck in an msleep(= )=20 > while waiting for the mnt_lockref to go to 0, which happens before the > VFS_UNMOUNT() call. (mnt_lockref gets incremented by various system > calls that call vfs_busy().) >=20 > I think I can fix this in the experimental nfsv4 client, since it has > a kernel thread that can check for MNTK_UNMOUNTF being set and then > kill off the RPCs in progress, but that won't help the regular client. This solution sounds good, but see below. >=20 > It's starting to look like too much work for FreeBSD8, but sounds like > it is worth pursuing. (Appologies to anyone that thought I would have it > all fixed in a day or two.) It may be argued by some people, me included, that umount -f shall not override any ownership of kernel resources. In particular, you must not ignore the lockref. Instead, the threads that own misc filesystem resources, like mount reference counter, locked vnodes etc shall be weed out of the syscalls. E.g., finishing stalled rpc calls with some error code that is propagated to return code from vops is good solution. Quite similar problems happen with SIGSTOP and intr NFS mounts. You saw the proposed solution that is quite similar, it forces the threads owning the resources to progress to syscall boundary. Another problem with forced unmounts is that VFS does not block new threads from arriving into VOPs. When finishing the inflight rpcs, you may either leave some new rpcs behind or loop infinitely chasing rpcs that arrive while you finishing old rpcs. Half-measure is the filesystem suspension, that keeps operations that modify filesystem from entering VOPs. UFS uses suspension for unmounts and rw->ro remounts. Umount -f is needed in two different situations, one is normally worked filesystem that shall be unmounted by administrative request, detaching any resources opened by application. Second is the last-resort action when backing storage (server in NFS case, disk for UFS) is misbehaving. I think we must not break first case for the second. --3/zQ9zHZ+bvXaNu1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpKaF8ACgkQC3+MBN1Mb4hWSACgtWq2bc/EH/RMoIiDxIX+9X0m BMUAnAxMbWuju006357agvAJMimc252u =b5Pm -----END PGP SIGNATURE----- --3/zQ9zHZ+bvXaNu1-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 20:01:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0586C1065674; Tue, 30 Jun 2009 20:01:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7FED88FC1D; Tue, 30 Jun 2009 20:01:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANsLSkqDaFvH/2dsb2JhbADRaoJBgU4FgTg X-IronPort-AV: E=Sophos;i="4.42,318,1243828800"; d="scan'208";a="37919896" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 30 Jun 2009 16:01:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 1A2C5108463B; Tue, 30 Jun 2009 16:01:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qQ09x6AgPl5; Tue, 30 Jun 2009 16:01:15 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 09DB5108462A; Tue, 30 Jun 2009 16:01:15 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n5UK3Y916395; Tue, 30 Jun 2009 16:03:34 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Tue, 30 Jun 2009 16:03:34 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Kostik Belousov In-Reply-To: <20090630193248.GY2884@deviant.kiev.zoral.com.ua> Message-ID: References: <3bbf2fe10906290256x4bfbe263jccef017a557f9410@mail.gmail.com> <20090630193248.GY2884@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Attilio Rao , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 20:01:18 -0000 On Tue, 30 Jun 2009, Kostik Belousov wrote: >> >> I think I can fix this in the experimental nfsv4 client, since it has >> a kernel thread that can check for MNTK_UNMOUNTF being set and then >> kill off the RPCs in progress, but that won't help the regular client. > This solution sounds good, but see below. > > It may be argued by some people, me included, that umount -f shall not > override any ownership of kernel resources. In particular, you must > not ignore the lockref. Instead, the threads that own misc filesystem > resources, like mount reference counter, locked vnodes etc shall be > weed out of the syscalls. E.g., finishing stalled rpc calls with some > error code that is propagated to return code from vops is good solution. > I think that the thread "fix" above would work this way. Right now, nfs_umount() terminates RPCs in progress for the "-f" case and they return RPC_CANTRECV, which just becomes EACCES at the moment. The problem is that, often, the "umount -f" thread never gets as far as nfs_umount(). All I was thinking of doing, above, is having the kernel thread check for MNTK_UNMOUNTF and then do the same thing. (ie. The NFS VOPs would end up returning EACCES, or whatever Exxx might be preferred.) > Another problem with forced unmounts is that VFS does not block new > threads from arriving into VOPs. When finishing the inflight rpcs, > you may either leave some new rpcs behind or loop infinitely chasing > rpcs that arrive while you finishing old rpcs. > The NFS clients already handle this by returning ESTALE at the beginning of nfs_request() without attempting the RPC, if MNTK_UNMOUNTF is set. (Why ESTALE?? Who knows, although I suspect that just about any Exxx will get the job done?) > Umount -f is needed in two different situations, one is normally worked > filesystem that shall be unmounted by administrative request, detaching > any resources opened by application. Second is the last-resort action > when backing storage (server in NFS case, disk for UFS) is misbehaving. > I think we must not break first case for the second. > I think this is what Bruce Evans was referring to. He suggested that there be two flags, like -f and -F, if I understood his post. rick From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 20:30:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4E5D1065670 for ; Tue, 30 Jun 2009 20:30:39 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 6857F8FC14 for ; Tue, 30 Jun 2009 20:30:39 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id AFA4663317E; Tue, 30 Jun 2009 22:11:52 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 1B408E1FE; Tue, 30 Jun 2009 22:11:54 +0200 (CEST) Date: Tue, 30 Jun 2009 22:11:53 +0200 From: Patrick Lamaiziere To: "Sean P. Dew" Message-ID: <20090630221153.6825f9fd@baby-jane.lamaiziere.net> In-Reply-To: <45d874490906192104w1a11271am97f6d9705b7fa49c@mail.gmail.com> References: <45d874490906192104w1a11271am97f6d9705b7fa49c@mail.gmail.com> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: building device drivers for FreeBSD 7.2+ /AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 20:30:39 -0000 Le Fri, 19 Jun 2009 21:04:53 -0700, "Sean P. Dew" a =E9crit : > Is there any tutorial/book on building device drivers for Free BSD? See also http://forums.freebsd.org/showthread.php?t=3D1566 HTH. From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 20:36:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45B571065674 for ; Tue, 30 Jun 2009 20:36:09 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id EE0AB8FC16 for ; Tue, 30 Jun 2009 20:36:08 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local (pooker.samsco.org [168.103.85.57]) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n5UKa5Tx054834; Tue, 30 Jun 2009 14:36:05 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4A4A7735.9060301@samsco.org> Date: Tue, 30 Jun 2009 14:36:05 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: =?ISO-8859-2?Q?Piotr_Zi=EAcik?= References: <200906251329.35200.kosmo@semihalf.com> <200906260929.40709.kosmo@semihalf.com> <4A44D4AD.8010307@samsco.org> <200906301529.42195.kosmo@semihalf.com> In-Reply-To: <200906301529.42195.kosmo@semihalf.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: [PATCH RFC]: Bus_dma eats all available memory X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 20:36:09 -0000 Piotr Ziêcik wrote: > Friday 26 June 2009 16:01:17 Scott Long napisa³(a): >> Tags and maps should be allocated at driver initialization time, not >> every time a request comes in. The problem here isn't the MAX() test, >> it's that the MIN_ALLOC_COMP test is getting fooled because the tag >> keeps on getting recycled. The correct fix is likely to move the flag >> into the bounce zone object. But in general, you should not be >> allocating and freeing tags and maps so often, they are meant to have a >> long lifespan. >> > > I have fixed my driver and updated patch for bus_dma. Could I ask you for > review ? Patch was successfully tested on ARM. > This looks reasonable. I'll give it a closer review and commit it to the FreeBSD repo. Thanks a lot for working on it. Scott From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 21:23:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE80B106564A; Tue, 30 Jun 2009 21:23:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 848D68FC15; Tue, 30 Jun 2009 21:23:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n5ULMwM8056788; Tue, 30 Jun 2009 17:22:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n5ULMvAV081476; Tue, 30 Jun 2009 17:22:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 97C3F7302F; Tue, 30 Jun 2009 17:22:57 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090630212257.97C3F7302F@freebsd-current.sentex.ca> Date: Tue, 30 Jun 2009 17:22:57 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 21:23:01 -0000 TB --- 2009-06-30 19:20:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-06-30 19:20:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-06-30 19:20:01 - cleaning the object tree TB --- 2009-06-30 19:21:14 - cvsupping the source tree TB --- 2009-06-30 19:21:14 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-06-30 19:21:23 - building world TB --- 2009-06-30 19:21:23 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-30 19:21:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-30 19:21:23 - TARGET=amd64 TB --- 2009-06-30 19:21:23 - TARGET_ARCH=amd64 TB --- 2009-06-30 19:21:23 - TZ=UTC TB --- 2009-06-30 19:21:23 - __MAKE_CONF=/dev/null TB --- 2009-06-30 19:21:23 - cd /src TB --- 2009-06-30 19:21:23 - /usr/bin/make -B buildworld >>> World build started on Tue Jun 30 19:21:24 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Tue Jun 30 21:22:01 UTC 2009 TB --- 2009-06-30 21:22:02 - generating LINT kernel config TB --- 2009-06-30 21:22:02 - cd /src/sys/amd64/conf TB --- 2009-06-30 21:22:02 - /usr/bin/make -B LINT TB --- 2009-06-30 21:22:02 - building LINT kernel TB --- 2009-06-30 21:22:02 - MAKEOBJDIRPREFIX=/obj TB --- 2009-06-30 21:22:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-06-30 21:22:02 - TARGET=amd64 TB --- 2009-06-30 21:22:02 - TARGET_ARCH=amd64 TB --- 2009-06-30 21:22:02 - TZ=UTC TB --- 2009-06-30 21:22:02 - __MAKE_CONF=/dev/null TB --- 2009-06-30 21:22:02 - cd /src TB --- 2009-06-30 21:22:02 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 30 21:22:02 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies -------------------------------------------------------------- cd /obj/amd64/src/sys/LINT; MAKEOBJDIRPREFIX=/obj/amd64 MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/obj/amd64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/amd64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/amd64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/amd64/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 800003" INSTALL="sh /src/tools/install.sh" PATH=/obj/amd64/src/tmp/legacy/usr/sbin:/obj/amd64/src/tmp/legacy/usr/bin:/obj/amd64/src/tmp/legacy/usr/games:/obj/amd64/src/tmp/usr/sbin:/obj/amd64/src/tmp/usr/bin:/obj/amd64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 /usr/bin/make KERNEL=kernel depend -DNO_MODULES_OBJ machine -> /src/sys/amd64/include cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /src/sys/amd64/amd64/g enassym.c /src/sys/amd64/amd64/genassym.c:67:23: error: nfs/rpcv2.h: No such file or directory *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-06-30 21:22:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-06-30 21:22:57 - ERROR: failed to build lint kernel TB --- 2009-06-30 21:22:57 - 5709.74 user 598.67 system 7376.29 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Jun 30 22:37:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81082106566C; Tue, 30 Jun 2009 22:37:42 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (chez.mckusick.com [64.81.247.49]) by mx1.freebsd.org (Postfix) with ESMTP id 5C3FE8FC1F; Tue, 30 Jun 2009 22:37:42 +0000 (UTC) (envelope-from mckusick@mckusick.com) Received: from chez.mckusick.com (localhost [127.0.0.1]) by chez.mckusick.com (8.14.2/8.14.2) with ESMTP id n5ULwdxk002480; Tue, 30 Jun 2009 14:58:39 -0700 (PDT) (envelope-from mckusick@chez.mckusick.com) Message-Id: <200906302158.n5ULwdxk002480@chez.mckusick.com> To: Attilio Rao In-reply-to: <3bbf2fe10906300908p6b0f314di25bab46b03b5933a@mail.gmail.com> Date: Tue, 30 Jun 2009 14:58:39 -0700 From: Kirk McKusick X-Mailman-Approved-At: Tue, 30 Jun 2009 22:49:16 +0000 Cc: freebsd-fs@freebsd.org, Rick Macklem , freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 22:37:43 -0000 Just for the history books, there originally were two forms of forced unmounts. The gentle force (-f) and the brute force (-F) unmount. The -f unmount flushes out all the dirty buffers so that when the unmount completes no data is lost and the filesystem is in a consistent state. The -F unmount invalidates and discards all the dirty buffers without attempting to do any I/O on them. The result is lost data and a possibly inconsistent filesystem. But it will get the job done even if the disk has died or the server has gone away. For reasons that I never tracked down, the -F unmount option was never incorporated into FreeBSD when they did the merge from 4.4BSD-Lite II, so that functionality never made it into the system. It is actually much easier to do than unmount -f since you just walk through and set B_INVAL and B_ERROR on all the dirty buffers for that filesystem. The problem with unmount -f is that it will hang if the server is gone since it will insist on pushing back all the dirty buffers. Kirk McKusick From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 01:09:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B15F106564A; Wed, 1 Jul 2009 01:09:59 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from flat.berklix.org (flat.berklix.org [83.236.223.115]) by mx1.freebsd.org (Postfix) with ESMTP id F258A8FC0C; Wed, 1 Jul 2009 01:09:58 +0000 (UTC) (envelope-from jhs@berklix.com) Received: from park.js.berklix.net (p549A613B.dip.t-dialin.net [84.154.97.59]) (authenticated bits=0) by flat.berklix.org (8.13.8/8.13.8) with ESMTP id n610nGf4019454; Wed, 1 Jul 2009 02:49:17 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (fire.js.berklix.net [192.168.91.41]) by park.js.berklix.net (8.13.8/8.13.8) with ESMTP id n610n3gr026985; Wed, 1 Jul 2009 02:49:06 +0200 (CEST) (envelope-from jhs@berklix.com) Received: from fire.js.berklix.net (localhost [127.0.0.1]) by fire.js.berklix.net (8.14.3/8.14.3) with ESMTP id n610mPem058027; Wed, 1 Jul 2009 02:48:30 +0200 (CEST) (envelope-from jhs@fire.js.berklix.net) Message-Id: <200907010048.n610mPem058027@fire.js.berklix.net> To: Kirk McKusick From: "Julian H. Stacey" Organization: http://www.berklix.com BSD Unix Linux Consultancy, Munich Germany User-agent: EXMH on FreeBSD http://www.berklix.com/free/ X-URL: http://www.berklix.com In-reply-to: Your message "Tue, 30 Jun 2009 14:58:39 PDT." <200906302158.n5ULwdxk002480@chez.mckusick.com> Date: Wed, 01 Jul 2009 02:48:25 +0200 Sender: jhs@berklix.com Cc: Attilio Rao , freebsd-fs@freebsd.org, Rick Macklem , freebsd-current@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 01:09:59 -0000 Kirk McKusick wrote: > forced unmounts. The gentle force (-f) and the brute force (-F) > unmount. -F Would also be nice for devd.conf detach, for when people forget & pull a USB stick without unmounting first. Better a corrupt stick than a crashed OS. Cheers, Julian -- Julian Stacey: BSD Unix Linux C Sys. Eng. Consultant Munich http://berklix.com Mail in plain ASCII text, HTML & Base64 are spam. http://asciiribbon.org From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 01:12:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC88A106566C for ; Wed, 1 Jul 2009 01:12:31 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 770458FC0C for ; Wed, 1 Jul 2009 01:12:31 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MLoNC-0001Ty-Ar for freebsd-current@freebsd.org; Wed, 01 Jul 2009 01:12:30 +0000 Received: from dslb-094-222-041-163.pools.arcor-ip.net ([94.222.41.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Jul 2009 01:12:30 +0000 Received: from js by dslb-094-222-041-163.pools.arcor-ip.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 01 Jul 2009 01:12:30 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Julian Stecklina Date: Wed, 01 Jul 2009 03:12:18 +0200 Lines: 33 Message-ID: <87hbxxp5ot.fsf@tabernacle.lan> References: <1246316092.3981.11.camel@Lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: dslb-094-222-041-163.pools.arcor-ip.net X-Archive: encrypt User-Agent: Gnus/5.101 (Gnus v5.10.10) Cancel-Lock: sha1:DI2ltxcgawvicpb+CT37y8a7TVE= Sender: news Subject: Re: 8-CURRENT Firewire X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 01:12:32 -0000 Sean Bruno writes: > -CURRENT has some slightly different Firewire code in it than 6/7. If > you have an opportunity to test it with your Firewire hard drives and > cameras I'd really appreciate it. > > Stuff that's changed: > multi-speed compatible devices will acutally work. > a 400/800 device is connected to a 400/800 compatible > firewire card via a 400 connection will work at 400 > fwcontrol understands multiple firewire cards as multiple > buses now. most commands now take a -u argument to > indicate the bus. > > Please report to the -firewire if you get a chance to test. It would > be great to get positive as well as negative results. I have an AMD 780G board with onboard Firewire controller. 8-CURRENT hangs at boot with: run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config ... If I disable the Firewire controller in the BIOS it boots fine. What is a good way to debug this? Regards, -- Julian Stecklina The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners - Ernst Jan Plugge From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 01:53:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7584B1065686; Wed, 1 Jul 2009 01:53:26 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 3E1928FC25; Wed, 1 Jul 2009 01:53:25 +0000 (UTC) (envelope-from mel.flynn+fbsd.current@mailing.thruhere.net) Received: from smoochies.rachie.is-a-geek.net (mailhub.lan.rachie.is-a-geek.net [192.168.2.11]) by mailhub.rachie.is-a-geek.net (Postfix) with ESMTP id 3FF707E837; Tue, 30 Jun 2009 17:53:25 -0800 (AKDT) From: Mel Flynn To: freebsd-current@freebsd.org Date: Tue, 30 Jun 2009 17:53:23 -0800 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906271948.54745.mel.flynn+fbsd.current@mailing.thruhere.net> <20090629144205.GA83592@lor.one-eyed-alien.net> <200906291241.56414.mel.flynn+fbsd.current@mailing.thruhere.net> In-Reply-To: <200906291241.56414.mel.flynn+fbsd.current@mailing.thruhere.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906301753.24089.mel.flynn+fbsd.current@mailing.thruhere.net> Cc: Brooks Davis Subject: Re: Interface dependencies X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 01:53:26 -0000 On Monday 29 June 2009 12:41:55 Mel Flynn wrote: > I'll revert to what it "should really be" and keep rc_debug. Well, guess what. It now works: cloned_interfaces="lagg0" ifconfig_wpi0="ether 00:16:36:f2:3b:84" wlans_wpi0="wlan0" ifconfig_wlan0="WPA" ifconfig_em0="up" ifconfig_lagg0="laggproto failover laggport em0 laggport wlan0 192.168.2.50 netmask 255.255.255.0" This didn't work ~week or so ago, the exact same lines. I didn't have rc_debug on at the time and the /var/log/messages is gone anyway :(. The kernel didn't really change either (I went from a custom copy+delete one to an include GENERIC with a lot of nodevice/nooptions, but with the same result), so I'm stumped. Maybe r195029 fixed this too. -- Mel From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 07:02:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA49E106564A; Wed, 1 Jul 2009 07:02:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id C0A948FC13; Wed, 1 Jul 2009 07:02:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n6172UuW097551; Wed, 1 Jul 2009 03:02:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n6172Un3062594; Wed, 1 Jul 2009 03:02:30 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 076767302F; Wed, 1 Jul 2009 03:02:29 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090701070230.076767302F@freebsd-current.sentex.ca> Date: Wed, 1 Jul 2009 03:02:29 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at smtp2.sentex.ca X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 07:02:33 -0000 TB --- 2009-07-01 05:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-07-01 05:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-07-01 05:00:00 - cleaning the object tree TB --- 2009-07-01 05:01:03 - cvsupping the source tree TB --- 2009-07-01 05:01:03 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-07-01 05:01:10 - building world TB --- 2009-07-01 05:01:10 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-01 05:01:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-01 05:01:10 - TARGET=amd64 TB --- 2009-07-01 05:01:10 - TARGET_ARCH=amd64 TB --- 2009-07-01 05:01:10 - TZ=UTC TB --- 2009-07-01 05:01:10 - __MAKE_CONF=/dev/null TB --- 2009-07-01 05:01:10 - cd /src TB --- 2009-07-01 05:01:10 - /usr/bin/make -B buildworld >>> World build started on Wed Jul 1 05:01:12 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Jul 1 07:01:31 UTC 2009 TB --- 2009-07-01 07:01:31 - generating LINT kernel config TB --- 2009-07-01 07:01:31 - cd /src/sys/amd64/conf TB --- 2009-07-01 07:01:31 - /usr/bin/make -B LINT TB --- 2009-07-01 07:01:31 - building LINT kernel TB --- 2009-07-01 07:01:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-07-01 07:01:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-07-01 07:01:31 - TARGET=amd64 TB --- 2009-07-01 07:01:31 - TARGET_ARCH=amd64 TB --- 2009-07-01 07:01:31 - TZ=UTC TB --- 2009-07-01 07:01:31 - __MAKE_CONF=/dev/null TB --- 2009-07-01 07:01:31 - cd /src TB --- 2009-07-01 07:01:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jul 1 07:01:31 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies -------------------------------------------------------------- cd /obj/amd64/src/sys/LINT; MAKEOBJDIRPREFIX=/obj/amd64 MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/obj/amd64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/amd64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/amd64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/amd64/src/tmp VERSION="FreeBSD 8.0-CURRENT i386 800003" INSTALL="sh /src/tools/install.sh" PATH=/obj/amd64/src/tmp/legacy/usr/sbin:/obj/amd64/src/tmp/legacy/usr/bin:/obj/amd64/src/tmp/legacy/usr/games:/obj/amd64/src/tmp/usr/sbin:/obj/amd64/src/tmp/usr/bin:/obj/amd64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 /usr/bin/make KERNEL=kernel depend -DNO_MODULES_OBJ machine -> /src/sys/amd64/include cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector /src/sys/amd64/amd64/g enassym.c /src/sys/amd64/amd64/genassym.c:67:23: error: nfs/rpcv2.h: No such file or directory *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-07-01 07:02:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-07-01 07:02:29 - ERROR: failed to build lint kernel TB --- 2009-07-01 07:02:29 - 5708.16 user 602.27 system 7349.05 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 08:30:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C72CC1065672; Wed, 1 Jul 2009 08:30:37 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from itchy.rabson.org (router.rabson.org [80.177.232.241]) by mx1.freebsd.org (Postfix) with ESMTP id 604918FC1B; Wed, 1 Jul 2009 08:30:33 +0000 (UTC) (envelope-from dfr@rabson.org) Received: from [IPv6:2001:470:909f:1:225:ff:feed:9426] (unknown [IPv6:2001:470:909f:1:225:ff:feed:9426]) by itchy.rabson.org (Postfix) with ESMTP id 61E2E5D0E; Wed, 1 Jul 2009 09:12:50 +0100 (BST) Message-Id: From: Doug Rabson To: FreeBSD Tinderbox In-Reply-To: <20090701070230.076767302F@freebsd-current.sentex.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 09:12:50 +0100 References: <20090701070230.076767302F@freebsd-current.sentex.ca> X-Mailer: Apple Mail (2.935.3) Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 08:30:38 -0000 Fixed. On 1 Jul 2009, at 08:02, FreeBSD Tinderbox wrote: > TB --- 2009-07-01 05:00:00 - tinderbox 2.6 running on freebsd- > current.sentex.ca > TB --- 2009-07-01 05:00:00 - starting HEAD tinderbox run for amd64/ > amd64 > TB --- 2009-07-01 05:00:00 - cleaning the object tree > TB --- 2009-07-01 05:01:03 - cvsupping the source tree > TB --- 2009-07-01 05:01:03 - /usr/bin/csup -z -r 3 -g -L 1 -h > localhost -s /tinderbox/HEAD/amd64/amd64/supfile > TB --- 2009-07-01 05:01:10 - building world > TB --- 2009-07-01 05:01:10 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-07-01 05:01:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-07-01 05:01:10 - TARGET=amd64 > TB --- 2009-07-01 05:01:10 - TARGET_ARCH=amd64 > TB --- 2009-07-01 05:01:10 - TZ=UTC > TB --- 2009-07-01 05:01:10 - __MAKE_CONF=/dev/null > TB --- 2009-07-01 05:01:10 - cd /src > TB --- 2009-07-01 05:01:10 - /usr/bin/make -B buildworld >>>> World build started on Wed Jul 1 05:01:12 UTC 2009 >>>> Rebuilding the temporary build tree >>>> stage 1.1: legacy release compatibility shims >>>> stage 1.2: bootstrap tools >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3: cross tools >>>> stage 4.1: building includes >>>> stage 4.2: building libraries >>>> stage 4.3: make dependencies >>>> stage 4.4: building everything >>>> stage 5.1: building 32 bit shim libraries >>>> World build completed on Wed Jul 1 07:01:31 UTC 2009 > TB --- 2009-07-01 07:01:31 - generating LINT kernel config > TB --- 2009-07-01 07:01:31 - cd /src/sys/amd64/conf > TB --- 2009-07-01 07:01:31 - /usr/bin/make -B LINT > TB --- 2009-07-01 07:01:31 - building LINT kernel > TB --- 2009-07-01 07:01:31 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-07-01 07:01:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-07-01 07:01:31 - TARGET=amd64 > TB --- 2009-07-01 07:01:31 - TARGET_ARCH=amd64 > TB --- 2009-07-01 07:01:31 - TZ=UTC > TB --- 2009-07-01 07:01:31 - __MAKE_CONF=/dev/null > TB --- 2009-07-01 07:01:31 - cd /src > TB --- 2009-07-01 07:01:31 - /usr/bin/make -B buildkernel > KERNCONF=LINT >>>> Kernel build for LINT started on Wed Jul 1 07:01:31 UTC 2009 >>>> stage 1: configuring the kernel >>>> stage 2.1: cleaning up the object tree >>>> stage 2.2: rebuilding the object tree >>>> stage 2.3: build tools >>>> stage 3.1: making dependencies > -------------------------------------------------------------- > cd /obj/amd64/src/sys/LINT; MAKEOBJDIRPREFIX=/obj/amd64 > MACHINE_ARCH=amd64 MACHINE=amd64 CPUTYPE= GROFF_BIN_PATH=/obj/ > amd64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/amd64/src/tmp/ > legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/amd64/src/tmp/ > legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/amd64/src/tmp > VERSION="FreeBSD 8.0-CURRENT i386 800003" INSTALL="sh /src/tools/ > install.sh" PATH=/obj/amd64/src/tmp/legacy/usr/sbin:/obj/amd64/src/ > tmp/legacy/usr/bin:/obj/amd64/src/tmp/legacy/usr/games:/obj/amd64/ > src/tmp/usr/sbin:/obj/amd64/src/tmp/usr/bin:/obj/amd64/src/tmp/usr/ > games:/sbin:/bin:/usr/sbin:/usr/bin NO_CTF=1 /usr/bin/make > KERNEL=kernel depend -DNO_MODULES_OBJ > machine -> /src/sys/amd64/include > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 - > Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes - > Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef - > Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/ > sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf - > I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ > ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/ > gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/ > opensolaris/compat -I/src/sys/dev/cxgb -D_KERNEL - > DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -finline- > limit=8000 --param inline-unit-growth=100 --param large-function- > growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno- > builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone - > mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft- > float -fno-asynchronous-unwind-tables -ffreestanding -fstack- > protector /src/sys/amd64/amd64/g > enassym.c > /src/sys/amd64/amd64/genassym.c:67:23: error: nfs/rpcv2.h: No such > file or directory > *** Error code 1 > > Stop in /obj/amd64/src/sys/LINT. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-07-01 07:02:29 - WARNING: /usr/bin/make returned exit > code 1 > TB --- 2009-07-01 07:02:29 - ERROR: failed to build lint kernel > TB --- 2009-07-01 07:02:29 - 5708.16 user 602.27 system 7349.05 real > > > http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 08:48:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 732D4106573E for ; Wed, 1 Jul 2009 08:48:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B84338FC08 for ; Wed, 1 Jul 2009 08:48:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 073F246B8B; Wed, 1 Jul 2009 04:48:39 -0400 (EDT) Date: Wed, 1 Jul 2009 09:48:38 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Stecklina In-Reply-To: <87hbxxp5ot.fsf@tabernacle.lan> Message-ID: References: <1246316092.3981.11.camel@Lappy> <87hbxxp5ot.fsf@tabernacle.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: 8-CURRENT Firewire X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 08:48:42 -0000 On Wed, 1 Jul 2009, Julian Stecklina wrote: >> -CURRENT has some slightly different Firewire code in it than 6/7. If you >> have an opportunity to test it with your Firewire hard drives and cameras >> I'd really appreciate it. >> >> Stuff that's changed: >> multi-speed compatible devices will acutally work. >> a 400/800 device is connected to a 400/800 compatible >> firewire card via a 400 connection will work at 400 >> fwcontrol understands multiple firewire cards as multiple >> buses now. most commands now take a -u argument to >> indicate the bus. >> >> Please report to the -firewire if you get a chance to test. It would be >> great to get positive as well as negative results. > > I have an AMD 780G board with onboard Firewire controller. 8-CURRENT hangs > at boot with: > > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > ... > > If I disable the Firewire controller in the BIOS it boots fine. What is a > good way to debug this? I've seen similar reports of this on 7.x; Richard Clayton has a box that has done this since at least 7.1, and it's one of the reasons I added the debugging output above :-). Unfortunately, it's not in an easy position to debug on that box. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 09:21:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0A7A1065670; Wed, 1 Jul 2009 09:21:52 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id 412128FC17; Wed, 1 Jul 2009 09:21:52 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n619LlaM049927; Wed, 1 Jul 2009 04:21:51 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:content-type:content-transfer-encoding; b=VwCfkcDl5r0jBL3XHfae+WF8VTfdm2aCCto6Dm10QNSdq+YIBXpScizBeDqJ9fRSp ZXl6s1ewAcJ3ccPtDmHf8h0bG2KOdzFC+eSdP8InXjpE34I/DSEkmVaiHiKe4zOo0WZ ynQJ560banIyZQp1l6seX1uX1DE65wM6oRhKXY8= Message-ID: <4A4B2A90.8090300@jrv.org> Date: Wed, 01 Jul 2009 04:21:20 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> <4A48D136.3050309@haruhiism.net> <4A48D551.5090509@FreeBSD.org> <4A49E7A3.70509@haruhiism.net> <4A49EA94.3070109@FreeBSD.org> In-Reply-To: <4A49EA94.3070109@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 09:21:54 -0000 Has anyone found any PCI-X or PCI cards that do AHCI? Or a PCI-Express, PCI-X or PCI card that supports AHCI & FIS-based switching for port multipliers? I'm trying to set up to test this but the only AHCI cards I've found are based on the Jmicron chips, which are PCI-e only, no more than 2 SATA ports, and don't do FIS-based switching. PS. I understand FIS-based switching isn't there yet but I assume it will be. From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 09:39:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3214106564A for ; Wed, 1 Jul 2009 09:39:57 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 651268FC14 for ; Wed, 1 Jul 2009 09:39:56 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247277780; Wed, 01 Jul 2009 12:39:53 +0300 Message-ID: <4A4B2EE6.2080501@FreeBSD.org> Date: Wed, 01 Jul 2009 12:39:50 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: "James R. Van Artsdalen" References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> <4A48D136.3050309@haruhiism.net> <4A48D551.5090509@FreeBSD.org> <4A49E7A3.70509@haruhiism.net> <4A49EA94.3070109@FreeBSD.org> <4A4B2A90.8090300@jrv.org> In-Reply-To: <4A4B2A90.8090300@jrv.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 09:39:58 -0000 James R. Van Artsdalen wrote: > Has anyone found any PCI-X or PCI cards that do AHCI? Or a PCI-Express, > PCI-X or PCI card that supports AHCI & FIS-based switching for port > multipliers? > > I'm trying to set up to test this but the only AHCI cards I've found are > based on the Jmicron chips, which are PCI-e only, no more than 2 SATA > ports, and don't do FIS-based switching. > > PS. I understand FIS-based switching isn't there yet but I assume it > will be. I still haven't found any AHCI card with FBS support. Ideas welcome. I am working on driver for SiI3124/3132. I haven't tested yet how fast they really are (3132 is quite cheap), but they declare PM with FBS support. First one is 4-port PCI-X, second - 2-port PCIe. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 10:57:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FE81106564A; Wed, 1 Jul 2009 10:57:43 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id DC6F68FC08; Wed, 1 Jul 2009 10:57:42 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MLxUh-0004KM-JM; Wed, 01 Jul 2009 11:57:41 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MLxUg-0003ZE-L4; Wed, 01 Jul 2009 11:56:51 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n61Aun4J062659; Wed, 1 Jul 2009 11:56:49 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n61Aun0E062658; Wed, 1 Jul 2009 11:56:49 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 1 Jul 2009 11:56:49 +0100 From: Anton Shterenlikht To: Marcel Moolenaar Message-ID: <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.2 X-Spam-Level: - Cc: freebsd-current@freebsd.org, Anton Shterenlikht , freebsd-questions@freebsd.org, freebsd-ia64@freebsd.org Subject: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 10:57:43 -0000 On Thu, Jun 25, 2009 at 09:41:13AM -0700, Marcel Moolenaar wrote: > > On Jun 25, 2009, at 4:02 AM, Anton Shterenlikht wrote: > > dev_taste(DEV,mirror/gm0) > > g_part_taste(PART,mirror/gm0) > > > > GEOM: mirror/gm0: the secondary GPT table is corrupt or invalid. > > GEOM: mirror/gm0: using the primary only -- recovery suggested. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > You created the mirror after the GPT, which means you destroyed > the GPT backup header. gmirror uses the last sector on the disk > for metadata and that by itself is a cause for various problems. > > It's better to use gmirror per partition. Like this? # gmirror label -vb round-robin root /dev/da0p2 gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. # I've read some boot disk gmirror examples, e.g. http://people.freebsd.org/~rse/mirror however, all examples I've seen are for i386, talking about MBR, fdisk and bsdlabel, so these are not directly applicable to ia64. Application of gvinum for boot disk on ia64 is not clear either. It seems gvinum section of the handbook, 21.9, is also based on i386. Please advise many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 11:45:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9375106566C; Wed, 1 Jul 2009 11:45:38 +0000 (UTC) (envelope-from js@alien8.de) Received: from mail.skyhub.de (cl-3117.ham-01.de.sixxs.net [IPv6:2001:6f8:900:c2c::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6FA198FC13; Wed, 1 Jul 2009 11:45:38 +0000 (UTC) (envelope-from js@alien8.de) Received: from localhost (localhost [127.0.0.1]) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTP id 432121DA109; Wed, 1 Jul 2009 13:45:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1246448737; bh=+RpKYJmIKDv6jDac4bRGWuR0poQCoxJojGEnf82eoT8=; h=To:Cc:Subject:References:From:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=bzjQydMFgVmZFG7aV9q7p07sv+vQREVgUNKEA 0f8OhqCMr6mbzVGi0HKSFRgrqtMclvt/fZk1uv3jcwHvBGtqmqvK8i7dLSu3i0hYE+T J6vUDwqUuWufLufSC0TBM3zeDHNJQskFhdJ+uLCpl8/hIMYfs74+A0+ifg5QsS8b4aA = X-Virus-Scanned: Nedap ESD1 at mail.skyhub.de Received: from mail.skyhub.de ([127.0.0.1]) by localhost (door.skyhub.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WtlnVS5iXF8Y; Wed, 1 Jul 2009 13:45:37 +0200 (CEST) Received: from tabernacle.localnet (unknown [141.76.6.53]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id E71121DA108; Wed, 1 Jul 2009 13:45:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alien8.de; s=alien8; t=1246448737; bh=+RpKYJmIKDv6jDac4bRGWuR0poQCoxJojGEnf82eoT8=; h=To:Cc:Subject:References:From:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=bzjQydMFgVmZFG7aV9q7p07sv+vQREVgUNKEA 0f8OhqCMr6mbzVGi0HKSFRgrqtMclvt/fZk1uv3jcwHvBGtqmqvK8i7dLSu3i0hYE+T J6vUDwqUuWufLufSC0TBM3zeDHNJQskFhdJ+uLCpl8/hIMYfs74+A0+ifg5QsS8b4aA = To: Robert Watson References: <1246316092.3981.11.camel@Lappy> <87hbxxp5ot.fsf@tabernacle.lan> X-Archive: encrypt From: Julian Stecklina X-Hashcash: 1:23:090701:rwatson@freebsd.org::iJaACbkAfB/cmjTK:000000000000000000000000000000000000000001HJ68 X-Hashcash: 1:23:090701:rwatson@freebsd.org::jJ+PcuEFt+bxpCFj:000000000000000000000000000000000000000000RX2J X-Hashcash: 1:23:090701:freebsd-current@freebsd.org::QuZPKErmS+Sii2sT:0000000000000000000000000000000000Gh1J Date: Wed, 01 Jul 2009 13:45:36 +0200 In-Reply-To: (Robert Watson's message of "Wed\, 1 Jul 2009 09\:48\:38 +0100 \(BST\)") Message-ID: <87d48k1va7.fsf@tabernacle.lan> User-Agent: Gnus/5.101 (Gnus v5.10.10) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: 8-CURRENT Firewire X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 11:45:39 -0000 Robert Watson writes: > On Wed, 1 Jul 2009, Julian Stecklina wrote: > >>> -CURRENT has some slightly different Firewire code in it than 6/7. >>> If you have an opportunity to test it with your Firewire hard >>> drives and cameras I'd really appreciate it. >>> >>> Stuff that's changed: >>> multi-speed compatible devices will acutally work. >>> a 400/800 device is connected to a 400/800 compatible >>> firewire card via a 400 connection will work at 400 >>> fwcontrol understands multiple firewire cards as multiple >>> buses now. most commands now take a -u argument to >>> indicate the bus. >>> >>> Please report to the -firewire if you get a chance to test. It >>> would be great to get positive as well as negative results. >> >> I have an AMD 780G board with onboard Firewire controller. 8-CURRENT >> hangs at boot with: >> >> run_interrupt_driven_hooks: still waiting after 60 seconds for >> xpt_config run_interrupt_driven_hooks: still waiting after 120 >> seconds for xpt_config ... >> >> If I disable the Firewire controller in the BIOS it boots fine. What >> is a good way to debug this? > > I've seen similar reports of this on 7.x; Richard Clayton has a box > that has done this since at least 7.1, and it's one of the reasons I > added the debugging output above :-). Unfortunately, it's not in an > easy position to debug on that box. Is there any other way I can help to resolve this? Regards, -- Julian Stecklina The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners - Ernst Jan Plugge From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 12:20:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 051531065672; Wed, 1 Jul 2009 12:20:22 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id B10FB8FC16; Wed, 1 Jul 2009 12:20:21 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MLynR-0004kf-8p; Wed, 01 Jul 2009 13:20:20 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by isis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MLynQ-0007iz-Gc; Wed, 01 Jul 2009 13:20:16 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n61CKF90063010; Wed, 1 Jul 2009 13:20:15 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n61CKF5g063009; Wed, 1 Jul 2009 13:20:15 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 1 Jul 2009 13:20:15 +0100 From: Anton Shterenlikht To: "James R. Van Artsdalen" , freebsd-ia64@freebsd.org, freebsd-current@freebsd.org Message-ID: <20090701122015.GA62937@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <4A4B4FFE.7010400@jrv.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A4B4FFE.7010400@jrv.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.2 X-Spam-Level: - Cc: Marcel Moolenaar , Anton Shterenlikht Subject: Re: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 12:20:22 -0000 On Wed, Jul 01, 2009 at 07:01:02AM -0500, James R. Van Artsdalen wrote: > Anton Shterenlikht wrote: > > Like this? > > > > # gmirror label -vb round-robin root /dev/da0p2 > > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > > # > > > > Is there a filesystem already mounted from da0p2? yes, da0 is the disk on which I installed the system. > Use gmirror label immediately after using gpart to create da0p2 then > always use /dev/mirror/root as the device after that, never da0p2, ie > > # gpart add -b 162 -s 1048576 -t freebsd-ufs ad0 wow! gpart is never mentioned in the handbook, neither in GEOM, nor in gvinum chapter. Is the handbook a bit out of date? > # gmirror label -vb round-robin root /dev/da0p2 > > # newfs /dev/mirror/root > > The examples from the gpart and gmirror man pages worked for me. are you using ia64? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 13:50:40 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53ED31065670 for ; Wed, 1 Jul 2009 13:50:40 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 79AC28FC0A for ; Wed, 1 Jul 2009 13:50:38 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from [41.145.103.163] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MM0Cp-0003sj-PX for current@freebsd.org; Wed, 01 Jul 2009 15:50:35 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MM0Co-0004BT-Jb for current@freebsd.org; Wed, 01 Jul 2009 15:50:34 +0200 To: current@freebsd.org From: "Ian Freislich" X-Attribution: BOFH Date: Wed, 01 Jul 2009 15:50:34 +0200 Message-Id: Cc: Subject: kgdb on an amd64 kernel anyone? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 13:50:40 -0000 Hi Has anyone managed to inspect a vmcore produced by an amd64 kernel in the last few months? I've had several crashes, but all the cores appear corrupted and no useful data can be had. The latest: [firewall2.jnb1] /var/crash # kgdb -c vmcore.5 /boot/kernel.old/kernel GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0x0000000000000000 in ?? () (kgdb) bt #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 Or this followed by pages and pages stack corruption. The most frames I've had the patience to scroll through like this is in the 0000s. [firewall1.jnb1] /var/db/firewall # kgdb -c /var/crash/vmcore.4 /boot/kernel/kernel GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols found)... Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. #0 0xffffffff802bdb8a in doadump () (kgdb) bt #0 0xffffffff802bdb8a in doadump () #1 0xffffff81a4af95f0 in ?? () #2 0xffffffff802be0bb in boot () #3 0xe880695fa0c7c748 in ?? () #4 0x9066eaebfff07554 in ?? () #5 0x31804b26a0c7c748 in ?? () #6 0xc3c900033ee2e8c0 in ?? () #7 0x56415741e5894855 in ?? () #8 0x48fb895354415541 in ?? () #9 0x253c8b486528ec83 in ?? () #10 0x000119b900000000 in ?? () #11 0x804b26d8c2c74800 in ?? () #12 0x65ffff14b1e8f631 in ?? () #13 0x00000000253c8b48 in ?? () #14 0x65000235f1e8f631 in ?? () #15 0x0000000025148b48 in ?? () #16 0x450c608b44028b48 in ?? () #17 0x000004cd840fe485 in ?? () #18 0x00000025348b4865 in ?? () #19 0xe80c49ff0e8b4800 in ?? () #20 0x68c7c74800148304 in ?? () #21 0x05c7df89418048c1 in ?? () #22 0x00000001003d81e8 in ?? () ---Type to continue, or q to quit---q The last useful crashdump I've had was before February this year. Do others share this experience? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 13:54:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1FBF31065675 for ; Wed, 1 Jul 2009 13:54:39 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id A5E648FC14 for ; Wed, 1 Jul 2009 13:54:38 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:40908 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MM0GW-0001I7-6E; Wed, 01 Jul 2009 15:54:27 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id C79A63C01; Wed, 1 Jul 2009 15:54:08 +0200 (CEST) Message-Id: <3EF4C954-2A84-42BA-B0F5-629B3CCC1578@exscape.org> From: Thomas Backman To: Ian Freislich In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 1 Jul 2009 15:54:06 +0200 References: X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MM0GW-0001I7-6E. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MM0GW-0001I7-6E 103a5a6df0d4cd92fe47676768495616 Cc: current@freebsd.org Subject: Re: kgdb on an amd64 kernel anyone? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 13:54:39 -0000 On Jul 1, 2009, at 03:50 PM, Ian Freislich wrote: > Hi > > Has anyone managed to inspect a vmcore produced by an amd64 kernel > in the last few months? I've had several crashes, but all the cores > appear corrupted and no useful data can be had. > > The latest: > > [firewall2.jnb1] /var/crash # kgdb -c vmcore.5 /boot/kernel.old/kernel > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"...(no debugging > symbols found)... > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > #0 0x0000000000000000 in ?? () > (kgdb) bt > #0 0x0000000000000000 in ?? () > Cannot access memory at address 0x0 > > Or this followed by pages and pages stack corruption. The most > frames I've had the patience to scroll through like this is in the > 0000s. > > [firewall1.jnb1] /var/db/firewall # kgdb -c /var/crash/vmcore.4 / > boot/kernel/kernel > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-marcel-freebsd"...(no debugging > symbols found)... > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > Attempt to extract a component of a value that is not a structure > pointer. > #0 0xffffffff802bdb8a in doadump () > (kgdb) bt > #0 0xffffffff802bdb8a in doadump () > #1 0xffffff81a4af95f0 in ?? () > #2 0xffffffff802be0bb in boot () > #3 0xe880695fa0c7c748 in ?? () > #4 0x9066eaebfff07554 in ?? () > #5 0x31804b26a0c7c748 in ?? () > #6 0xc3c900033ee2e8c0 in ?? () > #7 0x56415741e5894855 in ?? () > #8 0x48fb895354415541 in ?? () > #9 0x253c8b486528ec83 in ?? () > #10 0x000119b900000000 in ?? () > #11 0x804b26d8c2c74800 in ?? () > #12 0x65ffff14b1e8f631 in ?? () > #13 0x00000000253c8b48 in ?? () > #14 0x65000235f1e8f631 in ?? () > #15 0x0000000025148b48 in ?? () > #16 0x450c608b44028b48 in ?? () > #17 0x000004cd840fe485 in ?? () > #18 0x00000025348b4865 in ?? () > #19 0xe80c49ff0e8b4800 in ?? () > #20 0x68c7c74800148304 in ?? () > #21 0x05c7df89418048c1 in ?? () > #22 0x00000001003d81e8 in ?? () > ---Type to continue, or q to quit---q > > The last useful crashdump I've had was before February this year. > Do others share this experience? > > Ian I haven't had any such problems. I do often get a "broken stack?" following the rest of the BT, but they're generally useful anyway, and I've never ever seen "Attempt to extract a component of a value that is not a structure pointer" before. Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 14:00:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9ECF1065673 for ; Wed, 1 Jul 2009 14:00:22 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9414B8FC15 for ; Wed, 1 Jul 2009 14:00:22 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id A5E9378FA7; Wed, 1 Jul 2009 18:00:20 +0400 (MSD) Message-ID: <4A4B6C0D.5070104@haruhiism.net> Date: Wed, 01 Jul 2009 18:00:45 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ian Freislich References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: kgdb on an amd64 kernel anyone? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:00:23 -0000 Ian Freislich wrote: > Has anyone managed to inspect a vmcore produced by an amd64 kernel > in the last few months? I've had several crashes, but all the cores > appear corrupted and no useful data can be had No such luck. See f.ex. http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008777.html - an example of a correct dump on my amd64 -current (the netisr.c trap examples). -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 14:23:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 194AE1065674 for ; Wed, 1 Jul 2009 14:23:38 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id DC2238FC2C for ; Wed, 1 Jul 2009 14:23:37 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from PegaPegII (hydra.fletchermoorland.co.uk [78.33.209.59]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n61ENZ4H012455 for ; Wed, 1 Jul 2009 14:23:37 GMT (envelope-from ken@mthelicon.com) Message-ID: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> From: "Pegasus Mc Cleaft" To: Date: Wed, 1 Jul 2009 15:23:34 +0100 Organization: Feathers MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-Antivirus: avast! (VPS 090630-0, 30/06/2009), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Has anyone been able to actually boot the AMD64 kernel after r194958? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pegasus Mc Cleaft List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:23:38 -0000 Hi Current,=20 I was wondering.. Has anyone actually been able to boot a kernel = after r194958? On 2 different machine (simmilar archecture) the system = will kernel-trap right after attemping to mount the ZFS filesystems. I = dont know if it is ZFS related or not as I am not able to get a core. It = complains that no dump device has been defined and then locks up...=20 If there is a way that I can provide more information, please let me = know how and I will post it.=20 Thanks again,=20 Peg From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 14:25:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B75AE1065674 for ; Wed, 1 Jul 2009 14:25:41 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 459148FC21 for ; Wed, 1 Jul 2009 14:25:41 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from [41.145.103.163] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MM0kl-0005D3-PK; Wed, 01 Jul 2009 16:25:39 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1MM0kk-0004JU-1X; Wed, 01 Jul 2009 16:25:38 +0200 To: Thomas Backman From: Ian FREISLICH In-Reply-To: <3EF4C954-2A84-42BA-B0F5-629B3CCC1578@exscape.org> References: <3EF4C954-2A84-42BA-B0F5-629B3CCC1578@exscape.org> X-Attribution: BOFH Date: Wed, 01 Jul 2009 16:25:38 +0200 Message-Id: Cc: current@freebsd.org Subject: Re: kgdb on an amd64 kernel anyone? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:25:42 -0000 Thomas Backman wrote: > On Jul 1, 2009, at 03:50 PM, Ian Freislich wrote: > > > > The last useful crashdump I've had was before February this year. > > Do others share this experience? > > I haven't had any such problems. I do often get a "broken stack?" > following the rest of the BT, but they're generally useful anyway, and > I've never ever seen "Attempt to extract a component of a value that > is not a structure pointer" before. Interesting. So, it's just me then (which is why there haven't been any panic reports from me for a while). There's heavy use of the following modules to the tune of 3*10^9 packets a day peaking at several 1000Mbits/s: Id Refs Address Size Name 1 10 0xffffffff80100000 6f3108 kernel 2 1 0xffffffff80a22000 4986 if_lagg.ko 3 1 0xffffffff80a27000 9f9 pflog.ko 4 1 0xffffffff80a28000 5292 if_bridge.ko 5 1 0xffffffff80a2e000 350f bridgestp.ko I suspect it's blowing up in there somewhere a few times a week. I'll try compiling them into the kernel and see if that yields a useable vmcore. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 14:27:02 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32F19106566C for ; Wed, 1 Jul 2009 14:27:02 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id E069C8FC18 for ; Wed, 1 Jul 2009 14:27:01 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 86E0C78FA5; Wed, 1 Jul 2009 18:27:00 +0400 (MSD) Message-ID: <4A4B724D.10506@haruhiism.net> Date: Wed, 01 Jul 2009 18:27:25 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Pegasus Mc Cleaft References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> In-Reply-To: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Has anyone been able to actually boot the AMD64 kernel after r194958? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:27:02 -0000 Pegasus Mc Cleaft wrote: > I was wondering.. Has anyone actually been able to boot a kernel after r194958? On 2 different machine (simmilar archecture) the system will kernel-trap right after attemping to mount the ZFS filesystems. I dont know if it is ZFS related or not as I am not able to get a core. It complains that no dump device has been defined and then locks up... > > If there is a way that I can provide more information, please let me know how and I will post it. > If your swap space is in zpool, you won't be able to dump. Does the system boot in single user mode? Without starting /etc/rc.d/zfs I mean. And about being able to boot: fujibayashi@ameagari ~ % uname -a FreeBSD ameagari.fujibayashi.jp 8.0-CURRENT FreeBSD 8.0-CURRENT #8 r195182M: Tue Jun 30 16:02:54 JST 2009 fujibayashi@ameagari ~ % uptime 18:26 up 1 day, 6:10, 3 users, load averages: 0,18 0,05 0,02 fujibayashi@ameagari ~ % zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT data 928G 14,3G 914G 1% ONLINE - storage 1,36T 432G 960G 31% ONLINE - -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 14:41:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96C39106567C for ; Wed, 1 Jul 2009 14:41:23 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8EB8FC26 for ; Wed, 1 Jul 2009 14:41:23 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from PegaPegII (hydra.fletchermoorland.co.uk [78.33.209.59]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n61EfLb2012535; Wed, 1 Jul 2009 14:41:21 GMT (envelope-from ken@mthelicon.com) Message-ID: From: "Pegasus Mc Cleaft" To: "Kamigishi Rei" References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <4A4B724D.10506@haruhiism.net> In-Reply-To: <4A4B724D.10506@haruhiism.net> Date: Wed, 1 Jul 2009 15:41:19 +0100 Organization: Feathers MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18005 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18005 X-Antivirus: avast! (VPS 090630-0, 30/06/2009), Outbound message X-Antivirus-Status: Clean Cc: current@freebsd.org Subject: Re: Has anyone been able to actually boot the AMD64 kernel after r194958? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pegasus Mc Cleaft List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:41:23 -0000 > Pegasus Mc Cleaft wrote: >> I was wondering.. Has anyone actually been able to boot a kernel >> after r194958? On 2 different machine (simmilar archecture) the system >> will kernel-trap right after attemping to mount the ZFS filesystems. I >> dont know if it is ZFS related or not as I am not able to get a core. It >> complains that no dump device has been defined and then locks up... >> If there is a way that I can provide more information, please let me >> know how and I will post it. > > If your swap space is in zpool, you won't be able to dump. > Does the system boot in single user mode? Without starting /etc/rc.d/zfs I > mean. I use ZFS Boot with a three-way mirror (A seperate GPT slice on each of the drives) and the swap-space is spanned across 3 other slices (one on each of the boot drives). I think its giving me that error because it never gets far enough in the boot to swapon those slices before it panics. Another symptom of this is that it dosent get far enough to clear the nextboot flag, so when it does go boom, I have to manually tell it to boot from the working kernel (r194958). I'll try in a few hours to see if it will allow me to go into single user and report back to everyone. I'm not infront of the console at the moment (I need to get a IP-KVM) :> Peg From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 14:46:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEA24106566C for ; Wed, 1 Jul 2009 14:46:03 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 96D5F8FC12 for ; Wed, 1 Jul 2009 14:46:03 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.10] (datacenter.telecombusinessconsulting.net [77.221.137.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 2565078FA9; Wed, 1 Jul 2009 18:46:02 +0400 (MSD) Message-ID: <4A4B76C2.90406@haruhiism.net> Date: Wed, 01 Jul 2009 18:46:26 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Pegasus Mc Cleaft References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <4A4B724D.10506@haruhiism.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Has anyone been able to actually boot the AMD64 kernel after r194958? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 14:46:04 -0000 Pegasus Mc Cleaft wrote: > I use ZFS Boot with a three-way mirror (A seperate GPT slice on > each of the drives) and the swap-space is spanned across 3 other > slices (one on each of the boot drives). I think its giving me that > error because it never gets far enough in the boot to swapon those > slices before it panics. Another symptom of this is that it dosent get > far enough to clear the nextboot flag, so when it does go boom, I have > to manually tell it to boot from the working kernel (r194958). Well, then you won't be able to get a core, because by the time doadump starts the filesystem layer is already dead. The kernel just won't be able to save the dump to something as complicated as a 3-disk-span swap space - it can't even dump to a gmirror-based swapspace properly, you know ;) And if you're using ZFS boot, you probably have ZFS built into kernel so I'm not sure if booting without loading zfs.ko is possible as it's already inside... -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 15:42:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00C8C1065672 for ; Wed, 1 Jul 2009 15:42:31 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by mx1.freebsd.org (Postfix) with ESMTP id C6D388FC0A for ; Wed, 1 Jul 2009 15:42:30 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by wf-out-1314.google.com with SMTP id 24so400389wfg.7 for ; Wed, 01 Jul 2009 08:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=qza8LfQtXaj5p7xYaRbhh56wVzq2YM31rlMV4NdTFH8=; b=et2/iu3Qv9xGxYDQgOeXn/xmFXR+vnm3bZvYF406xFp+9jio4lV/dK7CBzZkA3m6jz A8zfs1WJAufPpZpUoN1ex/kXL5C/MwU9/dZ9yT9mPCcv+HpMywZKjzsjmSmHcYd2PUwg xg4LkOBTL6NuP2W5/Dk0kHsSPWXQEm6/OY/1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=mK5KYwrdv3HYl7xN/1B2D1s2VhB1Y2eyvDN0Hb82BG7o1JQNU+F9dryKvnUsfkfACv nXI4Tm8OXeZrtd5bxG3vV65EsY5RyVTlv9OJtZLxklFlGk0B9ASNHgh3TdN9cpikdVb0 Jp0Ylw1KA5J6BIj/sFGdbWs2NfP0ZpRIacX7o= MIME-Version: 1.0 Received: by 10.142.173.6 with SMTP id v6mr1091728wfe.233.1246462950439; Wed, 01 Jul 2009 08:42:30 -0700 (PDT) In-Reply-To: <4A4B2EE6.2080501@FreeBSD.org> References: <1246206181.00132972.1246192801@10.7.7.3> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> <4A48D136.3050309@haruhiism.net> <4A48D551.5090509@FreeBSD.org> <4A49E7A3.70509@haruhiism.net> <4A49EA94.3070109@FreeBSD.org> <4A4B2A90.8090300@jrv.org> <4A4B2EE6.2080501@FreeBSD.org> Date: Wed, 1 Jul 2009 17:42:30 +0200 Message-ID: <90a5caac0907010842r3f314186n366c2417f979e767@mail.gmail.com> From: Lucius Windschuh To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:42:31 -0000 I'd like to notice that the patch seems to break cdrecord -scanbus (freshly rebuilt from the ports): $ cdrecord -scanbus Cdrecord-Clone 2.01 (i386-unknown-freebsd8.0) Copyright (C) 1995-2004 J=F6rg Schilling cdrecord: Argument list too long. CAMIOCOMMAND ioctl failed. Cannot open SCSI driver. cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are r= oot. cdrecord: For possible transport specifiers try 'cdrecord dev=3Dhelp'. Regards Lucius From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 15:53:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2317C1065688 for ; Wed, 1 Jul 2009 15:53:54 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id 8BCC58FC14 for ; Wed, 1 Jul 2009 15:53:53 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from [192.168.0.154] (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.3/8.14.2) with ESMTP id n61FOnER065410; Wed, 1 Jul 2009 16:24:49 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4A4B7FC1.5020709@fletchermoorland.co.uk> Date: Wed, 01 Jul 2009 16:24:49 +0100 From: Paul Wootton User-Agent: Thunderbird 2.0.0.21 (X11/20090504) MIME-Version: 1.0 To: current@freebsd.org References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <4A4B724D.10506@haruhiism.net> <4A4B76C2.90406@haruhiism.net> In-Reply-To: <4A4B76C2.90406@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.64 on 192.168.0.1 Cc: Pegasus Mc Cleaft , Kamigishi Rei Subject: Re: Has anyone been able to actually boot the AMD64 kernel after r194958? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 15:53:54 -0000 Kamigishi Rei wrote: > Pegasus Mc Cleaft wrote: >> I use ZFS Boot with a three-way mirror (A seperate GPT slice on >> each of the drives) and the swap-space is spanned across 3 other >> slices (one on each of the boot drives). I think its giving me that >> error because it never gets far enough in the boot to swapon those >> slices before it panics. Another symptom of this is that it dosent >> get far enough to clear the nextboot flag, so when it does go boom, I >> have to manually tell it to boot from the working kernel (r194958). > Well, then you won't be able to get a core, because by the time > doadump starts the filesystem layer is already dead. The kernel just > won't be able to save the dump to something as complicated as a > 3-disk-span swap space - it can't even dump to a gmirror-based > swapspace properly, you know ;) > > And if you're using ZFS boot, you probably have ZFS built into kernel > so I'm not sure if booting without loading zfs.ko is possible as it's > already inside... > > -- > Kamigishi Rei > KREI-RIPE I also have the same issue and have not been able to boot any kernels from recent builds. I know that r194437 works for me I am also using ZFS on an intel Core2Quad If I boot a recent kernel I get (copied on to paper and type retyped here) ------------------ Jul 1 15:55:30 demophon kernel: pcm3: at cad 2 nid 1 on hdac1 Jul 1 15:55:30 demophon kernel: SMP: AP CPU #1 Launched! Jul 1 15:55:30 demophon kernel: SMP: AP CPU #3 Launched! Jul 1 15:55:30 demophon kernel: SMP: AP CPU #2 Launched! Jul 1 15:55:30 demophon kernel: hwpmc: TSC/1/ Fatal trap 30: reserved (unknown) fault while in kernel mode cpuid = 3; apic id = 03 instruction pointer = 0x20:0xffffffff808a547f stack pointer = 0x28:0xffffffff810618d0 frame pointer = 2x28:0xffffffff810618f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interput enable, IOPL=0 current process = 0 (swapper) trap number = 30 panic: reserved (unkown) fault cpuid 3 Uptime: 1s ------------------ Every time I try a kernel it always bombs out with cpuid 3 but the hwpmc line can be anywhere between "hwpmc: TSC/1" and "hwpmc: TSC/1/64/0x20 IAP/2/40/0x" I cant even start in to single user mode (get the same error as above.) If I try to boot with ACPI disabled I get --------------------- Trying to mount root from zfs:zfsroot/root ROOT MOUNT ERROR: If you have invalid mount options, reboot, and try the following from the loader prompt: set vfs.root.mountfrom.options=rw and then remove the invalid options from /etc/fstab Loader varaibles vfs.root.mountfrom="zfs:zfsroot/zfsroot" vfs.root.mountfrom.options= Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input mountroot> -------------------- Paul ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 16:37:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67E89106566C for ; Wed, 1 Jul 2009 16:37:43 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id F264C8FC0A for ; Wed, 1 Jul 2009 16:37:42 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,325,1243807200"; d="scan'208";a="217559638" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 01 Jul 2009 18:37:41 +0200 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 3D11D1B0764; Wed, 1 Jul 2009 18:37:41 +0200 (CEST) Date: Wed, 01 Jul 2009 18:37:40 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: building device drivers for FreeBSD 7.2+ /AMD64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 16:37:43 -0000 have you tried this article? http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/driverbasics.html i don't think it's amd64 specific though. cheers. alex From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 16:56:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA2A41065672 for ; Wed, 1 Jul 2009 16:56:56 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id B1A4E8FC14 for ; Wed, 1 Jul 2009 16:56:56 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.2/8.14.1) with ESMTP id n61Guubo012663 for ; Wed, 1 Jul 2009 09:56:56 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.2/8.13.4/Submit) id n61GuuEZ012662; Wed, 1 Jul 2009 09:56:56 -0700 (PDT) Date: Wed, 1 Jul 2009 09:56:56 -0700 (PDT) From: Matthew Dillon Message-Id: <200907011656.n61GuuEZ012662@apollo.backplane.com> To: freebsd-current@freebsd.org References: <1246206181.00132972.1246192801@10.7.7.3> <1246206186.00132982.1246194002@10.7.7.3> <1246209783.00133001.1246197001@10.7.7.3> <1246260183.00133237.1246247402@10.7.7.3> <4A48798A.5070604@FreeBSD.org> <4A487BF7.8060103@haruhiism.net> <4A48922D.5090507@FreeBSD.org> <4A48C0BC.3030104@haruhiism.net> <4A48CD19.8080606@FreeBSD.org> <4A48D136.3050309@haruhiism.net> <4A48D551.5090509@FreeBSD.org> <4A49E7A3.70509@haruhiism.net> <4A49EA94.3070109@FreeBSD.org> <4A4B2A90.8090300@jrv.org> <4A4B2EE6.2080501@FreeBSD.org> Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 16:56:57 -0000 :James R. Van Artsdalen wrote: :> Has anyone found any PCI-X or PCI cards that do AHCI? Or a PCI-Express, :> PCI-X or PCI card that supports AHCI & FIS-based switching for port :> multipliers? :> ... : :I still haven't found any AHCI card with FBS support. Ideas welcome. : :I am working on driver for SiI3124/3132. I haven't tested yet how fast :they really are (3132 is quite cheap), but they declare PM with FBS :support. First one is 4-port PCI-X, second - 2-port PCIe. : :-- :Alexander Motin I haven't had much luck on the AHCI front either re: FBSS. No cards, and very few motherboards have the FBSS capability. FBSS is a very new feature for AHCI, so the expectation is that it will work its way into more chipsets over time. It should become common in less then a year. There is huge demand for the feature. Alexander and I have been discussing the Sili chip. The linux folks found one very serious hardware bug and there are multiple other issues when working with targets behind a PM. Fortunately the worst hardware bug does seem to have workarounds which do not screw up performance too badly. The bug is related to reading the LRAM (that's right, just doing a simple memory read of a mapped LRAM location(!)(!)) on the chip while any command is active produces corruption. It is possible to operate the Sili chip with NCQ+FBSS (The chip does the FBSS internally). The chip seems to be able to handle upwards of 30,000 transactions per second but the main performance limitation appears to be physical port bandwidth limitations. Each physical port on the 3132 seems to be limited to 120-150 MBytes/sec (at least on the 3132), even if the phy probes at 3 Gbit/sec. And, of course, the 3132 uses only one PCI-E lane and that's something like 3 GBits/sec. I successfully ran a test on a 10-Terrabyte PM array with 5 2TB disks over 2 days of continuous reading and writing with no errors so the Sili chip does work once the issues are worked out, but with 5 disks going at once bandwidth was limited to 20-30 MB/sec on each one due to the above mentioned limitations. The SAS chipsets can probably do a lot better. The advantage of the Sili chipsets is that they are ridiculously cheap. So cheap that many of the PM enclosures sold on the market also come with a freebie PCI-e 3132 card to stuff into your computer. There are other issues with the Sili chipset and PM's related to hot insertions and firmware bugs... it isn't a walk in the park, but it seems to be possible to work around them and get something reasonably robust out of the boards. Also, error handling requires command exclusivity (due to the LRAM bug) so a failing target behind the PM can potentially cause problems for the entire enclosure. -Matt From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 17:27:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6578710656B3; Wed, 1 Jul 2009 17:27:24 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id DA9D88FC1B; Wed, 1 Jul 2009 17:27:23 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAY5S0qDaFvG/2dsb2JhbADRF4QRBQ X-IronPort-AV: E=Sophos;i="4.42,326,1243828800"; d="scan'208";a="39941217" Received: from amazon.cs.uoguelph.ca ([131.104.91.198]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 01 Jul 2009 13:27:23 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 0E772210159; Wed, 1 Jul 2009 13:27:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at amazon.cs.uoguelph.ca Received: from amazon.cs.uoguelph.ca ([127.0.0.1]) by localhost (amazon.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pNiV58pMoYq; Wed, 1 Jul 2009 13:27:22 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by amazon.cs.uoguelph.ca (Postfix) with ESMTP id 3B1B42100E1; Wed, 1 Jul 2009 13:27:22 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n61HTiq18898; Wed, 1 Jul 2009 13:29:44 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Wed, 1 Jul 2009 13:29:44 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "Julian H. Stacey" In-Reply-To: <200907010048.n610mPem058027@fire.js.berklix.net> Message-ID: References: <200907010048.n610mPem058027@fire.js.berklix.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kirk McKusick , Attilio Rao , freebsd-current@freebsd.org, freebsd-fs@freebsd.org Subject: Re: umount -f implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 17:27:25 -0000 On Wed, 1 Jul 2009, Julian H. Stacey wrote: > Kirk McKusick wrote: >> forced unmounts. The gentle force (-f) and the brute force (-F) >> unmount. > > -F Would also be nice for devd.conf detach, for when people > forget & pull a USB stick without unmounting first. > Better a corrupt stick than a crashed OS. > All I'll add is, for the experimental nfs client, if both semantics are desired (and, imho they are), there will need to be separate flags to indicate whether or not to terminate RPCs in progress. So, it seems that there is interest in a separate "umount -F" to handle the case of failed storage (disk subsystem, NAS server down,...). Is there anyone who is opposed to my pursuing this after FreeBSD-CURRENT branches from 8? (I can do the experimental nfs client + some testing. Hopefully others can help with the generic VFS issues and other file systems.) rick, who obviously doesn't have as good a memory as Kirk's:-) ps: Unfortunately Solaris uses "-F" for something entirely different, so feel free to suggest other flag values if you think that is a concern. From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 17:27:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EAD4D106566C for ; Wed, 1 Jul 2009 17:27:24 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id A442C8FC29 for ; Wed, 1 Jul 2009 17:27:24 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (11008@roadkill.tharned.org [75.145.12.185]) (authenticated bits=0) by roadkill.tharned.org (8.14.3/8.14.3) with ESMTP id n61GvLoH075598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Jul 2009 11:57:28 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) Date: Wed, 1 Jul 2009 11:57:20 -0500 (CDT) From: Greg Rivers To: freebsd-current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (roadkill.tharned.org [75.145.12.185]); Wed, 01 Jul 2009 11:57:28 -0500 (CDT) Subject: Panic during shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 17:27:26 -0000 I'm running -CURRENT on an Acer One netbook. Every kernel I've built since last Sunday panics on shutdown (see below). The panic occurs whenever shutdown(8) is executed, even if only to drop to single-user. halt(8) does not trigger the panic. I have a core dump and kernel with debugging symbols available if needed. -- Greg Rivers blue.tharned.org dumped core - see /var/crash/vmcore.0 Wed Jul 1 09:28:41 CDT 2009 FreeBSD blue.tharned.org 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Wed Jul 1 00:53:42 CDT 2009 root@blue.tharned.org:/usr/obj/usr/src/sys/SMALL-SMP i386 panic: swap_reserved < decr GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: <118>. <118>. <118>Jul 1 09:25:35 blue syslogd: exiting on signal 15 panic: swap_reserved < decr cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(c06bef5d,e649db30,c04fe90f,c06d6322,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c06d6322,0,c06cdb69,e649db3c,0,...) at kdb_backtrace+0x29 panic(c06cdb69,c065575e,c11ac1b8,e649db6c,c064e52e,...) at panic+0x114 swap_release_by_uid(f5000,0,c3d10340,e649db78,c0652b30,...) at swap_release_by_uid+0x94 vm_object_destroy(c4300000,c06cf12d,c06442e5,c3d2f280,bfbe0000,bfc00000) at vm_object_destroy+0xd0 vm_object_terminate(c4300000,c4176708,c3d2f1d0,e649dbc8,c064314a,...) at vm_object_terminate+0x225 vm_object_deallocate(c4300000,0,0,c3d2f1d0,0,...) at vm_object_deallocate+0x6cf _vm_map_unlock(c3d2f1d0,0,0,1,c3d2f1d0,...) at _vm_map_unlock+0x74 vm_map_remove(c3d2f1d0,0,bfc00000,c3effc40,0,...) at vm_map_remove+0x69 vmspace_exit(c417bd80,c41792a8,c41792a8,0,e649dc80,...) at vmspace_exit+0xbc exit1(c417bd80,0,e649dd2c,c068d2ee,c417bd80,...) at exit1+0x61a clear_entries(c417bd80,e649dcf8,4,c,e649dd2c,...) at clear_entries syscall(e649dd38) at syscall+0x2ff Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x8832b27f, esp = 0xbfbfedac, ebp = 0xbfbfedb8 --- Uptime: 1m4s Physical memory: 1003 MB Dumping 58 MB: 43 27 11 [snip] #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc04fe634 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:419 #2 0xc04fe94b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:575 #3 0xc063262d in swap_release_by_uid (decr=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/swap_pager.c:267 #4 0xc064a60b in vm_object_destroy (object=0xc4300000) at /usr/src/sys/vm/vm_object.c:622 #5 0xc064cb76 in vm_object_terminate (object=0xc4300000) at /usr/src/sys/vm/vm_object.c:715 #6 0xc064d24c in vm_object_deallocate (object=0xc4300000) at /usr/src/sys/vm/vm_object.c:592 #7 0xc0644059 in _vm_map_unlock (map=0xc3d2f1d0, file=0x0, line=0) at /usr/src/sys/vm/vm_map.c:480 #8 0xc0644586 in vm_map_remove (map=0xc3d2f1d0, start=0, end=Variable "end" is not available. ) at /usr/src/sys/vm/vm_map.c:2765 #9 0xc0647548 in vmspace_exit (td=0xc417bd80) at /usr/src/sys/vm/vm_map.c:329 #10 0xc04d3c1c in exit1 (td=0xc417bd80, rv=0) at /usr/src/sys/kern/kern_exit.c:299 #11 0xc04d4c10 in sys_exit (td=Could not find the frame base for "sys_exit". ) at /usr/src/sys/kern/kern_exit.c:110 #12 0xc068d2ee in syscall (frame=0xe649dd38) at /usr/src/sys/i386/i386/trap.c:1073 #13 0xc0672790 in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:261 #14 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) [snip] From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 18:01:27 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0C4F1065675 for ; Wed, 1 Jul 2009 18:01:27 +0000 (UTC) (envelope-from mjs@rakupottery.org.uk) Received: from lon1-post-1.mail.demon.net (lon1-post-1.mail.demon.net [195.173.77.148]) by mx1.freebsd.org (Postfix) with ESMTP id 688D28FC21 for ; Wed, 1 Jul 2009 18:01:27 +0000 (UTC) (envelope-from mjs@rakupottery.org.uk) Received: from rakuman.demon.co.uk ([80.177.154.53] helo=rakuba.rakupottery.org.uk) by lon1-post-1.mail.demon.net with esmtp (Exim 4.69) id 1MM47a-0001xy-XR for freebsd-current@FreeBSD.org; Wed, 01 Jul 2009 18:01:26 +0000 Message-ID: <4A4BA476.1020301@rakupottery.org.uk> Date: Wed, 01 Jul 2009 19:01:26 +0100 From: Martin Smith User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: freebsd-current@FreeBSD.org References: <20090611194557.GC98175@bsdcrew.de> <4A473976.6030807@rakupottery.org.uk> <20090629131534.2d764f72@ernst.jennejohn.org> In-Reply-To: <20090629131534.2d764f72@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: [Call For Testing] VirtualBox for FreeBSD! take 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 18:01:28 -0000 Gary Jennejohn wrote: > On Sun, 28 Jun 2009 10:35:50 +0100 > Martin Smith wrote: > >> Martin Wilke wrote: > [snip what miwi wrote] >> Well ,I have got it up and running on a stable of 26 June, managed to >> set up a vdi, no problem, but it will not see the cd drive. >> It (vbox) says the cd drive is always secondary master, but I only have >> one ata channel so it is primary master. The dropdown list just does >> not drop down. >> Is there a workaround for this, or have I missed something stupid? >> > > I saw this too and had to start hald in order for VirtualBox to see the > real DVD/CD drives, even though I'd compiled VirtualBox without hald > support. > > BTW I'm running -current, but the problem probably has the same solution > under -stable. Well hald is already running, no problem there, I also have a current box which I am just bringing up to date, I will try it on that later in the week. Cheers -- Martin From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 18:06:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1373106564A for ; Wed, 1 Jul 2009 18:06:13 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email1.allantgroup.com (email1.emsphone.com [199.67.51.115]) by mx1.freebsd.org (Postfix) with ESMTP id 57D378FC18 for ; Wed, 1 Jul 2009 18:06:13 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email1.allantgroup.com (8.14.0/8.14.0) with ESMTP id n61I64rG017495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Jul 2009 13:06:04 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.3/8.14.3) with ESMTP id n61I64XW061137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 1 Jul 2009 13:06:04 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.3/8.14.3/Submit) id n61I62FC061135; Wed, 1 Jul 2009 13:06:02 -0500 (CDT) (envelope-from dan) Date: Wed, 1 Jul 2009 13:06:02 -0500 From: Dan Nelson To: Robert Watson Message-ID: <20090701180602.GA36496@dan.emsphone.com> References: <1246316092.3981.11.camel@Lappy> <87hbxxp5ot.fsf@tabernacle.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 7.2-STABLE User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: ClamAV version 0.94.1, clamav-milter version 0.94.1 on email1.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (email1.allantgroup.com [199.67.51.78]); Wed, 01 Jul 2009 13:06:04 -0500 (CDT) X-Scanned-By: MIMEDefang 2.45 Cc: freebsd-current@freebsd.org, Julian Stecklina Subject: Re: 8-CURRENT Firewire X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 18:06:14 -0000 In the last episode (Jul 01), Robert Watson said: > On Wed, 1 Jul 2009, Julian Stecklina wrote: > > I have an AMD 780G board with onboard Firewire controller. 8-CURRENT hangs > > at boot with: > > > > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > > ... > > > > If I disable the Firewire controller in the BIOS it boots fine. What is a > > good way to debug this? > > I've seen similar reports of this on 7.x; Richard Clayton has a box that > has done this since at least 7.1, and it's one of the reasons I added the > debugging output above :-). Unfortunately, it's not in an easy position > to debug on that box. I have always seen this behaviour on bootup on 7.x, on a Dell Studio with an onboard port, or varying other Dells with add-on PCI cards. Loading the module after bootup works fine, but then you don't get to boot off a FW device :) -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 18:30:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FD9E1065676; Wed, 1 Jul 2009 18:30:57 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 2B17B8FC20; Wed, 1 Jul 2009 18:30:56 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: by qw-out-2122.google.com with SMTP id 5so471305qwd.7 for ; Wed, 01 Jul 2009 11:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cLVWpjw/Yt4qeFV+JWa6e4miarUyu363mt5kEiP6004=; b=q2JJQAZLpHPhkZ+WBZ/CWmdQddWZ3XW29nm+zBP9cEPl2sylEN2LdpqQUOXUBo1p5u 90P3/5dLgDD9cxzmgH0PZgCVyFVbRdnPVvUDjVw/4SfDasDMDLi0P5gEwoFDLFdIG07D 9xHCVW3QRujXsYnYMdjTD/EAKQgDjIrOs+vsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ieTrSP3bQnC2WobEBavN+6CIkn233mpoP/vBegEzbSbvBLylQ/4iBY4O30Jb8aV8zp pva7Y0kqeoDBbq/gzUIqZDA+gl4xlG+/e6hAs/1ssTbbIwrYSG6mFWhX+Wk5l8F6coi8 9UfxNljykkVPLja9LNIf2jkQBxKBnIVmJqQIE= MIME-Version: 1.0 Received: by 10.229.97.194 with SMTP id m2mr3398199qcn.21.1246473056407; Wed, 01 Jul 2009 11:30:56 -0700 (PDT) In-Reply-To: <747dc8f30906290434y77f11bf1i5911ea1efe29fab5@mail.gmail.com> References: <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <747dc8f30906290434y77f11bf1i5911ea1efe29fab5@mail.gmail.com> Date: Wed, 1 Jul 2009 13:30:56 -0500 Message-ID: <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> From: "Sam Fourman Jr." To: Renato Botelho Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Boris Samorodov , freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Juergen Lock , "Sean C. Farley" Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 18:30:58 -0000 On Mon, Jun 29, 2009 at 6:34 AM, Renato Botelho wrote: > On Sun, Jun 28, 2009 at 11:10 AM, Juergen Lock wr= ote: >> On Sun, Jun 28, 2009 at 04:40:20PM +0400, Boris Samorodov wrote: >>> Juergen Lock writes: >>> >>> > =A0New patch and shar: >>> >>> No more comments from me, thanks! >> >> Ok. =A0Has anyone tested this yet tho? =A0(Besides me in a vm... :) > > Working fine here. 8.0-current i386 > I saw linux-f10-flashplugin10 hit the ports tree so I decided to try it I have a recent FreeBSD CURRENT snapshot installed uname -a FreeBSD 8.0-HEAD-20090601-JPSNAP FreeBSD 8.0-HEAD-20090601-JPSNAP #0: Mon Jun 1 02:48:06 UTC 2009 root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386/usr/src/sys/GENERIC i386 I have linux-f10 installed pkg_info | grep linux linux_base-f10-10 Base set of packages needed in Linux mode for i386/amd6= 4 (L here is the error I get, is there some wiki available that details the steps it takes to test flash10? # cd /usr/ports/www/linux-f10-flashplugin10/ # make install =3D=3D=3D> linux-flashplugin-10.0r22 bsd.linux-apps.mk test failed: The component libidn is not defined for LINUX_DIST_SUFFIX=3D-f10 (the corresponding variable libidn_f10_FILE is not defined). *** Error code 1 Stop in /usr/ports/www/linux-f10-flashplugin10. most everything else is set to defaults Sam Fourman Jr. From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 19:02:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 098A71065674 for ; Wed, 1 Jul 2009 19:02:35 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by mx1.freebsd.org (Postfix) with ESMTP id 7E56A8FC14 for ; Wed, 1 Jul 2009 19:02:34 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by ewy9 with SMTP id 9so1260905ewy.43 for ; Wed, 01 Jul 2009 12:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; bh=VBKeely++F39GA+FMOI7zCEM8WjUx552QgYsbrywAS8=; b=KA48KV5WigI115pcX78io1MerKmHLUMj1126/aiR8st72d/9SUU+4x5IwG2cSsp5p4 v7FNe3HseumMpjuxh8qgPcEPfC9r9yK+916RwbnqjtdCJRPmeVWScJ/ggruceDJuwQw4 lLfWGbfmp6whbeb+UgUBS7Q+Dsc/GPMr+hnWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:subject:from:to:user-agent:mime-version :content-type:content-transfer-encoding:x-priority:importance; b=KcjHMMsvCtF+6zMy1e+Mj5y6BVbwXJ08jlUiYS/py8+mpi/HE2GmipQRgrEJAKfSZp FaqktY4KVLoPmgzUwlh4PcrUFLjXEpIzcmjAV+kjevfnc/w7leC74MhC/B+5EbDK6Ndv 4h/WGF7HIHIolidoAl68CzA8r1jRrIsgCEXBw= Received: by 10.216.70.135 with SMTP id p7mr3040925wed.138.1246474953322; Wed, 01 Jul 2009 12:02:33 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.105.194]) by mx.google.com with ESMTPS id j8sm3570840gvb.6.2009.07.01.12.02.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Jul 2009 12:02:32 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 48BB9B8083; Wed, 1 Jul 2009 16:02:25 -0300 (BRT) Received: from 189.92.197.238 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Wed, 1 Jul 2009 16:02:25 -0300 (BRT) Message-ID: <3730d4eb75f62cac45c8113ef595c2f5.squirrel@cygnus.homeunix.com> Date: Wed, 1 Jul 2009 16:02:25 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: problems building current from today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:02:35 -0000 hail, I'm trying to build tinybsd as of today, and I get this: cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/kern/sysv_msg.c /usr/src/sys/kern/sysv_msg.c:1263: error: invalid application of 'sizeof' to incomplete type 'struct freebsd7_msgctl_args' /usr/src/sys/kern/sysv_msg.c:1263: error: 'freebsd7_msgctl' undeclared here (not in a function) cc1: warnings being treated as errors /usr/src/sys/kern/sysv_msg.c:1309: warning: function declaration isn't a prototype /usr/src/sys/kern/sysv_msg.c: In function 'freebsd7_msgctl': /usr/src/sys/kern/sysv_msg.c:1318: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1318: error: request for member 'cmd' in something not a structure or union /usr/src/sys/kern/sysv_msg.c:1318: warning: comparison between pointer and integer /usr/src/sys/kern/sysv_msg.c:1319: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1319: error: request for member 'buf' in something not a structure or union /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'msqid' in something not a structure or union /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'cmd' in something not a structure or union /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 2 of 'kern_msgctl' makes integer from pointer without a cast /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 3 of 'kern_msgctl' makes integer from pointer without a cast /usr/src/sys/kern/sysv_msg.c:1337: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1337: error: request for member 'cmd' in something not a structure or union /usr/src/sys/kern/sysv_msg.c:1337: warning: comparison between pointer and integer /usr/src/sys/kern/sysv_msg.c:1350: error: dereferencing pointer to incomplete type /usr/src/sys/kern/sysv_msg.c:1350: error: request for member 'buf' in something not a structure or union *** Error code 1 Stop in /usr/obj/usr/src/sys/TINYBSD. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. tinybsd# I read about some commits breaking current recently, but also saw saying was fixed. if any hints, thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 19:04:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7236F1065672 for ; Wed, 1 Jul 2009 19:04:08 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.freebsd.org (Postfix) with ESMTP id EF85A8FC08 for ; Wed, 1 Jul 2009 19:04:07 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-185-198.belrs3.nsw.optusnet.com.au [122.106.185.198]) by mail18.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n61J44dk019912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 05:04:05 +1000 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id n61J44Ab045051; Thu, 2 Jul 2009 05:04:04 +1000 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id n61J44JK045046; Thu, 2 Jul 2009 05:04:04 +1000 (EST) (envelope-from peter) Date: Thu, 2 Jul 2009 05:04:04 +1000 From: Peter Jeremy To: "Sam Fourman Jr." Message-ID: <20090701190404.GA59698@server.vk2pj.dyndns.org> References: <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <747dc8f30906290434y77f11bf1i5911ea1efe29fab5@mail.gmail.com> <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DocE+STaALJfprDB" Content-Disposition: inline In-Reply-To: <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:04:08 -0000 --DocE+STaALJfprDB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2009-Jul-01 13:30:56 -0500, "Sam Fourman Jr." wrote: >I saw linux-f10-flashplugin10 hit the ports tree so I decided to try it =2E.. >=3D=3D=3D> linux-flashplugin-10.0r22 bsd.linux-apps.mk test failed: The >component libidn is not defined for LINUX_DIST_SUFFIX=3D-f10 (the >corresponding variable libidn_f10_FILE is not defined). >*** Error code 1 linux-f10-flashplugin10 has been repo-copied into place but the infrastructure to support it is not yet in place, hence you still need the patches mentioned earlier in this thread. --=20 Peter Jeremy --DocE+STaALJfprDB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpLsyQACgkQ/opHv/APuIcqwwCdHHmWFt49JN2e0JHh7YT5Lmw6 9CIAnRUkSK7xksMd3fC6ivuaOLkqK09f =RtAf -----END PGP SIGNATURE----- --DocE+STaALJfprDB-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 16:48:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D137106564A for ; Wed, 1 Jul 2009 16:48:18 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.freebsd.org (Postfix) with ESMTP id 895848FC08 for ; Wed, 1 Jul 2009 16:48:17 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.50) id 1MM2XU-0000aU-Hj for current@freebsd.org; Wed, 01 Jul 2009 23:20:04 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id n61GLEjC040947 for ; Wed, 1 Jul 2009 23:21:14 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id n61GL9qr040928 for current@freebsd.org; Wed, 1 Jul 2009 23:21:09 +0700 (NOVST) (envelope-from danfe) Date: Wed, 1 Jul 2009 23:21:08 +0700 From: Alexey Dokuchaev To: current@freebsd.org Message-ID: <20090701162108.GA33681@regency.nsu.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 01 Jul 2009 19:05:50 +0000 Cc: Subject: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 16:48:18 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello there, I've started to observe the following rather annoying panic if I boot with if_sf loaded (via loader.conf) and having sf0 configured via DHCP on recent -CURRENT. If I comment out driver from loader.conf and load it manually (via kldload(8)) after system boots, it loads and gets configured just fine. Any clues here? Attached is relevant dmesg + DDB trace (debug kernel with WITNESS). I'm happy to provide any additional information (that is, ps/show uma/malloc, whatever). Thanks. ./danfe --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sf_panic.trace" sf0: link state changed to UP Starting Network: lo0 sf0. sf1: link state changed to DOWN Kernel page fault with the following non-sleepable locks held: exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ sys/modules/sf/../../dev/sf/if_sf.c:1971 KDB: stack backtrace: db_trace_self_wrapper(c0683396,d655e808,c05188c5,c0fd7bc2,7b3,...) at db_trace_s elf_wrapper+0x26 kdb_backtrace(c0fd7bc2,7b3,ffffffff,c0eb2914,d655e840,...) at kdb_backtrace+0x29 _witness_debugger(c0685907,d655e854,4,1,0,...) at _witness_debugger+0x25 witness_warn(5,0,c06a5f7f,d655e890,c3537d48,...) at witness_warn+0x1fd trap(d655e8e0) at trap+0x192 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc062cec2, esp = 0xd655e920, ebp = 0xd655e954 --- _bus_dmamap_sync(c3551c80,c3573000,2,90a,6000,...) at _bus_dmamap_sync+0xa2 sf_stop(c3551d80,4,c0fd7bc2,7c1,c3556c70,...) at sf_stop+0x130 sf_init_locked(c356c584,0,c0fd7bc2,7b3,c36e3c00,...) at sf_init_locked+0x50 sf_init(c356b000,c356b000,0,0,c36e3cbb,...) at sf_init+0x3c ether_ioctl(c3554c00,8020690c,c36e3c00,d655ea38,456bc5b,...) at ether_ioctl+0x41 in_ifinit(0,c36e3c00,1aa,1a6,c0eb2910,...) at in_ifinit+0x2a6 in_control(c377bce0,8040691a,c35a26c0,c3554c00,c36b9720,...) at in_control+0xd7b ifioctl(c377bce0,8040691a,c35a26c0,c36b9720,4,...) at ifioctl+0x157d soo_ioctl(c36a57e0,8040691a,c35a26c0,c34a9b00,c36b9720,...) at soo_ioctl+0x3d2 kern_ioctl(c36b9720,4,8040691a,c35a26c0,6b9884,...) at kern_ioctl+0x1dd ioctl(c36b9720,d655ecf8,419,c06a5e55,c36b9720,...) at ioctl+0x134 syscall(d655ed38) at syscall+0x323 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281bf8a3, esp = 0xbfbfe5bc, ebp = 0xbfbfe5f8 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x400000c fault code = supervisor read, page not present instruction pointer = 0x20:0xc062cec2 stack pointer = 0x28:0xd655e920 frame pointer = 0x28:0xd655e954 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 453 (ifconfig) [thread pid 453 tid 100040 ] Stopped at _bus_dmamap_sync+0xa2: movl 0xc(%ebx),%eax db> show pcpu cpuid = 0 dynamic pcpu = 0xd3c597 curthread = 0xc36b9720: pid 453 "ifconfig" curpcb = 0xd655ed90 fpcurthread = none idlethread = 0xc34adbe0: pid 10 "idle" APIC ID = 0 currentldt = 0x50 spin locks held: db> show allpcpu Current CPU: 0 cpuid = 0 dynamic pcpu = 0xd3c597 curthread = 0xc36b9720: pid 453 "ifconfig" curpcb = 0xd655ed90 fpcurthread = none idlethread = 0xc34adbe0: pid 10 "idle" APIC ID = 0 currentldt = 0x50 spin locks held: db> show locks exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ sys/modules/sf/../../dev/sf/if_sf.c:1971 db> show alllocks Process 453 (ifconfig) thread 0xc36b9720 (100040) exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ sys/modules/sf/../../dev/sf/if_sf.c:1971 --azLHFNyN32YCQGCU-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 19:08:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C44AE1065672 for ; Wed, 1 Jul 2009 19:08:21 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out2.uni-muenster.de (ZIVM-OUT2.UNI-MUENSTER.DE [128.176.192.9]) by mx1.freebsd.org (Postfix) with ESMTP id 57AA88FC0C for ; Wed, 1 Jul 2009 19:08:20 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,327,1243807200"; d="scan'208";a="217568932" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER04.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay2.uni-muenster.de with ESMTP; 01 Jul 2009 21:08:19 +0200 Received: by ZIVMAILUSER04.UNI-MUENSTER.DE (Postfix, from userid 149459) id A79371B002E; Wed, 1 Jul 2009 21:08:19 +0200 (CEST) Date: Wed, 01 Jul 2009 21:08:19 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Re: nspluginwrapper patch for testing (was: Re: flash10 vs f10) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:08:22 -0000 the latest patch to get rid of the ulimit warning doesn't suppress the warning since it get's output to stderr and not to stdout. replacing it with "ulimit -s 32768 2 > /dev/null 2>&1" should work. cheers. From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 19:22:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D745F106564A for ; Wed, 1 Jul 2009 19:22:00 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 5668E8FC0A for ; Wed, 1 Jul 2009 19:21:59 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n61JLstS063514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jul 2009 22:21:55 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n61JLspG074503; Wed, 1 Jul 2009 22:21:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n61JLsvb074502; Wed, 1 Jul 2009 22:21:54 +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, 1 Jul 2009 22:21:54 +0300 From: Kostik Belousov To: Greg Rivers Message-ID: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MmX58n9T22ba0WwG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: Panic during shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:22:01 -0000 --MmX58n9T22ba0WwG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 01, 2009 at 11:57:20AM -0500, Greg Rivers wrote: > I'm running -CURRENT on an Acer One netbook. Every kernel I've built=20 > since last Sunday panics on shutdown (see below). The panic occurs=20 > whenever shutdown(8) is executed, even if only to drop to single-user.=20 > halt(8) does not trigger the panic. >=20 > I have a core dump and kernel with debugging symbols available if needed. =2E.. >=20 > #0 doadump () at pcpu.h:246 > 246 pcpu.h: No such file or directory. > in pcpu.h > (kgdb) #0 doadump () at pcpu.h:246 > #1 0xc04fe634 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :419 > #2 0xc04fe94b in panic (fmt=3DVariable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:575 > #3 0xc063262d in swap_release_by_uid (decr=3DUnhandled dwarf expression= =20 > opcode 0x93 > ) > at /usr/src/sys/vm/swap_pager.c:267 > #4 0xc064a60b in vm_object_destroy (object=3D0xc4300000) > at /usr/src/sys/vm/vm_object.c:622 > #5 0xc064cb76 in vm_object_terminate (object=3D0xc4300000) > at /usr/src/sys/vm/vm_object.c:715 > #6 0xc064d24c in vm_object_deallocate (object=3D0xc4300000) > at /usr/src/sys/vm/vm_object.c:592 I am interested in the output of p *object from the frame 6, and the output of p swap_total p swap_reserved all from kgdb. Also, please describe the load on the machine, and look up what process exited when the panic happens. Thanks for the report. > #7 0xc0644059 in _vm_map_unlock (map=3D0xc3d2f1d0, file=3D0x0, line=3D0) > at /usr/src/sys/vm/vm_map.c:480 > #8 0xc0644586 in vm_map_remove (map=3D0xc3d2f1d0, start=3D0, end=3DVaria= ble=20 > "end" is not available. > ) > at /usr/src/sys/vm/vm_map.c:2765 > #9 0xc0647548 in vmspace_exit (td=3D0xc417bd80) at=20 > /usr/src/sys/vm/vm_map.c:329 > #10 0xc04d3c1c in exit1 (td=3D0xc417bd80, rv=3D0) > at /usr/src/sys/kern/kern_exit.c:299 > #11 0xc04d4c10 in sys_exit (td=3DCould not find the frame base for "sys_e= xit". > ) at /usr/src/sys/kern/kern_exit.c:110 > #12 0xc068d2ee in syscall (frame=3D0xe649dd38) > at /usr/src/sys/i386/i386/trap.c:1073 > #13 0xc0672790 in Xint0x80_syscall () > at /usr/src/sys/i386/i386/exception.s:261 > #14 0x00000033 in ?? () > Previous frame inner to this frame (corrupt stack?) > (kgdb) >=20 > [snip] > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --MmX58n9T22ba0WwG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpLt1IACgkQC3+MBN1Mb4hYpQCgytDDZK4ekQAQ32HeECsQ1SPe 3XYAoMxVGUnr8KX9xf/dSecy1+GEd7f6 =1xlv -----END PGP SIGNATURE----- --MmX58n9T22ba0WwG-- From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 19:37:59 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42B74106566C for ; Wed, 1 Jul 2009 19:37:59 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 024E98FC16 for ; Wed, 1 Jul 2009 19:37:58 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id D30631E001F7; Wed, 1 Jul 2009 21:37:57 +0200 (CEST) Received: from triton.kn-bremen.de (noident@localhost [127.0.0.1]) by triton.kn-bremen.de (8.14.3/8.14.3) with ESMTP id n61Jai6Y061039; Wed, 1 Jul 2009 21:36:44 +0200 (CEST) (envelope-from nox@triton.kn-bremen.de) Received: (from nox@localhost) by triton.kn-bremen.de (8.14.3/8.14.3/Submit) id n61Jahd7061038; Wed, 1 Jul 2009 21:36:43 +0200 (CEST) (envelope-from nox) Date: Wed, 1 Jul 2009 21:36:43 +0200 (CEST) From: Juergen Lock Message-Id: <200907011936.n61Jahd7061038@triton.kn-bremen.de> To: alexbestms@math.uni-muenster.de X-Newsgroups: local.list.freebsd.current In-Reply-To: Organization: home Cc: freebsd-current@FreeBSD.org Subject: Re: nspluginwrapper patch for testing (was: Re: flash10 vs f10) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:37:59 -0000 In article you write: >the latest patch to get rid of the ulimit warning doesn't suppress the warning >since it get's output to stderr and not to stdout. replacing it with "ulimit >-s 32768 2 > /dev/null 2>&1" should work. You mean the patch doesn't work for you? It already does redirect stderr to /dev/null (`2>/dev/null'), which works as expected when tested here from commandline /bin/sh and from a script, and also when invoking firefox after ulimit -s 16384. If it doesn't work for you there must be something else going on... Wondering... Juergen From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 19:50:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B32871065670 for ; Wed, 1 Jul 2009 19:50:42 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id 45EA78FC16 for ; Wed, 1 Jul 2009 19:50:42 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,327,1243807200"; d="scan'208";a="276013122" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER03.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay1.uni-muenster.de with ESMTP; 01 Jul 2009 21:50:41 +0200 Received: by ZIVMAILUSER03.UNI-MUENSTER.DE (Postfix, from userid 149459) id CED8D1B0741; Wed, 1 Jul 2009 21:50:40 +0200 (CEST) Date: Wed, 01 Jul 2009 21:50:40 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Juergen Lock Message-ID: In-Reply-To: <200907011936.n61Jahd7061038@triton.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: nspluginwrapper patch for testing (was: Re: flash10 vs f10) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:50:42 -0000 you're right. it was my mistake. i didn't apply the patch, but added the changes manually. i probably overlooked the "2>". sorry for that. ;) alex Juergen Lock schrieb am 2009-07-01: > In article > > you write: > >the latest patch to get rid of the ulimit warning doesn't suppress > >the warning > >since it get's output to stderr and not to stdout. replacing it with > >"ulimit > >-s 32768 2 > /dev/null 2>&1" should work. > You mean the patch doesn't work for you? It already does redirect > stderr to /dev/null (`2>/dev/null'), which works as expected when > tested here from commandline /bin/sh and from a script, and also when > invoking firefox after ulimit -s 16384. If it doesn't work for you > there > must be something else going on... > Wondering... > Juergen From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 20:02:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 779001065672; Wed, 1 Jul 2009 20:02:37 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id 2910D8FC17; Wed, 1 Jul 2009 20:02:37 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from gate.ipt.ru ([194.62.233.123] helo=h30.sp.ipt.ru) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1MM60o-000ISK-Vx; Thu, 02 Jul 2009 00:02:35 +0400 To: "Sam Fourman Jr." References: <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <747dc8f30906290434y77f11bf1i5911ea1efe29fab5@mail.gmail.com> <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> From: Boris Samorodov In-Reply-To: <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> (Sam Fourman, Jr.'s message of "Wed\, 1 Jul 2009 13\:30\:56 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) Date: Thu, 02 Jul 2009 00:02:34 +0400 Message-ID: <57964197_-_@h30.sp.ipt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Juergen Lock Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 20:02:38 -0000 On Wed, 1 Jul 2009 13:30:56 -0500 Sam Fourman Jr. wrote: > On Mon, Jun 29, 2009 at 6:34 AM, Renato Botelho wrote: > > On Sun, Jun 28, 2009 at 11:10 AM, Juergen Lock wrote: > >> On Sun, Jun 28, 2009 at 04:40:20PM +0400, Boris Samorodov wrote: > >>> Juergen Lock writes: > >>> > >>> >  New patch and shar: > >>> > >>> No more comments from me, thanks! > >> > >> Ok.  Has anyone tested this yet tho?  (Besides me in a vm... :) > > > > Working fine here. 8.0-current i386 > > > I saw linux-f10-flashplugin10 hit the ports tree so I decided to try it > I have a recent FreeBSD CURRENT snapshot installed > uname -a > FreeBSD 8.0-HEAD-20090601-JPSNAP FreeBSD 8.0-HEAD-20090601-JPSNAP #0: > Mon Jun 1 02:48:06 UTC 2009 > root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386/usr/src/sys/GENERIC > i386 > I have linux-f10 installed > pkg_info | grep linux > linux_base-f10-10 Base set of packages needed in Linux mode for i386/amd64 (L For future reference, either show another command (i.e. pkg_info | grep linux_base) or show the full output for the command you give. > here is the error I get, is there some wiki available that details the > steps it takes to test flash10? > # cd /usr/ports/www/linux-f10-flashplugin10/ > # make install > ===> linux-flashplugin-10.0r22 bsd.linux-apps.mk test failed: The > component libidn is not defined for LINUX_DIST_SUFFIX=-f10 (the This component should not present at the makefile (the package is included at linux_base-f10 port). > corresponding variable libidn_f10_FILE is not defined). > *** Error code 1 > Stop in /usr/ports/www/linux-f10-flashplugin10. Here is a patch to test: ----- --- Makefile.orig 2009-07-01 23:56:23.000000000 +0400 +++ Makefile 2009-07-01 23:56:39.000000000 +0400 @@ -20,7 +20,7 @@ ONLY_FOR_ARCHS= amd64 i386 USE_LINUX= yes -USE_LINUX_APPS= openssl curl libssh2 libidn nspr nss +USE_LINUX_APPS= openssl curl libssh2 nspr nss RESTRICTED= Redistribution not allowed RESTRICTED_FILES= ${DISTFILES:Nlinux-f8-flashsupport*:C/:[^:]+$//} ----- WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 20:08:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1426F1065750; Wed, 1 Jul 2009 20:08:19 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from services.ipt.ru (services.ipt.ru [194.62.233.110]) by mx1.freebsd.org (Postfix) with ESMTP id BA92B8FC1A; Wed, 1 Jul 2009 20:08:18 +0000 (UTC) (envelope-from bsam@ipt.ru) Received: from gate.ipt.ru ([194.62.233.123] helo=h30.sp.ipt.ru) by services.ipt.ru with esmtp (Exim 4.54 (FreeBSD)) id 1MM66L-000IWc-FG; Thu, 02 Jul 2009 00:08:17 +0400 To: "Sam Fourman Jr." References: <20090627143719.GA28318@triton.kn-bremen.de> <33059629@ipt.ru> <20090627213533.GA46429@triton.kn-bremen.de> <88413085@ipt.ru> <20090628082701.GA34665@triton.kn-bremen.de> <56244219@ipt.ru> <20090628141008.GA3841@triton.kn-bremen.de> <747dc8f30906290434y77f11bf1i5911ea1efe29fab5@mail.gmail.com> <11167f520907011130u744a36a3m71ee5d125c69f446@mail.gmail.com> <57964197_-_@h30.sp.ipt.ru> From: Boris Samorodov Date: Thu, 02 Jul 2009 00:08:16 +0400 In-Reply-To: <57964197_-_@h30.sp.ipt.ru> (Boris Samorodov's message of "Thu\, 02 Jul 2009 00\:02\:34 +0400") Message-ID: <91883855@h30.sp.ipt.ru> User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, Juergen Lock Subject: Re: flash10 vs f10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 20:08:19 -0000 On Thu, 02 Jul 2009 00:02:34 +0400 Boris Samorodov wrote: > Here is a patch to test: Sorry, was stupid of me. Peter Jeremy is right -- it was just a repocopy and the port is not committed yet. I spoke too soon. WBR -- bsam From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 20:13:18 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 7094010656EE; Wed, 1 Jul 2009 20:13:18 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 1 Jul 2009 16:13:08 -0400 User-Agent: KMail/1.6.2 References: <20090701162108.GA33681@regency.nsu.ru> In-Reply-To: <20090701162108.GA33681@regency.nsu.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907011613.10550.jkim@FreeBSD.org> Cc: Alexey Dokuchaev Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 20:13:18 -0000 On Wednesday 01 July 2009 12:21 pm, Alexey Dokuchaev wrote: > Hello there, > > I've started to observe the following rather annoying panic if I > boot with if_sf loaded (via loader.conf) and having sf0 configured > via DHCP on recent -CURRENT. If I comment out driver from > loader.conf and load it manually (via kldload(8)) after system > boots, it loads and gets configured just fine. > > Any clues here? Attached is relevant dmesg + DDB trace (debug > kernel with WITNESS). I'm happy to provide any additional > information (that is, ps/show uma/malloc, whatever). Last time I checked, bpf(4) with MAC caused a similar problem when it is destroying bpf descriptor label. GENERIC includes MAC by default now. If you don't need MAC, try removing "options MAC" from your kernel configuration. FYI... Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 20:17:25 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C084C10656F2; Wed, 1 Jul 2009 20:17:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2388FC20; Wed, 1 Jul 2009 20:17:25 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 2321D46B46; Wed, 1 Jul 2009 16:17:25 -0400 (EDT) Date: Wed, 1 Jul 2009 21:17:25 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jung-uk Kim In-Reply-To: <200907011613.10550.jkim@FreeBSD.org> Message-ID: References: <20090701162108.GA33681@regency.nsu.ru> <200907011613.10550.jkim@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexey Dokuchaev , freebsd-current@FreeBSD.org Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 20:17:26 -0000 On Wed, 1 Jul 2009, Jung-uk Kim wrote: > On Wednesday 01 July 2009 12:21 pm, Alexey Dokuchaev wrote: > >> I've started to observe the following rather annoying panic if I boot with >> if_sf loaded (via loader.conf) and having sf0 configured via DHCP on recent >> -CURRENT. If I comment out driver from loader.conf and load it manually >> (via kldload(8)) after system boots, it loads and gets configured just >> fine. >> >> Any clues here? Attached is relevant dmesg + DDB trace (debug kernel with >> WITNESS). I'm happy to provide any additional information (that is, >> ps/show uma/malloc, whatever). > > Last time I checked, bpf(4) with MAC caused a similar problem when it is > destroying bpf descriptor label. GENERIC includes MAC by default now. If > you don't need MAC, try removing "options MAC" from your kernel > configuration. I was not aware of this problem -- could you provide some more details? Any panic caused by having MAC in the kernel is a bug... Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 20:12:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F2EC1065694; Wed, 1 Jul 2009 20:12:56 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojteks.tensor.gdynia.pl (wojteks.tensor.gdynia.pl [IPv6:2001:4070:101:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id C700D8FC18; Wed, 1 Jul 2009 20:12:55 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [IPv6:2001:4070:101:2::2]) by wojteks.tensor.gdynia.pl (8.14.3/8.14.3) with ESMTP id n61KD1NW004530; Wed, 1 Jul 2009 22:13:01 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3) with ESMTP id n61K0tcS001793; Wed, 1 Jul 2009 22:00:55 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3/Submit) with ESMTP id n61K0sR7001790; Wed, 1 Jul 2009 22:00:54 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Wed, 1 Jul 2009 22:00:54 +0200 (CEST) From: Wojciech Puchar To: Anton Shterenlikht In-Reply-To: <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> Message-ID: References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 01 Jul 2009 20:24:15 +0000 Cc: freebsd-ia64@freebsd.org, Marcel Moolenaar , freebsd-questions@freebsd.org, freebsd-current@freebsd.org Subject: Re: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 20:12:57 -0000 >> It's better to use gmirror per partition. > > Like this? > > # gmirror label -vb round-robin root /dev/da0p2 > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. isn't that partition accessed by other process or mounted? From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 21:23:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37F06106566C for ; Wed, 1 Jul 2009 21:23:16 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-ew0-f213.google.com (mail-ew0-f213.google.com [209.85.219.213]) by mx1.freebsd.org (Postfix) with ESMTP id AFD578FC08 for ; Wed, 1 Jul 2009 21:23:15 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by ewy9 with SMTP id 9so1365186ewy.43 for ; Wed, 01 Jul 2009 14:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=rmlc+wm9EF3pyKUcmNxTeBUClKkJm6Jtrmn2wG2SCm4=; b=WUWmrsU2kFazCcSGLLZxIy4uyStHi/ZXw2z+jrro8vUBNHxAiZY6qG9NGzh+y3bsnZ hWhYIlJrvIIxI7Z+2r7WNtPZYoqXhNb19TsbqHkk61Otdm5B6fyylDl/v3wEwVkgETWq KNwHh80F6lVWELH6CjY+hdhRhH/+cojEhPvoU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=e7GuWj0S2iw9EzNaeF8aX8LVnAci+Y0ADWmVTQsGCZ3TjevV9u7j6ppkc9EC+VbGrU Vwi3xkeL3U7kdSn/ag1D+GelmEyU9h0o1npaNpFvknMvJ0ILRfQJWA1gl5+RtpBiVp25 Z+jvlV+LGtiViqbrd8S35A0ldiRt3+EvMC5QA= Received: by 10.210.57.3 with SMTP id f3mr401015eba.94.1246483394801; Wed, 01 Jul 2009 14:23:14 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.105.194]) by mx.google.com with ESMTPS id 7sm61173eyg.47.2009.07.01.14.23.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Jul 2009 14:23:13 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 2CA12B8083; Wed, 1 Jul 2009 18:23:07 -0300 (BRT) Received: from 189.92.197.238 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Wed, 1 Jul 2009 18:23:07 -0300 (BRT) Message-ID: <278f1543f854567d812e3cd65ff4d42d.squirrel@cygnus.homeunix.com> In-Reply-To: <1de79840907011400v7f625f6av926ffc311f469f52@mail.gmail.com> References: <3730d4eb75f62cac45c8113ef595c2f5.squirrel@cygnus.homeunix.com> <1de79840907011400v7f625f6av926ffc311f469f52@mail.gmail.com> Date: Wed, 1 Jul 2009 18:23:07 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: problems building current from today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 21:23:16 -0000 On Wed, July 1, 2009 18:00, Michael Proto wrote: > On Wed, Jul 1, 2009 at 3:02 PM, Nenhum_de_Nos > wrote: >> hail, >> >> I'm trying to build tinybsd as of today, and I get this: >> >> cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls >> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >> -Wpointer-arith >> -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions >> -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL >> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common >> -finline-limit=8000 --param inline-unit-growth=100 --param >> large-function-growth=1000 -mno-align-long-strings >> -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >> -mno-sse3 -ffreestanding -fstack-protector -Werror >> /usr/src/sys/kern/sysv_msg.c >> /usr/src/sys/kern/sysv_msg.c:1263: error: invalid application of >> 'sizeof' >> to incomplete type 'struct freebsd7_msgctl_args' >> /usr/src/sys/kern/sysv_msg.c:1263: error: 'freebsd7_msgctl' undeclared >> here (not in a function) >> cc1: warnings being treated as errors >> /usr/src/sys/kern/sysv_msg.c:1309: warning: function declaration isn't a >> prototype >> /usr/src/sys/kern/sysv_msg.c: In function 'freebsd7_msgctl': >> /usr/src/sys/kern/sysv_msg.c:1318: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1318: error: request for member 'cmd' in >> something not a structure or union >> /usr/src/sys/kern/sysv_msg.c:1318: warning: comparison between pointer >> and >> integer >> /usr/src/sys/kern/sysv_msg.c:1319: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1319: error: request for member 'buf' in >> something not a structure or union >> /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'msqid' in >> something not a structure or union >> /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'cmd' in >> something not a structure or union >> /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 2 of >> 'kern_msgctl' makes integer from pointer without a cast >> /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 3 of >> 'kern_msgctl' makes integer from pointer without a cast >> /usr/src/sys/kern/sysv_msg.c:1337: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1337: error: request for member 'cmd' in >> something not a structure or union >> /usr/src/sys/kern/sysv_msg.c:1337: warning: comparison between pointer >> and >> integer >> /usr/src/sys/kern/sysv_msg.c:1350: error: dereferencing pointer to >> incomplete type >> /usr/src/sys/kern/sysv_msg.c:1350: error: request for member 'buf' in >> something not a structure or union >> *** Error code 1 >> >> Stop in /usr/obj/usr/src/sys/TINYBSD. >> *** Error code 1 >> >> Stop in /usr/src. >> *** Error code 1 >> >> Stop in /usr/src. >> tinybsd# >> >> I read about some commits breaking current recently, but also saw saying >> was fixed. >> > > I ran across this myself on a non-TINYBSD build, and was able to > resolve it by commenting-out COMPAT_FREEBSD6 in my kernel config since > I didn't need it (all other COMPAT entries except COMPAT_43TTY were > already disabled, so now only COMPAT_43TTY is enabled). Might help > your situation. > > > -Proto thanks, I looked into it and there is no COMPAT_FREEBSD6, just COMPAT_FREEBSD4. sam said to put COMPAT_FREEBSD7 on it. trying it now. thanks all, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 21:25:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E13810656B6 for ; Wed, 1 Jul 2009 21:25:11 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: from mail-bw0-f211.google.com (mail-bw0-f211.google.com [209.85.218.211]) by mx1.freebsd.org (Postfix) with ESMTP id 8E1F18FC2D for ; Wed, 1 Jul 2009 21:25:10 +0000 (UTC) (envelope-from mike@jellydonut.org) Received: by bwz7 with SMTP id 7so1200647bwz.19 for ; Wed, 01 Jul 2009 14:25:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.115.80 with SMTP id h16mr6641647faq.94.1246482027741; Wed, 01 Jul 2009 14:00:27 -0700 (PDT) In-Reply-To: <3730d4eb75f62cac45c8113ef595c2f5.squirrel@cygnus.homeunix.com> References: <3730d4eb75f62cac45c8113ef595c2f5.squirrel@cygnus.homeunix.com> Date: Wed, 1 Jul 2009 17:00:27 -0400 Message-ID: <1de79840907011400v7f625f6av926ffc311f469f52@mail.gmail.com> From: Michael Proto To: Nenhum_de_Nos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: problems building current from today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 21:25:11 -0000 On Wed, Jul 1, 2009 at 3:02 PM, Nenhum_de_Nos wrote: > hail, > > I'm trying to build tinybsd as of today, and I get this: > > cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls > -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith > -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions > -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL > -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common > -finline-limit=8000 --param inline-unit-growth=100 --param > large-function-growth=1000 -mno-align-long-strings > -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > -mno-sse3 -ffreestanding -fstack-protector -Werror > /usr/src/sys/kern/sysv_msg.c > /usr/src/sys/kern/sysv_msg.c:1263: error: invalid application of 'sizeof' > to incomplete type 'struct freebsd7_msgctl_args' > /usr/src/sys/kern/sysv_msg.c:1263: error: 'freebsd7_msgctl' undeclared > here (not in a function) > cc1: warnings being treated as errors > /usr/src/sys/kern/sysv_msg.c:1309: warning: function declaration isn't a > prototype > /usr/src/sys/kern/sysv_msg.c: In function 'freebsd7_msgctl': > /usr/src/sys/kern/sysv_msg.c:1318: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1318: error: request for member 'cmd' in > something not a structure or union > /usr/src/sys/kern/sysv_msg.c:1318: warning: comparison between pointer and > integer > /usr/src/sys/kern/sysv_msg.c:1319: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1319: error: request for member 'buf' in > something not a structure or union > /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'msqid' in > something not a structure or union > /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'cmd' in > something not a structure or union > /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 2 of > 'kern_msgctl' makes integer from pointer without a cast > /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 3 of > 'kern_msgctl' makes integer from pointer without a cast > /usr/src/sys/kern/sysv_msg.c:1337: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1337: error: request for member 'cmd' in > something not a structure or union > /usr/src/sys/kern/sysv_msg.c:1337: warning: comparison between pointer and > integer > /usr/src/sys/kern/sysv_msg.c:1350: error: dereferencing pointer to > incomplete type > /usr/src/sys/kern/sysv_msg.c:1350: error: request for member 'buf' in > something not a structure or union > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/TINYBSD. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > tinybsd# > > I read about some commits breaking current recently, but also saw saying > was fixed. > I ran across this myself on a non-TINYBSD build, and was able to resolve it by commenting-out COMPAT_FREEBSD6 in my kernel config since I didn't need it (all other COMPAT entries except COMPAT_43TTY were already disabled, so now only COMPAT_43TTY is enabled). Might help your situation. -Proto From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 21:29:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB52D106566C for ; Wed, 1 Jul 2009 21:29:55 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: from iron2.pdx.net (iron2.pdx.net [69.64.224.71]) by mx1.freebsd.org (Postfix) with ESMTP id AD5018FC16 for ; Wed, 1 Jul 2009 21:29:55 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: (qmail 16762 invoked from network); 1 Jul 2009 14:29:52 -0700 Received: from host-246-98.pubnet.pdx.edu (HELO ?131.252.246.98?) (131.252.246.98) by iron2.pdx.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Jul 2009 14:29:52 -0700 From: Sean Bruno To: Julian Stecklina In-Reply-To: <87hbxxp5ot.fsf@tabernacle.lan> References: <1246316092.3981.11.camel@Lappy> <87hbxxp5ot.fsf@tabernacle.lan> Content-Type: text/plain Date: Wed, 01 Jul 2009 14:29:54 -0700 Message-Id: <1246483794.3443.6.camel@Lappy> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 8-CURRENT Firewire X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 21:29:56 -0000 > I have an AMD 780G board with onboard Firewire controller. 8-CURRENT > hangs at boot with: > > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > ... Two things: 1. Full dmesg output from boot with the firewire enabled and disabled would be great. Post it over on freebsd-firewire. 2. Can you boot with the firewire enabled in the BIOS and the following in loader.conf: firewire_load="NO" If you can boot this way, what happens when you: kldload sbp.ko Sean From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 21:37:25 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 057DD106564A; Wed, 1 Jul 2009 21:37:25 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: freebsd-current@FreeBSD.org Date: Wed, 1 Jul 2009 17:37:05 -0400 User-Agent: KMail/1.6.2 References: <20090701162108.GA33681@regency.nsu.ru> <200907011613.10550.jkim@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907011737.15525.jkim@FreeBSD.org> Cc: Alexey Dokuchaev , Robert Watson Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 21:37:25 -0000 On Wednesday 01 July 2009 04:17 pm, Robert Watson wrote: > On Wed, 1 Jul 2009, Jung-uk Kim wrote: > > On Wednesday 01 July 2009 12:21 pm, Alexey Dokuchaev wrote: > >> I've started to observe the following rather annoying panic if I > >> boot with if_sf loaded (via loader.conf) and having sf0 > >> configured via DHCP on recent -CURRENT. If I comment out driver > >> from loader.conf and load it manually (via kldload(8)) after > >> system boots, it loads and gets configured just fine. > >> > >> Any clues here? Attached is relevant dmesg + DDB trace (debug > >> kernel with WITNESS). I'm happy to provide any additional > >> information (that is, ps/show uma/malloc, whatever). > > > > Last time I checked, bpf(4) with MAC caused a similar problem > > when it is destroying bpf descriptor label. GENERIC includes MAC > > by default now. If you don't need MAC, try removing "options > > MAC" from your kernel configuration. > > I was not aware of this problem -- could you provide some more > details? Any panic caused by having MAC in the kernel is a bug... It was about a month ago. I had funny impression that you and sam were working on it cause it started happening when sam added bpf detach event handler and MAC was enabled by default. Any way, I will let you know if I can reproduce the problem. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 21:31:02 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DE1A1065678; Wed, 1 Jul 2009 21:31:02 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.freebsd.org (Postfix) with ESMTP id D972B8FC08; Wed, 1 Jul 2009 21:31:01 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.50) id 1MM76M-00034c-9E; Thu, 02 Jul 2009 04:12:22 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id n61LDWvW004371; Thu, 2 Jul 2009 04:13:32 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id n61LDRpU004329; Thu, 2 Jul 2009 04:13:27 +0700 (NOVST) (envelope-from danfe) Date: Thu, 2 Jul 2009 04:13:27 +0700 From: Alexey Dokuchaev To: Robert Watson Message-ID: <20090701211327.GA99767@regency.nsu.ru> References: <20090701162108.GA33681@regency.nsu.ru> <200907011613.10550.jkim@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Wed, 01 Jul 2009 21:40:04 +0000 Cc: freebsd-current@FreeBSD.org, Jung-uk Kim Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 21:31:02 -0000 Robert Watson wrote: > Jung-uk Kim wrote: > >Last time I checked, bpf(4) with MAC caused a similar problem when it is > >destroying bpf descriptor label. GENERIC includes MAC by default now. If > >you don't need MAC, try removing "options MAC" from your kernel > >configuration. > > I was not aware of this problem -- could you provide some more details? > Any panic caused by having MAC in the kernel is a bug... My kernel is custom one, with everything I could moved out to modules (had to add "nodevice" entries for io and mem since they are in DEFAULTS these days). So I don't see how it can be related to MAC. ./danfe P.S. Took me couple of hours to figure out that "uart" must be compiled in, loading it via loader.conf does not quite work for serial console. :-( From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 21:42:47 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 372B11065691; Wed, 1 Jul 2009 21:42:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 0B9348FC21; Wed, 1 Jul 2009 21:42:47 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 7D88D46B8E; Wed, 1 Jul 2009 17:42:46 -0400 (EDT) Date: Wed, 1 Jul 2009 22:42:46 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jung-uk Kim In-Reply-To: <200907011737.15525.jkim@FreeBSD.org> Message-ID: References: <20090701162108.GA33681@regency.nsu.ru> <200907011613.10550.jkim@FreeBSD.org> <200907011737.15525.jkim@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexey Dokuchaev , freebsd-current@FreeBSD.org Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 21:42:48 -0000 On Wed, 1 Jul 2009, Jung-uk Kim wrote: >>> Last time I checked, bpf(4) with MAC caused a similar problem when it is >>> destroying bpf descriptor label. GENERIC includes MAC by default now. >>> If you don't need MAC, try removing "options MAC" from your kernel >>> configuration. >> >> I was not aware of this problem -- could you provide some more details? >> Any panic caused by having MAC in the kernel is a bug... > > It was about a month ago. I had funny impression that you and sam were > working on it cause it started happening when sam added bpf detach event > handler and MAC was enabled by default. Any way, I will let you know if I > can reproduce the problem. There have been a number of tear-down related races for ifnets, more of which are closed now than before the last few weeks, but none MAC-related as far as I'm aware. If it recurs, please let me know and I'm happy to help investigate (MAC-related or otherwise). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 21:54:25 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D246B106566C for ; Wed, 1 Jul 2009 21:54:25 +0000 (UTC) (envelope-from root@free.fr) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7FD8FC12 for ; Wed, 1 Jul 2009 21:54:23 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 7F7C1CA8AF0 for ; Wed, 1 Jul 2009 23:38:04 +0200 (CEST) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 4F595818174 for ; Wed, 1 Jul 2009 23:37:58 +0200 (CEST) Received: from free.fr (evr27-1-88-172-40-194.fbx.proxad.net [88.172.40.194]) by smtp3-g21.free.fr (Postfix) with ESMTP id 55F3E8180D1 for ; Wed, 1 Jul 2009 23:37:56 +0200 (CEST) To: freebsd-current@freebsd.org Date: Wed, 01 Jul 2009 23:37:54 +0200 From: raoul megelas Message-Id: <20090701213756.55F3E8180D1@smtp3-g21.free.fr> X-Mailman-Approved-At: Wed, 01 Jul 2009 22:09:52 +0000 Subject: shutdown panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 21:54:26 -0000 Hi all, i am bitten by this one, (current from this day). in all case i will re cvsup later. Hope to help. REgards raoul* rmgls@free.Fr Jul 1 23:22:46 asus_p2bd_biXeon syslogd: exiting on signal 15 panic: swap_reserved < decr cpuid = 2 KDB: enter: panic [thread pid 1402 tid 100143 ] Stopped at kdb_enter+0x3a: movl $0,kdb_why db> bt Tracing pid 1402 tid 100143 td 0xc5ef4480 kdb_enter(c0c56d5d,c0c56d5d,c0c7db0e,e753fb20,2,...) at kdb_enter+0x3a panic(c0c7db0e,0,c0c7da6a,109,df,...) at panic+0x136 swap_release_by_uid(fb000,0,c553d300,264,c5c6a198,...) at swap_release_by_uid+0x75 vm_object_destroy(c5c6a198,0,c0c7f941,2c9,c0c55540,df) at vm_object_destroy+0xdc vm_object_terminate(c5c6a198,0,c0c7f941,247,c5c98360,...) at vm_object_terminate+0x217 vm_object_deallocate(c5c6a198,c0c7ee43,acd,c5bffd98,0,...) at vm_object_deallocate+0x5ef _vm_map_unlock(c5bffd98,c0c7ee43,acd,1,c5bffd98,...) at _vm_map_unlock+0x76 vm_map_remove(c5bffd98,0,bfc00000,c5d42fa0,c5d42d48,...) at vm_map_remove+0x6b vmspace_exit(c5ef4480,0,c0c5210e,129,0,...) at vmspace_exit+0xbf exit1(c5ef4480,100,e753fd2c,c0b97953,c5ef4480,...) at exit1+0x5cb sys_exit(c5ef4480,e753fcf8,4,c0c5d7a7,c0d3a91c,...) at sys_exit+0x1d syscall(e753fd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x28139b83, esp = 0xbfbfddcc, ebp = 0xbfbfddd8 --- db> bt Tracing pid 1402 tid 100143 td 0xc5ef4480 kdb_enter(c0c56d5d,c0c56d5d,c0c7db0e,e753fb20,2,...) at kdb_enter+0x3a panic(c0c7db0e,0,c0c7da6a,109,df,...) at panic+0x136 swap_release_by_uid(fb000,0,c553d300,264,c5c6a198,...) at swap_release_by_uid+0x75 vm_object_destroy(c5c6a198,0,c0c7f941,2c9,c0c55540,df) at vm_object_destroy+0xdc vm_object_terminate(c5c6a198,0,c0c7f941,247,c5c98360,...) at vm_object_terminate+0x217 vm_object_deallocate(c5c6a198,c0c7ee43,acd,c5bffd98,0,...) at vm_object_deallocate+0x5ef _vm_map_unlock(c5bffd98,c0c7ee43,acd,1,c5bffd98,...) at _vm_map_unlock+0x76 vm_map_remove(c5bffd98,0,bfc00000,c5d42fa0,c5d42d48,...) at vm_map_remove+0x6b vmspace_exit(c5ef4480,0,c0c5210e,129,0,...) at vmspace_exit+0xbf exit1(c5ef4480,100,e753fd2c,c0b97953,c5ef4480,...) at exit1+0x5cb sys_exit(c5ef4480,e753fcf8,4,c0c5d7a7,c0d3a91c,...) at sys_exit+0x1d syscall(e753fd38) at syscall+0x2a3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (1, FreeBSD ELF32, sys_exit), eip = 0x28139b83, esp = 0xbfbfddcc, ebp = 0xbfbfddd8 --- db>* From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 22:13:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85A2A1065673 for ; Wed, 1 Jul 2009 22:13:53 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 140538FC12 for ; Wed, 1 Jul 2009 22:13:52 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: by fxm18 with SMTP id 18so1039661fxm.43 for ; Wed, 01 Jul 2009 15:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G+AGlxkvIWs5sSpd5jmgo8beeqLknj2KddKbPn8hYDw=; b=XfaaxEnBvipSFDN3Og4CDs3k+q4GIaj04pCiGzwI95RNMx6XoIZSdNhnHLmzXcBa8o uufY3avYcE+uVasxiOszMvuAHt5zhxlIgP9X0stIlUE8neAv7+GCqZmTvuVXF5q+FPRk HUKD3CoePLsPNfJiyPSMghf4bcYqBbMDjpPJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pCoaiAYg39pi7H8Z+NOe8j6vGvq4fT7gA79vn9ulNfGCL7DKn7ApPjSwT9cep5Eui+ /S46jFwKdGYzm+dHuC+s9AxUGWEefic0xZtPEjb4hCwMHeIE8Q7vJ0z18zc7Z0u645T8 4jtN2+0Q7+Y8T7DTEE/07rtfg8XdbOjNTfUi0= MIME-Version: 1.0 Received: by 10.204.118.207 with SMTP id w15mr10088535bkq.126.1246486431894; Wed, 01 Jul 2009 15:13:51 -0700 (PDT) In-Reply-To: <20090701213756.55F3E8180D1@smtp3-g21.free.fr> References: <20090701213756.55F3E8180D1@smtp3-g21.free.fr> Date: Wed, 1 Jul 2009 18:13:51 -0400 Message-ID: <4ad871310907011513o1e569ebct9a74796252ee86b4@mail.gmail.com> From: Glen Barber To: raoul megelas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: shutdown panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 22:13:53 -0000 On Wed, Jul 1, 2009 at 5:37 PM, raoul megelas wrote: > > > Hi all, > > i am bitten by this one, (current from this day). > in all case i will re cvsup later. > Hope to help. > Hi, Raoul. There's another thread floating around from today with a similar situation. Just an FYI. :) -- Glen Barber From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 22:28:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C25AA10656C6 for ; Wed, 1 Jul 2009 22:28:31 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: from mail-pz0-f197.google.com (mail-pz0-f197.google.com [209.85.222.197]) by mx1.freebsd.org (Postfix) with ESMTP id 899588FC13 for ; Wed, 1 Jul 2009 22:28:31 +0000 (UTC) (envelope-from matheusber@gmail.com) Received: by pzk35 with SMTP id 35so947436pzk.3 for ; Wed, 01 Jul 2009 15:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:received:received :message-id:in-reply-to:references:date:subject:from:to:user-agent :mime-version:content-type:content-transfer-encoding:x-priority :importance; bh=EJ4omu30DSECbFeRc7pdNPQRSFMX/PfVGfXgPpvc3S8=; b=dlEKbD+4jHis7xhLbJattT9e3sgctqbid09c9tT4bMU+26C5hJ5Dk7UziCA3fvSVxG 7/eQ1Un40l8hec8zWMG35tJ2IOFnJ2U1tAeeFacU5W069YQ4znx1shyTjxhd3APKpB2i 40Tp6JgdeOLNP8U4w9s3DeDrewodOToHXAWsY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:in-reply-to:references:date:subject:from:to :user-agent:mime-version:content-type:content-transfer-encoding :x-priority:importance; b=N/DhCm+RJJdw5Rg1bvkexl8VagIX+S6e12hnsbrlwApd2SHZkqQqWIUEwQJs/O/9xO mbDmB2t1XJDKJmmRHg6PVVWLwM//UirmV6nbs3JnWGZ3qtvfPV01LbzsuQtsfPrOhui9 1kWbkd7sipOfaJIsmko7JNGpNCycu5G2WUutk= Received: by 10.114.75.1 with SMTP id x1mr16001250waa.4.1246487310876; Wed, 01 Jul 2009 15:28:30 -0700 (PDT) Received: from cygnus.homeunix.com ([189.71.105.194]) by mx.google.com with ESMTPS id m28sm2881604waf.37.2009.07.01.15.28.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Jul 2009 15:28:30 -0700 (PDT) Sender: Nenhum_de_Nos Received: by cygnus.homeunix.com (Postfix, from userid 80) id 04953B8083; Wed, 1 Jul 2009 19:28:18 -0300 (BRT) Received: from 189.92.197.238 (SquirrelMail authenticated user matheus) by cygnus.homeunix.com with HTTP; Wed, 1 Jul 2009 19:28:18 -0300 (BRT) Message-ID: <6f61f2768503d60751a837d8cd81c3db.squirrel@cygnus.homeunix.com> In-Reply-To: <278f1543f854567d812e3cd65ff4d42d.squirrel@cygnus.homeunix.com> References: <3730d4eb75f62cac45c8113ef595c2f5.squirrel@cygnus.homeunix.com> <1de79840907011400v7f625f6av926ffc311f469f52@mail.gmail.com> <278f1543f854567d812e3cd65ff4d42d.squirrel@cygnus.homeunix.com> Date: Wed, 1 Jul 2009 19:28:18 -0300 (BRT) From: "Nenhum_de_Nos" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: problems building current from today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 22:28:32 -0000 On Wed, July 1, 2009 18:23, Nenhum_de_Nos wrote: > > On Wed, July 1, 2009 18:00, Michael Proto wrote: >> On Wed, Jul 1, 2009 at 3:02 PM, Nenhum_de_Nos >> wrote: >>> hail, >>> >>> I'm trying to build tinybsd as of today, and I get this: >>> >>> cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls >>> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes >>> -Wpointer-arith >>> -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions >>> -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL >>> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common >>> -finline-limit=8000 --param inline-unit-growth=100 --param >>> large-function-growth=1000 -mno-align-long-strings >>> -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 >>> -mno-sse3 -ffreestanding -fstack-protector -Werror >>> /usr/src/sys/kern/sysv_msg.c >>> /usr/src/sys/kern/sysv_msg.c:1263: error: invalid application of >>> 'sizeof' >>> to incomplete type 'struct freebsd7_msgctl_args' >>> /usr/src/sys/kern/sysv_msg.c:1263: error: 'freebsd7_msgctl' undeclared >>> here (not in a function) >>> cc1: warnings being treated as errors >>> /usr/src/sys/kern/sysv_msg.c:1309: warning: function declaration isn't >>> a >>> prototype >>> /usr/src/sys/kern/sysv_msg.c: In function 'freebsd7_msgctl': >>> /usr/src/sys/kern/sysv_msg.c:1318: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1318: error: request for member 'cmd' in >>> something not a structure or union >>> /usr/src/sys/kern/sysv_msg.c:1318: warning: comparison between pointer >>> and >>> integer >>> /usr/src/sys/kern/sysv_msg.c:1319: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1319: error: request for member 'buf' in >>> something not a structure or union >>> /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'msqid' in >>> something not a structure or union >>> /usr/src/sys/kern/sysv_msg.c:1334: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1334: error: request for member 'cmd' in >>> something not a structure or union >>> /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 2 of >>> 'kern_msgctl' makes integer from pointer without a cast >>> /usr/src/sys/kern/sysv_msg.c:1334: warning: passing argument 3 of >>> 'kern_msgctl' makes integer from pointer without a cast >>> /usr/src/sys/kern/sysv_msg.c:1337: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1337: error: request for member 'cmd' in >>> something not a structure or union >>> /usr/src/sys/kern/sysv_msg.c:1337: warning: comparison between pointer >>> and >>> integer >>> /usr/src/sys/kern/sysv_msg.c:1350: error: dereferencing pointer to >>> incomplete type >>> /usr/src/sys/kern/sysv_msg.c:1350: error: request for member 'buf' in >>> something not a structure or union >>> *** Error code 1 >>> >>> Stop in /usr/obj/usr/src/sys/TINYBSD. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> tinybsd# >>> >>> I read about some commits breaking current recently, but also saw >>> saying >>> was fixed. >>> >> >> I ran across this myself on a non-TINYBSD build, and was able to >> resolve it by commenting-out COMPAT_FREEBSD6 in my kernel config since >> I didn't need it (all other COMPAT entries except COMPAT_43TTY were >> already disabled, so now only COMPAT_43TTY is enabled). Might help >> your situation. >> >> >> -Proto > > thanks, > > I looked into it and there is no COMPAT_FREEBSD6, just COMPAT_FREEBSD4. > > sam said to put COMPAT_FREEBSD7 on it. > > trying it now. > > thanks all, > > matheus for the record, options COMPAT_FREEBSD7 did the trick. thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 22:33:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 950AF1065673; Wed, 1 Jul 2009 22:33:28 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4C6108FC16; Wed, 1 Jul 2009 22:33:28 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 2499778FA7; Thu, 2 Jul 2009 02:33:26 +0400 (MSD) Message-ID: <4A4BE438.5060203@haruhiism.net> Date: Thu, 02 Jul 2009 02:33:28 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lawrence Stewart References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> In-Reply-To: <4A48DA31.5010900@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: r194546 amd64: kernel panic in tcp_sack.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 22:33:28 -0000 Lawrence Stewart wrote: > Ok. I'm working on a patch to address a different TCP/SACK issue, but > it may in fact be partially relevant to the cause of your panic... > can't promise when I'll be able to take a close look at this but I'm > aware of it now so that's a start. If you run into it again or find > the trigger for the panic, please let me know. Reproduced. I don't know what was the trigger this time. The system runs lighttpd, fastcgi python and php, mysql and postgresql. Also, in this core somehow everything looks quite similar (looks like another page fault but with panic() called prior to getting into fatal trap 12) to my two earlier dumps: http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008777.html http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008781.html so maybe it's not really a problem with tcp_sack.c or netisr.c. Should I attach the core.txt as well? Unread portion of the kernel message buffer: panic: tcp_sack_globalholes >= 0 cpuid = 0 KDB: enter: panic Physical memory: 2014 MB Dumping 1622 MB: 1607 1591 1575 1559 1543 1527 1511 1495 1479 1463 1447 1431 1415 1399 1383 1367 1351 1335 1319 1303 1287 1271 1255 1239 1223 1207 1191 1175 1159 1143 1127 1111 1095 1079 1063 1047 1031 1015 999 983 967 951 935 919 903 887 871 855 839 823 807 791 775 759 743 727 711 695 679 663 647 631 615 599 583 567 551 535 519 503 487 471 455 439 423 407 391 375 359 343 327 311 295 279 263 247 231 215 199 183 167 151 135 119 103 87 71 55 39 23 7 Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/coretemp.ko...Reading symbols from /boot/kernel/coretemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/coretemp.ko Reading symbols from /boot/kernel/ahci.ko...Reading symbols from /boot/kernel/ahci.ko.symbols...done. done. Loaded symbols for /boot/kernel/ahci.ko Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko Reading symbols from /boot/kernel/fdescfs.ko...Reading symbols from /boot/kernel/fdescfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/fdescfs.ko Reading symbols from /boot/kernel/blank_saver.ko...Reading symbols from /boot/kernel/blank_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/blank_saver.ko #0 doadump () at pcpu.h:223 223 __asm __volatile("movq %%gs:0,%0" : "=r" (td)); (kgdb) backtrace #0 doadump () at pcpu.h:223 #1 0xffffffff801f909c in db_fncall (dummy1=Variable "dummy1" is not available. ) at /usr/src/sys/ddb/db_command.c:548 #2 0xffffffff801f93d1 in db_command (last_cmdp=0xffffffff80bec5e0, cmd_table=Variable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #3 0xffffffff801f9620 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498 #4 0xffffffff801fb5c9 in db_trap (type=Variable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #5 0xffffffff805c92e5 in kdb_trap (type=3, code=0, tf=0xffffff8000031900) at /usr/src/sys/kern/subr_kdb.c:534 #6 0xffffffff80862ad1 in trap (frame=0xffffff8000031900) at /usr/src/sys/amd64/amd64/trap.c:613 #7 0xffffffff80848f03 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:223 #8 0xffffffff805c94bd in kdb_enter (why=0xffffffff8095b989 "panic", msg=0xa
) at cpufunc.h:63 #9 0xffffffff80599ecb in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:558 #10 0xffffffff80709537 in tcp_sackhole_remove (tp=0xffffffff81020fe0, hole=0xa) at /usr/src/sys/netinet/tcp_sack.c:295 #11 0xffffffff80709598 in tcp_free_sackholes (tp=0xffffff0030168b60) at /usr/src/sys/netinet/tcp_sack.c:554 #12 0xffffffff807100f3 in tcp_timer_rexmt (xtp=Variable "xtp" is not available. ) at /usr/src/sys/netinet/tcp_timer.c:482 #13 0xffffffff805ac041 in softclock (arg=Variable "arg" is not available. ) at /usr/src/sys/kern/kern_timeout.c:411 #14 0xffffffff805735d8 in intr_event_execute_handlers (p=Variable "p" is not available. ) at /usr/src/sys/kern/kern_intr.c:1145 #15 0xffffffff80574232 in ithread_loop (arg=0xffffff000131d640) at /usr/src/sys/kern/kern_intr.c:1158 #16 0xffffffff8057153a in fork_exit (callout=0xffffffff80574180 , arg=0xffffff000131d640, frame=0xffffff8000031c90) at /usr/src/sys/kern/kern_fork.c:842 #17 0xffffffff8084938e in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:552 #18 0x0000000000000000 in ?? () #19 0x0000000000000000 in ?? () #20 0x0000000000000001 in ?? () #21 0x0000000000000000 in ?? () #22 0x0000000000000000 in ?? () #23 0x0000000000000000 in ?? () #24 0x0000000000000000 in ?? () #25 0x0000000000000000 in ?? () #26 0x0000000000000000 in ?? () #27 0x0000000000000000 in ?? () #28 0x0000000000000000 in ?? () #29 0x0000000000000000 in ?? () #30 0x0000000000000000 in ?? () #31 0x0000000000000000 in ?? () #32 0x0000000000000000 in ?? () #33 0x0000000000000000 in ?? () #34 0x0000000000000000 in ?? () #35 0x0000000000000000 in ?? () #36 0x0000000000000000 in ?? () #37 0x0000000000000000 in ?? () #38 0x0000000000000000 in ?? () #39 0x0000000000000000 in ?? () #40 0x0000000000000000 in ?? () #41 0x0000000000000000 in ?? () #42 0x0000000000eb9000 in ?? () #43 0x0000000000000000 in ?? () #44 0xffffffff80c28ec0 in affinity () #45 0xffffffff80c28ec0 in affinity () #46 0xffffff0001321390 in ?? () #47 0xffffff8000031b90 in ?? () #48 0xffffff8000031b48 in ?? () #49 0xffffff0001332390 in ?? () #50 0xffffffff805bccf0 in sched_switch (td=0xffffff000131d640, newtd=0xffffffff80574180, flags=Variable "flags" is not available. ) at /usr/src/sys/kern/sched_ule.c:1858 Previous frame inner to this frame (corrupt stack?) -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 22:42:12 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by hub.freebsd.org (Postfix) with ESMTP id 3A009106567F; Wed, 1 Jul 2009 22:42:12 +0000 (UTC) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: Robert Watson Date: Wed, 1 Jul 2009 18:42:00 -0400 User-Agent: KMail/1.6.2 References: <20090701162108.GA33681@regency.nsu.ru> <200907011737.15525.jkim@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200907011842.01710.jkim@FreeBSD.org> Cc: Alexey Dokuchaev , freebsd-current@FreeBSD.org Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 22:42:13 -0000 On Wednesday 01 July 2009 05:42 pm, Robert Watson wrote: > On Wed, 1 Jul 2009, Jung-uk Kim wrote: > >>> Last time I checked, bpf(4) with MAC caused a similar problem > >>> when it is destroying bpf descriptor label. GENERIC includes > >>> MAC by default now. If you don't need MAC, try removing > >>> "options MAC" from your kernel configuration. > >> > >> I was not aware of this problem -- could you provide some more > >> details? Any panic caused by having MAC in the kernel is a > >> bug... > > > > It was about a month ago. I had funny impression that you and > > sam were working on it cause it started happening when sam added > > bpf detach event handler and MAC was enabled by default. Any > > way, I will let you know if I can reproduce the problem. > > There have been a number of tear-down related races for ifnets, > more of which are closed now than before the last few weeks, but > none MAC-related as far as I'm aware. If it recurs, please let me > know and I'm happy to help investigate (MAC-related or otherwise). I cannot reproduce it any more. It must be fixed already. FYI, when it happened, I traced it down to: shutdown -> dhclient closing fd -> bpf_dtor() -> mac_bpfdesc_destroy() -> mac_bpfdesc_label_free() -> d->bd_label corrupt! bpfmac_labelzone_free() -> uma_zfree() -> ... -> page fault! Any way, sorry for the noise and thanks for fixing this, whoever that is. Jung-uk Kim From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 23:07:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A85F1065670; Wed, 1 Jul 2009 23:07:57 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id DE2418FC14; Wed, 1 Jul 2009 23:07:56 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (host86-150-124-14.range86-150.btcentralplus.com [86.150.124.14]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n61N7kg2027881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 09:07:49 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A4BEC3A.2060108@freebsd.org> Date: Thu, 02 Jul 2009 00:07:38 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Kamigishi Rei References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> In-Reply-To: <4A4BE438.5060203@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-current@freebsd.org, Robert Watson Subject: Re: r194546 amd64: kernel panic in tcp_sack.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 23:07:57 -0000 Kamigishi Rei wrote: > Lawrence Stewart wrote: >> Ok. I'm working on a patch to address a different TCP/SACK issue, but >> it may in fact be partially relevant to the cause of your panic... >> can't promise when I'll be able to take a close look at this but I'm >> aware of it now so that's a start. If you run into it again or find >> the trigger for the panic, please let me know. > Reproduced. I don't know what was the trigger this time. The system runs > lighttpd, fastcgi python and php, mysql and postgresql. hmmm, handy. What is generating the TCP load on this machine? Serving to clients on the Internet? Or machines on a local lan? Is there lots of load? Little bit? > Also, in this core somehow everything looks quite similar (looks like > another page fault but with panic() called prior to getting into fatal > trap 12) to my two earlier dumps: > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008777.html > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008781.html > so maybe it's not really a problem with tcp_sack.c or netisr.c. > No, the two earlier panics look like the same issue as one another, but they are unrelated to this SACK panic. I've CC'd Robert who might have thoughts on the netisr related panics. > Should I attach the core.txt as well? Yes, send it to me directly and I'll take a look. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 23:27:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 932261065678; Wed, 1 Jul 2009 23:27:09 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 49E458FC08; Wed, 1 Jul 2009 23:27:09 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id 1251C78FA7; Thu, 2 Jul 2009 03:27:08 +0400 (MSD) Message-ID: <4A4BF0CE.2070203@haruhiism.net> Date: Thu, 02 Jul 2009 03:27:10 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lawrence Stewart References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> <4A4BEC3A.2060108@freebsd.org> In-Reply-To: <4A4BEC3A.2060108@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: r194546 amd64: kernel panic in tcp_sack.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 23:27:10 -0000 Lawrence Stewart wrote: > hmmm, handy. What is generating the TCP load on this machine? Serving > to clients on the Internet? Or machines on a local lan? Is there lots > of load? Little bit? I've forgot to mention that in both cases with this tcp_sack conditional panic the uptime was approximately 40 hours. -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 23:32:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E73E1065673 for ; Wed, 1 Jul 2009 23:32:10 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3FC8FC13 for ; Wed, 1 Jul 2009 23:32:09 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (host86-150-124-14.range86-150.btcentralplus.com [86.150.124.14]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n61NW1Ne028435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 09:32:03 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A4BF1E9.8030609@freebsd.org> Date: Thu, 02 Jul 2009 00:31:53 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Kamigishi Rei References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> <4A4BEC3A.2060108@freebsd.org> <4A4BF0CE.2070203@haruhiism.net> In-Reply-To: <4A4BF0CE.2070203@haruhiism.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-current@freebsd.org Subject: Re: r194546 amd64: kernel panic in tcp_sack.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 23:32:11 -0000 Kamigishi Rei wrote: > Lawrence Stewart wrote: >> hmmm, handy. What is generating the TCP load on this machine? Serving >> to clients on the Internet? Or machines on a local lan? Is there lots >> of load? Little bit? > I've forgot to mention that in both cases with this tcp_sack conditional > panic the uptime was approximately 40 hours. You didn't mention whether the clients being served were local lan or remote. I ask because tcp_timer_rexmt() is in the backtrace indicating you're getting TCP RTOs firing on the connection that's triggering the panic. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 23:34:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C056F106564A; Wed, 1 Jul 2009 23:34:55 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from fujibayashi.jp (karas.fujibayashi.jp [77.221.159.4]) by mx1.freebsd.org (Postfix) with ESMTP id 764018FC08; Wed, 1 Jul 2009 23:34:55 +0000 (UTC) (envelope-from spambox@haruhiism.net) Received: from [192.168.0.2] (ppp91-122-47-189.pppoe.avangarddsl.ru [91.122.47.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by fujibayashi.jp (Postfix) with ESMTPSA id DD1E178FA7; Thu, 2 Jul 2009 03:34:53 +0400 (MSD) Message-ID: <4A4BF2A0.5040207@haruhiism.net> Date: Thu, 02 Jul 2009 03:34:56 +0400 From: Kamigishi Rei User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Lawrence Stewart References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> <4A4BEC3A.2060108@freebsd.org> <4A4BF0CE.2070203@haruhiism.net> <4A4BF1E9.8030609@freebsd.org> In-Reply-To: <4A4BF1E9.8030609@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: r194546 amd64: kernel panic in tcp_sack.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 23:34:56 -0000 Lawrence Stewart wrote: > You didn't mention whether the clients being served were local lan or > remote. I ask because tcp_timer_rexmt() is in the backtrace indicating > you're getting TCP RTOs firing on the connection that's triggering the > panic. Lighttpd only serves remote clients. Local LAN is a /29 network at the datacenter which is bound to the server (5 IP addresses as aliases). -- Kamigishi Rei KREI-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jul 1 23:54:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF1321065670 for ; Wed, 1 Jul 2009 23:54:23 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id 622288FC16 for ; Wed, 1 Jul 2009 23:54:23 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from blue.tharned.org (blue.tharned.org [10.10.10.8]) (authenticated bits=0) by roadkill.tharned.org (8.14.3/8.14.3) with ESMTP id n61NsMIf078273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jul 2009 18:54:22 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) Date: Wed, 1 Jul 2009 18:54:22 -0500 (CDT) From: Greg Rivers To: Kostik Belousov In-Reply-To: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> Message-ID: References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (roadkill.tharned.org [75.145.12.185]); Wed, 01 Jul 2009 18:54:22 -0500 (CDT) Cc: freebsd-current@freebsd.org Subject: Re: Panic during shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 23:54:24 -0000 On Wed, 1 Jul 2009, Kostik Belousov wrote: >> at /usr/src/sys/vm/vm_object.c:715 >> #6 0xc064d24c in vm_object_deallocate (object=0xc4300000) >> at /usr/src/sys/vm/vm_object.c:592 > I am interested in the output of > p *object > from the frame 6, and the output of > p swap_total > p swap_reserved > all from kgdb. > ... (kgdb) frame 6 #6 0xc064d24c in vm_object_deallocate (object=0xc4300000) at /usr/src/sys/vm/vm_object.c:592 592 vm_object_terminate(object); (kgdb) list 587 * Don't double-terminate, we could be in a termination 588 * recursion due to the terminate having to sync data 589 * to disk. 590 */ 591 if ((object->flags & OBJ_DEAD) == 0) 592 vm_object_terminate(object); 593 else 594 VM_OBJECT_UNLOCK(object); 595 object = temp; 596 } (kgdb) p *object $1 = {mtx = {lock_object = {lo_name = 0xc06ce176 "vm object", lo_flags = 21168128, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4}, object_list = {tqe_next = 0xc43217f8, tqe_prev = 0xc41b1454}, shadow_head = { lh_first = 0x0}, shadow_list = {le_next = 0x0, le_prev = 0xc415c5f4}, memq = {tqh_first = 0x0, tqh_last = 0xc4300028}, root = 0x0, size = 245, generation = 271, ref_count = 0, shadow_count = 0, type = 0 '\0', flags = 12552, pg_color = 250, paging_in_progress = 0, resident_page_count = 0, backing_object = 0x0, backing_object_offset = 0, pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, rvq = { lh_first = 0x0}, cache = 0x0, handle = 0x0, un_pager = {vnp = { vnp_size = 0}, devp = {devp_pglist = {tqh_first = 0x0, tqh_last = 0x0}}, swp = {swp_bcount = 0}}, uip = 0xc3d10340, charge = 1003520} (kgdb) p swap_total $2 = 2147483648 (kgdb) p swap_reserved $3 = 634880 > Also, please describe the load on the machine, > It happens regardless of the load. For example, just booting multi-user and immediately running shutdown (either by logging in or pressing the ACPI power button) triggers the panic. > ... and look up what process exited when the panic happens. > The panic message on the console does not show the process. Can that be determined from kgdb? If so, how? > Thanks for the report. > Thanks for looking into it! -- Greg Rivers From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 01:59:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27E841065670 for ; Thu, 2 Jul 2009 01:59:35 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by mx1.freebsd.org (Postfix) with ESMTP id EA40B8FC20 for ; Thu, 2 Jul 2009 01:59:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f9so469938rvb.43 for ; Wed, 01 Jul 2009 18:59:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=UMSlrs3f5tLXuWTy6jo+cbWUC3lslitqnCRAwCE+95U=; b=ARzv3ximb5jBtKDC4QzAyO+o3FB7cPHGw3gCzAJQLC5VixBqAc+j6Qa0dSwhCOwpi2 QZythlYmu80PgXb2F8Y9ZGhk2cykqfc9npvF2yik1ZfLTLJcvKe5YiW4lcGeTwchfKh/ XyXXGlZ2iWhex5K9s8Rrstx86Z1qKg72SEQFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=o95EtkIccE9x0T/ZH/dbZCz1C5x8FjgdqZZi75RonOyXOSNIHg1DtfGGrN07z017tu S35RImLoWmrcdPxEqdBeIsnP11Hx/Sxv5IvKH43u/SBELRTrV9PgkXrEgZv2fY9LDY08 2gjYzS5Lm+YDL8AtJN/LOVGyHi5vePu0ltblw= Received: by 10.141.3.10 with SMTP id f10mr313605rvi.97.1246499974519; Wed, 01 Jul 2009 18:59:34 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id k37sm8158240rvb.18.2009.07.01.18.59.32 (version=SSLv3 cipher=RC4-MD5); Wed, 01 Jul 2009 18:59:33 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Thu, 2 Jul 2009 10:57:29 +0900 From: Pyun YongHyeon Date: Thu, 2 Jul 2009 10:57:29 +0900 To: Alexey Dokuchaev Message-ID: <20090702015729.GE13137@michelle.cdnetworks.co.kr> References: <20090701162108.GA33681@regency.nsu.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090701162108.GA33681@regency.nsu.ru> User-Agent: Mutt/1.4.2.3i Cc: current@freebsd.org Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 01:59:35 -0000 On Wed, Jul 01, 2009 at 11:21:08PM +0700, Alexey Dokuchaev wrote: > Hello there, > > I've started to observe the following rather annoying panic if I boot > with if_sf loaded (via loader.conf) and having sf0 configured via DHCP > on recent -CURRENT. If I comment out driver from loader.conf and load > it manually (via kldload(8)) after system boots, it loads and gets > configured just fine. > Hmm, sf(4) also calls me. :-( I can't reproduce this on 10 days old CURRENT box so will try reproduce it on latest CURRENT. > Any clues here? Attached is relevant dmesg + DDB trace (debug kernel > with WITNESS). I'm happy to provide any additional information (that > is, ps/show uma/malloc, whatever). > Still have no idea why it panicked but can you let me know the line number of sf_stop+0x130? > Thanks. > > ./danfe > sf0: link state changed to UP > Starting Network: lo0 sf0. > sf1: link state changed to DOWN > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ > sys/modules/sf/../../dev/sf/if_sf.c:1971 > KDB: stack backtrace: > db_trace_self_wrapper(c0683396,d655e808,c05188c5,c0fd7bc2,7b3,...) at db_trace_s > elf_wrapper+0x26 > kdb_backtrace(c0fd7bc2,7b3,ffffffff,c0eb2914,d655e840,...) at kdb_backtrace+0x29 > _witness_debugger(c0685907,d655e854,4,1,0,...) at _witness_debugger+0x25 > witness_warn(5,0,c06a5f7f,d655e890,c3537d48,...) at witness_warn+0x1fd > trap(d655e8e0) at trap+0x192 > calltrap() at calltrap+0x6 > --- trap 0xc, eip = 0xc062cec2, esp = 0xd655e920, ebp = 0xd655e954 --- > _bus_dmamap_sync(c3551c80,c3573000,2,90a,6000,...) at _bus_dmamap_sync+0xa2 > sf_stop(c3551d80,4,c0fd7bc2,7c1,c3556c70,...) at sf_stop+0x130 > sf_init_locked(c356c584,0,c0fd7bc2,7b3,c36e3c00,...) at sf_init_locked+0x50 > sf_init(c356b000,c356b000,0,0,c36e3cbb,...) at sf_init+0x3c > ether_ioctl(c3554c00,8020690c,c36e3c00,d655ea38,456bc5b,...) at ether_ioctl+0x41 > in_ifinit(0,c36e3c00,1aa,1a6,c0eb2910,...) at in_ifinit+0x2a6 > in_control(c377bce0,8040691a,c35a26c0,c3554c00,c36b9720,...) at in_control+0xd7b > ifioctl(c377bce0,8040691a,c35a26c0,c36b9720,4,...) at ifioctl+0x157d > soo_ioctl(c36a57e0,8040691a,c35a26c0,c34a9b00,c36b9720,...) at soo_ioctl+0x3d2 > kern_ioctl(c36b9720,4,8040691a,c35a26c0,6b9884,...) at kern_ioctl+0x1dd > ioctl(c36b9720,d655ecf8,419,c06a5e55,c36b9720,...) at ioctl+0x134 > syscall(d655ed38) at syscall+0x323 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281bf8a3, esp = 0xbfbfe5bc, ebp > = 0xbfbfe5f8 --- > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x400000c > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc062cec2 > stack pointer = 0x28:0xd655e920 > frame pointer = 0x28:0xd655e954 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 453 (ifconfig) > [thread pid 453 tid 100040 ] > Stopped at _bus_dmamap_sync+0xa2: movl 0xc(%ebx),%eax > db> show pcpu > cpuid = 0 > dynamic pcpu = 0xd3c597 > curthread = 0xc36b9720: pid 453 "ifconfig" > curpcb = 0xd655ed90 > fpcurthread = none > idlethread = 0xc34adbe0: pid 10 "idle" > APIC ID = 0 > currentldt = 0x50 > spin locks held: > db> show allpcpu > Current CPU: 0 > > cpuid = 0 > dynamic pcpu = 0xd3c597 > curthread = 0xc36b9720: pid 453 "ifconfig" > curpcb = 0xd655ed90 > fpcurthread = none > idlethread = 0xc34adbe0: pid 10 "idle" > APIC ID = 0 > currentldt = 0x50 > spin locks held: > db> show locks > exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ > sys/modules/sf/../../dev/sf/if_sf.c:1971 > db> show alllocks > Process 453 (ifconfig) thread 0xc36b9720 (100040) > exclusive sleep mutex sf0 (network driver) r = 0 (0xc356c584) locked @ /usr/src/ > sys/modules/sf/../../dev/sf/if_sf.c:1971 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 04:03:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7281C106564A for ; Thu, 2 Jul 2009 04:03:55 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by mx1.freebsd.org (Postfix) with ESMTP id 45F028FC08 for ; Thu, 2 Jul 2009 04:03:55 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rv-out-0506.google.com with SMTP id l9so2001439rvb.3 for ; Wed, 01 Jul 2009 21:03:54 -0700 (PDT) Received: by 10.140.208.16 with SMTP id f16mr4189485rvg.263.1246506108797; Wed, 01 Jul 2009 20:41:48 -0700 (PDT) Received: from ?10.0.1.198? (udp016664uds.hawaiiantel.net [72.235.41.117]) by mx.google.com with ESMTPS id g14sm8491049rvb.44.2009.07.01.20.41.44 (version=SSLv3 cipher=RC4-MD5); Wed, 01 Jul 2009 20:41:46 -0700 (PDT) Date: Wed, 1 Jul 2009 17:41:34 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Randall Stewart In-Reply-To: <2BE0378C-96A3-4714-A5C3-7B1A6AA0DCE2@lakerest.net> Message-ID: References: <951233.95131.qm@web39108.mail.mud.yahoo.com> <3c1674c90905302055g542cfadarf201cc273639977d@mail.gmail.com> <4A23919F.8050905@mail.zedat.fu-berlin.de> <4A2B3040.7020509@poildetroll.net> <3bbf2fe10906070339k663bace7qe5142702248ce6c9@mail.gmail.com> <4A2BBDC0.6000801@poildetroll.net> <3bbf2fe10906070623o65ce021fkb7f59fe1924cc1ec@mail.gmail.com> <4A353E21.1080001@poildetroll.net> <2BE0378C-96A3-4714-A5C3-7B1A6AA0DCE2@lakerest.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Pierre Guinoiseau , "O. Hartmann" , Attilio Rao , bf , freebsd-current@freebsd.org, Kip Macy Subject: Re: signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 04:03:55 -0000 On Tue, 23 Jun 2009, Randall Stewart wrote: > One thing I have noticed for a while.. and have not > been able to track down.. > > If one runs > > /usr/src/tools/tools/syscall_timing/syscall_timing > > On a 7.2 kernel and compare it on the same machine to an 8.0 kernel > you will see almost a 3x slow down in 8. > > Yes I have 8.0 without witness and all the debug. The thing > that is most interesting is I even ran 8 on a 7.2 user space... > same result. > > My AMD 64 1.6Gig 8 core machines (in SMP) are showing > > 250ns or so for getuid 1000 times on 7.2 > and > 880ns or so for getuid 1000 times on 8.0 This is due to Kib's segment changes in current. I found it with hwpmc and he has produced a patch which fixes it. It will be in after beta 1. Thank you for reporting it. Jeff > > I started tracking this in 7.1.. > > When I get some more time next week I will do some more digging.. not sure > its related to this issue though > > R > > On Jun 14, 2009, at 2:14 PM, Pierre Guinoiseau wrote: > >> Hi again, >> >> I don't know if it can be of better help or not, but I made 2 other >> dumps, before and after the slowdown, and without X running and all... I >> recompiled some packages several times to make the slowdown appear. >> >> The dumps are here : http://foo.poildetroll.net/freebsd/ktr/ >> >> Thanks again for your help! >> >> Pierre Guinoiseau >> >> >> Attilio Rao wrote: >>> 2009/6/7 Pierre Guinoiseau : >>>> Ok, here is a ktr output. This time, the slowdown appeared while >>>> recompiling thunderbird. I have 2 core at 2.2Ghz (and powerd running, I >>>> don't know if it matters). >>>> >>>> BTW, what is the use of py-tkinter ? If it was in order to cause the >>>> bug, it failed, it needed a higher load. :) >>> >>> Ah sorry, I was supposed to let you run schedgraph but I'm going to do >>> that, so you actually didn't need it >>> I will let you know if something cames up. >>> If others can report the same it will be great. >>> >>> Thanks, >>> Attilio >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >> > > ------------------------------ > Randall Stewart > 803-317-4952 (cell) > 803-345-0391(direct) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 08:23:01 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 909E1106566C for ; Thu, 2 Jul 2009 08:23:01 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from ch-smtp01.sth.basefarm.net (ch-smtp01.sth.basefarm.net [80.76.149.212]) by mx1.freebsd.org (Postfix) with ESMTP id 4BE9F8FC08 for ; Thu, 2 Jul 2009 08:23:01 +0000 (UTC) (envelope-from serenity@exscape.org) Received: from c83-253-252-234.bredband.comhem.se ([83.253.252.234]:38448 helo=mx.exscape.org) by ch-smtp01.sth.basefarm.net with esmtp (Exim 4.69) (envelope-from ) id 1MMHZG-00082D-56; Thu, 02 Jul 2009 10:22:56 +0200 Received: from [192.168.1.5] (macbookpro [192.168.1.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx.exscape.org (Postfix) with ESMTPSA id 00CF36A5A3; Thu, 2 Jul 2009 10:22:52 +0200 (CEST) From: Thomas Backman To: Pegasus Mc Cleaft In-Reply-To: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> X-Priority: 3 References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> Message-Id: <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 10:22:51 +0200 X-Mailer: Apple Mail (2.935.3) X-Originating-IP: 83.253.252.234 X-Scan-Result: No virus found in message 1MMHZG-00082D-56. X-Scan-Signature: ch-smtp01.sth.basefarm.net 1MMHZG-00082D-56 2283fd5c6324b1d21301e07bce62663b Cc: current@freebsd.org Subject: Re: Has anyone been able to actually boot the AMD64 kernel after r194958? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 08:23:01 -0000 On Jul 1, 2009, at 04:23 PM, Pegasus Mc Cleaft wrote: > Hi Current, > > I was wondering.. Has anyone actually been able to boot a kernel > after r194958? On 2 different machine (simmilar archecture) the > system will kernel-trap right after attemping to mount the ZFS > filesystems. I dont know if it is ZFS related or not as I am not > able to get a core. It complains that no dump device has been > defined and then locks up... > > If there is a way that I can provide more information, please let > me know how and I will post it. > > Thanks again, > Peg I tried this after reading this thread, and no problems whatsoever. gptzfsboot. [root@clone ~]# uname -a FreeBSD clone.exscape.org 8.0-CURRENT FreeBSD 8.0-CURRENT #3 r195244M: Wed Jul 1 23:03:10 CEST 2009 root@clone.exscape.org:/usr/obj/usr/ src/sys/DTRACE amd64 [root@clone ~]# df -h Filesystem Size Used Avail Capacity Mounted on rpool 7.5G 461M 7.0G 6% / devfs 1.0K 1.0K 0B 100% /dev rpool/tmp 7.0G 10M 7.0G 0% /tmp rpool/usr 9.3G 2.2G 7.0G 24% /usr rpool/usr/ports 7.2G 199M 7.0G 3% /usr/ ports rpool/usr/src 7.5G 434M 7.0G 6% /usr/src rpool/var 7.1G 104M 7.0G 1% /var rpool/var/crash 7.0G 0B 7.0G 0% /var/ crash Regards, Thomas From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 08:37:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6DDD1065674; Thu, 2 Jul 2009 08:37:18 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 5CEE98FC1A; Thu, 2 Jul 2009 08:37:18 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MMHn8-0003vd-Ip; Thu, 02 Jul 2009 09:37:17 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MMHn4-0000EO-QI; Thu, 02 Jul 2009 09:37:11 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n628bAFW066873; Thu, 2 Jul 2009 09:37:10 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n628b9J3066872; Thu, 2 Jul 2009 09:37:09 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Thu, 2 Jul 2009 09:37:09 +0100 From: Anton Shterenlikht To: Wojciech Puchar Message-ID: <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.2 X-Spam-Level: - Cc: Marcel Moolenaar , Anton Shterenlikht , freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 08:37:19 -0000 On Wed, Jul 01, 2009 at 10:00:54PM +0200, Wojciech Puchar wrote: > >> It's better to use gmirror per partition. > > > > Like this? > > > > # gmirror label -vb round-robin root /dev/da0p2 > > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > isn't that partition accessed by other process or mounted? should it not be mounted? Sorry, I was just following the handbook, but I now understand it is incorrect when it comes to ia64. many thanks anton > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 08:41:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00D6D106564A for ; Thu, 2 Jul 2009 08:41:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 8F1698FC13 for ; Thu, 2 Jul 2009 08:41:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n628fnfG012973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 11:41:50 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n628fnsB080659; Thu, 2 Jul 2009 11:41:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n628fn41080658; Thu, 2 Jul 2009 11:41:49 +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, 2 Jul 2009 11:41:49 +0300 From: Kostik Belousov To: Greg Rivers Message-ID: <20090702084149.GE2884@deviant.kiev.zoral.com.ua> References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="307FGJNKNK2k8fNP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-current@freebsd.org Subject: Re: Panic during shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 08:41:55 -0000 --307FGJNKNK2k8fNP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 01, 2009 at 06:54:22PM -0500, Greg Rivers wrote: > On Wed, 1 Jul 2009, Kostik Belousov wrote: >=20 > >> at /usr/src/sys/vm/vm_object.c:715 > >>#6 0xc064d24c in vm_object_deallocate (object=3D0xc4300000) > >> at /usr/src/sys/vm/vm_object.c:592 > >I am interested in the output of > >p *object > >from the frame 6, and the output of > >p swap_total > >p swap_reserved > >all from kgdb. > > >=20 > ... > (kgdb) frame 6 > #6 0xc064d24c in vm_object_deallocate (object=3D0xc4300000) > at /usr/src/sys/vm/vm_object.c:592 > 592 vm_object_terminate(object); > (kgdb) list > 587 * Don't double-terminate, we could be in a=20 > termination > 588 * recursion due to the terminate having to sync= =20 > data > 589 * to disk. > 590 */ > 591 if ((object->flags & OBJ_DEAD) =3D=3D 0) > 592 vm_object_terminate(object); > 593 else > 594 VM_OBJECT_UNLOCK(object); > 595 object =3D temp; > 596 } > (kgdb) p *object > $1 =3D {mtx =3D {lock_object =3D {lo_name =3D 0xc06ce176 "vm object", > lo_flags =3D 21168128, lo_data =3D 0, lo_witness =3D 0x0}, mtx_lock= =3D 4}, > object_list =3D {tqe_next =3D 0xc43217f8, tqe_prev =3D 0xc41b1454}, sha= dow_head=20 > =3D { > lh_first =3D 0x0}, shadow_list =3D {le_next =3D 0x0, le_prev =3D 0xc4= 15c5f4}, > memq =3D {tqh_first =3D 0x0, tqh_last =3D 0xc4300028}, root =3D 0x0, si= ze =3D 245, > generation =3D 271, ref_count =3D 0, shadow_count =3D 0, type =3D 0 '\0= ', > flags =3D 12552, pg_color =3D 250, paging_in_progress =3D 0, > resident_page_count =3D 0, backing_object =3D 0x0, backing_object_offse= t =3D 0, > pager_object_list =3D {tqe_next =3D 0x0, tqe_prev =3D 0x0}, rvq =3D { > lh_first =3D 0x0}, cache =3D 0x0, handle =3D 0x0, un_pager =3D {vnp = =3D { > vnp_size =3D 0}, devp =3D {devp_pglist =3D {tqh_first =3D 0x0, tqh_= last =3D=20 > 0x0}}, > swp =3D {swp_bcount =3D 0}}, uip =3D 0xc3d10340, charge =3D 1003520} > (kgdb) p swap_total > $2 =3D 2147483648 > (kgdb) p swap_reserved > $3 =3D 634880 >=20 >=20 > >Also, please describe the load on the machine, > > >=20 > It happens regardless of the load. For example, just booting multi-user= =20 > and immediately running shutdown (either by logging in or pressing the=20 > ACPI power button) triggers the panic. No, it does not happen regardless of the load. The patch was tested on the semi-standard set of programs run on the system, and all seen accounting mistakes were fixed. You have some process that does exhibit the behaviour causing error in swap accounting. I think for start you could just show me ps auxww output, in private, if you prefer. >=20 >=20 > >... and look up what process exited when the panic happens. > > >=20 > The panic message on the console does not show the process. Can that be= =20 > determined from kgdb? If so, how? It does show the process, like KDB: enter: panic [thread pid 32021 tid 100598 ] there, you can look up pid/tid and then do ps in ddb to look at the process= es. Also, you may do "show allpcpu" in ddb. In kgdb, info threads should do the trick, AFAIR. BTW, did you saw the kernel messages like negative vmsize for uid =3D XXX ? --307FGJNKNK2k8fNP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpMcs0ACgkQC3+MBN1Mb4g7JQCgvjHd1tzpGSA5OL+ygyrYw4sA JwoAniNYUB1K6jVVLtMyrTpJ5idCQtyM =RsfX -----END PGP SIGNATURE----- --307FGJNKNK2k8fNP-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 11:14:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A593E10656B7 for ; Thu, 2 Jul 2009 11:14:07 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 5A2978FC14 for ; Thu, 2 Jul 2009 11:14:07 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from stasss.yandex.ru (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id 78CC68FC27; Thu, 2 Jul 2009 15:14:04 +0400 (MSD) Date: Thu, 2 Jul 2009 15:13:54 +0400 From: Stanislav Sedov To: pyunyh@gmail.com Message-Id: <20090702151354.75dff22a.stas@FreeBSD.org> In-Reply-To: <20090702015729.GE13137@michelle.cdnetworks.co.kr> References: <20090701162108.GA33681@regency.nsu.ru> <20090702015729.GE13137@michelle.cdnetworks.co.kr> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__2_Jul_2009_15_13_54_+0400_G1tzkFjVhsWpFeiQ" Cc: Alexey Dokuchaev , current@freebsd.org Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 11:14:08 -0000 --Signature=_Thu__2_Jul_2009_15_13_54_+0400_G1tzkFjVhsWpFeiQ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 2 Jul 2009 10:57:29 +0900 Pyun YongHyeon mentioned: >=20 > Still have no idea why it panicked but can you let me know the line > number of sf_stop+0x130? >=20 It looks like a memory corruption issue. From the information he provided it appears that sc contains 0x400000 while a couple of lines before busdma_= sync it had the correct value (otherwise it would have paniced earlier. --=20 Stanislav Sedov ST4096-RIPE --Signature=_Thu__2_Jul_2009_15_13_54_+0400_G1tzkFjVhsWpFeiQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKTJZ6AAoJEKN82nOYvCd0f0EP/1Fy725Ah2vSnrDtnCoJEyoJ e+WWfF8bJBG4tgLTog2OiPNpVNb1Kzeiv2auC6pyMQkDHRs09H7mbokrG+BzO/4c FJ8vGbugY4nfFh4GrZflXyhUUs6oPACDS600Tnsm3yTihrCtKJaxpXCbnRZG6R2o flv2h6lqO27uB6zVTFuyr3KpZCukbZLKLHFYybVQvbIfvSiN6e3VVqb7WwJm004i QPtHdL/Rkp62WUTzeGTomyXQPe2Bn/XBX9OJ9L/e8pDuByXHM7esYql3F5bGId39 bCP/6f3j24hWl3+RVRVrhp3dhSMvr6lkAumxuq0Z19izdYkW+oisnb3PDPBm03+d kEnT7AmD18RXNMrdeo69hFlc9FNptDAgUFVPvaeIWILdQJpCv2tGT+OQpZkne0kZ 3JpO5LW/CTEq6Cg4ijazf0CAuGy/Tkan06FtSWw0TrFtXFwwQcLrE/GkV+8hJCk1 A/MrJZkVQJJWZi2xZ/GDYjzHXIWoqCDs406UuTkJIe5Ft7FWBa2//cTGiYvfoca8 4JjkV+nWSNHaRUCLhgny2rc0qWz5yY7hgulF7FXX7qbMXZhDv7THtAfCjCOSujJ3 xc0+jVyvIR1JfU5L+/CzgJgZ/dwKhgLHdI9d/ydAaW/jAMTWFDf/MfoAokxqj/1f G6sjWl92pDmlHh6YCpPZ =FmtM -----END PGP SIGNATURE----- --Signature=_Thu__2_Jul_2009_15_13_54_+0400_G1tzkFjVhsWpFeiQ-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 11:15:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F17771065697 for ; Thu, 2 Jul 2009 11:15:08 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id AA8C38FC08 for ; Thu, 2 Jul 2009 11:15:08 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from stasss.yandex.ru (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id DB90C8FC2B; Thu, 2 Jul 2009 15:15:07 +0400 (MSD) Date: Thu, 2 Jul 2009 15:15:07 +0400 From: Stanislav Sedov To: Alexey Dokuchaev Message-Id: <20090702151507.c997fa89.stas@FreeBSD.org> In-Reply-To: <20090701162108.GA33681@regency.nsu.ru> References: <20090701162108.GA33681@regency.nsu.ru> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__2_Jul_2009_15_15_07_+0400_N1wlHRunmq2zob4W" Cc: current@freebsd.org Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 11:15:09 -0000 --Signature=_Thu__2_Jul_2009_15_15_07_+0400_N1wlHRunmq2zob4W Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, 1 Jul 2009 23:21:08 +0700 Alexey Dokuchaev mentioned: > Hello there, >=20 > I've started to observe the following rather annoying panic if I boot > with if_sf loaded (via loader.conf) and having sf0 configured via DHCP > on recent -CURRENT. If I comment out driver from loader.conf and load > it manually (via kldload(8)) after system boots, it loads and gets > configured just fine. >=20 > Any clues here? Attached is relevant dmesg + DDB trace (debug kernel > with WITNESS). I'm happy to provide any additional information (that > is, ps/show uma/malloc, whatever). >=20 Hi, Alexey! Do you use SMP system? --=20 Stanislav Sedov ST4096-RIPE --Signature=_Thu__2_Jul_2009_15_15_07_+0400_N1wlHRunmq2zob4W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKTJa7AAoJEKN82nOYvCd0m+MP/j9w1E7sVOo6cLmMfVT0IhkA egAzQjG8u9T7SMMTFkTUDlABtZUvanNP68HRysaJzMeWSWGImbSt1dPxFhcPiiHF yJ61FXmpmKgrbcTHWi2/T1cI6YdCXh8O1p2OCNmbA/rnJ1L2x97+gnymb1ZsTZJW 1PdYXw1/W1rEsYEZ8ElRk1keaV2mSXfP5uncrNWkdTt/SJ43gxu1ZWhb31mHFHj4 QDB4dcCKTrm5iffHOZs7vfmKK+P4SEoItf3O9NtOVXL8eTG8rof/s0+JEPmoYRJW Z6jJB27PJaAnpFwfXLX4AJoRd5a1HGinKXNTxxtVEGpm4yYqLLEqPvxI6MkQ7rhs VJDzrwFGKUoCvHwisqqFscQ1sDLCvDbYMaNn3/bTntBdYV4sgqptEfaF+ASgqILb AqlgekZ+Knfjt3iXFDKbS1UeAyvY9p9vJ9kCaAy/ngGTbKWLE2cun5V4EBU/JhHS cqQYfBy0bGnF/fBoaIbNnlAju3Rk/SFSHgvy7zxvzHC/V5kAw+oNmf7jNZJoZgwt kgh3ebeooDY7cGfyFdtFqs82tsvu+qQ2dTs1Bv6OhSC7bne942XxxcEMr1ZsPxp+ cywN9PlE3JxowxHn8SJyHU6XS2gqxJzPqdItuVvXatrygMN9k4/asbO/0jHG41G8 iboUM+OMDuOPok2v8smU =vmy3 -----END PGP SIGNATURE----- --Signature=_Thu__2_Jul_2009_15_15_07_+0400_N1wlHRunmq2zob4W-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 11:49:36 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A75D9106564A for ; Thu, 2 Jul 2009 11:49:36 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from smtp.semihalf.com (smtp.semihalf.com [213.17.239.109]) by mx1.freebsd.org (Postfix) with ESMTP id 60F9D8FC1D for ; Thu, 2 Jul 2009 11:49:36 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from [10.0.0.34] (cardhu.semihalf.com [213.17.239.108]) by smtp.semihalf.com (Postfix) with ESMTPSA id B7DF6C3AAA for ; Thu, 2 Jul 2009 13:30:55 +0200 (CEST) Message-Id: From: Rafal Jaworowski To: current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 2 Jul 2009 13:32:08 +0200 X-Mailer: Apple Mail (2.935.3) Cc: Subject: MD5 test slowdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 11:49:36 -0000 I'm observing some heavy slowdown seen with md5 test on PowerPC: 1. On the MPC8572 machine with today's HEAD I'm getting: # md5 -t MD5 time trial. Digesting 100000 10000-byte blocks ... done Digest = 766a2bb5d24bddae466c572bcabca3ee Time = 36.930565 seconds Speed = 27077842.000000 bytes/second 2. While a couple of months back it yielded 6x shorter times on this very same hardware, like this one: # md5 -t MD5 time trial. Digesting 100000 10000-byte blocks ... done Digest = 766a2bb5d24bddae466c572bcabca3ee Time = 6.027277 seconds Speed = 165912400.000000 bytes/second Timers work fine, the slowdown is real. I don't know if this is PowerPC related, and was wondering if anybody observed something similar on other archs perhaps? Any suggestions what could be causing this or where to look? I cannot see immediate suspects in the arch/ platform code. Rafal From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 12:20:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0B75B10656A4 for ; Thu, 2 Jul 2009 12:20:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id A3BEB8FC19 for ; Thu, 2 Jul 2009 12:20:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 666C841C7D9 for ; Thu, 2 Jul 2009 14:20:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id 2AybKVr77wLL for ; Thu, 2 Jul 2009 14:20:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 8C3E241C7E9; Thu, 2 Jul 2009 14:20:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 48FE44448E6 for ; Thu, 2 Jul 2009 12:18:38 +0000 (UTC) Date: Thu, 2 Jul 2009 12:18:38 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20090702121640.D245@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1237793657-1246537118=:245" Cc: Subject: Install from NFS onto NFS fails on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 12:20:08 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1237793657-1246537118=:245 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi, trying to installworld from NFS to NFS (which also is the NFS Root of the installing and to be updated machien) on amd64 always fails with this error. Anyone knows why that is? ------------------------------------------------------------------------ lion1# make installworld -DNO_FSCHG =2E.. =2E.. =2E.. =2E.. =3D=3D=3D> libkafs5 (install) install -C -o root -g wheel -m 444 libkafs5.a /usr/lib32 install -C -o root -g wheel -m 444 libkafs5_p.a /usr/lib32 install -s -o root -g wheel -m 444 libkafs5.so.10 /usr/lib32 ln -fs libkafs5.so.10 /usr/lib32/libkafs5.so =3D=3D=3D> libkrb5 (install) install -C -o root -g wheel -m 444 libkrb5.a /usr/lib32 install -C -o root -g wheel -m 444 libkrb5_p.a /usr/lib32 install -s -o root -g wheel -m 444 libkrb5.so.10 /usr/lib32 ln -fs libkrb5.so.10 /usr/lib32/libkrb5.so =3D=3D=3D> libroken (install) install -C -o root -g wheel -m 444 libroken.a /usr/lib32 install -C -o root -g wheel -m 444 libroken_p.a /usr/lib32 install -s -o root -g wheel -m 444 libroken.so.10 /usr/lib32 ln -fs libroken.so.10 /usr/lib32/libroken.so =3D=3D=3D> libsl (install) =3D=3D=3D> libvers (install) cd /zoo/bz/HEAD.svn/libexec/rtld-elf; PROG=3Dld-elf32.so.1 MAKEOBJDIRPREFI= X=3D/usr/obj/lib32 _SHLIBDIRPREFIX=3D/usr/obj/zoo/bz/HEAD.svn/lib32 VERSION= =3D"FreeBSD 8.0-CURRENT amd64 800101" MACHINE=3Di386 MACHINE_ARCH=3Di386 PA= TH=3D/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/= tmp/legacy/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/games:/usr/obj/z= oo/bz/HEAD.svn/tmp/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/bin:/usr/obj/z= oo/bz/HEAD.svn/tmp/usr/games:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/sbin:/= usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/leg= acy/usr/games:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/sbin:/usr/obj/zoo/bz/HEAD.sv= n/tmp/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/games:/tmp/install.uMl44I7W = CC=3D"cc -m32 -march=3Di686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32= BIT -iprefix /usr/obj/zoo/bz/HEAD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.s= vn/lib32/usr/lib32 -B/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" CXX=3D"c++ = -m32 -march=3Di686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -ipr= efix /usr/obj/zoo/bz/HEAD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.svn/lib32/= usr/lib32 -B/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" OBJC=3D"cc -m32 -mar= ch=3Di686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr= /obj/zoo/bz/HEAD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32= -B/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" LD=3D"ld -m elf_i386_fbsd -Y = P,/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" AS=3D"as --32" LIBDIR=3D/usr/li= b32 SHLIBDIR=3D/usr/lib32 make -DNO_CPU_CFLAGS -DCOMPAT_32BIT -DWITHOUT_BIN= D -DWITHOUT_MAN -DWITHOUT_INFO -DWITHOUT_HTML -DNO_CTF -DNO_INCS install chflags noschg /usr/libexec/ld-elf32.so.1 install -s -o root -g wheel -m 555 -C -b -S ld-elf32.so.1 /libexec /usr/libexec/ld-elf32.so.1 -> /libexec/ld-elf32.so.1 cd /zoo/bz/HEAD.svn/usr.bin/ldd; PROG=3Dldd32 MAKEOBJDIRPREFIX=3D/usr/obj/l= ib32 _SHLIBDIRPREFIX=3D/usr/obj/zoo/bz/HEAD.svn/lib32 VERSION=3D"FreeBSD 8.= 0-CURRENT amd64 800101" MACHINE=3Di386 MACHINE_ARCH=3Di386 PATH=3D/usr/obj/= zoo/bz/HEAD.svn/tmp/legacy/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr= /bin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/games:/usr/obj/zoo/bz/HEAD.svn= /tmp/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/bin:/usr/obj/zoo/bz/HEAD.svn= /tmp/usr/games:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/sbin:/usr/obj/zoo/bz= /HEAD.svn/tmp/legacy/usr/bin:/usr/obj/zoo/bz/HEAD.svn/tmp/legacy/usr/games:= /usr/obj/zoo/bz/HEAD.svn/tmp/usr/sbin:/usr/obj/zoo/bz/HEAD.svn/tmp/usr/bin:= /usr/obj/zoo/bz/HEAD.svn/tmp/usr/games:/tmp/install.uMl44I7W CC=3D"cc -m32 = -march=3Di686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix = /usr/obj/zoo/bz/HEAD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.svn/lib32/usr/l= ib32 -B/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" CXX=3D"c++ -m32 -march=3D= i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/= zoo/bz/HEAD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32 -B/= usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32" OBJC=3D"cc -m32 -march=3Di686 -mmm= x -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT -iprefix /usr/obj/zoo/bz/HE= AD.svn/lib32/usr/ -L/usr/obj/zoo/bz/HEAD.svn/lib32/usr/lib32 -B/usr/obj/z= oo/bz/HEAD.svn/lib32/usr/lib32" LD=3D"ld -m elf_i386_fbsd -Y P,/usr/obj/zoo= /bz/HEAD.svn/lib32/usr/lib32" AS=3D"as --32" LIBDIR=3D/usr/lib32 SHLIBDIR= =3D/usr/lib32 make -DNO_CPU_CFLAGS -DCOMPAT_32BIT -DWITHOUT_BIND -DWITHOUT_= MAN -DWITHOUT_INFO -DWITHOUT_HTML -DNO_CTF -DNO_INCS install install -s -o root -g wheel -m 555 ldd32 /usr/bin rm: /tmp/install.uMl44I7W: Directory not empty *** Error code 1 Stop in /zoo/bz/HEAD.svn. *** Error code 1 Stop in /zoo/bz/HEAD.svn. lion1#=20 ------------------------------------------------------------------------ --=20 Bjoern A. Zeeb The greatest risk is not taking one. --0-1237793657-1246537118=:245-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 12:35:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82B3A1065675 for ; Thu, 2 Jul 2009 12:35:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 367A18FC29 for ; Thu, 2 Jul 2009 12:35:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 5D1C541C7D4 for ; Thu, 2 Jul 2009 14:35:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id xW87SvYXedFn for ; Thu, 2 Jul 2009 14:35:05 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id B1EBD41C7DF; Thu, 2 Jul 2009 14:35:05 +0200 (CEST) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 70A184448E6 for ; Thu, 2 Jul 2009 12:31:16 +0000 (UTC) Date: Thu, 2 Jul 2009 12:31:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list In-Reply-To: <20090702121640.D245@maildrop.int.zabbadoz.net> Message-ID: <20090702122955.J245@maildrop.int.zabbadoz.net> References: <20090702121640.D245@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: Re: Install from NFS onto NFS fails on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 12:35:07 -0000 On Thu, 2 Jul 2009, Bjoern A. Zeeb wrote: > Hi, > > trying to installworld from NFS to NFS (which also is the NFS Root > of the installing and to be updated machien) on amd64 always fails > with this error. Anyone knows why that is? > > ------------------------------------------------------------------------ > lion1# make installworld -DNO_FSCHG > ... > ... > ... > install -s -o root -g wheel -m 555 ldd32 /usr/bin > rm: /tmp/install.uMl44I7W: Directory not empty > *** Error code 1 > > Stop in /zoo/bz/HEAD.svn. > *** Error code 1 > > Stop in /zoo/bz/HEAD.svn. > lion1# > ------------------------------------------------------------------------ I probably should have added that the directory is empty: lion1# ls -la /tmp/install.uMl44I7W total 4 drwxr-xr-x 2 root wheel 1024 Jul 2 12:15 . drwxrwxrwt 15 root wheel 1024 Jul 2 12:10 .. and I am well aware that that is one of the last things that make installworld does; it's just strange and I blame it on NFS;-) /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 14:02:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96985106564A; Thu, 2 Jul 2009 14:02:31 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojteks.tensor.gdynia.pl (wojteks.tensor.gdynia.pl [IPv6:2001:4070:101:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id A971B8FC15; Thu, 2 Jul 2009 14:02:30 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [IPv6:2001:4070:101:2::2]) by wojteks.tensor.gdynia.pl (8.14.3/8.14.3) with ESMTP id n62E2atR012668; Thu, 2 Jul 2009 16:02:36 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3) with ESMTP id n62DmgDc002283; Thu, 2 Jul 2009 15:48:42 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.3/8.14.3/Submit) with ESMTP id n62Dmfbi002280; Thu, 2 Jul 2009 15:48:41 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Thu, 2 Jul 2009 15:48:41 +0200 (CEST) From: Wojciech Puchar To: Anton Shterenlikht In-Reply-To: <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> Message-ID: References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 02 Jul 2009 14:16:02 +0000 Cc: freebsd-ia64@freebsd.org, Marcel Moolenaar , freebsd-questions@freebsd.org, freebsd-current@freebsd.org Subject: Re: gmirror per partition. Was: Re: gmirror gm0 destroyed on shutdown; GPT corrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:02:32 -0000 >>> >>> # gmirror label -vb round-robin root /dev/da0p2 >>> gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. >> isn't that partition accessed by other process or mounted? > > should it not be mounted? yes it should not, no matter what architecture. From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 14:50:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60355106564A for ; Thu, 2 Jul 2009 14:50:37 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id C1D7C8FC12 for ; Thu, 2 Jul 2009 14:50:36 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from [192.168.0.154] (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.3/8.14.2) with ESMTP id n62EoVT5089968; Thu, 2 Jul 2009 15:50:32 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4A4CC937.5050008@fletchermoorland.co.uk> Date: Thu, 02 Jul 2009 15:50:31 +0100 From: Paul Wootton User-Agent: Thunderbird 2.0.0.21 (X11/20090504) MIME-Version: 1.0 To: current@freebsd.org References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> In-Reply-To: <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.64 on 192.168.0.1 Cc: Pegasus Mc Cleaft , Thomas Backman Subject: Re: Has anyone been able to actually boot the AMD64 kernel after r194958? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:50:37 -0000 Thomas Backman wrote: > On Jul 1, 2009, at 04:23 PM, Pegasus Mc Cleaft wrote: > >> Hi Current, >> >> I was wondering.. Has anyone actually been able to boot a kernel >> after r194958? On 2 different machine (simmilar archecture) the >> system will kernel-trap right after attemping to mount the ZFS >> filesystems. I dont know if it is ZFS related or not as I am not able >> to get a core. It complains that no dump device has been defined and >> then locks up... >> >> If there is a way that I can provide more information, please let >> me know how and I will post it. >> >> Thanks again, >> Peg > I tried this after reading this thread, and no problems whatsoever. > gptzfsboot. > > [root@clone ~]# uname -a > FreeBSD clone.exscape.org 8.0-CURRENT FreeBSD 8.0-CURRENT #3 r195244M: > Wed Jul 1 23:03:10 CEST 2009 > root@clone.exscape.org:/usr/obj/usr/src/sys/DTRACE amd64 > [root@clone ~]# df -h > Filesystem Size Used Avail Capacity > Mounted on > rpool 7.5G 461M 7.0G 6% / > devfs 1.0K 1.0K 0B 100% /dev > rpool/tmp 7.0G 10M 7.0G 0% /tmp > rpool/usr 9.3G 2.2G 7.0G 24% /usr > rpool/usr/ports 7.2G 199M 7.0G 3% > /usr/ports > rpool/usr/src 7.5G 434M 7.0G 6% /usr/src > rpool/var 7.1G 104M 7.0G 1% /var > rpool/var/crash 7.0G 0B 7.0G 0% > /var/crash > > > Regards, > Thomas With you saying this, I decided to try GENERIC kernel configuration and that builds and runs just fine. I suspect that Peg and myself have something in our kernel conf files that is causing an issue. I'll have a go later on and see if I can narrow it down a little bit more Paul ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 14:50:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47D4A106564A for ; Thu, 2 Jul 2009 14:50:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id ED8C08FC17 for ; Thu, 2 Jul 2009 14:50:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADRmTEqDaFvH/2dsb2JhbADQN4QRBYE6 X-IronPort-AV: E=Sophos;i="4.42,334,1243828800"; d="scan'208";a="40018580" Received: from danube.cs.uoguelph.ca ([131.104.91.199]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 02 Jul 2009 10:50:40 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 03B881084191; Thu, 2 Jul 2009 10:50:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at danube.cs.uoguelph.ca Received: from danube.cs.uoguelph.ca ([127.0.0.1]) by localhost (danube.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TVFW1zonEDV; Thu, 2 Jul 2009 10:50:40 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by danube.cs.uoguelph.ca (Postfix) with ESMTP id 396961084183; Thu, 2 Jul 2009 10:50:40 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n62Er3F17591; Thu, 2 Jul 2009 10:53:03 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Thu, 2 Jul 2009 10:52:35 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: "Bjoern A. Zeeb" In-Reply-To: <20090702121640.D245@maildrop.int.zabbadoz.net> Message-ID: References: <20090702121640.D245@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: Install from NFS onto NFS fails on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:50:42 -0000 On Thu, 2 Jul 2009, Bjoern A. Zeeb wrote: > Hi, > > trying to installworld from NFS to NFS (which also is the NFS Root > of the installing and to be updated machien) on amd64 always fails > with this error. Anyone knows why that is? > [stuff snipped] > install -s -o root -g wheel -m 555 ldd32 /usr/bin > rm: /tmp/install.uMl44I7W: Directory not empty > *** Error code 1 > > Stop in /zoo/bz/HEAD.svn. > *** Error code 1 > > Stop in /zoo/bz/HEAD.svn. > lion1# Well, at a quick glance, I can't see anything in either the NFS client nor server that generates ENOTEMPTY for rmdir. It would seem to me that it was generated by the underlying file system on the NFS server for some reason. (Same goes for the syscall above the client side NFS.) You could confirm this with a printf() right after VOP_RMDIR() in sys/nfsserver/nfs_serv.c. (A tcpdump/wireshark trace would tell you if the ENOTEMPTY was reported by the server, which looks like it is the case.) Not much help, but...rick From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 14:53:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D5EA10656BE for ; Thu, 2 Jul 2009 14:53:15 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 06F598FC08 for ; Thu, 2 Jul 2009 14:53:14 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (c149.al.cl.cam.ac.uk [128.232.110.149]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n62Eqrhs057661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2009 00:52:56 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A4CC9C1.4080200@freebsd.org> Date: Thu, 02 Jul 2009 15:52:49 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Hans Petter Selasky References: <200906080902.43391.hselasky@c2i.net> In-Reply-To: <200906080902.43391.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_05,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org, freebsd-usb@freebsd.org, markus@brueffer.de Subject: Re: Temporary patch to fix USB in kdebase4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 14:53:15 -0000 Hans Petter Selasky wrote: > See attachment. > --HPS Any chance you (or someone with the right clue) could update this patch to work with more recent 8-CURRENT? I get the following output when trying to compile kdebase4 (which applies your original patch as extra-patch-libusb20) on r195046 world/kernel: Scanning dependencies of target kcm_usb [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o [ 67%] Building CXX object apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o In file included from /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevices.h:20, from /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/kcmusb.cpp:27: /usr/include/dev/usb/usb_revision.h:33: error: multiple definition of 'enum usb_dev_speed' /usr/include/dev/usb/usb.h:686: error: previous definition here /usr/include/dev/usb/usb_revision.h:34: error: conflicting declaration 'USB_SPEED_VARIABLE' /usr/include/dev/usb/usb.h:687: error: 'USB_SPEED_VARIABLE' has a previous declaration as 'usb_dev_speed USB_SPEED_VARIABLE' /usr/include/dev/usb/usb_revision.h:35: error: conflicting declaration 'USB_SPEED_LOW' /usr/include/dev/usb/usb.h:688: error: 'USB_SPEED_LOW' has a previous declaration as 'usb_dev_speed USB_SPEED_LOW' /usr/include/dev/usb/usb_revision.h:36: error: conflicting declaration 'USB_SPEED_FULL' /usr/include/dev/usb/usb.h:689: error: 'USB_SPEED_FULL' has a previous declaration as 'usb_dev_speed USB_SPEED_FULL' /usr/include/dev/usb/usb_revision.h:37: error: conflicting declaration 'USB_SPEED_HIGH' /usr/include/dev/usb/usb.h:690: error: 'USB_SPEED_HIGH' has a previous declaration as 'usb_dev_speed USB_SPEED_HIGH' /usr/include/dev/usb/usb_revision.h:38: error: conflicting declaration 'USB_SPEED_SUPER' /usr/include/dev/usb/usb.h:691: error: 'USB_SPEED_SUPER' has a previous declaration as 'usb_dev_speed USB_SPEED_SUPER' /usr/include/dev/usb/usb_revision.h:45: error: multiple definition of 'enum usb_revision' /usr/include/dev/usb/usb.h:698: error: previous definition here /usr/include/dev/usb/usb_revision.h:46: error: conflicting declaration 'USB_REV_UNKNOWN' /usr/include/dev/usb/usb.h:699: error: 'USB_REV_UNKNOWN' has a previous declaration as 'usb_revision USB_REV_UNKNOWN' /usr/include/dev/usb/usb_revision.h:47: error: conflicting declaration 'USB_REV_PRE_1_0' /usr/include/dev/usb/usb.h:700: error: 'USB_REV_PRE_1_0' has a previous declaration as 'usb_revision USB_REV_PRE_1_0' /usr/include/dev/usb/usb_revision.h:48: error: conflicting declaration 'USB_REV_1_0' /usr/include/dev/usb/usb.h:701: error: 'USB_REV_1_0' has a previous declaration as 'usb_revision USB_REV_1_0' /usr/include/dev/usb/usb_revision.h:49: error: conflicting declaration 'USB_REV_1_1' /usr/include/dev/usb/usb.h:702: error: 'USB_REV_1_1' has a previous declaration as 'usb_revision USB_REV_1_1' /usr/include/dev/usb/usb_revision.h:50: error: conflicting declaration 'USB_REV_2_0' /usr/include/dev/usb/usb.h:703: error: 'USB_REV_2_0' has a previous declaration as 'usb_revision USB_REV_2_0' /usr/include/dev/usb/usb_revision.h:51: error: conflicting declaration 'USB_REV_2_5' /usr/include/dev/usb/usb.h:704: error: 'USB_REV_2_5' has a previous declaration as 'usb_revision USB_REV_2_5' /usr/include/dev/usb/usb_revision.h:52: error: conflicting declaration 'USB_REV_3_0' /usr/include/dev/usb/usb.h:705: error: 'USB_REV_3_0' has a previous declaration as 'usb_revision USB_REV_3_0' /usr/include/dev/usb/usb_revision.h:59: error: multiple definition of 'enum usb_hc_mode' /usr/include/dev/usb/usb.h:712: error: previous definition here /usr/include/dev/usb/usb_revision.h:60: error: conflicting declaration 'USB_MODE_HOST' /usr/include/dev/usb/usb.h:713: error: 'USB_MODE_HOST' has a previous declaration as 'usb_hc_mode USB_MODE_HOST' /usr/include/dev/usb/usb_revision.h:61: error: conflicting declaration 'USB_MODE_DEVICE' /usr/include/dev/usb/usb.h:714: error: 'USB_MODE_DEVICE' has a previous declaration as 'usb_hc_mode USB_MODE_DEVICE' /usr/include/dev/usb/usb_revision.h:62: error: conflicting declaration 'USB_MODE_DUAL' /usr/include/dev/usb/usb.h:715: error: 'USB_MODE_DUAL' has a previous declaration as 'usb_hc_mode USB_MODE_DUAL' /usr/include/dev/usb/usb_revision.h:69: error: multiple definition of 'enum usb_dev_state' /usr/include/dev/usb/usb.h:722: error: previous definition here /usr/include/dev/usb/usb_revision.h:70: error: conflicting declaration 'USB_STATE_DETACHED' /usr/include/dev/usb/usb.h:723: error: 'USB_STATE_DETACHED' has a previous declaration as 'usb_dev_state USB_STATE_DETACHED' /usr/include/dev/usb/usb_revision.h:71: error: conflicting declaration 'USB_STATE_ATTACHED' /usr/include/dev/usb/usb.h:724: error: 'USB_STATE_ATTACHED' has a previous declaration as 'usb_dev_state USB_STATE_ATTACHED' /usr/include/dev/usb/usb_revision.h:72: error: conflicting declaration 'USB_STATE_POWERED' /usr/include/dev/usb/usb.h:725: error: 'USB_STATE_POWERED' has a previous declaration as 'usb_dev_state USB_STATE_POWERED' /usr/include/dev/usb/usb_revision.h:73: error: conflicting declaration 'USB_STATE_ADDRESSED' /usr/include/dev/usb/usb.h:726: error: 'USB_STATE_ADDRESSED' has a previous declaration as 'usb_dev_state USB_STATE_ADDRESSED' /usr/include/dev/usb/usb_revision.h:74: error: conflicting declaration 'USB_STATE_CONFIGURED' /usr/include/dev/usb/usb.h:727: error: 'USB_STATE_CONFIGURED' has a previous declaration as 'usb_dev_state USB_STATE_CONFIGURED' *** Error code 1 Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. *** Error code 1 Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. *** Error code 1 Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. *** Error code 1 Stop in /usr/ports/x11/kdebase4. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 15:01:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1A56106564A; Thu, 2 Jul 2009 15:01:13 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 9DA5E8FC16; Thu, 2 Jul 2009 15:01:12 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=-C_3ZPTwNAkA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=GaNxpZAkVcGcGMhTNGoA:9 a=L7s4sSZD9cNdtay08dYA:7 a=dVKp4SPAa-r4XVwOhKDApwT3xLkA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1271753061; Thu, 02 Jul 2009 17:01:10 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 2 Jul 2009 17:00:37 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <200906080902.43391.hselasky@c2i.net> <4A4CC9C1.4080200@freebsd.org> In-Reply-To: <4A4CC9C1.4080200@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907021700.39350.hselasky@c2i.net> Cc: Lawrence Stewart , freebsd-usb@freebsd.org, freebsd-ports@freebsd.org, markus@brueffer.de Subject: Re: Temporary patch to fix USB in kdebase4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:01:14 -0000 On Thursday 02 July 2009 16:52:49 Lawrence Stewart wrote: > Hans Petter Selasky wrote: > > See attachment. > > --HPS > > Any chance you (or someone with the right clue) could update this patch > to work with more recent 8-CURRENT? I get the following output when > trying to compile kdebase4 (which applies your original patch as > extra-patch-libusb20) on r195046 world/kernel: > > > Scanning dependencies of target kcm_usb > > [ 67%] Building CXX object > apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o > [ 67%] Building CXX object > apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o > In file included from > /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevi >ces.h:20, > > Hi, It looks like you have two set of header files. Second, change the USB "dev/" header files to: # include # include Else there are no further changes. --HPS From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 15:14:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85CC21065670; Thu, 2 Jul 2009 15:14:41 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 140638FC12; Thu, 2 Jul 2009 15:14:40 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (c149.al.cl.cam.ac.uk [128.232.110.149]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n62FEMnR012481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2009 01:14:25 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A4CCECA.40607@freebsd.org> Date: Thu, 02 Jul 2009 16:14:18 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Hans Petter Selasky References: <200906080902.43391.hselasky@c2i.net> <4A4CC9C1.4080200@freebsd.org> <200907021700.39350.hselasky@c2i.net> In-Reply-To: <200907021700.39350.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org, freebsd-usb@freebsd.org, markus@brueffer.de Subject: Re: Temporary patch to fix USB in kdebase4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:14:42 -0000 Hans Petter Selasky wrote: > On Thursday 02 July 2009 16:52:49 Lawrence Stewart wrote: >> Hans Petter Selasky wrote: >>> See attachment. >>> --HPS >> Any chance you (or someone with the right clue) could update this patch >> to work with more recent 8-CURRENT? I get the following output when >> trying to compile kdebase4 (which applies your original patch as >> extra-patch-libusb20) on r195046 world/kernel: >> >> >> Scanning dependencies of target kcm_usb >> >> [ 67%] Building CXX object >> apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o >> [ 67%] Building CXX object >> apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o >> In file included from >> /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevi >> ces.h:20, >> >> > > Hi, > > It looks like you have two set of header files. Second, change the USB "dev/" > header files to: > > # include > # include > > Else there are no further changes. ah ha, had forgotten to run "make delete-old" after last update. Thanks for the hint and thanks for the include fix. Trying it out now. Cheers, Lawrence From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 15:31:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 301621065676; Thu, 2 Jul 2009 15:31:24 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmmtai105.cox.net (eastrmmtai105.cox.net [68.230.240.12]) by mx1.freebsd.org (Postfix) with ESMTP id BA8938FC1D; Thu, 2 Jul 2009 15:31:23 +0000 (UTC) (envelope-from mezz7@cox.net) Received: from eastrmimpo03.cox.net ([68.1.16.126]) by eastrmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090702150515.GWPL4885.eastrmmtao107.cox.net@eastrmimpo03.cox.net>; Thu, 2 Jul 2009 11:05:15 -0400 Received: from localhost ([68.103.37.153]) by eastrmimpo03.cox.net with bizsmtp id B35E1c00B3JFCbG0235E9Y; Thu, 02 Jul 2009 11:05:15 -0400 X-VR-Score: -220.00 X-Authority-Analysis: v=1.0 c=1 a=-C_3ZPTwNAkA:10 a=6I5d2MoRAAAA:8 a=kviXuzpPAAAA:8 a=Z8JsemIFVpmymWuZVRwA:9 a=TnFUQNAWKIVIPj-EqJ4A:7 a=VU7_dud1WVF3KmXX-G0doK5fnJMA:4 a=SV7veod9ZcQA:10 a=4vB-4DCPJfMA:10 X-CM-Score: 0.00 Date: Thu, 02 Jul 2009 10:05:53 -0500 To: "Lawrence Stewart" From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200906080902.43391.hselasky@c2i.net> <4A4CC9C1.4080200@freebsd.org> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <4A4CC9C1.4080200@freebsd.org> User-Agent: Opera Mail/9.64 (Linux) Cc: freebsd-current@freebsd.org, Hans Petter Selasky , freebsd-usb@freebsd.org, freebsd-ports@freebsd.org, markus@brueffer.de Subject: Re: Temporary patch to fix USB in kdebase4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:31:24 -0000 On Thu, 02 Jul 2009 09:52:49 -0500, Lawrence Stewart wrote: > Hans Petter Selasky wrote: >> See attachment. >> --HPS > > Any chance you (or someone with the right clue) could update this patch > to work with more recent 8-CURRENT? I get the following output when > trying to compile kdebase4 (which applies your original patch as > extra-patch-libusb20) on r195046 world/kernel: There is no usb_revision.h in recently -CURRENT. I have nothing of it in my system, I always run make delete-old and delete-old-libs. However, I am able to installed both kdebase3 and kdebase4 by tweak in extra-patch-libusb20. All I have to do like this: Change from: +#include To: +/*#include */ As for the kdebase3, I just took a patch from ports/135860 then tweak a bit. I am planning to follow up in its PR. But, I haven't run those in runtime yet thought. Cheers, Mezz > Scanning dependencies of target kcm_usb [ 67%] Building CXX object > apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcm_usb_automoc.o > [ 67%] Building CXX object > apps/kinfocenter/usbview/CMakeFiles/kcm_usb.dir/kcmusb.o > In file included from > /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/usbdevices.h:20, > from > /usr/ports/x11/kdebase4/work/kdebase-4.2.4/apps/kinfocenter/usbview/kcmusb.cpp:27: > /usr/include/dev/usb/usb_revision.h:33: error: multiple definition of > 'enum usb_dev_speed' > /usr/include/dev/usb/usb.h:686: error: previous definition here > /usr/include/dev/usb/usb_revision.h:34: error: conflicting declaration > 'USB_SPEED_VARIABLE' > /usr/include/dev/usb/usb.h:687: error: 'USB_SPEED_VARIABLE' has a > previous declaration as 'usb_dev_speed USB_SPEED_VARIABLE' > /usr/include/dev/usb/usb_revision.h:35: error: conflicting declaration > 'USB_SPEED_LOW' > /usr/include/dev/usb/usb.h:688: error: 'USB_SPEED_LOW' has a previous > declaration as 'usb_dev_speed USB_SPEED_LOW' > /usr/include/dev/usb/usb_revision.h:36: error: conflicting declaration > 'USB_SPEED_FULL' > /usr/include/dev/usb/usb.h:689: error: 'USB_SPEED_FULL' has a previous > declaration as 'usb_dev_speed USB_SPEED_FULL' > /usr/include/dev/usb/usb_revision.h:37: error: conflicting declaration > 'USB_SPEED_HIGH' > /usr/include/dev/usb/usb.h:690: error: 'USB_SPEED_HIGH' has a previous > declaration as 'usb_dev_speed USB_SPEED_HIGH' > /usr/include/dev/usb/usb_revision.h:38: error: conflicting declaration > 'USB_SPEED_SUPER' > /usr/include/dev/usb/usb.h:691: error: 'USB_SPEED_SUPER' has a previous > declaration as 'usb_dev_speed USB_SPEED_SUPER' > /usr/include/dev/usb/usb_revision.h:45: error: multiple definition of > 'enum usb_revision' > /usr/include/dev/usb/usb.h:698: error: previous definition here > /usr/include/dev/usb/usb_revision.h:46: error: conflicting declaration > 'USB_REV_UNKNOWN' > /usr/include/dev/usb/usb.h:699: error: 'USB_REV_UNKNOWN' has a previous > declaration as 'usb_revision USB_REV_UNKNOWN' > /usr/include/dev/usb/usb_revision.h:47: error: conflicting declaration > 'USB_REV_PRE_1_0' > /usr/include/dev/usb/usb.h:700: error: 'USB_REV_PRE_1_0' has a previous > declaration as 'usb_revision USB_REV_PRE_1_0' > /usr/include/dev/usb/usb_revision.h:48: error: conflicting declaration > 'USB_REV_1_0' > /usr/include/dev/usb/usb.h:701: error: 'USB_REV_1_0' has a previous > declaration as 'usb_revision USB_REV_1_0' > /usr/include/dev/usb/usb_revision.h:49: error: conflicting declaration > 'USB_REV_1_1' > /usr/include/dev/usb/usb.h:702: error: 'USB_REV_1_1' has a previous > declaration as 'usb_revision USB_REV_1_1' > /usr/include/dev/usb/usb_revision.h:50: error: conflicting declaration > 'USB_REV_2_0' > /usr/include/dev/usb/usb.h:703: error: 'USB_REV_2_0' has a previous > declaration as 'usb_revision USB_REV_2_0' > /usr/include/dev/usb/usb_revision.h:51: error: conflicting declaration > 'USB_REV_2_5' > /usr/include/dev/usb/usb.h:704: error: 'USB_REV_2_5' has a previous > declaration as 'usb_revision USB_REV_2_5' > /usr/include/dev/usb/usb_revision.h:52: error: conflicting declaration > 'USB_REV_3_0' > /usr/include/dev/usb/usb.h:705: error: 'USB_REV_3_0' has a previous > declaration as 'usb_revision USB_REV_3_0' > /usr/include/dev/usb/usb_revision.h:59: error: multiple definition of > 'enum usb_hc_mode' > /usr/include/dev/usb/usb.h:712: error: previous definition here > /usr/include/dev/usb/usb_revision.h:60: error: conflicting declaration > 'USB_MODE_HOST' > /usr/include/dev/usb/usb.h:713: error: 'USB_MODE_HOST' has a previous > declaration as 'usb_hc_mode USB_MODE_HOST' > /usr/include/dev/usb/usb_revision.h:61: error: conflicting declaration > 'USB_MODE_DEVICE' > /usr/include/dev/usb/usb.h:714: error: 'USB_MODE_DEVICE' has a previous > declaration as 'usb_hc_mode USB_MODE_DEVICE' > /usr/include/dev/usb/usb_revision.h:62: error: conflicting declaration > 'USB_MODE_DUAL' > /usr/include/dev/usb/usb.h:715: error: 'USB_MODE_DUAL' has a previous > declaration as 'usb_hc_mode USB_MODE_DUAL' > /usr/include/dev/usb/usb_revision.h:69: error: multiple definition of > 'enum usb_dev_state' > /usr/include/dev/usb/usb.h:722: error: previous definition here > /usr/include/dev/usb/usb_revision.h:70: error: conflicting declaration > 'USB_STATE_DETACHED' > /usr/include/dev/usb/usb.h:723: error: 'USB_STATE_DETACHED' has a > previous declaration as 'usb_dev_state USB_STATE_DETACHED' > /usr/include/dev/usb/usb_revision.h:71: error: conflicting declaration > 'USB_STATE_ATTACHED' > /usr/include/dev/usb/usb.h:724: error: 'USB_STATE_ATTACHED' has a > previous declaration as 'usb_dev_state USB_STATE_ATTACHED' > /usr/include/dev/usb/usb_revision.h:72: error: conflicting declaration > 'USB_STATE_POWERED' > /usr/include/dev/usb/usb.h:725: error: 'USB_STATE_POWERED' has a > previous declaration as 'usb_dev_state USB_STATE_POWERED' > /usr/include/dev/usb/usb_revision.h:73: error: conflicting declaration > 'USB_STATE_ADDRESSED' > /usr/include/dev/usb/usb.h:726: error: 'USB_STATE_ADDRESSED' has a > previous declaration as 'usb_dev_state USB_STATE_ADDRESSED' > /usr/include/dev/usb/usb_revision.h:74: error: conflicting declaration > 'USB_STATE_CONFIGURED' > /usr/include/dev/usb/usb.h:727: error: 'USB_STATE_CONFIGURED' has a > previous declaration as 'usb_dev_state USB_STATE_CONFIGURED' *** Error > code 1 > Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. > *** Error code 1 > > Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. > *** Error code 1 > > Stop in /usr/ports/x11/kdebase4/work/kdebase-4.2.4/build. > *** Error code 1 > > Stop in /usr/ports/x11/kdebase4. > > > > > Cheers, > Lawrence > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 15:51:03 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D36D41065678 for ; Thu, 2 Jul 2009 15:51:03 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from carrick.bishnet.net (carrick.bishnet.net [IPv6:2a01:348:132::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9663E8FC23 for ; Thu, 2 Jul 2009 15:51:03 +0000 (UTC) (envelope-from tdb@carrick.bishnet.net) Received: from tdb by carrick.bishnet.net with local (Exim 4.66 (FreeBSD)) (envelope-from ) id 1MMOYp-000DWr-NQ for freebsd-current@FreeBSD.org; Thu, 02 Jul 2009 16:50:55 +0100 Date: Thu, 2 Jul 2009 16:50:55 +0100 From: Tim Bishop To: freebsd-current@FreeBSD.org Message-ID: <20090702155055.GM2504@carrick.bishnet.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 0x5AE7D984, http://www.bishnet.net/tim/tim-bishnet-net.asc X-PGP-Fingerprint: 1453 086E 9376 1A50 ECF6 AE05 7DCE D659 5AE7 D984 User-Agent: Mutt/1.5.13 (2006-08-11) X-Bishnet-MailScanner-Information: Contact postmaster@bishnet.net X-Bishnet-MailScanner-VirusCheck: Found to be clean X-Bishnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.6, required 5, autolearn=not spam, BAYES_00 -2.60, NO_RELAYS -0.00) X-Bishnet-MailScanner-From: tdb@carrick.bishnet.net Cc: Subject: XEN kernel config - supposed to build? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:51:04 -0000 I'm building the XEN kernel config on a recent (today) csup of CURRENT, but I'm getting the following build error: # make buildkernel KERNCONF=XEN ... cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /usr/src/sys/xen/evtchn/evtchn.c cc1: warnings being treated as errors /usr/src/sys/xen/evtchn/evtchn.c:653: warning: initialization from incompatible pointer type *** Error code 1 Is this supposed to be working? Or have I dived randomly in and missed the pool? :-) Thanks, Tim. -- Tim Bishop http://www.bishnet.net/tim/ PGP Key: 0x5AE7D984 From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 16:37:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BD69106566C for ; Thu, 2 Jul 2009 16:37:06 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id C46C28FC08 for ; Thu, 2 Jul 2009 16:37:04 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (11008@roadkill.tharned.org [75.145.12.185]) (authenticated bits=0) by roadkill.tharned.org (8.14.3/8.14.3) with ESMTP id n62Gb2Tw083767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 11:37:04 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) Date: Thu, 2 Jul 2009 11:37:01 -0500 (CDT) From: Greg Rivers To: Kostik Belousov In-Reply-To: <20090702084149.GE2884@deviant.kiev.zoral.com.ua> Message-ID: References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> <20090702084149.GE2884@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (roadkill.tharned.org [75.145.12.185]); Thu, 02 Jul 2009 11:37:04 -0500 (CDT) Cc: freebsd-current@freebsd.org Subject: Re: Panic during shutdown (cause identified) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 16:37:06 -0000 On Thu, 2 Jul 2009, Kostik Belousov wrote: >>> Also, please describe the load on the machine, >>> >> >> It happens regardless of the load. For example, just booting >> multi-user and immediately running shutdown (either by logging in or >> pressing the ACPI power button) triggers the panic. > No, it does not happen regardless of the load. The patch was tested on > the semi-standard set of programs run on the system, and all seen > accounting mistakes were fixed. > I don't know what patch you're referring to. Are you saying this issue was seen before and thought to have been fixed? > You have some process that does exhibit the behaviour causing error in > swap accounting. I think for start you could just show me ps auxww > output, in private, if you prefer. > I can save you the trouble of reading ps output. Based on your insight that the problem is with a particular process, I eliminated variables from /etc/rc.conf by trial, and have determined that it's the amd(8) automounter that's causing the panic. When I remove 'amd_enable="YES"', no more panic. > > The panic message on the console does not show the process. Can that > > be determined from kgdb? If so, how? > It does show the process, like > KDB: enter: panic > [thread pid 32021 tid 100598 ] > Yes, ordinarily such message is shown, but it is not shown for this panic. Also with this panic, about half the time the machine locks up hard just before, during, or after the core dump. > BTW, did you saw the kernel messages like negative vmsize for uid = XXX ? > No, there have been none of those. Please let me know if I can help with further testing/debugging. BTW, I did not customize the amd configuration; I was using the stock configuration from the base system. -- Greg Rivers From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 18:13:39 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E225E1065677; Thu, 2 Jul 2009 18:13:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BCE2D8FC28; Thu, 2 Jul 2009 18:13:39 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 58A4C46B29; Thu, 2 Jul 2009 14:13:39 -0400 (EDT) Date: Thu, 2 Jul 2009 19:13:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jung-uk Kim In-Reply-To: <200907011842.01710.jkim@FreeBSD.org> Message-ID: References: <20090701162108.GA33681@regency.nsu.ru> <200907011737.15525.jkim@FreeBSD.org> <200907011842.01710.jkim@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Alexey Dokuchaev , freebsd-current@FreeBSD.org Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 18:13:40 -0000 On Wed, 1 Jul 2009, Jung-uk Kim wrote: > I cannot reproduce it any more. It must be fixed already. FYI, when it > happened, I traced it down to: > > shutdown -> > dhclient closing fd -> > bpf_dtor() -> > mac_bpfdesc_destroy() -> > mac_bpfdesc_label_free() -> d->bd_label corrupt! > bpfmac_labelzone_free() -> > uma_zfree() -> > ... -> page fault! > > Any way, sorry for the noise and thanks for fixing this, whoever that is. This is almost certainly an ifnet-related race condition that has been fixed in 8.x, and that MAC is panicking is just a symptom that it picked up on a double free (or the like) since it has internal validation. It may still existing in 7.x as there's a lot of ifnet/ifaddr work I haven't MFC'd yet (and won't for a few weeks at least). Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 17:28:01 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEE3D1065670 for ; Thu, 2 Jul 2009 17:28:01 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from mx.nsu.ru (mx.nsu.ru [212.192.164.5]) by mx1.freebsd.org (Postfix) with ESMTP id 69C658FC08 for ; Thu, 2 Jul 2009 17:28:00 +0000 (UTC) (envelope-from danfe@regency.nsu.ru) Received: from regency.nsu.ru ([193.124.210.26]) by mx.nsu.ru with esmtp (Exim 4.50) id 1MMQ4p-0005HS-3M; Fri, 03 Jul 2009 00:28:04 +0700 Received: from regency.nsu.ru (localhost [127.0.0.1]) by regency.nsu.ru (8.14.2/8.14.2) with ESMTP id n62HSxgP096934; Fri, 3 Jul 2009 00:28:59 +0700 (NOVST) (envelope-from danfe@regency.nsu.ru) Received: (from danfe@localhost) by regency.nsu.ru (8.14.2/8.14.2/Submit) id n62HSrrf096859; Fri, 3 Jul 2009 00:28:53 +0700 (NOVST) (envelope-from danfe) Date: Fri, 3 Jul 2009 00:28:53 +0700 From: Alexey Dokuchaev To: Stanislav Sedov Message-ID: <20090702172853.GA94604@regency.nsu.ru> References: <20090701162108.GA33681@regency.nsu.ru> <20090702151507.c997fa89.stas@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090702151507.c997fa89.stas@FreeBSD.org> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Thu, 02 Jul 2009 18:28:35 +0000 Cc: current@FreeBSD.org Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 17:28:02 -0000 Stanislav Sedov wrote: > Alexey Dokuchaev mentioned: > > I've started to observe the following rather annoying panic if I boot > > with if_sf loaded (via loader.conf) and having sf0 configured via DHCP > > on recent -CURRENT. If I comment out driver from loader.conf and load > > it manually (via kldload(8)) after system boots, it loads and gets > > configured just fine. > > > > Any clues here? Attached is relevant dmesg + DDB trace (debug kernel > > with WITNESS). I'm happy to provide any additional information (that > > is, ps/show uma/malloc, whatever). > > > > Do you use SMP system? Nope, it's good old UP box: $ dmesg | grep CPU: CPU: Intel Pentium III (1125.00-MHz 686-class CPU) ./danfe From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 18:31:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A5B71065688 for ; Thu, 2 Jul 2009 18:31:08 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 01DB78FC28 for ; Thu, 2 Jul 2009 18:31:07 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247479495; Thu, 02 Jul 2009 21:31:04 +0300 Message-ID: <4A4CFCDD.4020202@FreeBSD.org> Date: Thu, 02 Jul 2009 21:30:53 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Lucius Windschuh References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 18:31:09 -0000 Lucius Windschuh wrote: > I'd like to notice that the patch seems to break cdrecord -scanbus > (freshly rebuilt from the ports): > $ cdrecord -scanbus > Cdrecord-Clone 2.01 (i386-unknown-freebsd8.0) Copyright (C) 1995-2004 > J=F6rg Schilling > cdrecord: Argument list too long. CAMIOCOMMAND ioctl failed. Cannot > open SCSI driver. > cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are r= > oot. > cdrecord: For possible transport specifiers try 'cdrecord dev=3Dhelp'. It is the same problem I have fixed in camcontrol. You can do the same with changing in scsi-bsd.c in cdrtools #define>CAM_MAXDEVS 128 to #define>CAM_MAXDEVS 50. I hope it is temporal solution. I am thinking about to remove or at least rise that limitation. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 19:02:11 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B33521065687; Thu, 2 Jul 2009 19:02:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 681E38FC1F; Thu, 2 Jul 2009 19:02:11 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n62IxghN009931; Thu, 2 Jul 2009 14:59:42 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907021859.n62IxghN009931@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Jul 2009 15:02:10 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <4A471F44.7010108@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 19:02:12 -0000 At 03:44 AM 6/28/2009, Alexander Motin wrote: >I see no any relation to the patch here. I would say it is some >BIOS/loader problem, as kernel wasn't yet booted. Have you been ever >able to boot this system with AHCI enabled before? I re-installed the OS on a new drive with a 200906 snapshot, and can now boot with AHCI enabled in the BIOS. The original image was a RELENG_7 box that I upgraded to HEAD some time ago. Is there something that needs to be manually updated that would not have been done as part of the normal buildworld/buildkernel ? Re-install the boot blocks perhaps ? ahci0: port 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb49f mem 0xfadd6000-0xfadd67ff irq 19 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.20 controller with 6 3Gbps ports, PM not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] On the ich10 board, its trying to boot up now, but I am getting uhub8: 4 ports with 4 removable, self powered (probe2:ahcich2:0:0:0): SIGNATURE: eb14 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ahcich2: Timeout on slot 4 run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config ahcich2: Timeout on slot 5 run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config ahcich2: Timeout on slot 6 run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config ahcich2: Timeout on slot 7 run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config ahcich2: Timeout on slot 8 ada0 at ahcich1 bus 0 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing Enabled mountroot> ufs:/dev/ada0s1 Trying to mount root from ufs:/dev/ada0s1 GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). And then it hangs there. ---Mike From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 19:33:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB3F9106564A; Thu, 2 Jul 2009 19:33:29 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 08A5F8FC18; Thu, 2 Jul 2009 19:33:28 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247481460; Thu, 02 Jul 2009 22:33:24 +0300 Message-ID: <4A4D0B7E.8060503@FreeBSD.org> Date: Thu, 02 Jul 2009 22:33:18 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Mike Tancsa References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> In-Reply-To: <200907021859.n62IxghN009931@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 19:33:30 -0000 Mike Tancsa wrote: > At 03:44 AM 6/28/2009, Alexander Motin wrote: >> I see no any relation to the patch here. I would say it is some >> BIOS/loader problem, as kernel wasn't yet booted. Have you been ever >> able to boot this system with AHCI enabled before? > > I re-installed the OS on a new drive with a 200906 snapshot, and can now > boot with AHCI enabled in the BIOS. The original image was a RELENG_7 > box that I upgraded to HEAD some time ago. Is there something that needs > to be manually updated that would not have been done as part of the > normal buildworld/buildkernel ? Re-install the boot blocks perhaps ? mergemaster? As soon as you are able to run kernel, loaders are fine. > ahci0: port > 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb49f > mem 0xfadd6000-0xfadd67ff irq 19 at device 31.2 on pci0 > ahci0: [ITHREAD] > ahci0: AHCI v1.20 controller with 6 3Gbps ports, PM not supported > ahcich0: at channel 0 on ahci0 > ahcich0: [ITHREAD] > ahcich1: at channel 1 on ahci0 > ahcich1: [ITHREAD] > ahcich2: at channel 2 on ahci0 > ahcich2: [ITHREAD] > ahcich3: at channel 3 on ahci0 > ahcich3: [ITHREAD] > ahcich4: at channel 4 on ahci0 > ahcich4: [ITHREAD] > ahcich5: at channel 5 on ahci0 > ahcich5: [ITHREAD] > > On the ich10 board, its trying to boot up now, but I am getting > > uhub8: 4 ports with 4 removable, self powered > (probe2:ahcich2:0:0:0): SIGNATURE: eb14 Looks like you have CD on third SATA channel. > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > ahcich2: Timeout on slot 4 > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > ahcich2: Timeout on slot 5 > run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config > ahcich2: Timeout on slot 6 > run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config > ahcich2: Timeout on slot 7 > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > ahcich2: Timeout on slot 8 And this CD does not really wants speak. > ada0 at ahcich1 bus 0 target 0 lun 0 > ada0: ATA/ATAPI-8 SATA 2.x device > ada0: 300.000MB/s transfers > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: Native Command Queueing Enabled > > mountroot> ufs:/dev/ada0s1 > Trying to mount root from ufs:/dev/ada0s1 > GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). As soon as GEOM found the label, disk seems to work. > And then it hangs there. Can you try to disconnect CD? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 19:44:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CBCF1065677; Thu, 2 Jul 2009 19:44:51 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 9D85E8FC27; Thu, 2 Jul 2009 19:44:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n62JijV5061275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 22:44:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n62JijvK028671; Thu, 2 Jul 2009 22:44:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n62JijKr028670; Thu, 2 Jul 2009 22:44:45 +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, 2 Jul 2009 22:44:44 +0300 From: Kostik Belousov To: Greg Rivers Message-ID: <20090702194444.GK2884@deviant.kiev.zoral.com.ua> References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> <20090702084149.GE2884@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MKQswQ7UUMqTthTa" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: Panic during shutdown (cause identified) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 19:44:51 -0000 --MKQswQ7UUMqTthTa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 02, 2009 at 11:37:01AM -0500, Greg Rivers wrote: > On Thu, 2 Jul 2009, Kostik Belousov wrote: >=20 > >>>Also, please describe the load on the machine, > >>> > >> > >>It happens regardless of the load. For example, just booting=20 > >>multi-user and immediately running shutdown (either by logging in or=20 > >>pressing the ACPI power button) triggers the panic. > >No, it does not happen regardless of the load. The patch was tested on= =20 > >the semi-standard set of programs run on the system, and all seen=20 > >accounting mistakes were fixed. > > >=20 > I don't know what patch you're referring to. Are you saying this issue= =20 > was seen before and thought to have been fixed? The issue is an indicator of the bug somewhere else, in the code that does precise swap accounting. I committed that approximately one week ago. The patch I am referring to is the r194766. >=20 >=20 > >You have some process that does exhibit the behaviour causing error in= =20 > >swap accounting. I think for start you could just show me ps auxww=20 > >output, in private, if you prefer. > > >=20 > I can save you the trouble of reading ps output. Based on your insight= =20 > that the problem is with a particular process, I eliminated variables fro= m=20 > /etc/rc.conf by trial, and have determined that it's the amd(8)=20 > automounter that's causing the panic. When I remove 'amd_enable=3D"YES"'= ,=20 > no more panic. >=20 >=20 > >> The panic message on the console does not show the process. Can that= =20 > >> be determined from kgdb? If so, how? > >It does show the process, like > >KDB: enter: panic > >[thread pid 32021 tid 100598 ] > > >=20 > Yes, ordinarily such message is shown, but it is not shown for this panic= .=20 > Also with this panic, about half the time the machine locks up hard just= =20 > before, during, or after the core dump. >=20 >=20 > >BTW, did you saw the kernel messages like negative vmsize for uid =3D XX= X ? > > >=20 > No, there have been none of those. >=20 >=20 > Please let me know if I can help with further testing/debugging. BTW, I= =20 > did not customize the amd configuration; I was using the stock=20 > configuration from the base system. The information you provided about amd(8) causing the problem was crusial. The issue is that amd locks its pages with mlockall(2), and the code neglected to account the wired mappings, but did not forgot to decrease their swap share on unmapping. Patch below fixed the issue for me. diff --git a/sys/vm/vm_extern.h b/sys/vm/vm_extern.h index 7bacde4..ec21a3a 100644 --- a/sys/vm/vm_extern.h +++ b/sys/vm/vm_extern.h @@ -55,7 +55,8 @@ vm_map_t kmem_suballoc(vm_map_t, vm_offset_t *, vm_offset= _t *, vm_size_t, void swapout_procs(int); int useracc(void *, int, int); int vm_fault(vm_map_t, vm_offset_t, vm_prot_t, int); -void vm_fault_copy_entry(vm_map_t, vm_map_t, vm_map_entry_t, vm_map_entry_= t); +void vm_fault_copy_entry(vm_map_t, vm_map_t, vm_map_entry_t, vm_map_entry_= t, + vm_ooffset_t *); void vm_fault_unwire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t); int vm_fault_wire(vm_map_t, vm_offset_t, vm_offset_t, boolean_t, boolean_t= ); int vm_forkproc(struct thread *, struct proc *, struct thread *, struct vm= space *, int); diff --git a/sys/vm/vm_fault.c b/sys/vm/vm_fault.c index 43743f4..579cf49 100644 --- a/sys/vm/vm_fault.c +++ b/sys/vm/vm_fault.c @@ -1126,11 +1126,9 @@ vm_fault_unwire(vm_map_t map, vm_offset_t start, vm_= offset_t end, * entry corresponding to a main map entry that is wired down). */ void -vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry) - vm_map_t dst_map; - vm_map_t src_map; - vm_map_entry_t dst_entry; - vm_map_entry_t src_entry; +vm_fault_copy_entry(vm_map_t dst_map, vm_map_t src_map, + vm_map_entry_t dst_entry, vm_map_entry_t src_entry, + vm_ooffset_t *fork_charge) { vm_object_t backing_object, dst_object, object; vm_object_t src_object; @@ -1163,10 +1161,12 @@ vm_fault_copy_entry(dst_map, src_map, dst_entry, sr= c_entry) VM_OBJECT_LOCK(dst_object); dst_entry->object.vm_object =3D dst_object; dst_entry->offset =3D 0; - if (dst_entry->uip !=3D NULL) { - dst_object->uip =3D dst_entry->uip; + if (fork_charge !=3D NULL) { + dst_object->uip =3D curthread->td_ucred->cr_ruidinfo; + uihold(dst_object->uip); dst_object->charge =3D dst_entry->end - dst_entry->start; dst_entry->uip =3D NULL; + *fork_charge +=3D dst_entry->end - dst_entry->start; } prot =3D dst_entry->max_protection; =20 diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index 82d37e6..ea6f713 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -2909,7 +2909,8 @@ vm_map_copy_entry( * Cause wired pages to be copied into the new map by * simulating faults (the new pages are pageable) */ - vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry); + vm_fault_copy_entry(dst_map, src_map, dst_entry, src_entry, + fork_charge); } } =20 --MKQswQ7UUMqTthTa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpNDiwACgkQC3+MBN1Mb4gsYACgm0KZ2+Qt9cl/wiSMLAEAgVCv oQwAnAxa2Rtg6Hra04ujYLl5xm/sl0Td =aJMH -----END PGP SIGNATURE----- --MKQswQ7UUMqTthTa-- From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 20:36:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDFF91065678; Thu, 2 Jul 2009 20:36:17 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id ADD878FC0C; Thu, 2 Jul 2009 20:36:17 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from feathers.peganest.com (feathers.peganest.com [78.33.110.3]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n62Ka8AH021977 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 20:36:11 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: freebsd-current@freebsd.org Date: Thu, 2 Jul 2009 21:36:03 +0100 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; amd64; ; ) References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> <4A4CC937.5050008@fletchermoorland.co.uk> In-Reply-To: <4A4CC937.5050008@fletchermoorland.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907022136.04164.ken@mthelicon.com> Cc: Thomas Backman , current@freebsd.org, Paul Wootton Subject: Re: Has anyone been able to actually boot the AMD64 kernel after r194958? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 20:36:18 -0000 On Thursday 02 July 2009 15:50:31 Paul Wootton wrote: > > With you saying this, I decided to try GENERIC kernel configuration and > that builds and runs just fine. I suspect that Peg and myself have > something in our kernel conf files that is causing an issue. I'll have a > go later on and see if I can narrow it down a little bit more > > Paul > Hi Paul, I think I may have tracked down the trigger, although I dont know how to pin- point the cause. It looks like compiling in the radeondrm driver into the kernel is the culprit. if I omit that line from my kernel config, the latest kernels will compile and boot properly on my machine. I'm using a R7xx (but it load the R6xx code) radeon HD card. From talking to you, I know you are using a proper R6xx card. Strangely I can kldload the driver after the machine has booted and all is well, it just seems to hate being compiled into the kernel. Can you see if this is the same on your machine? Peg From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 20:36:17 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDFF91065678; Thu, 2 Jul 2009 20:36:17 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id ADD878FC0C; Thu, 2 Jul 2009 20:36:17 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from feathers.peganest.com (feathers.peganest.com [78.33.110.3]) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n62Ka8AH021977 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 20:36:11 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: freebsd-current@freebsd.org Date: Thu, 2 Jul 2009 21:36:03 +0100 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; amd64; ; ) References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> <4A4CC937.5050008@fletchermoorland.co.uk> In-Reply-To: <4A4CC937.5050008@fletchermoorland.co.uk> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907022136.04164.ken@mthelicon.com> Cc: Thomas Backman , current@freebsd.org, Paul Wootton Subject: Re: Has anyone been able to actually boot the AMD64 kernel after r194958? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 20:36:18 -0000 On Thursday 02 July 2009 15:50:31 Paul Wootton wrote: > > With you saying this, I decided to try GENERIC kernel configuration and > that builds and runs just fine. I suspect that Peg and myself have > something in our kernel conf files that is causing an issue. I'll have a > go later on and see if I can narrow it down a little bit more > > Paul > Hi Paul, I think I may have tracked down the trigger, although I dont know how to pin- point the cause. It looks like compiling in the radeondrm driver into the kernel is the culprit. if I omit that line from my kernel config, the latest kernels will compile and boot properly on my machine. I'm using a R7xx (but it load the R6xx code) radeon HD card. From talking to you, I know you are using a proper R6xx card. Strangely I can kldload the driver after the machine has booted and all is well, it just seems to hate being compiled into the kernel. Can you see if this is the same on your machine? Peg From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 20:49:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEBCC1065676 for ; Thu, 2 Jul 2009 20:49:20 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 3877C8FC1D for ; Thu, 2 Jul 2009 20:49:20 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by bwz12 with SMTP id 12so1610393bwz.43 for ; Thu, 02 Jul 2009 13:49:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PkfS81SUZtJL2i/hAuM6ZjANoHtZg9blE9wDynCQ70o=; b=T26Wxp+CLgUySHyAM0Y1/eD2gWfRPiki9oM7+NDh12oPfkJSE5w/8JbGlgZwskPaqc JIFnnsmFgJEcEQq7eSEAWDyp/MUH2pla5Gb88DN0wQ6g8EAs6odaHJ3t3ViiOGot2riH YNCOObhuA0dM0InSVJHs6GvDRNiGuhA6BVctU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=DaN8wiNna5523FbwI+U+ki2++8Bxjm910/bhXplR13z7iGjehcEWXSBFJKdXqpDRuI MkaSylqodRVoWYuMgbGcD3Sa23cvQ67t3OVkfB6jaqmYfWN955VbzqaphJ2LAOcxuEUp rQWFouEStknaRdNzRdPm3775/iBdcqnqcrvCo= MIME-Version: 1.0 Received: by 10.204.103.203 with SMTP id l11mr439059bko.71.1246567759288; Thu, 02 Jul 2009 13:49:19 -0700 (PDT) In-Reply-To: <20090702194444.GK2884@deviant.kiev.zoral.com.ua> References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> <20090702084149.GE2884@deviant.kiev.zoral.com.ua> <20090702194444.GK2884@deviant.kiev.zoral.com.ua> Date: Thu, 2 Jul 2009 20:49:19 +0000 Message-ID: From: pluknet To: Kostik Belousov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: Panic during shutdown (cause identified) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 20:49:21 -0000 2009/7/2 Kostik Belousov : > On Thu, Jul 02, 2009 at 11:37:01AM -0500, Greg Rivers wrote: >> Please let me know if I can help with further testing/debugging. BTW, I >> did not customize the amd configuration; I was using the stock >> configuration from the base system. > > The information you provided about amd(8) causing the problem was crusial. > The issue is that amd locks its pages with mlockall(2), and the code > neglected to account the wired mappings, but did not forgot to decrease > their swap share on unmapping. > > Patch below fixed the issue for me. I can confirm that simply staring amd(8) daemon and then reboot would cause such panic in swap accounting. I saw a dozen messages "negative vmsize for uid = 0" in time just before panic. This patch fixes that for me. my 2c. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 21:20:21 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA3DF106564A; Thu, 2 Jul 2009 21:20:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 69C5C8FC15; Thu, 2 Jul 2009 21:20:21 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n62LHrvZ010791; Thu, 2 Jul 2009 17:17:53 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907022117.n62LHrvZ010791@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Jul 2009 17:20:20 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <4A4D0B7E.8060503@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:20:22 -0000 At 03:33 PM 7/2/2009, Alexander Motin wrote: >As soon as GEOM found the label, disk seems to work. Actually, It went to single user mode on the console (I was logged in via serial console). However, I could not mount anything for some reason. Going in /dev, only /dev/ada0 and /dev/ada0s1 were there. The disk slices were not for some reason. This was on an AMD64 kernel BTW. But, going back to the original i386 image, with the boot blocks reinstalled and using your latest patch, it seems to work! (however, the same 300sec delay due to the cdrom ? ) mountroot> ufs:/dev/ada0s1a Trying to mount root from ufs:/dev/ada0s1a dumpon: /dev/ad4s1b: No such file or directory /etc/rc: WARNING: unable to specify /dev/ad4s1b as a dump device Entropy harvesting: interrupts ethernet point_to_point kickstart. swapon: /dev/ad4s1b: No such file or directory /dev/ada0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ada0s1a: clean, 259768 free (1048 frags, 32340 blocks, 0.2% fragmentation) Can't stat /dev/ad4s1d: No such file or directorJul 1 08:07:58 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode Enter full pathname of shell or RETURN for /bin/sh: # ls -l /dev/ad* crw-r----- 1 root operator 0, 111 Jul 1 08:02 /dev/ada0 crw-r----- 1 root operator 0, 112 Jul 1 08:02 /dev/ada0s1 crw-r----- 1 root operator 0, 113 Jul 1 08:02 /dev/ada0s1a crw-r----- 1 root operator 0, 114 Jul 1 08:02 /dev/ada0s1b crw-r----- 1 root operator 0, 115 Jul 1 08:02 /dev/ada0s1d crw-r----- 1 root operator 0, 116 Jul 1 08:02 /dev/ada0s1e crw-r----- 1 root operator 0, 117 Jul 1 08:02 /dev/ada0s1f # And, after its booted up, ahci0: port 0xc000-0xc007,0xbc00-0xbc03,0xb880-0xb887,0xb800-0xb803,0xb480-0xb49f mem 0xfadd6000-0xfadd67ff irq 19 at device 31.2 on pci0 ahci0: Reserved 0x800 bytes for rid 0x24 type 3 at 0xfadd6000 ahci0: attempting to allocate 1 MSI vectors (16 supported) msi: routing MSI IRQ 262 to local APIC 0 vector 64 ahci0: using IRQ 262 for MSI ahci0: [MPSAFE] ahci0: [ITHREAD] ahci0: AHCI v1.20 controller with 6 3Gbps ports, PM not supported ahci0: Caps: 64bit NCQ SNTF SS ALP AL CLO 3Gbps PMD SSC PSC 32cmd CCC EM eSATA 6ports ahcich0: at channel 0 on ahci0 ahcich0: [MPSAFE] ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [MPSAFE] ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [MPSAFE] ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [MPSAFE] ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [MPSAFE] ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [MPSAFE] ahcich5: [ITHREAD] ---Mike From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 21:25:07 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E9401065670 for ; Thu, 2 Jul 2009 21:25:07 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id CE4068FC1A for ; Thu, 2 Jul 2009 21:25:06 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 20A66359947; Thu, 2 Jul 2009 23:25:06 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id A1336228CD; Thu, 2 Jul 2009 23:25:05 +0200 (CEST) Date: Thu, 2 Jul 2009 23:25:05 +0200 From: Jilles Tjoelker To: "Bjoern A. Zeeb" Message-ID: <20090702212505.GA39889@stack.nl> References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090702122955.J245@maildrop.int.zabbadoz.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD current mailing list Subject: Re: Install from NFS onto NFS fails on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 21:25:07 -0000 On Thu, Jul 02, 2009 at 12:31:16PM +0000, Bjoern A. Zeeb wrote: > On Thu, 2 Jul 2009, Bjoern A. Zeeb wrote: > > trying to installworld from NFS to NFS (which also is the NFS Root > > of the installing and to be updated machien) on amd64 always fails > > with this error. Anyone knows why that is? > > ------------------------------------------------------------------------ > > lion1# make installworld -DNO_FSCHG > > ... > > ... > > ... > > install -s -o root -g wheel -m 555 ldd32 /usr/bin > > rm: /tmp/install.uMl44I7W: Directory not empty > > *** Error code 1 > > > > Stop in /zoo/bz/HEAD.svn. > > *** Error code 1 > > > > Stop in /zoo/bz/HEAD.svn. > > lion1# > > ------------------------------------------------------------------------ > I probably should have added that the directory is empty: > lion1# ls -la /tmp/install.uMl44I7W > total 4 > drwxr-xr-x 2 root wheel 1024 Jul 2 12:15 . > drwxrwxrwt 15 root wheel 1024 Jul 2 12:10 .. > and I am well aware that that is one of the last things that make > installworld does; it's just strange and I blame it on NFS;-) This could be because of NFS "sillyrename". To avoid some ESTALE errors, the NFS client (for NFSv2 and NFSv3 at least) renames if you delete a file that is currently in use (in this case, the rm binary). Because the renamed file (name typically starts with .nfs) is in the same directory, this causes problems when removing directories. Once the file is no longer in use, it is finally deleted. Without sillyrename, rm could segfault after deleting itself. Maybe NFSv4 has a cleaner way to keep a file with 0 links as long as it is open. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Thu Jul 2 22:36:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 05D8A1065674; Thu, 2 Jul 2009 22:36:20 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id B598C8FC0A; Thu, 2 Jul 2009 22:36:19 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 3570F46B51; Thu, 2 Jul 2009 18:36:19 -0400 (EDT) Received: from John-Baldwins-Macbook-Pro.local (localhost [IPv6:::1]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 28FF58A08B; Thu, 2 Jul 2009 18:36:17 -0400 (EDT) Message-ID: <4A4D3665.3060502@FreeBSD.org> Date: Thu, 02 Jul 2009 18:36:21 -0400 From: John Baldwin User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Maxim Ignatenko References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 02 Jul 2009 18:36:17 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-3.1 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Anonymous , Hans Ottevanger , Norikatsu Shigemura , Robert Noland , freebsd-current@freebsd.org Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 22:36:20 -0000 Maxim Ignatenko wrote: >> Fatal trap 30: reserved (unknown) fault while in kernel mode >> cpuid = 3; apic id = 03 >> instruction pointer = 0x20:0xffffffff804bce56 >> stack pointer = 0x20:0xffffff8000039b60 >> frame pointer = 0x20:0xffffff8000039b70 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, IOPL = 0 >> current process = 11 (idle: cpu3) >> [thread pid 11 tid 100003 ] >> Stopped at acpi_cpu_c1+0x6: leave >> db> bt >> Tracing pid 11 tid 100003 td 0xffffff8001863720 >> acpi_cpu_c1() at acpi_cpu_c1+0x6 >> acpi_cpu_idle() at acpi_cpu_idle+0x20c >> sched_idletd() at sched_idletd+0x123 >> fork_exit() at fork_exit+0x117 >> fork_trampoline() at fork_trampoline+0xe > > As for me, r194984 runs normally, but when I tried to boot with > r194985 at second try it paniced with backtrace very similar to shown > in first message, and at first try even earlier: in sched_ideltd and > again on instruction that uses %ebp when ebp = 0. > First time I stepped on this panic after updating to r195130: > > Trying to mount root from ufs:/dev/ufs/root > > > Fatal trap 30; reserved (unknown) fault while in kernel mode > cpuid = 1; apic id = 01 > instruction ponter = 0x20:0xc09252c5 > stack pointer = 0x28:0xc4ecec94 > frame pointer = 0x28:0xc4ecec94 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 11 (idle: cpu1) > [thread pid 11 tid 100003] > Stopped at 0xc09252c5 = acpi_cpu_c1+0x5: popl %ebp > db> bt > Tracing pid 11 tid 100003 td 0xc5176af0 > acpi_cpu_c1(1,c4ececa8,1,0,c4ececc0,...) at 0xc09252c5 = acpi_cpu_c1+0x5 > acpi_cpu_idle(c4ececd4,c093c0ab,0,c4ececf4,c066fdec,...) at 0xc04acf37 > = acpi_cpu_idle+0x107 > cpu_idle_acpi(0,c4ececf4,c066fdec,0,0,...) at 0xc093d5bb = cpu_idle_acpi+0x1b > cpu_idle(0,0,c5176af0,c4ececf4,202,...) at 0xc093c0ab = cpu_idle+0x1b > sched_idletd(0,c4ececd38,a4108400,2c0a0e,7022d00,...) at 0xc066fdec = > sched_idletd+0x1c > fork_exit(c066fdd0,0,c4eced38) at 0xc0623aa1 = fork_exit+0x91 > fork_trampoline() at 0xc0930c80 = fork_tramoline+0x8 > --- trap 0, eip = 0, esp = 0xc4ececd70, ebp = 0 --- > > > P.S.: i386, dual-core, drm and radeon compiled as modules > When I'm trying to boot w/o ACPI support all seems work fine, but > system hangs just before starting kdm Please try http://www.FreeBSD.org/~jhb/patches/msi_assign.patch -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 00:04:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A3A61065673 for ; Fri, 3 Jul 2009 00:04:54 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id C13E28FC13 for ; Fri, 3 Jul 2009 00:04:53 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-023-170.pools.arcor-ip.net [88.66.23.170]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MKt2u-1MMWGq1yRZ-000nnB; Fri, 03 Jul 2009 02:04:52 +0200 Received: (qmail 58090 invoked from network); 3 Jul 2009 00:04:51 -0000 Received: from kvm.laiers.local (HELO kvm.localnet) (192.168.4.200) by mx.laiers.local with SMTP; 3 Jul 2009 00:04:51 -0000 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Fri, 3 Jul 2009 02:04:50 +0200 User-Agent: KMail/1.11.3 (Linux/2.6.30-rc5-ARCH; KDE/4.2.3; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907030204.51415.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1+mjc6h0Tk2S1/niEm7mPXfmsrr6/AORmqRRW+ j9zPFWIrnPl5SpmXPHJSx3+E14C5v72f6vzfAFHkgogvutnRBb v8wNIBYjTb+1owVJ/hYvQ== Cc: Rafal Jaworowski , Jeff Roberson Subject: Re: MD5 test slowdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 00:04:54 -0000 On Thursday 02 July 2009 13:32:08 Rafal Jaworowski wrote: > I'm observing some heavy slowdown seen with md5 test on PowerPC: > > 1. On the MPC8572 machine with today's HEAD I'm getting: > > # md5 -t > MD5 time trial. Digesting 100000 10000-byte blocks ... done > Digest = 766a2bb5d24bddae466c572bcabca3ee > Time = 36.930565 seconds > Speed = 27077842.000000 bytes/second > > 2. While a couple of months back it yielded 6x shorter times on this > very same hardware, like this one: > > # md5 -t > MD5 time trial. Digesting 100000 10000-byte blocks ... done > Digest = 766a2bb5d24bddae466c572bcabca3ee > Time = 6.027277 seconds > Speed = 165912400.000000 bytes/second > > Timers work fine, the slowdown is real. I don't know if this is > PowerPC related, and was wondering if anybody observed something > similar on other archs perhaps? Any suggestions what could be causing > this or where to look? I cannot see immediate suspects in the arch/ > platform code. "signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64" to this mailing list reports something that might be related. It seems there is a patch available, but not committed yet. Though I'm not sure about the nature of the problem exactly. Jeff? -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 01:24:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94765106564A for ; Fri, 3 Jul 2009 01:24:32 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from roadkill.tharned.org (roadkill.tharned.org [75.145.12.185]) by mx1.freebsd.org (Postfix) with ESMTP id 513278FC1B for ; Fri, 3 Jul 2009 01:24:32 +0000 (UTC) (envelope-from gcr+freebsd-current@tharned.org) Received: from blue.tharned.org (blue.tharned.org [10.10.10.8]) (authenticated bits=0) by roadkill.tharned.org (8.14.3/8.14.3) with ESMTP id n631OUkF086578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Jul 2009 20:24:31 -0500 (CDT) (envelope-from gcr+freebsd-current@tharned.org) Date: Thu, 2 Jul 2009 20:24:30 -0500 (CDT) From: Greg Rivers To: Kostik Belousov In-Reply-To: <20090702194444.GK2884@deviant.kiev.zoral.com.ua> Message-ID: References: <20090701192154.GW2884@deviant.kiev.zoral.com.ua> <20090702084149.GE2884@deviant.kiev.zoral.com.ua> <20090702194444.GK2884@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (roadkill.tharned.org [75.145.12.185]); Thu, 02 Jul 2009 20:24:31 -0500 (CDT) Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: Panic during shutdown (cause identified) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 01:24:32 -0000 On Thu, 2 Jul 2009, Kostik Belousov wrote: > The information you provided about amd(8) causing the problem was > crusial. The issue is that amd locks its pages with mlockall(2), and > the code neglected to account the wired mappings, but did not forgot to > decrease their swap share on unmapping. > > Patch below fixed the issue for me. > [snip] > Confirmed: your patch fixes the issue for me as well. Thanks! -- Greg Rivers From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 02:08:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3701106564A; Fri, 3 Jul 2009 02:08:59 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-bw0-f214.google.com (mail-bw0-f214.google.com [209.85.218.214]) by mx1.freebsd.org (Postfix) with ESMTP id CF4738FC12; Fri, 3 Jul 2009 02:08:58 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: by bwz10 with SMTP id 10so4157bwz.43 for ; Thu, 02 Jul 2009 19:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:message-id:user-agent:mime-version:content-type; bh=5DvbnWtcraY91nedk3TyVMJCg6ltJdfiDQ/WgmYm53w=; b=lEvL/YZaYZsiyrdxfWIfsQEs/kutTxNa4T7yCTtkt2OitHcycgIFU7IYnLuw0dsmpk mcRgyT5m4jybnnum/YAwRRzS7MB7UodSrWtHJl21aCN8pvO5hP9k3GhJt+WW0fHFJ8cL x3BuRl2qTJfIq5MalCkAfF6g+CEviSxq8K78Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:message-id:user-agent :mime-version:content-type; b=Gsg3MnvBszOez5zIfL/YXZOjR99y33mDYLLSsJKW4fWP8OtB/VV8sqdDtOE90Yj/0M ye8c4GO4vRpfhWU5dCL4DPKyBsUHWUNM400DGbiv7EQ0G71O18hp0pd3dV4WqljBp20d aYR5R8YXTE+KxDLQYi1aLbzd3zAS7gNAvho3Q= Received: by 10.204.71.15 with SMTP id f15mr696670bkj.113.1246586937820; Thu, 02 Jul 2009 19:08:57 -0700 (PDT) Received: from localhost (95-24-83-95.broadband.corbina.ru [95.24.83.95]) by mx.google.com with ESMTPS id 21sm5411602fks.39.2009.07.02.19.08.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Jul 2009 19:08:56 -0700 (PDT) From: Anonymous To: John Baldwin References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> <4A4D3665.3060502@FreeBSD.org> Date: Fri, 03 Jul 2009 06:08:27 +0400 Message-ID: <86hbxujz6s.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Hans Ottevanger , Norikatsu Shigemura , Robert Noland , freebsd-current@freebsd.org Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 02:09:00 -0000 John Baldwin writes: > Maxim Ignatenko wrote: >>> Fatal trap 30: reserved (unknown) fault while in kernel mode >>> cpuid = 3; apic id = 03 >>> instruction pointer = 0x20:0xffffffff804bce56 >>> stack pointer = 0x20:0xffffff8000039b60 >>> frame pointer = 0x20:0xffffff8000039b70 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, IOPL = 0 >>> current process = 11 (idle: cpu3) >>> [thread pid 11 tid 100003 ] >>> Stopped at acpi_cpu_c1+0x6: leave >>> db> bt >>> Tracing pid 11 tid 100003 td 0xffffff8001863720 >>> acpi_cpu_c1() at acpi_cpu_c1+0x6 >>> acpi_cpu_idle() at acpi_cpu_idle+0x20c >>> sched_idletd() at sched_idletd+0x123 >>> fork_exit() at fork_exit+0x117 >>> fork_trampoline() at fork_trampoline+0xe >> >> As for me, r194984 runs normally, but when I tried to boot with >> r194985 at second try it paniced with backtrace very similar to shown >> in first message, and at first try even earlier: in sched_ideltd and >> again on instruction that uses %ebp when ebp = 0. >> First time I stepped on this panic after updating to r195130: >> >> Trying to mount root from ufs:/dev/ufs/root >> >> >> Fatal trap 30; reserved (unknown) fault while in kernel mode >> cpuid = 1; apic id = 01 >> instruction ponter = 0x20:0xc09252c5 >> stack pointer = 0x28:0xc4ecec94 >> frame pointer = 0x28:0xc4ecec94 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, IOPL = 0 >> current process = 11 (idle: cpu1) >> [thread pid 11 tid 100003] >> Stopped at 0xc09252c5 = acpi_cpu_c1+0x5: popl %ebp >> db> bt >> Tracing pid 11 tid 100003 td 0xc5176af0 >> acpi_cpu_c1(1,c4ececa8,1,0,c4ececc0,...) at 0xc09252c5 = acpi_cpu_c1+0x5 >> acpi_cpu_idle(c4ececd4,c093c0ab,0,c4ececf4,c066fdec,...) at 0xc04acf37 >> = acpi_cpu_idle+0x107 >> cpu_idle_acpi(0,c4ececf4,c066fdec,0,0,...) at 0xc093d5bb = cpu_idle_acpi+0x1b >> cpu_idle(0,0,c5176af0,c4ececf4,202,...) at 0xc093c0ab = cpu_idle+0x1b >> sched_idletd(0,c4ececd38,a4108400,2c0a0e,7022d00,...) at 0xc066fdec = >> sched_idletd+0x1c >> fork_exit(c066fdd0,0,c4eced38) at 0xc0623aa1 = fork_exit+0x91 >> fork_trampoline() at 0xc0930c80 = fork_tramoline+0x8 >> --- trap 0, eip = 0, esp = 0xc4ececd70, ebp = 0 --- >> >> >> P.S.: i386, dual-core, drm and radeon compiled as modules >> When I'm trying to boot w/o ACPI support all seems work fine, but >> system hangs just before starting kdm > > Please try http://www.FreeBSD.org/~jhb/patches/msi_assign.patch This fixes the panic for me. Loading drm module either at loader prompt or compiling it in both works with your patch. From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 02:26:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA7E5106564A for ; Fri, 3 Jul 2009 02:26:50 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 44F438FC13 for ; Fri, 3 Jul 2009 02:26:49 +0000 (UTC) (envelope-from swell.k@gmail.com) Received: by fxm18 with SMTP id 18so1715193fxm.43 for ; Thu, 02 Jul 2009 19:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:references :date:in-reply-to:message-id:user-agent:mime-version:content-type; bh=0on0MWRuq3KSd0dJB3ZGLn0kPJg4aQecih/3dShn1VY=; b=JtUURyoXp5v6IWzUYFgT6LHYIBb4HLXrrK7AANwPEkYw5u9TSaXlVQiMmtysVFEChZ +gtNUrguBN8jdEPHNAc8wHJL8bMkXm9ZUaiqRTFPDmCsHbW9lgzv7eWvgU5svAoD+Vtp V4Rrp1UMyOqiaVjRqAozyWnrYtaDnr3fE8a74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; b=AGONCWJ+ZntzVcQ7KQ89sxiNmofqZ2QykQfZGVhfLjnEQEnOozMfMdWkbbwTq6T6qf Gdvlt6Eu9itKRhQ64PANCfxW7FsTRypDv1/plKpubNhuyANNJHgoHM7gXuMnAcoVhI6X OjNzPEvZNGP3lI9zydES5fr784bbASgqu4tLU= Received: by 10.204.72.129 with SMTP id m1mr719684bkj.61.1246588009207; Thu, 02 Jul 2009 19:26:49 -0700 (PDT) Received: from localhost (95-24-83-95.broadband.corbina.ru [95.24.83.95]) by mx.google.com with ESMTPS id 1sm5377123fkt.57.2009.07.02.19.26.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Jul 2009 19:26:48 -0700 (PDT) From: Anonymous To: Pegasus Mc Cleaft References: <895D2AA2E9964CEE970A64C74D2FF622@PegaPegII> <95B6A153-B61A-474B-B3D6-66D80DA53D50@exscape.org> <4A4CC937.5050008@fletchermoorland.co.uk> <200907022136.04164.ken@mthelicon.com> Date: Fri, 03 Jul 2009 06:26:21 +0400 In-Reply-To: <200907022136.04164.ken@mthelicon.com> (Pegasus Mc Cleaft's message of "Thu, 2 Jul 2009 21:36:03 +0100") Message-ID: <86ab3mec36.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, Paul Wootton , Thomas Backman Subject: Re: Has anyone been able to actually boot the AMD64 kernel after r194958? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 02:26:51 -0000 Pegasus Mc Cleaft writes: > On Thursday 02 July 2009 15:50:31 Paul Wootton wrote: >> >> With you saying this, I decided to try GENERIC kernel configuration and >> that builds and runs just fine. I suspect that Peg and myself have >> something in our kernel conf files that is causing an issue. I'll have a >> go later on and see if I can narrow it down a little bit more >> >> Paul >> > Hi Paul, > > I think I may have tracked down the trigger, although I dont know how to pin- > point the cause. > > It looks like compiling in the radeondrm driver into the kernel is the > culprit. if I omit that line from my kernel config, the latest kernels will > compile and boot properly on my machine. I'm using a R7xx (but it load the > R6xx code) radeon HD card. From talking to you, I know you are using a proper > R6xx card. I think this is related to the recent problem described in "panic on acpi_cpu_c1()" thread[1]. There is at least one patch and two workarounds (load drm module after boot or set hw.drm.msi=0 at loader prompt). [1] http://docs.freebsd.org/cgi/mid.cgi?4A4D3665.3060502 > > Strangely I can kldload the driver after the machine has booted and all is > well, it just seems to hate being compiled into the kernel. > > Can you see if this is the same on your machine? > > Peg From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 07:26:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07A50106564A for ; Fri, 3 Jul 2009 07:26:17 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from mail.jrv.org (adsl-70-243-84-13.dsl.austtx.swbell.net [70.243.84.13]) by mx1.freebsd.org (Postfix) with ESMTP id BDB0B8FC22 for ; Fri, 3 Jul 2009 07:26:16 +0000 (UTC) (envelope-from james-freebsd-current@jrv.org) Received: from kremvax.housenet.jrv (kremvax.housenet.jrv [192.168.3.124]) by mail.jrv.org (8.14.3/8.14.3) with ESMTP id n637QHip044782 for ; Fri, 3 Jul 2009 02:26:17 -0500 (CDT) (envelope-from james-freebsd-current@jrv.org) Authentication-Results: mail.jrv.org; domainkeys=pass (testing) header.from=james-freebsd-current@jrv.org DomainKey-Signature: a=rsa-sha1; s=enigma; d=jrv.org; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:subject: content-type:content-transfer-encoding; b=dlyzM6W+k4/YC/5ByMMBnvPwkY1wxyfd08ZYRLSdJde+RQ8aQ8I/lBm3kB8ScSPvq AbOSQ33GtFPA1stqvLEw9WZZGs5j5rkkTuA72G/hpZXOVexdTf5Gfslt3zCmjFpDp6H M6HZ0m3VAbPDzwYkew4vrRGewkSGPNeMWeDoEnE= Message-ID: <4A4DB284.607@jrv.org> Date: Fri, 03 Jul 2009 02:25:56 -0500 From: "James R. Van Artsdalen" User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: how to enable /dev/ufs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 07:26:17 -0000 amd64, svn HEAD 195136 June 28, 2009 What enables /dev/ufs and /dev/ufsid? Below /usr is labeled yet /dev/ufs and /dev/ufsid are empty. geom label is loaded. [root@esata /usr/home/james]# tunefs -p /usr tunefs: ACLs: (-a) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) enabled tunefs: gjournal: (-J) disabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) usr [root@esata /usr/home/james]# ls -la /dev/ufs total 1 dr-xr-xr-x 2 root wheel 512 Jul 2 23:06 . dr-xr-xr-x 9 root wheel 512 Jul 2 18:06 .. [root@esata /usr/home/james]# kldstat Id Refs Address Size Name 1 13 0xffffffff80100000 e6c278 kernel 2 1 0xffffffff80f6d000 196550 zfs.ko 3 2 0xffffffff81104000 3a90 opensolaris.ko 4 1 0xffffffff81108000 8958 geom_label.ko 5 1 0xffffffff81111000 23e30 geom_mirror.ko [root@esata /usr/home/james]# ls -la /dev/ufsid/ total 1 dr-xr-xr-x 2 root wheel 512 Jul 2 23:06 . dr-xr-xr-x 9 root wheel 512 Jul 2 18:06 .. [root@esata /usr/home/james]# From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 07:41:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E1491065674 for ; Fri, 3 Jul 2009 07:41:54 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mx1.freebsd.org (Postfix) with ESMTP id 221AC8FC08 for ; Fri, 3 Jul 2009 07:41:54 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-023-170.pools.arcor-ip.net [88.66.23.170]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MKsym-1MMdP70X9y-000Ofg; Fri, 03 Jul 2009 09:41:53 +0200 Received: (qmail 95943 invoked from network); 3 Jul 2009 07:41:52 -0000 Received: from kvm.laiers.local (HELO kvm.localnet) (192.168.4.200) by router.laiers.local with SMTP; 3 Jul 2009 07:41:52 -0000 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Fri, 3 Jul 2009 09:41:51 +0200 User-Agent: KMail/1.11.3 (Linux/2.6.30-rc5-ARCH; KDE/4.2.3; x86_64; ; ) References: <4A4DB284.607@jrv.org> In-Reply-To: <4A4DB284.607@jrv.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907030941.52387.max@love2party.net> X-Provags-ID: V01U2FsdGVkX19aQWsM4OP2Rk1NKvr5SBJTJBH1DMpQNYUuXGf 6baeAxYK5f4c0haqK+vuUbUJ8jeQQrXaJXHHCDLwDdz/6OjK75 lp/hRvl6VF5rPay8h2JHA== Cc: "James R. Van Artsdalen" Subject: Re: how to enable /dev/ufs? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 07:41:54 -0000 On Friday 03 July 2009 09:25:56 James R. Van Artsdalen wrote: > amd64, svn HEAD 195136 June 28, 2009 > > What enables /dev/ufs and /dev/ufsid? Below /usr is labeled yet > /dev/ufs and /dev/ufsid are empty. geom label is loaded. > > [root@esata /usr/home/james]# tunefs -p /usr > tunefs: ACLs: (-a) disabled > tunefs: MAC multilabel: (-l) disabled > tunefs: soft updates: (-n) enabled > tunefs: gjournal: (-J) disabled > tunefs: maximum blocks per file in a cylinder group: (-e) 2048 > tunefs: average file size: (-f) 16384 > tunefs: average number of files in a directory: (-s) 64 > tunefs: minimum percentage of free space: (-m) 8% > tunefs: optimization preference: (-o) time > tunefs: volume label: (-L) usr > [root@esata /usr/home/james]# ls -la /dev/ufs > total 1 > dr-xr-xr-x 2 root wheel 512 Jul 2 23:06 . > dr-xr-xr-x 9 root wheel 512 Jul 2 18:06 .. > [root@esata /usr/home/james]# kldstat > Id Refs Address Size Name > 1 13 0xffffffff80100000 e6c278 kernel > 2 1 0xffffffff80f6d000 196550 zfs.ko > 3 2 0xffffffff81104000 3a90 opensolaris.ko > 4 1 0xffffffff81108000 8958 geom_label.ko > 5 1 0xffffffff81111000 23e30 geom_mirror.ko > [root@esata /usr/home/james]# ls -la /dev/ufsid/ > total 1 > dr-xr-xr-x 2 root wheel 512 Jul 2 23:06 . > dr-xr-xr-x 9 root wheel 512 Jul 2 18:06 .. > [root@esata /usr/home/james]# Once the partition is mounted, the label link is removed. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 08:20:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 386D51065676 for ; Fri, 3 Jul 2009 08:20:46 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id C62DB8FC17 for ; Fri, 3 Jul 2009 08:20:45 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n638Kffi006173 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2009 11:20:41 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n638KeAO035871; Fri, 3 Jul 2009 11:20:40 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n638KeGs035870; Fri, 3 Jul 2009 11:20:40 +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: Fri, 3 Jul 2009 11:20:40 +0300 From: Kostik Belousov To: Max Laier Message-ID: <20090703082040.GN2884@deviant.kiev.zoral.com.ua> References: <200907030204.51415.max@love2party.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mT4yAvgikiid89S9" Content-Disposition: inline In-Reply-To: <200907030204.51415.max@love2party.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Rafal Jaworowski , freebsd-current@freebsd.org, Jeff Roberson Subject: Re: MD5 test slowdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 08:20:47 -0000 --mT4yAvgikiid89S9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 03, 2009 at 02:04:50AM +0200, Max Laier wrote: > On Thursday 02 July 2009 13:32:08 Rafal Jaworowski wrote: > > I'm observing some heavy slowdown seen with md5 test on PowerPC: > > > > 1. On the MPC8572 machine with today's HEAD I'm getting: > > > > # md5 -t > > MD5 time trial. Digesting 100000 10000-byte blocks ... done > > Digest =3D 766a2bb5d24bddae466c572bcabca3ee > > Time =3D 36.930565 seconds > > Speed =3D 27077842.000000 bytes/second > > > > 2. While a couple of months back it yielded 6x shorter times on this > > very same hardware, like this one: > > > > # md5 -t > > MD5 time trial. Digesting 100000 10000-byte blocks ... done > > Digest =3D 766a2bb5d24bddae466c572bcabca3ee > > Time =3D 6.027277 seconds > > Speed =3D 165912400.000000 bytes/second > > > > Timers work fine, the slowdown is real. I don't know if this is > > PowerPC related, and was wondering if anybody observed something > > similar on other archs perhaps? Any suggestions what could be causing > > this or where to look? I cannot see immediate suspects in the arch/ > > platform code. >=20 > "signifanctly slowdown of FreeBSD 8.0-CURRENT/amd64" to this mailing list= =20 > reports something that might be related. It seems there is a patch=20 > available, but not committed yet. Though I'm not sure about the nature o= f=20 > the problem exactly. Jeff? I want to make some points clear to avoid a confusion and spread of FUD. It seems we have at least three issues, all different: 1. Syscalls slowdown on amd64. To see this, you need to microbenchmark syscall enter/leave sequence. I doubt that it can be seen on any load except while (1) {getpid();} loops or such. The issue is valid _only_ for amd64. I developed the patch with the input from Jeff who confirmed that this slowdown is solved by the change. 2. There are enough independent reports of i/o slowdown to believe that some problem is real; but we have not seen numbers or detailed configurations or (most desirable) the revision after which the slowdown started. Note the i/o part. This report is for PPC (right ?) and for workload that is purely CPU-bounded. Please do not mix different issues. --mT4yAvgikiid89S9 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkpNv1gACgkQC3+MBN1Mb4hJ/ACfRAKVy4GIbLeR/f7IZbVYgEDp S4cAn1rhzLzrCL97SrH97SWTDbY1PmbZ =e+oN -----END PGP SIGNATURE----- --mT4yAvgikiid89S9-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 09:03:20 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF6201065673 for ; Fri, 3 Jul 2009 09:03:20 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 7B3168FC13 for ; Fri, 3 Jul 2009 09:03:20 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from stasss.yandex.ru (dhcp170-227-red.yandex.net [95.108.170.227]) by mx0.deglitch.com (Postfix) with ESMTPSA id B56018FC27; Fri, 3 Jul 2009 13:03:18 +0400 (MSD) Date: Fri, 3 Jul 2009 13:03:11 +0400 From: Stanislav Sedov To: Alexey Dokuchaev Message-Id: <20090703130311.1b028de5.stas@FreeBSD.org> In-Reply-To: <20090702172853.GA94604@regency.nsu.ru> References: <20090701162108.GA33681@regency.nsu.ru> <20090702151507.c997fa89.stas@FreeBSD.org> <20090702172853.GA94604@regency.nsu.ru> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__3_Jul_2009_13_03_11_+0400_+BNs_OmdtR.Gxz6b" Cc: current@FreeBSD.org Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 09:03:21 -0000 --Signature=_Fri__3_Jul_2009_13_03_11_+0400_+BNs_OmdtR.Gxz6b Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, 3 Jul 2009 00:28:53 +0700 Alexey Dokuchaev mentioned: >=20 > $ dmesg | grep CPU: > CPU: Intel Pentium III (1125.00-MHz 686-class CPU) >=20 Hi, Alexey! Do you have a core dump available? It might help to debug this issue. Thanks! --=20 Stanislav Sedov ST4096-RIPE --Signature=_Fri__3_Jul_2009_13_03_11_+0400_+BNs_OmdtR.Gxz6b Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJKTclVAAoJEKN82nOYvCd0B9oQAJ3lk6oLvXsOA8dsF3q2WEx7 fWTRDKz9AuRF2qNeWeBZVhYpeXZ8LcgW9gkEcQEfTxskokm2p9E9ql2spe4dHWP8 Nez4vmi9vXPV6JvGgJKgwdhkCLbmP2TgHSGNRGsWe8uNVxrR1VgDDN34kIRm+LLr k0Z9KpFiBA07FIrK5GlCiQUAJRetOV74sxCDx5ZPE1RCGOJWtqBOrzcrOoiZrlRr 9JYkVgT1AM9G+g1KFgxrsgtG0s+RD09/f7/qePBdbYyUbf1d1GJlyQin8S7JGWvQ jzGNplLkAZ0W/lIOW5gX5bTrGRI/RvUFKNftuDA6YF6Y0x1mdVGnbkdfWMCtB31x osHA1oJXUA5pooCiaKYJXqti9RRayOVidcmljCMbFxOS7F5KiFEl7ib9Ao3UCGnQ yWWjEC6xzbcfCwpPWnjRckvJv1+u37enigG0YgWxUEz7Ky5vko/s6m9WtPVhy1KM 3RdU3JLw4kzFG3YiJ4uD3GzTBubQUWFyAtU43LEJUN73QgsMQvJDuDbUXfAxmqrC HyJ5Nc+Hg18cVpH2GOoC3Cd9iiZ8gYa8vMlV1waS32ocNEBaOKcLHBsbrIp4pgC1 GLmeqbyq+7dq1XFZD09U+AsqyDRaBle4yRyLNxf8RMFRt8e2OaFutKXIjeb6gq/X mrBx3ZadyexD0Kw02Ptn =R9BK -----END PGP SIGNATURE----- --Signature=_Fri__3_Jul_2009_13_03_11_+0400_+BNs_OmdtR.Gxz6b-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 09:09:22 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 562091065670 for ; Fri, 3 Jul 2009 09:09:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f181.google.com (mail-px0-f181.google.com [209.85.216.181]) by mx1.freebsd.org (Postfix) with ESMTP id 231E98FC12 for ; Fri, 3 Jul 2009 09:09:22 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by pxi11 with SMTP id 11so580225pxi.3 for ; Fri, 03 Jul 2009 02:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=pja2PwqRu+L70vQGBrdN3VIqozCw0EVGfllYGV5NhT8=; b=EK512mzQTjuamG9dHheRsl0XjuakgWcVtgoVtWyrxbvrwm2iiJLhIZnEq3elBeEeGC q9SeldPrcUh2Anmzia+yWwyAvmitA1vTTyHI2BKXN7b6H60YUUavFVZKcZrCiO/mtJ5v zJYId2VwdvAeDQ8/S4UVCk2nW2UI4++gFo8GE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=f8MsNnA6TJv4ecjn+whCUR3RUZOMnjBu1KPj45xldkOlHSzjz+2uGrNV4XHdGroUwi cB9DpWKUOskIIR8Gke4E1JK0i9O6k6q89b3el4fGUzEOXpBKgDDex+vPO33sEnqqv+yb BBJsd0bACGgeL3TgOrraoodBvdr1rZtk2PGpg= Received: by 10.140.173.10 with SMTP id v10mr66827rve.35.1246612161890; Fri, 03 Jul 2009 02:09:21 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id g31sm15078962rvb.1.2009.07.03.02.09.19 (version=SSLv3 cipher=RC4-MD5); Fri, 03 Jul 2009 02:09:20 -0700 (PDT) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Fri, 3 Jul 2009 18:07:33 +0900 From: Pyun YongHyeon Date: Fri, 3 Jul 2009 18:07:33 +0900 To: Stanislav Sedov Message-ID: <20090703090733.GK13137@michelle.cdnetworks.co.kr> References: <20090701162108.GA33681@regency.nsu.ru> <20090702151507.c997fa89.stas@FreeBSD.org> <20090702172853.GA94604@regency.nsu.ru> <20090703130311.1b028de5.stas@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090703130311.1b028de5.stas@FreeBSD.org> User-Agent: Mutt/1.4.2.3i Cc: Alexey Dokuchaev , current@freebsd.org Subject: Re: Kernel panic with if_sf.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 09:09:22 -0000 On Fri, Jul 03, 2009 at 01:03:11PM +0400, Stanislav Sedov wrote: > On Fri, 3 Jul 2009 00:28:53 +0700 > Alexey Dokuchaev mentioned: > > > > > $ dmesg | grep CPU: > > CPU: Intel Pentium III (1125.00-MHz 686-class CPU) > > > > Hi, Alexey! > > Do you have a core dump available? It might help to debug this issue. > I'm actively debugging the issue and waiting for reply of my patch. > Thanks! From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 10:12:54 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5764106564A; Fri, 3 Jul 2009 10:12:54 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 97D4A8FC18; Fri, 3 Jul 2009 10:12:54 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MMfl8-0005jG-9P; Fri, 03 Jul 2009 11:12:53 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by isis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MMfl7-0002g1-Dy; Fri, 03 Jul 2009 11:12:45 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n63ACiPF092311; Fri, 3 Jul 2009 11:12:44 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n63ACgXm092310; Fri, 3 Jul 2009 11:12:42 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Fri, 3 Jul 2009 11:12:42 +0100 From: Anton Shterenlikht To: Wojciech Puchar Message-ID: <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.2 X-Spam-Level: - Cc: Marcel Moolenaar , Anton Shterenlikht , freebsd-questions@freebsd.org, freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: gmirror per partition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 10:12:55 -0000 On Thu, Jul 02, 2009 at 03:48:41PM +0200, Wojciech Puchar wrote: > >>> > >>> # gmirror label -vb round-robin root /dev/da0p2 > >>> gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > >> isn't that partition accessed by other process or mounted? > > > > should it not be mounted? > yes it should not, no matter what architecture. ok, thank you So how can I gmirror root partition? I can't unmount it, I think. Perhaps I need to use a single-user mode? Following is a gpart/gmirror report - some success and problems. I did a fresh FBSD current install on ia64 on directly attached scsi, da0. # gpart show => 34 35566411 da0 GPT (17G) 34 819200 1 efi (400M) 819234 1048576 2 freebsd-ufs (512M) 1867810 4194304 3 freebsd-swap (2.0G) 6062114 2097152 4 freebsd-ufs (1.0G) 8159266 2097152 5 freebsd-ufs (1.0G) 10256418 25310027 6 freebsd-ufs (12G) # What I want is to mirror the whole of the boot disk to da1, which is identical to da0, but following Marcel's advice, will apply gmirror per partition. So starting with efi partition: First I create GPT scheme on da1 # gpart create -s gpt da1 da1 created # gpart show da1 => 34 35566411 da1 GPT (17G) 34 35566411 - free - (17G) # then I create EFI partition of the same size as on the boot disk, da0. # gpart add -b 34 -s 819200 -t efi da1 da1p1 added # gpart show da1 => 34 35566411 da1 GPT (17G) 34 819200 1 efi (400M) 819234 34747211 - free - (17G) # then I umount /efi so that I can create gmirror label on da0p1. # umount /efi # gmirror label -vb round-robin efi /dev/da0p1 Metadata value stored on /dev/da0p1. Done. # Checking gmirror # gmirror status Name Status Components mirror/efi COMPLETE da0p1 # and another check # gmirror list Geom name: efi State: COMPLETE Components: 1 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 3904698645 Providers: 1. Name: mirror/efi Mediasize: 419429888 (400M) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: da0p1 Mediasize: 419430400 (400M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 1288665799 # now insert a spare partition, da1p1, into the mirror # gmirror insert efi /dev/da1p1 status looks fine # gmirror status Name Status Components mirror/efi DEGRADED da0p1 da1p1 (44%) # gmirror status Name Status Components mirror/efi DEGRADED da0p1 da1p1 (87%) # gmirror status Name Status Components mirror/efi COMPLETE da0p1 da1p1 # and another check # gmirror list Geom name: efi State: COMPLETE Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 3904698645 Providers: 1. Name: mirror/efi Mediasize: 419429888 (400M) Sectorsize: 512 Mode: r0w0e0 Consumers: 1. Name: da0p1 Mediasize: 419430400 (400M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 1288665799 2. Name: da1p1 Mediasize: 419430400 (400M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 1724596009 # So far, so good. Now, I don't need to create the filesystem on the mirror, because EFI was copied from da0p1 to da1p1. So, I try to mount /dev/mirror/efi # mount -t msdosfs /dev/mirror/efi /mnt # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0p2 507630 35904 431116 8% / devfs 1 1 0 100% /dev /dev/da0p5 1012974 12 931926 0% /tmp /dev/da0p6 12252370 252608 11019574 2% /usr /dev/da0p4 1012974 242 931696 0% /var /dev/mirror/efi 409504 163264 246240 40% /mnt # again seems ok so I proceed to modify /etc/fstab and change da0p1 into mirror/efi # cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/da0p3 none swap sw 0 0 /dev/da0p2 / ufs rw 1 1 /dev/mirror/efi /efi msdosfs rw 0 0 ^^^^^^^^^^^^^^^ /dev/da0p5 /tmp ufs rw 2 2 /dev/da0p6 /usr ufs rw 2 2 /dev/da0p4 /var ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 # now I can try to just mount /efi # umount /mnt # mount /efi # df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/da0p2 507630 35904 431116 8% / devfs 1 1 0 100% /dev /dev/da0p5 1012974 12 931926 0% /tmp /dev/da0p6 12252370 252608 11019574 2% /usr /dev/da0p4 1012974 242 931696 0% /var /dev/mirror/efi 409504 163264 246240 40% /efi # good, working! now to mirror root partition. My problem is that root is mounted and cannot (?) be unmounted, unlike /efi, on the live system. # gpart add -b 819234 -s 1048576 -t freebsd-ufs da1 da1p2 added # # gmirror label -vb round-robin root /dev/da0p2 gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. # If I create gmirror on da1, the spare disk: # gmirror label -vb round-robin root /dev/da1p2 Metadata value stored on /dev/da0p1. Done. # so that # gmirror status Name Status Components mirror/efi COMPLETE da0p1 da1p1 mirror/root COMPLETE da1p2 # then I still cannot insert da0p2 # gmirror insert root da0p2 gmirror: Cannot access provider da0p2. # So how can I gmirror root partion on a live system? Also, if gmirror overwrites the last sector in the partition, then gmirror per partition cannot be used for /usr, because secondary GPT is stored in the last sector of /usr. Isn't it? many thanks -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 10:52:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83758106566C for ; Fri, 3 Jul 2009 10:52:38 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirj.bris.ac.uk (dirj.bris.ac.uk [137.222.10.78]) by mx1.freebsd.org (Postfix) with ESMTP id 40AA98FC1F for ; Fri, 3 Jul 2009 10:52:38 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from seis.bris.ac.uk ([137.222.10.93]) by dirj.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MMgNd-0003l7-EV for freebsd-current@freebsd.org; Fri, 03 Jul 2009 11:52:37 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by seis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MMgNc-0001A2-OZ for freebsd-current@freebsd.org; Fri, 03 Jul 2009 11:52:33 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n63AqWkR016620 for ; Fri, 3 Jul 2009 11:52:32 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n63AqW1p016619 for freebsd-current@freebsd.org; Fri, 3 Jul 2009 11:52:32 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Fri, 3 Jul 2009 11:52:32 +0100 From: Anton Shterenlikht To: freebsd-current@freebsd.org Message-ID: <20090703105232.GA14372@mech-cluster238.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.4 X-Spam-Level: - Subject: nice work on ntp.conf! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 10:52:40 -0000 ntp.conf update from 2009/06/07 is very welcome, works great straight out of the box, much better than before! many thanks to whoever worked on this. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 11:30:31 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 014801065672; Fri, 3 Jul 2009 11:30:31 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from smtp-vbr1.xs4all.nl (smtp-vbr1.xs4all.nl [194.109.24.21]) by mx1.freebsd.org (Postfix) with ESMTP id 87A608FC0A; Fri, 3 Jul 2009 11:30:29 +0000 (UTC) (envelope-from hansot@iae.nl) Received: from merom.hotsoft.nl (beasties.demon.nl [82.161.3.114]) by smtp-vbr1.xs4all.nl (8.13.8/8.13.8) with ESMTP id n63BUSB4037094; Fri, 3 Jul 2009 13:30:28 +0200 (CEST) (envelope-from hansot@iae.nl) Message-ID: <4A4DEBD4.50609@iae.nl> Date: Fri, 03 Jul 2009 13:30:28 +0200 From: Hans Ottevanger User-Agent: Thunderbird 2.0.0.22 (X11/20090624) MIME-Version: 1.0 To: John Baldwin References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> <4A4D3665.3060502@FreeBSD.org> In-Reply-To: <4A4D3665.3060502@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by XS4ALL Virus Scanner Cc: Anonymous , freebsd-current@FreeBSD.org, Norikatsu Shigemura , Robert Noland Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 11:30:31 -0000 John Baldwin wrote: > Maxim Ignatenko wrote: >>> Fatal trap 30: reserved (unknown) fault while in kernel mode >>> cpuid = 3; apic id = 03 >>> instruction pointer = 0x20:0xffffffff804bce56 >>> stack pointer = 0x20:0xffffff8000039b60 >>> frame pointer = 0x20:0xffffff8000039b70 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags = interrupt enabled, IOPL = 0 >>> current process = 11 (idle: cpu3) >>> [thread pid 11 tid 100003 ] >>> Stopped at acpi_cpu_c1+0x6: leave >>> db> bt >>> Tracing pid 11 tid 100003 td 0xffffff8001863720 >>> acpi_cpu_c1() at acpi_cpu_c1+0x6 >>> acpi_cpu_idle() at acpi_cpu_idle+0x20c >>> sched_idletd() at sched_idletd+0x123 >>> fork_exit() at fork_exit+0x117 >>> fork_trampoline() at fork_trampoline+0xe >> >> As for me, r194984 runs normally, but when I tried to boot with >> r194985 at second try it paniced with backtrace very similar to shown >> in first message, and at first try even earlier: in sched_ideltd and >> again on instruction that uses %ebp when ebp = 0. >> First time I stepped on this panic after updating to r195130: >> >> Trying to mount root from ufs:/dev/ufs/root >> >> >> Fatal trap 30; reserved (unknown) fault while in kernel mode >> cpuid = 1; apic id = 01 >> instruction ponter = 0x20:0xc09252c5 >> stack pointer = 0x28:0xc4ecec94 >> frame pointer = 0x28:0xc4ecec94 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, IOPL = 0 >> current process = 11 (idle: cpu1) >> [thread pid 11 tid 100003] >> Stopped at 0xc09252c5 = acpi_cpu_c1+0x5: popl %ebp >> db> bt >> Tracing pid 11 tid 100003 td 0xc5176af0 >> acpi_cpu_c1(1,c4ececa8,1,0,c4ececc0,...) at 0xc09252c5 = acpi_cpu_c1+0x5 >> acpi_cpu_idle(c4ececd4,c093c0ab,0,c4ececf4,c066fdec,...) at 0xc04acf37 >> = acpi_cpu_idle+0x107 >> cpu_idle_acpi(0,c4ececf4,c066fdec,0,0,...) at 0xc093d5bb = >> cpu_idle_acpi+0x1b >> cpu_idle(0,0,c5176af0,c4ececf4,202,...) at 0xc093c0ab = cpu_idle+0x1b >> sched_idletd(0,c4ececd38,a4108400,2c0a0e,7022d00,...) at 0xc066fdec = >> sched_idletd+0x1c >> fork_exit(c066fdd0,0,c4eced38) at 0xc0623aa1 = fork_exit+0x91 >> fork_trampoline() at 0xc0930c80 = fork_tramoline+0x8 >> --- trap 0, eip = 0, esp = 0xc4ececd70, ebp = 0 --- >> >> >> P.S.: i386, dual-core, drm and radeon compiled as modules >> When I'm trying to boot w/o ACPI support all seems work fine, but >> system hangs just before starting kdm > > Please try http://www.FreeBSD.org/~jhb/patches/msi_assign.patch > I have applied your patch to r195303 (which still panics as before when unpatched). The panic I previously got with my amd64 based system does not occur anymore, so the problem seems to be solved. I do not have an i386 system with MSI available to test the patch. Kind regards, Hans From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 11:37:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B32E106566C for ; Fri, 3 Jul 2009 11:37:11 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from solfertje.student.utwente.nl (solfertje.student.utwente.nl [130.89.167.40]) by mx1.freebsd.org (Postfix) with ESMTP id 0410E8FC16 for ; Fri, 3 Jul 2009 11:37:10 +0000 (UTC) (envelope-from dalroi@solfertje.student.utwente.nl) Received: from localhost (localhost [127.0.0.1]) by solfertje.student.utwente.nl (Postfix) with SMTP id 17BE18061 for ; Fri, 3 Jul 2009 13:18:33 +0200 (CEST) Received: from hollewijn.internal (hollewijn.internal [10.236.150.4]) by solfertje.student.utwente.nl (Postfix) with ESMTP id 841F68053; Fri, 3 Jul 2009 13:18:28 +0200 (CEST) Message-Id: <1944CCC8-B2D5-4C06-B21C-FAA5A37D6EE1@solfertje.student.utwente.nl> From: Alban Hertroys To: Anton Shterenlikht In-Reply-To: <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 3 Jul 2009 13:18:28 +0200 References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> X-Mailer: Apple Mail (2.935.3) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Jul 3 13:18:33 2009 X-DSPAM-Confidence: 1.0000 X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 909,4a4de909759157325793587 X-DSPAM-Factors: 27, many, 0.40000, but, 0.40000, but, 0.40000, That, 0.40000, That, 0.40000, From*Alban, 0.40000, shell, 0.40000, I+tried, 0.40000, partion, 0.40000, just, 0.40000, that+case, 0.40000, I'd+like, 0.40000, mount+the, 0.40000, system+>, 0.40000, still+cannot, 0.40000, from+a, 0.40000, can+always, 0.40000, Mime-Version*Message, 0.40000, geom+metadata, 0.40000, >+gmirror, 0.40000, >+gmirror, 0.40000, freebsd+current, 0.40000, "freebsd, 0.40000, or, 0.40000, or, 0.40000, 12+12, 0.40000, >+da1p2, 0.40000 Cc: freebsd-ia64@freebsd.org, Wojciech Puchar , Marcel Moolenaar , freebsd-questions@freebsd.org, freebsd-current@freebsd.org Subject: Re: gmirror per partition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 11:37:12 -0000 On Jul 3, 2009, at 12:12 PM, Anton Shterenlikht wrote: > now to mirror root partition. > > My problem is that root is mounted and cannot (?) be unmounted, > unlike /efi, > on the live system. > > # gpart add -b 819234 -s 1048576 -t freebsd-ufs da1 > da1p2 added > # > > # gmirror label -vb round-robin root /dev/da0p2 > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > # > > If I create gmirror on da1, the spare disk: > > # gmirror label -vb round-robin root /dev/da1p2 > Metadata value stored on /dev/da0p1. > Done. > # > > so that > > # gmirror status > Name Status Components > mirror/efi COMPLETE da0p1 > da1p1 > mirror/root COMPLETE da1p2 > > # > > > then I still cannot insert da0p2 > > > # gmirror insert root da0p2 > gmirror: Cannot access provider da0p2. > # > > So how can I gmirror root partion on a live system? You're almost there... I did this a while ago, can't remember when, but I just upgraded the system that had this from FreeBSD 6.3 of sometime in 2006 to 7.2. What I believe I did from this point on was: Copy everything from the root partition to mirror/root. Modify /etc/fstab to mount root on mirror/root. Reboot. Now the original root partition isn't mounted anymore, so we can do operate on it's geom stuff. gmirror insert root da0p2 That should be it. If that doesn't work you can always boot off a live file-system CD/DVD and perform these actions from there. You won't have man pages in that case though, or at least I couldn't find a way to read them off the DVD last I tried. One thing I'd like to warn about at this point: If you ever upgrade to a kernel with a newer geom metadata version and that new kernel crashes, you're left with a system where the new kernel can't boot at all while the old kernel can't mount the root mirror as it's now of a version it can't handle. You can however mount a single geom provider of that root file system (/dev/da1p2 for example) to try to fix things. That file-system WILL be dirty, but DON'T run fsck on it or you will destroy it's contents. That's what happened to my upgrade above... Thankfully it was only my root partition with hardly any data on it and I did make level 0 dumps before the upgrade, but I needed to restore that FS from a fixit shell without man pages. Augh! > many thanks > > -- > Anton Shterenlikht > Room 2.6, Queen's Building > Mech Eng Dept > Bristol University > University Walk, Bristol BS8 1TR, UK > Tel: +44 (0)117 928 8233 > Fax: +44 (0)117 929 4423 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " > > > > Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:909,4a4de909759157325793587! From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 13:07:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F6361065670; Fri, 3 Jul 2009 13:07:21 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: from mail-px0-f181.google.com (mail-px0-f181.google.com [209.85.216.181]) by mx1.freebsd.org (Postfix) with ESMTP id 3CE908FC0A; Fri, 3 Jul 2009 13:07:21 +0000 (UTC) (envelope-from lwindschuh@googlemail.com) Received: by pxi11 with SMTP id 11so681899pxi.3 for ; Fri, 03 Jul 2009 06:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=HJgERYNJPBIzb1hjkBTg5jMuPsho3jkNkc6Alna2CXs=; b=sz8hJhb5YlEHPLQczhtjd7lNrIsoDC8X8APAV+hl13p3EJskbon8ji61K9jhe8EsZ0 PHlmxefRnU63X+C5XdM602eXYj+AGFvLSzHsnWXKEG0v6QpoJ7BQwxj3FHVdXDpYQIiM HUtqpOlocVt6EIP5OClod6Jjvrp6kPjdWrqQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=mY2hAypVgtLk1plbGaajVt1YW+sgQC9aUpk1Nal3uMp7WsnS2x328PQHGKUgeLdYa9 skLMiJLlfYqUuSxe0NfT4K/wzgzwSVx0sw+t7juGJaMZ/Q54t99f59QCxVSybmqAWqhf pHAwjCUw2AGWCziibj0ldPu6yG+lbWiROCZGA= MIME-Version: 1.0 Received: by 10.142.114.15 with SMTP id m15mr482618wfc.284.1246626440912; Fri, 03 Jul 2009 06:07:20 -0700 (PDT) In-Reply-To: <4A4CFCDD.4020202@FreeBSD.org> References: <4A4CFCDD.4020202@FreeBSD.org> Date: Fri, 3 Jul 2009 15:07:20 +0200 Message-ID: <90a5caac0907030607s3db6a325jbf41f65f3d5fe428@mail.gmail.com> From: Lucius Windschuh To: Alexander Motin , current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 13:07:21 -0000 2009/7/2 Alexander Motin : > [cdrecord -scanbus broken] > > It is the same problem I have fixed in camcontrol. You can do the same wi= th > changing in scsi-bsd.c in cdrtools > #define>CAM_MAXDEVS =A0 =A0 128 > to > #define>CAM_MAXDEVS =A0 =A0 50. > I hope it is temporal solution. I am thinking about to remove or at least > rise that limitation. It woks, indeed. And you AHCI driver also works without problems until now. Thanks Lucius From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 13:28:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F5421065672; Fri, 3 Jul 2009 13:28:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 592D78FC23; Fri, 3 Jul 2009 13:28:41 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n63DQCGM016627; Fri, 3 Jul 2009 09:26:12 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907031326.n63DQCGM016627@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Jul 2009 09:28:41 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <200907022117.n62LHrvZ010791@lava.sentex.ca> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 13:28:41 -0000 At 05:20 PM 7/2/2009, Mike Tancsa wrote: >But, going back to the original i386 image, with the boot blocks >reinstalled and using your latest patch, it seems to work! (however, >the same 300sec delay due to the cdrom ? ) At first, I thought something was a miss speed wise, but it looks like this hardware is either having issues, or something is wrong in general as its the same no matter which driver is used. Usually the speeds are much quicker than whats below on block writes Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 1 4000 39798 20.8 39725 4.3 17776 3.4 40269 27.1 42085 4.2 255.8 0.6 2 4000 38827 20.3 40116 4.4 18068 3.4 40227 27.3 42266 4.3 244.8 0.5 3 4000 39748 20.8 40166 4.4 17952 3.3 40192 27.3 42259 4.3 243.4 0.5 4 4000 39855 20.8 40066 4.4 18017 3.3 40206 27.1 42401 4.2 264.2 0.6 1=AHCI in bios, AHCI.ko loaded 2=AHCI in bios, plain old ata driver used post patch 3=IDE in bios, plain old ata driver used post patch 4=IDE in bios, plain old ata driver from the cvs Note, with 2 dmesg shows acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 the boot process then hangs for about 5 seconds, and then proceeds with 3, the boot process hangs a total of about 2 min. ---Mike From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 13:53:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C5C21065674; Fri, 3 Jul 2009 13:53:27 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id C4AC58FC18; Fri, 3 Jul 2009 13:53:26 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 247581945; Fri, 03 Jul 2009 16:53:21 +0300 Message-ID: <4A4E0D51.3080904@FreeBSD.org> Date: Fri, 03 Jul 2009 16:53:21 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Mike Tancsa References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> In-Reply-To: <200907031326.n63DQCGM016627@lava.sentex.ca> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 13:53:27 -0000 Mike Tancsa wrote: > At 05:20 PM 7/2/2009, Mike Tancsa wrote: >> But, going back to the original i386 image, with the boot blocks >> reinstalled and using your latest patch, it seems to work! (however, >> the same 300sec delay due to the cdrom ? ) > > At first, I thought something was a miss speed wise, but it looks like > this hardware is either having issues, or something is wrong in general > as its the same no matter which driver is used. Usually the speeds are > much quicker than whats below on block writes > > > Seeker 1...Seeker 2...Seeker 3...start 'em...done...done...done... > -------Sequential Output-------- ---Sequential Input-- > --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- > --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > /sec %CPU > 1 4000 39798 20.8 39725 4.3 17776 3.4 40269 27.1 42085 4.2 > 255.8 0.6 > 2 4000 38827 20.3 40116 4.4 18068 3.4 40227 27.3 42266 4.3 > 244.8 0.5 > 3 4000 39748 20.8 40166 4.4 17952 3.3 40192 27.3 42259 4.3 > 243.4 0.5 > 4 4000 39855 20.8 40066 4.4 18017 3.3 40206 27.1 42401 4.2 > 264.2 0.6 > > 1=AHCI in bios, AHCI.ko loaded > 2=AHCI in bios, plain old ata driver used post patch > 3=IDE in bios, plain old ata driver used post patch > 4=IDE in bios, plain old ata driver from the cvs This test looks inadequate. there is almost no modern SATA HDDs having only 40MB/s of linear read/write speed. Usual values now are 60-100MB/s and they should be reached with almost any working driver. Can you try simple `dd if=/dev/ada0 of=/dev/null bs=1m count=1000`? To obtain any measurable benefit from NCQ usage you should have many random requests to the drive running simultaneously. Not sure how this specific test works. Also NCQ depends on effective disk firmware to realize that benefit. > Note, with 2 dmesg shows > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > acd0: FAILURE - READ_BIG ILLEGAL REQUEST asc=0x64 ascq=0x00 > > the boot process then hangs for about 5 seconds, and then proceeds > > with 3, the boot process hangs a total of about 2 min. If you have issues with old driver also, then it is probably some drive specifics, but not a bug of the new implementation. There was no changes to the old ATA. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 14:15:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 879DD1065687; Fri, 3 Jul 2009 14:15:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 4894F8FC15; Fri, 3 Jul 2009 14:15:31 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n63ED2jl016885; Fri, 3 Jul 2009 10:13:02 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907031413.n63ED2jl016885@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Jul 2009 10:15:26 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <4A4E0D51.3080904@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 14:15:31 -0000 At 09:53 AM 7/3/2009, Alexander Motin wrote: >This test looks inadequate. there is almost no modern SATA HDDs having >only 40MB/s of linear read/write speed. Usual values now are 60-100MB/s >and they should be reached with almost any working driver. Can you try >simple `dd if=/dev/ada0 of=/dev/null bs=1m count=1000`? Something about this particular disk perhaps 0[i7]# dd if=/dev/ad4 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 14.933896 secs (70214497 bytes/sec) Using a different seagate disk, 0[i7]# dd if=/dev/ad6 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 7.542932 secs (139014377 bytes/sec) 0[i7]# I will re-run the tests with the newer seagate. Perhaps a firmware update to the 'slow' one might help Protocol SATA revision 2.x device model ST380811AS serial number 6PS03G9Z firmware revision 3.AAE cylinders 16383 heads 16 sectors/track 63 lba supported 156301488 sectors lba48 supported 156301488 sectors dma supported overlap not supported Feature Support Enable Value Vendor write cache yes yes read ahead yes yes Native Command Queuing (NCQ) yes - 31/0x1F Tagged Command Queuing (TCQ) no no 31/0x1F SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management no no 65278/0xFEFE automatic acoustic management no no 0/0x00 208/0xD0 >If you have issues with old driver also, then it is probably some drive >specifics, but not a bug of the new implementation. There was no changes >to the old ATA. Yes, it certainly seems so. This DVD is off the PATA bus 0[i7]# atacontrol list ATA channel 0: Master: no device present Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: no device present Slave: acd0 ATA/ATAPI revision 7 ATA channel 3: Master: ad6 SATA revision 2.x Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present 0[i7]# >-- >Alexander Motin >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 14:26:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA45D106564A; Fri, 3 Jul 2009 14:26:50 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 380C78FC14; Fri, 3 Jul 2009 14:26:49 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 247586714; Fri, 03 Jul 2009 17:26:46 +0300 Message-ID: <4A4E1525.2040809@FreeBSD.org> Date: Fri, 03 Jul 2009 17:26:45 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Mike Tancsa References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> In-Reply-To: <200907031413.n63ED2jl016885@lava.sentex.ca> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 14:26:51 -0000 Mike Tancsa wrote: >> If you have issues with old driver also, then it is probably some drive >> specifics, but not a bug of the new implementation. There was no changes >> to the old ATA. > > Yes, it certainly seems so. This DVD is off the PATA bus > > 0[i7]# atacontrol list > ATA channel 2: > Master: no device present > Slave: acd0 ATA/ATAPI revision 7 Wait! Stop! I have got lost in what we are testing. In some of your your previous messages today I have seen: (probe2:ahcich2:0:0:0): SIGNATURE: eb14 run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config ahcich2: Timeout on slot 4 run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config ahcich2: Timeout on slot 5 First line means that it is ATAPI drive on AHCI SATA controller and latest lines mean that it is not working properly. Now you are talking that this is PATA drive. Could you please somehow identify each of your system to let me identify problems and solutions separately. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 14:32:52 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BB4D1065814; Fri, 3 Jul 2009 14:32:52 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id AC15A8FC16; Fri, 3 Jul 2009 14:32:51 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n63EUMH1016965; Fri, 3 Jul 2009 10:30:22 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907031430.n63EUMH1016965@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Jul 2009 10:32:48 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <4A4E1525.2040809@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 14:32:53 -0000 At 10:26 AM 7/3/2009, Alexander Motin wrote: >Wait! Stop! I have got lost in what we are testing. In some of your your >previous messages today I have seen: Sorry, I just opened up the case to confirm, and it is indeed a SATA DVD drive. ---Mike From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 14:49:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 994251065673; Fri, 3 Jul 2009 14:49:21 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id DDD638FC14; Fri, 3 Jul 2009 14:49:20 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 247590252; Fri, 03 Jul 2009 17:49:17 +0300 Message-ID: <4A4E1A6C.3090605@FreeBSD.org> Date: Fri, 03 Jul 2009 17:49:16 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: Mike Tancsa References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> In-Reply-To: <200907031430.n63EUMH1016965@lava.sentex.ca> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 14:49:21 -0000 Mike Tancsa wrote: > At 10:26 AM 7/3/2009, Alexander Motin wrote: > >> Wait! Stop! I have got lost in what we are testing. In some of your your >> previous messages today I have seen: > > Sorry, I just opened up the case to confirm, and it is indeed a SATA DVD > drive. Messages like "it's just not working" will not give anything except upsetting me. Usually I need more information. So if you are really what to track and fix some problem, please, identify it somehow, to be able to send more follow-ups later and compare to different user's results. Open cases one by one in separate emails. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 15:26:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0D12106564A for ; Fri, 3 Jul 2009 15:26:05 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 761488FC15 for ; Fri, 3 Jul 2009 15:26:05 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 3496063317E for ; Fri, 3 Jul 2009 17:26:04 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id A39CFB973 for ; Fri, 3 Jul 2009 17:26:02 +0200 (CEST) Date: Fri, 3 Jul 2009 17:26:00 +0200 From: Patrick Lamaiziere To: freebsd-current@freebsd.org Message-ID: <20090703172600.1971111e@baby-jane.lamaiziere.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 15:26:05 -0000 Hello, [Yesterday CURRENT/i386] I've got some troubles with unlpt, most of the time I can't print and I must stop cupsd, kill -9 the process usb, and unplug the USB printer. Then it works again for some time (but mostly one time). The printer is a Brother HL-1430 (working fine under FreeBSD since FreeBSD 4.X) ulpt0: on usbus0 ulpt_attach:562: setting alternate config number: 0 ulpt0: using bi-directional mode With hw.usb.ulpt.debug=1, I've got a lot of: ulpt_write_callback:204: state=0x0 actlen=0 ulpt_status_callback:328: error=USB_ERR_IOERROR last message repeated 31 times last message repeated 78 times ... When it works: ulpt_write_callback:220: state=0x0 actlen=0 ulpt_write_callback:220: state=0x1 actlen=2889 ulpt_write_callback:220: state=0x1 actlen=3023 ... Thanks in advance, regards. From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 15:57:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AC4AB1065670 for ; Fri, 3 Jul 2009 15:57:23 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.tele2.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 3AF038FC18 for ; Fri, 3 Jul 2009 15:57:22 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=BQeo18V-fugA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=LW_lHvPeHecOIxRYOa0A:9 a=d9WZKUr1I55NipgeVG8A:7 a=ab8BiIIzGlbPuIFN5SX9rBnwrqYA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 529420021; Fri, 03 Jul 2009 17:57:20 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 3 Jul 2009 17:56:54 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090703172600.1971111e@baby-jane.lamaiziere.net> In-Reply-To: <20090703172600.1971111e@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907031756.55253.hselasky@c2i.net> Cc: Patrick Lamaiziere Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 15:57:23 -0000 On Friday 03 July 2009 17:26:00 Patrick Lamaiziere wrote: > Hello, > > [Yesterday CURRENT/i386] > > I've got some troubles with unlpt, most of the time I can't print and I > must stop cupsd, kill -9 the process usb, and unplug the USB printer. > Then it works again for some time (but mostly one time). > > The printer is a Brother HL-1430 (working fine under FreeBSD since > FreeBSD 4.X) > > ulpt0: addr 2> on usbus0 > ulpt_attach:562: setting alternate config number: 0 > ulpt0: using bi-directional mode > > With hw.usb.ulpt.debug=1, I've got a lot of: > > ulpt_write_callback:204: state=0x0 actlen=0 > ulpt_status_callback:328: error=USB_ERR_IOERROR > last message repeated 31 times > last message repeated 78 times > ... > > When it works: > ulpt_write_callback:220: state=0x0 actlen=0 > ulpt_write_callback:220: state=0x1 actlen=2889 > ulpt_write_callback:220: state=0x1 actlen=3023 > ... Hi, Have you tried: usbconfig -u XXX -a YYY reset Does it help? To me it looks like a problem about your printer USB firmware. Does it respond to: usbconfig -u XXX -a YYY dump_curr_config_desc After the first print job? XXX and YYY are the numbers after the "ugen" in dmesg. --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 15:59:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A151A1065686 for ; Fri, 3 Jul 2009 15:59:00 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.tele2.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id 2F26D8FC0A for ; Fri, 3 Jul 2009 15:58:59 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=BQeo18V-fugA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=wowbBRiDF6J161K-dfAA:9 a=9e5b3OZf0JbDbl6Ql2gA:7 a=hsjLSH9-U5V8yJK7lv78a3SCdzkA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 529421087; Fri, 03 Jul 2009 17:58:58 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 3 Jul 2009 17:58:34 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090703172600.1971111e@baby-jane.lamaiziere.net> In-Reply-To: <20090703172600.1971111e@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907031758.35319.hselasky@c2i.net> Cc: Patrick Lamaiziere Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 15:59:00 -0000 On Friday 03 July 2009 17:26:00 Patrick Lamaiziere wrote: > Hello, > > [Yesterday CURRENT/i386] > > I've got some troubles with unlpt, most of the time I can't print and I > must stop cupsd, kill -9 the process usb, and unplug the USB printer. > Then it works again for some time (but mostly one time). > > The printer is a Brother HL-1430 (working fine under FreeBSD since > FreeBSD 4.X) > Did you try both: /dev/unlpt0 and /dev/ulpt0 ? --HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 16:52:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2D751065674 for ; Fri, 3 Jul 2009 16:52:36 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 9629B8FC21 for ; Fri, 3 Jul 2009 16:52:36 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 7FA7063317E; Fri, 3 Jul 2009 18:52:35 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id DC06FB973; Fri, 3 Jul 2009 18:52:33 +0200 (CEST) Date: Fri, 3 Jul 2009 18:52:33 +0200 From: Patrick Lamaiziere To: Hans Petter Selasky Message-ID: <20090703185233.4f7e4a65@baby-jane.lamaiziere.net> In-Reply-To: <200907031756.55253.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031756.55253.hselasky@c2i.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 16:52:37 -0000 Le Fri, 3 Jul 2009 17:56:54 +0200, Hans Petter Selasky a =E9crit : > Have you tried: >=20 > usbconfig -u XXX -a YYY reset >=20 > Does it help? No, it returns=20 # usbconfig -u 0 -a 2 reset usbconfig: could not reset device: Input/output error Then ulpt detaches ulpt0: at uhub0, port 1, addr 2 (disconnected) ulpt_detach:653: sc=3D0xc317f000 > To me it looks like a problem about your printer USB firmware. Does > it respond to: >=20 > usbconfig -u XXX -a YYY dump_curr_config_desc >=20 > After the first print job? Yes, after the first job: # usbconfig -u 0 -a 2 dump_curr_config_desc ugen0.2: at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON Configuration index 0 bLength =3D 0x0009=20 bDescriptorType =3D 0x0002=20 wTotalLength =3D 0x0020 =20 bNumInterfaces =3D 0x0001 =20 bConfigurationValue =3D 0x0001=20 iConfiguration =3D 0x0000 bmAttributes =3D 0x00c0 =20 bMaxPower =3D 0x0001 =20 Interface 0 bLength =3D 0x0009=20 bDescriptorType =3D 0x0004 bInterfaceNumber =3D 0x0000 bAlternateSetting =3D 0x0000 bNumEndpoints =3D 0x0002 bInterfaceClass =3D 0x0007 bInterfaceSubClass =3D 0x0001 bInterfaceProtocol =3D 0x0002 iInterface =3D 0x0000 Endpoint 0 bLength =3D 0x0007 bDescriptorType =3D 0x0005 bEndpointAddress =3D 0x0001 bmAttributes =3D 0x0002 wMaxPacketSize =3D 0x0040 bInterval =3D 0x0000 bRefresh =3D 0x0000 bSynchAddress =3D 0x0000 Endpoint 1 bLength =3D 0x0007 bDescriptorType =3D 0x0005 bEndpointAddress =3D 0x0082 bmAttributes =3D 0x0002 wMaxPacketSize =3D 0x0040 bInterval =3D 0x0000 bRefresh =3D 0x0000 bSynchAddress =3D 0x0000 It looks like there are some problems even with the first job (I missed this point before). ulpt0: using bi-directional ulpt_write_callback:220: state=3D0x0 actlen=3D0=20 ulpt_write_callback:220: state=3D0x1 actlen=3D2889 ulpt_write_callback:220: state=3D0x1 actlen=3D3023 ... ulpt_status_callback:352: error=3DUSB_ERR_STALLED ulpt_write_callback:220: state=3D0x1 actlen=3D16384 ulpt_write_callback:220: state=3D0x1 actlen=3D16384 ... ulpt_status_callback:352: error=3DUSB_ERR_IOERROR ulpt_write_callback:220: state=3D0x1 actlen=3D16384 ulpt_write_callback:220: state=3D0x1 actlen=3D16384 ... ulpt_status_callback:352: error=3DUSB_ERR_IOERROR ulpt_write_callback:220: state=3D0x1 actlen=3D16384 ulpt_write_callback:220: state=3D0x1 actlen=3D15970 ulpt_status_callback:352: error=3DUSB_ERR_IOERROR ulpt_status_callback:352: error=3DUSB_ERR_IOERROR ulpt_status_callback:352: error=3DUSB_ERR_IOERROR ... (ad eternam) If it can help, I can compare with FreeBSD 7.2. Thank you. From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 17:29:46 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF508106564A for ; Fri, 3 Jul 2009 17:29:46 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swip.net [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 1B42E8FC0A for ; Fri, 3 Jul 2009 17:29:45 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=BQeo18V-fugA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=8kQB0OdkAAAA:8 a=btfoDKtnj2lBV_FJ9zQA:9 a=T7Aa-naySfWFPN8LFeEA:7 a=BvayL-nRSsXDwiZb4KGQxTAOLl0A:4 a=9aOQ2cSd83gA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 529979622; Fri, 03 Jul 2009 19:29:42 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 3 Jul 2009 19:29:15 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031756.55253.hselasky@c2i.net> <20090703185233.4f7e4a65@baby-jane.lamaiziere.net> In-Reply-To: <20090703185233.4f7e4a65@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200907031929.17327.hselasky@c2i.net> Cc: Patrick Lamaiziere Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 17:29:47 -0000 On Friday 03 July 2009 18:52:33 Patrick Lamaiziere wrote: > Le Fri, 3 Jul 2009 17:56:54 +0200, > > Hans Petter Selasky a =E9crit : > > Have you tried: > > > > usbconfig -u XXX -a YYY reset > > > > Does it help? > > No, it returns > # usbconfig -u 0 -a 2 reset > usbconfig: could not reset device: Input/output error > > Then ulpt detaches > ulpt0: at uhub0, port 1, addr 2 (disconnected) > ulpt_detach:653: sc=3D0xc317f000 > > > To me it looks like a problem about your printer USB firmware. Does > > it respond to: > > > > usbconfig -u XXX -a YYY dump_curr_config_desc > > > > After the first print job? > > Yes, after the first job: > > # usbconfig -u 0 -a 2 dump_curr_config_desc ugen0.2: vendor 0x04f9> at usbus0, cfg=3D0 md=3DHOST spd=3DFULL (12Mbps) pwr=3DON > > > Configuration index 0 > > bLength =3D 0x0009 > bDescriptorType =3D 0x0002 > wTotalLength =3D 0x0020 > bNumInterfaces =3D 0x0001 > bConfigurationValue =3D 0x0001 > iConfiguration =3D 0x0000 > bmAttributes =3D 0x00c0 > bMaxPower =3D 0x0001 > > Interface 0 > bLength =3D 0x0009 > bDescriptorType =3D 0x0004 > bInterfaceNumber =3D 0x0000 > bAlternateSetting =3D 0x0000 > bNumEndpoints =3D 0x0002 > bInterfaceClass =3D 0x0007 > bInterfaceSubClass =3D 0x0001 > bInterfaceProtocol =3D 0x0002 > iInterface =3D 0x0000 > > Endpoint 0 > bLength =3D 0x0007 > bDescriptorType =3D 0x0005 > bEndpointAddress =3D 0x0001 > bmAttributes =3D 0x0002 > wMaxPacketSize =3D 0x0040 > bInterval =3D 0x0000 > bRefresh =3D 0x0000 > bSynchAddress =3D 0x0000 > > Endpoint 1 > bLength =3D 0x0007 > bDescriptorType =3D 0x0005 > bEndpointAddress =3D 0x0082 > bmAttributes =3D 0x0002 > wMaxPacketSize =3D 0x0040 > bInterval =3D 0x0000 > bRefresh =3D 0x0000 > bSynchAddress =3D 0x0000 > > > It looks like there are some problems even with the first job (I missed > this point before). > > ulpt0: using bi-directional > ulpt_write_callback:220: state=3D0x0 actlen=3D0 > ulpt_write_callback:220: state=3D0x1 actlen=3D2889 > ulpt_write_callback:220: state=3D0x1 actlen=3D3023 > ... > ulpt_status_callback:352: error=3DUSB_ERR_STALLED > ulpt_write_callback:220: state=3D0x1 actlen=3D16384 > ulpt_write_callback:220: state=3D0x1 actlen=3D16384 At this point it looks like the firmware crashes, when the error code chang= es=20 from STALLED to IOERROR. Are you sure the .ps/.pcl file is not corrupt? > ... > ulpt_status_callback:352: error=3DUSB_ERR_IOERROR > ulpt_write_callback:220: state=3D0x1 actlen=3D16384 > ulpt_write_callback:220: state=3D0x1 actlen=3D16384 > ... > ulpt_status_callback:352: error=3DUSB_ERR_IOERROR > ulpt_write_callback:220: state=3D0x1 actlen=3D16384 > ulpt_write_callback:220: state=3D0x1 actlen=3D15970 > ulpt_status_callback:352: error=3DUSB_ERR_IOERROR > ulpt_status_callback:352: error=3DUSB_ERR_IOERROR > ulpt_status_callback:352: error=3DUSB_ERR_IOERROR > ... (ad eternam) > > If it can help, I can compare with FreeBSD 7.2. Yes, that might give some more clues. =2D-HPS From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 17:34:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0BD011065670 for ; Fri, 3 Jul 2009 17:34:04 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id C42CA8FC1A for ; Fri, 3 Jul 2009 17:34:03 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 1B3A463317E; Fri, 3 Jul 2009 19:34:03 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 702EABE76; Fri, 3 Jul 2009 19:34:01 +0200 (CEST) Date: Fri, 3 Jul 2009 19:34:00 +0200 From: Patrick Lamaiziere To: freebsd-current@freebsd.org Message-ID: <20090703193400.60fef21f@baby-jane.lamaiziere.net> In-Reply-To: <200907031758.35319.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031758.35319.hselasky@c2i.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hans Petter Selasky Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 17:34:04 -0000 Le Fri, 3 Jul 2009 17:58:34 +0200, Hans Petter Selasky a =E9crit : > > The printer is a Brother HL-1430 (working fine under FreeBSD since > > FreeBSD 4.X) > > >=20 > Did you try both: >=20 > /dev/unlpt0 and /dev/ulpt0 I tried : with ulpt0 the printer does not print anything (With previous FreeBSD I used unlpt0): the reset disconnects the printer. ulpt0: on usbus0=20 ulpt_attach:562: setting alternate config number: 0 ulpt0: using bi-directional mode ugen0.2: at usbus0 (disconnected) ulpt0: at uhub0, port 1, addr 2 (disconnected) ulpt_detach:653: sc=3D0xc3176480 ugen0.2: at usbus0 ulpt0: on usbus0 ulpt_attach:562: setting alternate config number: 0 ulpt0: using bi-directional mode From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 18:25:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0126B106564A for ; Fri, 3 Jul 2009 18:25:29 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id CA9308FC12 for ; Fri, 3 Jul 2009 18:25:28 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n63IPMXY095470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Jul 2009 11:25:22 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <4A4E4D12.9010501@freebsd.org> Date: Fri, 03 Jul 2009 11:25:22 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.21 (X11/20090411) MIME-Version: 1.0 To: Patrick Lamaiziere References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031758.35319.hselasky@c2i.net> <20090703193400.60fef21f@baby-jane.lamaiziere.net> In-Reply-To: <20090703193400.60fef21f@baby-jane.lamaiziere.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org, Hans Petter Selasky Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 18:25:29 -0000 Patrick Lamaiziere wrote: > Le Fri, 3 Jul 2009 17:58:34 +0200, > Hans Petter Selasky a écrit : > > >>> The printer is a Brother HL-1430 (working fine under FreeBSD since >>> FreeBSD 4.X) >>> >>> >> Did you try both: >> >> /dev/unlpt0 and /dev/ulpt0 >> > > I tried : with ulpt0 the printer does not print anything (With > previous FreeBSD I used unlpt0): the reset disconnects the printer. > > ulpt0: > on usbus0 > ulpt_attach:562: setting alternate config number: 0 > ulpt0: using bi-directional mode > ugen0.2: at usbus0 (disconnected) > ulpt0: at uhub0, port 1, addr 2 (disconnected) > ulpt_detach:653: sc=0xc3176480 > ugen0.2: at usbus0 > ulpt0: > on usbus0 ulpt_attach:562: setting alternate config number: 0 > ulpt0: using bi-directional mode > This looks a bit like an issue I'm about to start chasing where FS devices fed through a HS hub disconnect "spontaneously" under load. It doesn't look like it but to be sure there are no hubs between the host and the printer? Sam From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 19:00:43 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 54C31106566C; Fri, 3 Jul 2009 19:00:43 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 15DC68FC0C; Fri, 3 Jul 2009 19:00:42 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n63IwDIt018455; Fri, 3 Jul 2009 14:58:13 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907031858.n63IwDIt018455@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Jul 2009 15:00:34 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <4A4E1A6C.3090605@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 19:00:43 -0000 At 10:49 AM 7/3/2009, Alexander Motin wrote: >Mike Tancsa wrote: > > At 10:26 AM 7/3/2009, Alexander Motin wrote: > > > >> Wait! Stop! I have got lost in what we are testing. In some of your your > >> previous messages today I have seen: > > > > Sorry, I just opened up the case to confirm, and it is indeed a SATA DVD > > drive. > >Messages like "it's just not working" will not give anything except >upsetting me. Usually I need more information. So if you are really what >to track and fix some problem, please, identify it somehow, to be able >to send more follow-ups later and compare to different user's results. >Open cases one by one in separate emails. Sorry again for the confusion. I am trying a *different* motherboard (INTEL DX58SO) and drive now with your 0629 patch as well as the diff below. --- ahci.c.prev 2009-06-29 12:48:45.000000000 +0300 +++ ahci.c 2009-06-29 17:25:29.000000000 +0300 @@ -986,7 +986,7 @@ ahci_begin_transaction(device_t dev, uni if (ch->slot[tag].state == AHCI_SLOT_EMPTY) break; } while (tag != ch->lastslot); - if (tag == ch->lastslot) + if (ch->slot[tag].state != AHCI_SLOT_EMPTY) device_printf(ch->dev, "ALL SLOTS BUSY!\n"); ch->lastslot = tag; /* Occupy chosen slot. */ Without the diff, I was getting a steady stream of ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! ahcich0: ALL SLOTS BUSY! With the above diff, all seems to work well. Full verbose dmesg and pciconf -lvc at http://www.tancsa.com/ahci/DX58SO.txt Read/Write speed looks good with a more modern disk as well -------Sequential Output-------- ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 4000 103884 51.4 109344 9.7 42048 6.0 91201 59.0 116723 8.5 1123.4 2.0 0(ich10)# dd if=/dev/ada0 of=/dev/null bs=1m count=1000 1000+0 records in 1000+0 records out 1048576000 bytes transferred in 7.562206 secs (138660068 bytes/sec) 0(ich10)# The eSata port does not work, but it never did under the old driver either. I think it has a separate controller ? At the BIOS boot up time, it shows some Marvell controller talking to the eSata attached drive, and pciconf does show a separate ATA controller ahci0@pci0:0:31:2: class=0x010601 card=0x4f538086 chip=0x3a228086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '6 port SATA AHCI Controller' class = mass storage subclass = SATA cap 05[80] = MSI supports 16 messages enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair none7@pci0:0:31:3: class=0x0c0500 card=0x4f538086 chip=0x3a308086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'SMB controller (50011458)' class = serial bus subclass = SMBus atapci0@pci0:6:0:0: class=0x01018f card=0x4f538086 chip=0x612111ab rev=0xb2 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '6121 SATA2 Controller' class = mass storage subclass = ATA cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 cap 05[50] = MSI supports 1 message cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link x1(x1) From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 19:31:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE018106564A; Fri, 3 Jul 2009 19:31:26 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 03D8C8FC0C; Fri, 3 Jul 2009 19:31:25 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247606204; Fri, 03 Jul 2009 22:31:22 +0300 Message-ID: <4A4E5C82.9070209@FreeBSD.org> Date: Fri, 03 Jul 2009 22:31:14 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Mike Tancsa References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> In-Reply-To: <200907031858.n63IwDIt018455@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 19:31:27 -0000 Mike Tancsa wrote: > I am trying a *different* motherboard > (INTEL DX58SO) and drive now with your 0629 patch as well as the diff > below. > With the above diff, all seems to work well. > > Full verbose dmesg and pciconf -lvc at > > http://www.tancsa.com/ahci/DX58SO.txt Fine. > Read/Write speed looks good with a more modern disk as well > > -------Sequential Output-------- ---Sequential Input-- > --Random-- > -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- > --Seeks--- > Machine MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU > /sec %CPU > 4000 103884 51.4 109344 9.7 42048 6.0 91201 59.0 116723 8.5 > 1123.4 2.0 > 0(ich10)# dd if=/dev/ada0 of=/dev/null bs=1m count=1000 > 1000+0 records in > 1000+0 records out > 1048576000 bytes transferred in 7.562206 secs (138660068 bytes/sec) > 0(ich10)# Fine. But first test still looks like bound by something. Or this test requires some tuning, or it is used over file system, your system may require tuning. It would be more interesting to investigate benefits on NCQ suitable workload, as that are new for us. Something like unpacking a lot of small files to normal or async-mounted or gjournalled FS, or some multi-threaded read, or something else. Would be nice to understand on which types of workload NCQ could give us visible effects. You can track real requests parallelism by looking on dev_active field of `camcontrol tags ada0 -v`. > The eSata port does not work, but it never did under the old driver > either. I think it has a separate controller ? At the BIOS boot up > time, it shows some Marvell controller talking to the eSata attached > drive, and pciconf does show a separate ATA controller > > > ahci0@pci0:0:31:2: class=0x010601 card=0x4f538086 chip=0x3a228086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = '6 port SATA AHCI Controller' > class = mass storage > subclass = SATA > cap 05[80] = MSI supports 16 messages enabled with 1 message > cap 01[70] = powerspec 3 supports D0 D3 current D0 > cap 12[a8] = SATA Index-Data Pair As I have noted in man page, "mass storage"/"SATA" is right device. > atapci0@pci0:6:0:0: class=0x01018f card=0x4f538086 chip=0x612111ab > rev=0xb2 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = '6121 SATA2 Controller' > class = mass storage > subclass = ATA > cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 > cap 05[50] = MSI supports 1 message > cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link > x1(x1) But this device, implementing both PATA and SATA ports, report itself as PATA controller. It's SATA part may be AHCI compatible, but driver unable to attach it due to incorrect device identification. Alike happens to my JMicron controllers, but in that case system BIOS is able to switch it into the right mode with separate PATA and AHCI SATA controllers devices. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 19:39:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67F79106566C for ; Fri, 3 Jul 2009 19:39:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 1913F8FC16 for ; Fri, 3 Jul 2009 19:39:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKv7TUqDaFvI/2dsb2JhbADNYIQSBYE6 X-IronPort-AV: E=Sophos;i="4.42,344,1243828800"; d="scan'208";a="40153151" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 03 Jul 2009 15:39:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 2BE5194009E; Fri, 3 Jul 2009 15:39:41 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzGyydD+rX4s; Fri, 3 Jul 2009 15:39:40 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 432F0940062; Fri, 3 Jul 2009 15:39:40 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n63Jg5u18625; Fri, 3 Jul 2009 15:42:05 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Fri, 3 Jul 2009 15:42:05 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Jilles Tjoelker In-Reply-To: <20090702212505.GA39889@stack.nl> Message-ID: References: <20090702121640.D245@maildrop.int.zabbadoz.net> <20090702122955.J245@maildrop.int.zabbadoz.net> <20090702212505.GA39889@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: Install from NFS onto NFS fails on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 19:39:42 -0000 On Thu, 2 Jul 2009, Jilles Tjoelker wrote: > > This could be because of NFS "sillyrename". To avoid some ESTALE errors, > the NFS client (for NFSv2 and NFSv3 at least) renames if you delete a > file that is currently in use (in this case, the rm binary). Because the > renamed file (name typically starts with .nfs) is in the same directory, > this causes problems when removing directories. Once the file is no > longer in use, it is finally deleted. > Yes, if some file that was in that directory is still open (or mmap'd and the process hasn't yet exit()'d), it will exist as a file named ".nfsXXX" until the v_usecount goes to 0 and then it's removed, which would explain it. > Maybe NFSv4 has a cleaner way to keep a file with 0 links as long as it > is open. > Afraid not. NFSv4 has an Open, but it is an open share lock and not a POSIX style open, so NFSv4 clients still do the silly rename. (ie. The NFSv4 Remove Op is defined as removing the file and not just unlinking it and the NFSv4 server isn't required to retain the file after removal if it is Open'd by a client.) rick From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 21:03:58 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BBE04106564A; Fri, 3 Jul 2009 21:03:58 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (unknown [IPv6:2001:2f0:104:80a0:21b:78ff:fe37:f1cf]) by mx1.freebsd.org (Postfix) with ESMTP id 589A48FC15; Fri, 3 Jul 2009 21:03:58 +0000 (UTC) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com ([192.168.36.249]) (authenticated bits=0) by sakura.ninth-nine.com (8.14.3/8.14.3/NinthNine) with ESMTP id n63L3nhb094300; Sat, 4 Jul 2009 06:03:54 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 4 Jul 2009 06:03:44 +0900 From: Norikatsu Shigemura To: John Baldwin Message-Id: <20090704060344.c1cd57f2.nork@FreeBSD.org> In-Reply-To: <4A4D3665.3060502@FreeBSD.org> References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> <4A4D3665.3060502@FreeBSD.org> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.16.4; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Hans Ottevanger , Robert Noland , Norikatsu Shigemura , freebsd-current@FreeBSD.org, Anonymous Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 21:03:59 -0000 Hi John. On Thu, 02 Jul 2009 18:36:21 -0400 John Baldwin wrote: > Please try http://www.FreeBSD.org/~jhb/patches/msi_assign.patch I confirmed that this issue was fixed by your patch on latest current kernel!! Thank you! -- Norikatsu Shigemura From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 21:06:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B14421065674 for ; Fri, 3 Jul 2009 21:06:16 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from mail.geek.sh (decoder.geek.sh [196.36.198.81]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC2F8FC20 for ; Fri, 3 Jul 2009 21:06:16 +0000 (UTC) (envelope-from aragon@phat.za.net) Received: from igor.geek.sh (unknown [196.209.244.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.geek.sh (Postfix) with ESMTPSA id 66FAA39913; Fri, 3 Jul 2009 22:48:58 +0200 (SAST) Message-ID: <4A4E6EB4.9000000@phat.za.net> Date: Fri, 03 Jul 2009 22:48:52 +0200 From: Aragon Gouveia User-Agent: Thunderbird 2.0.0.21 (X11/20090331) MIME-Version: 1.0 To: Anton Shterenlikht References: <20090703105232.GA14372@mech-cluster238.men.bris.ac.uk> In-Reply-To: <20090703105232.GA14372@mech-cluster238.men.bris.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: nice work on ntp.conf! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 21:06:17 -0000 Anton Shterenlikht wrote: > ntp.conf update from 2009/06/07 is very welcome, > works great straight out of the box, much better than before! > > many thanks to whoever worked on this. Agreed, thanks! Just wish there were a simple solution to the restriction directives... Regards, Aragon From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 21:28:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 646BA1065672 for ; Fri, 3 Jul 2009 21:28:50 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 0AE508FC18 for ; Fri, 3 Jul 2009 21:28:49 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lstewart-laptop.caia.swin.edu.au (host86-150-124-14.range86-150.btcentralplus.com [86.150.124.14]) (authenticated bits=0) by lauren.room52.net (8.14.3/8.14.3) with ESMTP id n63LSLvC013137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Jul 2009 07:28:41 +1000 (EST) (envelope-from lstewart@freebsd.org) Message-ID: <4A4E77EA.7030803@freebsd.org> Date: Fri, 03 Jul 2009 22:28:10 +0100 From: Lawrence Stewart User-Agent: Thunderbird 2.0.0.22 (X11/20090626) MIME-Version: 1.0 To: Kamigishi Rei References: <4A45ABB1.7040506@haruhiism.net> <4A48CE02.5000200@freebsd.org> <4A48D4A2.8010207@haruhiism.net> <4A48DA31.5010900@freebsd.org> <4A4BE438.5060203@haruhiism.net> In-Reply-To: <4A4BE438.5060203@haruhiism.net> Content-Type: multipart/mixed; boundary="------------020601070500000604040401" X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_PBL, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=disabled version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on lauren.room52.net Cc: silby@freebsd.org, freebsd-current@freebsd.org Subject: Re: r194546 amd64: kernel panic in tcp_sack.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 21:28:50 -0000 This is a multi-part message in MIME format. --------------020601070500000604040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kamigishi Rei wrote: > Lawrence Stewart wrote: >> Ok. I'm working on a patch to address a different TCP/SACK issue, but >> it may in fact be partially relevant to the cause of your panic... >> can't promise when I'll be able to take a close look at this but I'm >> aware of it now so that's a start. If you run into it again or find >> the trigger for the panic, please let me know. > Reproduced. I don't know what was the trigger this time. The system runs > lighttpd, fastcgi python and php, mysql and postgresql. > Also, in this core somehow everything looks quite similar (looks like > another page fault but with panic() called prior to getting into fatal > trap 12) to my two earlier dumps: > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008777.html > http://lists.freebsd.org/pipermail/freebsd-current/2009-June/008781.html > so maybe it's not really a problem with tcp_sack.c or netisr.c. > With some poking around and a key insight provided by Robert Watson, I believe we've got this sorted. The SACK code puts a global cap on the amount of memory that can be used for SACK accounting. The variable V_tcp_sack_globalholes tracks how many SACK holes are currently allocated across all active TCP connections. It gets incremented in tcp_sackhole_alloc() and decremented in tcp_sackhole_free() in netinet/tcp_sack.c. It turns out that there is currently no lock synchronising access to the variable, and the incrementing/decrementing is not being done atomically. In Kamigishi's case, his server had a traffic profile consisting of a large number of clients simultaneously connecting over cruddy links which was giving the SACK accounting a real workout. The inevitable race would strike one or more times, leaving the count of holes not in tune with reality, and eventually when traffic died down the variable would decrement down below 0, triggering the panic. Note that this panic only occurs if INVARIANTS is compiled into the kernel so the issue has been around for some time but not noticed. The attached patch makes use of the atomic(9) KPI to ensure incrementing/decrementing the variable is done atomically, which should fix the bug. Reviews/testing would be good so that we can get this into 8.0. Cheers, Lawrence --------------020601070500000604040401 Content-Type: text/plain; name="sack_globalholes.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sack_globalholes.diff" Index: sys/netinet/tcp_sack.c =================================================================== --- sys/netinet/tcp_sack.c (revision 195317) +++ sys/netinet/tcp_sack.c (working copy) @@ -273,7 +273,7 @@ hole->rxmit = start; tp->snd_numholes++; - V_tcp_sack_globalholes++; + atomic_add_int(&V_tcp_sack_globalholes, 1); return hole; } @@ -289,7 +289,7 @@ uma_zfree(V_sack_hole_zone, hole); tp->snd_numholes--; - V_tcp_sack_globalholes--; + atomic_subtract_int(&V_tcp_sack_globalholes, 1); KASSERT(tp->snd_numholes >= 0, ("tp->snd_numholes >= 0")); KASSERT(V_tcp_sack_globalholes >= 0, ("tcp_sack_globalholes >= 0")); --------------020601070500000604040401-- From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 21:30:21 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F4224106566C; Fri, 3 Jul 2009 21:30:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9E54D8FC1A; Fri, 3 Jul 2009 21:30:20 +0000 (UTC) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id n63LRpO9019250; Fri, 3 Jul 2009 17:27:51 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <200907032127.n63LRpO9019250@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Jul 2009 17:30:05 -0400 To: Alexander Motin From: Mike Tancsa In-Reply-To: <4A4E5C82.9070209@FreeBSD.org> References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> <4A4D0B7E.8060503@FreeBSD.org> <200907022117.n62LHrvZ010791@lava.sentex.ca> <200907031326.n63DQCGM016627@lava.sentex.ca> <4A4E0D51.3080904@FreeBSD.org> <200907031413.n63ED2jl016885@lava.sentex.ca> <4A4E1525.2040809@FreeBSD.org> <200907031430.n63EUMH1016965@lava.sentex.ca> <4A4E1A6C.3090605@FreeBSD.org> <200907031858.n63IwDIt018455@lava.sentex.ca> <4A4E5C82.9070209@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch (INTEL DX58SO) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 21:30:21 -0000 At 03:31 PM 7/3/2009, Alexander Motin wrote: >It would be more interesting to investigate benefits on NCQ suitable >workload, as that are new for us. Something like unpacking a lot of >small files to normal or async-mounted or gjournalled FS, or some >multi-threaded read, or something else. Would be nice to understand >on which types of workload NCQ could give us visible effects. > >You can track real requests parallelism by looking on dev_active >field of `camcontrol tags ada0 -v`. We dont have too many disk I/O bound apps here. Where we do, we typically have used raid controllers in RAID10. But I will experiment a little more over the weekend. For us, we are interested in large amounts of storage for backup purposes. Having things like port multiplier features are very nice to have. But I will try some random io tests to see if I can measure a difference. >>The eSata port does not work, but it never did under the old driver >>either. I think it has a separate controller ? At the BIOS boot up >>time, it shows some Marvell controller talking to the eSata >>attached drive, and pciconf does show a separate ATA controller >>atapci0@pci0:6:0:0: class=0x01018f card=0x4f538086 >>chip=0x612111ab rev=0xb2 hdr=0x00 >> vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' >> device = '6121 SATA2 Controller' >> class = mass storage >> subclass = ATA >> cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 >> cap 05[50] = MSI supports 1 message >> cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link x1(x1) > >But this device, implementing both PATA and SATA ports, report >itself as PATA controller. It's SATA part may be AHCI compatible, >but driver unable to attach it due to incorrect device >identification. Alike happens to my JMicron controllers, but in that >case system BIOS is able to switch it into the right mode with >separate PATA and AHCI SATA controllers devices. Looking in the BIOS, I am able to toggle IDE and RAID mode only for the eSata controller portion, where as I have IDE, AHCI and RAID for the onboard Intel controller. ---Mike From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 22:26:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FD4F1065670; Fri, 3 Jul 2009 22:26:06 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 015438FC14; Fri, 3 Jul 2009 22:26:05 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1MMrCj-0004Sn-AT; Fri, 03 Jul 2009 23:26:04 +0100 Received: from mech-cluster238.men.bris.ac.uk ([137.222.187.238]) by isis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1MMrCh-000309-PV; Fri, 03 Jul 2009 23:26:00 +0100 Received: from mech-cluster238.men.bris.ac.uk (localhost.men.bris.ac.uk [127.0.0.1]) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id n63MPxw2032504; Fri, 3 Jul 2009 23:25:59 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster238.men.bris.ac.uk (8.14.3/8.14.3/Submit) id n63MPwkL032501; Fri, 3 Jul 2009 23:25:58 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster238.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Fri, 3 Jul 2009 23:25:58 +0100 From: Anton Shterenlikht To: Alban Hertroys Message-ID: <20090703222558.GA32365@mech-cluster238.men.bris.ac.uk> References: <20090625110253.GA31443@mech-cluster238.men.bris.ac.uk> <10FCC74D-6D46-4112-AD89-BBB4C5933957@mac.com> <20090701105649.GA62596@mech-cluster238.men.bris.ac.uk> <20090702083709.GA66827@mech-cluster238.men.bris.ac.uk> <20090703101242.GA59906@mech-cluster238.men.bris.ac.uk> <1944CCC8-B2D5-4C06-B21C-FAA5A37D6EE1@solfertje.student.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1944CCC8-B2D5-4C06-B21C-FAA5A37D6EE1@solfertje.student.utwente.nl> User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.2 X-Spam-Level: - Cc: Marcel Moolenaar , freebsd-current@freebsd.org, Wojciech Puchar , Anton Shterenlikht , freebsd-questions@freebsd.org, freebsd-ia64@freebsd.org Subject: SUCCESS: Re: gmirror per partition X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 22:26:06 -0000 On Fri, Jul 03, 2009 at 01:18:28PM +0200, Alban Hertroys wrote: > On Jul 3, 2009, at 12:12 PM, Anton Shterenlikht wrote: > > > now to mirror root partition. > > > > My problem is that root is mounted and cannot (?) be unmounted, > > unlike /efi, > > on the live system. > > > > # gpart add -b 819234 -s 1048576 -t freebsd-ufs da1 > > da1p2 added > > # > > > > # gmirror label -vb round-robin root /dev/da0p2 > > gmirror: Can't store metadata on /dev/da0p2: Operation not permitted. > > # > > > > If I create gmirror on da1, the spare disk: > > > > # gmirror label -vb round-robin root /dev/da1p2 > > Metadata value stored on /dev/da0p1. > > Done. > > # > > > > so that > > > > # gmirror status > > Name Status Components > > mirror/efi COMPLETE da0p1 > > da1p1 > > mirror/root COMPLETE da1p2 > > > > # > > > > > > then I still cannot insert da0p2 > > > > > > # gmirror insert root da0p2 > > gmirror: Cannot access provider da0p2. > > # > > > > So how can I gmirror root partion on a live system? > > You're almost there... I did this a while ago, can't remember when, > but I just upgraded the system that had this from FreeBSD 6.3 of > sometime in 2006 to 7.2. > > What I believe I did from this point on was: > > Copy everything from the root partition to mirror/root. > Modify /etc/fstab to mount root on mirror/root. > Reboot. > > Now the original root partition isn't mounted anymore, so we can do > operate on it's geom stuff. > > gmirror insert root da0p2 > > That should be it. > If that doesn't work you can always boot off a live file-system CD/DVD > and perform these actions from there. You won't have man pages in that > case though, or at least I couldn't find a way to read them off the > DVD last I tried. > > One thing I'd like to warn about at this point: > If you ever upgrade to a kernel with a newer geom metadata version and > that new kernel crashes, you're left with a system where the new > kernel can't boot at all while the old kernel can't mount the root > mirror as it's now of a version it can't handle. > You can however mount a single geom provider of that root file system > (/dev/da1p2 for example) to try to fix things. > That file-system WILL be dirty, but DON'T run fsck on it or you will > destroy it's contents. That's what happened to my upgrade above... > > Thankfully it was only my root partition with hardly any data on it > and I did make level 0 dumps before the upgrade, but I needed to > restore that FS from a fixit shell without man pages. Augh! thank you, that was helpful. I think I've got it, but it's a bit more complex on ia64 because /boot is a symlink to /efi/boot, which is a separate partition. Anyway, I've got: # gmirror status Name Status Components mirror/efi COMPLETE da0p1 da1p1 mirror/root COMPLETE da0p2 da1p2 mirror/swap COMPLETE da0p3 da1p3 mirror/var COMPLETE da1p4 da0p4 mirror/tmp COMPLETE da1p5 da0p5 mirror/usr DEGRADED da1p6 da0p6 (24%) # I'll try to write up my experience and post later. thanks again -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 928 8233 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Fri Jul 3 22:31:16 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 206A0106566C for ; Fri, 3 Jul 2009 22:31:16 +0000 (UTC) (envelope-from jos@catnook.com) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.freebsd.org (Postfix) with ESMTP id 0D3028FC0A for ; Fri, 3 Jul 2009 22:31:15 +0000 (UTC) (envelope-from jos@catnook.com) Received: from lizzy.dyndns.org (209-204-188-132.dsl.static.sonic.net [209.204.188.132]) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with SMTP id n63MHlMg031641 for ; Fri, 3 Jul 2009 15:17:47 -0700 Received: (qmail 31184 invoked by uid 1000); 3 Jul 2009 22:18:10 -0000 Date: Fri, 3 Jul 2009 15:18:10 -0700 From: Jos Backus To: current@freebsd.org Message-ID: <20090703221810.GA31128@lizzy.catnook.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: Selection using mouse aborts unexpectedly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jos@catnook.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 22:31:16 -0000 Hi, For a few weeks now, when I drag my mouse over some text with the left button pressed down, the selection will reproducibly abort after a second or so and start re-selecting even though I never let go of the mouse button. This used to work fine and is very annoying, to say the least. Is anybody else seeing this? It happens both on the console and in X. I'm running moused like this: /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid dmesg output: ums0: on usbus6 ums0: 5 buttons and [XYZ] coordinates ID=1 ums0: on usbus6 ums0: 5 buttons and [XYZ] coordinates ID=1 -- Jos Backus jos at catnook.com From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 00:20:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FEDB106564A for ; Sat, 4 Jul 2009 00:20:23 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-out1.uni-muenster.de (ZIVM-OUT1.UNI-MUENSTER.DE [128.176.192.8]) by mx1.freebsd.org (Postfix) with ESMTP id C96478FC18 for ; Sat, 4 Jul 2009 00:20:22 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) X-IronPort-AV: E=Sophos;i="4.42,345,1243807200"; d="scan'208";a="276250764" Received: from zivmaildisp2.uni-muenster.de (HELO ZIVMAILUSER05.UNI-MUENSTER.DE) ([128.176.188.143]) by zivm-relay1.uni-muenster.de with ESMTP; 04 Jul 2009 02:20:21 +0200 Received: by ZIVMAILUSER05.UNI-MUENSTER.DE (Postfix, from userid 149459) id 204C71B07E4; Sat, 4 Jul 2009 02:20:21 +0200 (CEST) Date: Sat, 04 Jul 2009 02:20:20 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: clangbsd svn compilation error X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 00:20:23 -0000 i just grabbed a svn snapshot of clangbsd and did a buildworld inside it, but i'm getting this error: c++ -O2 -fno-strict-aliasing -pipe -I/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../../../contrib/llvm/include -I/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../../../contrib/llvm/tools/clang/include -I/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../../../contrib/llvm/utils/TableGen -I. -I/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\"i386-undermydesk-freebsd8.0\" -I/usr/obj/usr/local/src/clangbsd/tmp/legacy/usr/include -fconserve-space -static -L/usr/obj/usr/local/src/clangbsd/tmp/legacy/usr/lib -o tblgen AsmWriterEmitter.o CallingConvEmitter.o ClangDiagnosticsEmitter.o CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenInstruction.o CodeGenTarget.o DAGISelEmitter.o FastISelEmitter.o InstrEnumEmitter.o InstrInfoEmitter.o IntrinsicEmitter.o LLVMCConfigurationEmitter.o Record.o RegisterInfoEmitter.o SubtargetEmitter.o TGLexer.o TGParser.o TGValueTypes.o TableGen.o TableGenBackend.o /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsupport/libllvmsupport.a /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsystem/libllvmsystem.a -lpthread -legacy /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsystem/libllvmsystem.a(Atomic.o)(.text+0x25): In function `llvm::sys::AtomicIncrement(unsigned int volatile*)': : undefined reference to `__sync_add_and_fetch_4' /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsystem/libllvmsystem.a(Atomic.o)(.text+0x45): In function `llvm::sys::AtomicDecrement(unsigned int volatile*)': : undefined reference to `__sync_sub_and_fetch_4' /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsystem/libllvmsystem.a(Atomic.o)(.text+0x5): In function `llvm::sys::AtomicAdd(unsigned int volatile*, unsigned int)': : undefined reference to `__sync_add_and_fetch_4' /usr/obj/usr/local/src/clangbsd/tmp/usr/local/src/clangbsd/usr.bin/clang/bin/tblgen/../../lib/libllvmsystem/libllvmsystem.a(Atomic.o)(.text+0x61): In function `llvm::sys::CompareAndSwap(unsigned int volatile*, unsigned int, unsigned int)': : undefined reference to `__sync_val_compare_and_swap_4' *** Error code 1 Stop in /usr/local/src/clangbsd/usr.bin/clang/bin/tblgen. *** Error code 1 Stop in /usr/local/src/clangbsd. *** Error code 1 Stop in /usr/local/src/clangbsd. *** Error code 1 Stop in /usr/local/src/clangbsd. i followed the instructions on the wiki. i'm running r195247 (HEAD) and the revision of the clangbsd svn snapshot i was trying to build is 195329. i have llvm-devel-2.6.r71086 installed and running gcc version 4.2.1 20070719 (the one that comes with world). cheers. alex From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 07:07:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4681E1065672 for ; Sat, 4 Jul 2009 07:07:13 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 08B5F8FC0A for ; Sat, 4 Jul 2009 07:07:12 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 223EE63352C; Sat, 4 Jul 2009 09:07:12 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 4B75FB956; Sat, 4 Jul 2009 09:07:10 +0200 (CEST) Date: Sat, 4 Jul 2009 09:07:03 +0200 From: Patrick Lamaiziere To: freebsd-current@freebsd.org Message-ID: <20090704090703.1b26dce1@baby-jane.lamaiziere.net> In-Reply-To: <200907031929.17327.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031756.55253.hselasky@c2i.net> <20090703185233.4f7e4a65@baby-jane.lamaiziere.net> <200907031929.17327.hselasky@c2i.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hans Petter Selasky Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 07:07:13 -0000 Le Fri, 3 Jul 2009 19:29:15 +0200, Hans Petter Selasky a =E9crit : ... > > It looks like there are some problems even with the first job (I > > missed this point before). > > > > ulpt0: using bi-directional > > ulpt_write_callback:220: state=3D0x0 actlen=3D0 > > ulpt_write_callback:220: state=3D0x1 actlen=3D2889 > > ulpt_write_callback:220: state=3D0x1 actlen=3D3023 > > ... > > ulpt_status_callback:352: error=3DUSB_ERR_STALLED > > ulpt_write_callback:220: state=3D0x1 actlen=3D16384 > > ulpt_write_callback:220: state=3D0x1 actlen=3D16384 >=20 > At this point it looks like the firmware crashes, when the error code > changes from STALLED to IOERROR. >=20 > Are you sure the .ps/.pcl file is not corrupt? Yes I print the cups' test page, I've reinstalled all cupds, foomatic and hpijs just to be sure. > > If it can help, I can compare with FreeBSD 7.2. >=20 > Yes, that might give some more clues. On 7.2 (but not on the same hardware): ulptopen: flags=3D0x40 ulpt_open: open input pipe ulpt_open: start read callout=20 ulptopen: done, error=3D0=20 ulpt_tick: start sc=3D0xc6fae000=20 ulpt_tick: err=3D1=20 ulpt_read_cb: start sc=3D0xc6fae000, err=3D0 n=3D0=20 ulpt_tick: start sc=3D0xc6fae000 ulpt_tick: err=3D1=20 ulpt_read_cb: start sc=3D0xc6fae000, err=3D0 n=3D0 ulptwrite=20 ulpt_status: status=3D0x18 err=3D0=20 ulptwrite: transfer 4096 bytes ulptwrite ulpt_status: status=3D0x18 err=3D0=20 ulptwrite: transfer 4096 bytes ulpt_status: status=3D0x18 err=3D0 ulptwrite: transfer 4096 bytes ulptwrite=20 ulpt_status: status=3D0x18 err=3D0 ulptwrite: transfer 4096 bytes ulpt_status: status=3D0x18 err=3D0 ulptwrite: transfer 4096 bytes ulptwrite=20 ulpt_status: status=3D0x18 err=3D0 ulptwrite: transfer 4096 bytes ulpt_tick: start sc=3D0xc6fae000=20 ulpt_tick: err=3D1 ulpt_read_cb: start sc=3D0xc6fae000, err=3D0 n=3D0 ulpt_status: status=3D0x18 err=3D0 ulptwrite: transfer 4096 bytes ... ulptclose: closed I've tried to change ULPT_BSIZE to 4096 (ulpt.c) on Current but there are still some "USB_ERR_IOERROR". No luck. Thanks! From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 07:14:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE6D21065676 for ; Sat, 4 Jul 2009 07:14:47 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 7B2668FC17 for ; Sat, 4 Jul 2009 07:14:47 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id BB23163352C; Sat, 4 Jul 2009 09:14:46 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id EFBB3B956; Sat, 4 Jul 2009 09:14:44 +0200 (CEST) Date: Sat, 4 Jul 2009 09:14:44 +0200 From: Patrick Lamaiziere To: freebsd-current@freebsd.org Message-ID: <20090704091444.0fbdd018@baby-jane.lamaiziere.net> In-Reply-To: <4A4E4D12.9010501@freebsd.org> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907031758.35319.hselasky@c2i.net> <20090703193400.60fef21f@baby-jane.lamaiziere.net> <4A4E4D12.9010501@freebsd.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Sam Leffler , Hans Petter Selasky Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 07:14:48 -0000 Le Fri, 03 Jul 2009 11:25:22 -0700, Sam Leffler a =E9crit : > > I tried : with ulpt0 the printer does not print anything (With > > previous FreeBSD I used unlpt0): the reset disconnects the printer. > > > > ulpt0: > addr 2> on usbus0=20 > > ulpt_attach:562: setting alternate config number: 0 > > ulpt0: using bi-directional mode > > ugen0.2: at usbus0 (disconnected) > > ulpt0: at uhub0, port 1, addr 2 (disconnected) > > ulpt_detach:653: sc=3D0xc3176480 > > ugen0.2: at usbus0 > > ulpt0: > addr 2> on usbus0 ulpt_attach:562: setting alternate config number: > > 0 ulpt0: using bi-directional mode > > =20 >=20 > This looks a bit like an issue I'm about to start chasing where FS=20 > devices fed through a HS hub disconnect "spontaneously" under load. > It doesn't look like it but to be sure there are no hubs between the > host and the printer? No hub at all. May be it's related to the usb chipset but I do not have any problem with umass. From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 07:46:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81EF61065670 for ; Sat, 4 Jul 2009 07:46:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id D180B8FC08 for ; Sat, 4 Jul 2009 07:46:06 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=BQeo18V-fugA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=33Q1iqRhdDkRyLzi_yoA:9 a=HloqvuDLeC_4pYrExIxWpZwax_YA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1171816954; Sat, 04 Jul 2009 09:46:05 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 4 Jul 2009 09:45:40 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <20090703172600.1971111e@baby-jane.lamaiziere.net> In-Reply-To: <20090703172600.1971111e@baby-jane.lamaiziere.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907040945.41153.hselasky@c2i.net> Cc: Patrick Lamaiziere Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 07:46:07 -0000 On Friday 03 July 2009 17:26:00 Patrick Lamaiziere wrote: > ulpt_write_callback:220: state=0x1 actlen=2889 > ulpt_write_callback:220: state=0x1 actlen=3023 These two lines are interesting. Are these printed when doing the same job? If the actlen is not a factor of 64 in your case, the printer will think that the document has ended. Could you verify that, that cups is feeding too little data into the ULPT port? --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 08:13:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0118F1065670 for ; Sat, 4 Jul 2009 08:13:26 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 7FFB18FC0A for ; Sat, 4 Jul 2009 08:13:25 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n648DNrN066573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Jul 2009 10:13:23 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A4F0F23.3050208@omnilan.de> Date: Sat, 04 Jul 2009 10:13:23 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigADDA6AC2481331458AB66F1B" Subject: Odd disk spin-ups (seperate non-OS-disk) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 08:13:26 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigADDA6AC2481331458AB66F1B Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hello, I have -current installed on a SSD (incl. /var) and have another,=20 usually not used, hard disk which gets spun down after some minutes idle = time. Frequently my complete system stops (no mouse moving) until the not used = hard disk spins up. How can I find out what process causes the disk access and more=20 important, why does it block my complete system? Best regards, -Harry --------------enigADDA6AC2481331458AB66F1B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkpPDyMACgkQLDqVQ9VXb8jLMgCgrxsbRWiIohQzdfSQhd5mLyO2 qUwAn0Z8r6639MKk1jpLEAwW6IR7dr2O =s4VN -----END PGP SIGNATURE----- --------------enigADDA6AC2481331458AB66F1B-- From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 09:22:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CE5A106564A for ; Sat, 4 Jul 2009 09:22:20 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id CEB2D8FC08 for ; Sat, 4 Jul 2009 09:22:19 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MN0wB-0003CX-Ia; Sat, 04 Jul 2009 10:49:35 +0200 Message-ID: <4A4F179A.6060606@gwdg.de> Date: Sat, 04 Jul 2009 10:49:30 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Hans Petter Selasky References: <49AAA35F.3080805@gwdg.de> <200903012105.55371.hselasky@c2i.net> <49AAFC99.9030205@gwdg.de> <200903012231.32565.hselasky@c2i.net> <49AB6E18.2000207@gwdg.de> <49C4B426.3070603@gwdg.de> In-Reply-To: <49C4B426.3070603@gwdg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: Logitech QuickCam 9000 Pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 09:22:20 -0000 Hello Hans Petter, with the last changes on usb stack (a few days ago) my webcam is not regocnized any more. We got it working in march, if you remember ... Please tell me if I can help. Thanks in advance, Rainer Hurling On 21.03.2009 10:32 (UTC+2), Rainer Hurling wrote: > Since yesterday (03/20/2009) I find this webcam recognized from new > usbstack. Now we can start testing software working with it :-) > > Thank you, > Rainer > > > On 02.03.2009 06:26 (UTC+1), Rainer Hurling wrote: >> On 01.03.2009 22:31 (UTC+1), Hans Petter Selasky wrote: >>> On Sunday 01 March 2009, Rainer Hurling wrote: >>>> On 01.03.2009 21:05 (UTC+1), Hans Petter Selasky wrote: >>>>> On Sunday 01 March 2009, Rainer Hurling wrote: >>>>>> Rainer Hurling >>>>> Should end up in -current sometime next week. >>>>> >>>>> http://perforce.freebsd.org/chv.cgi?CH=158561 >>>>> >>>>> --HPS >>>> I just recognized that the naming for this device is correctly >>>> spelled as >>>> >>>> 'QuickCam Pro 9000' (the number at last). >>>> >>>> I am afraid this could be relevant for some linux drivers and >>>> applications. Hope you can change it for the last time :-) >>>> >>>> And there is a salience in sys/dev/usb/usbdevs: at line 1648 another >>>> device is named QUICKCAMPRO2. Could this provoke unpredictable >>>> behaviour >>>> of the driver? >>> >>> Ok, try this: >>> >>> http://perforce.freebsd.org/chv.cgi?CH=158563 >>> >>> --HPS >> >> This should work. >> >> Thanks, >> Rainer From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 09:43:43 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 651A81065673 for ; Sat, 4 Jul 2009 09:43:43 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id E94C88FC20 for ; Sat, 4 Jul 2009 09:43:42 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6Ab6_U9z3p6SxPI7XzEA:9 a=1Uwr3XV8n7w6F6YJODkIC0rqHAEA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1272908968; Sat, 04 Jul 2009 11:43:41 +0200 From: Hans Petter Selasky To: Rainer Hurling Date: Sat, 4 Jul 2009 11:43:14 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <49AAA35F.3080805@gwdg.de> <49C4B426.3070603@gwdg.de> <4A4F179A.6060606@gwdg.de> In-Reply-To: <4A4F179A.6060606@gwdg.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907041143.15598.hselasky@c2i.net> Cc: freebsd-current@freebsd.org Subject: Re: Logitech QuickCam 9000 Pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 09:43:43 -0000 On Saturday 04 July 2009 10:49:30 Rainer Hurling wrote: > Hello Hans Petter, > > with the last changes on usb stack (a few days ago) my webcam is not > regocnized any more. We got it working in march, if you remember ... > > Please tell me if I can help. What is the location of the driver? You need to refresh my memory. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 10:40:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 97B121065675 for ; Sat, 4 Jul 2009 10:40:59 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 577028FC1B for ; Sat, 4 Jul 2009 10:40:58 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MN2fw-0007Uz-VI; Sat, 04 Jul 2009 12:40:57 +0200 Message-ID: <4A4F31B7.2090501@gwdg.de> Date: Sat, 04 Jul 2009 12:40:55 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Hans Petter Selasky References: <49AAA35F.3080805@gwdg.de> <49C4B426.3070603@gwdg.de> <4A4F179A.6060606@gwdg.de> <200907041143.15598.hselasky@c2i.net> In-Reply-To: <200907041143.15598.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: Logitech QuickCam 9000 Pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 10:41:00 -0000 Hello Hans Petter, thank you for answering. I am working with newest 8.0-CURRENT. Your latest changes in our post were at: http://p4db.freebsd.org/chv.cgi?CH=158563 After that patches, I got the following output # usbconfig ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON The entry in /sys/dev/usb/usbdevs (line 1649) seems ok: product LOGITECH QUICKCAMPRO3 0x0990 QuickCam Pro 9000 Tell me, if you need more information or testing. Rainer On 04.07.2009 11:43 (UTC+2), Hans Petter Selasky wrote: > On Saturday 04 July 2009 10:49:30 Rainer Hurling wrote: >> Hello Hans Petter, >> >> with the last changes on usb stack (a few days ago) my webcam is not >> regocnized any more. We got it working in march, if you remember ... >> >> Please tell me if I can help. > > What is the location of the driver? > > You need to refresh my memory. > > --HPS > From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 10:43:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D12D71065670 for ; Sat, 4 Jul 2009 10:43:26 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 622AD8FC08 for ; Sat, 4 Jul 2009 10:43:25 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=osgFCMFzPAKAtQ_kGYkA:9 a=vEGcVam0-pg2K3TJavif4YX1krkA:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1268694789; Sat, 04 Jul 2009 12:43:24 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 4 Jul 2009 12:42:59 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <49AAA35F.3080805@gwdg.de> <200907041143.15598.hselasky@c2i.net> <4A4F31B7.2090501@gwdg.de> In-Reply-To: <4A4F31B7.2090501@gwdg.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907041243.00578.hselasky@c2i.net> Cc: Subject: Re: Logitech QuickCam 9000 Pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 10:43:27 -0000 On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: > Hello Hans Petter, > > thank you for answering. I am working with newest 8.0-CURRENT. > > Your latest changes in our post were at: > > http://p4db.freebsd.org/chv.cgi?CH=158563 > > > After that patches, I got the following output > > # usbconfig > ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH > (480Mbps) pwr=ON Are you compiling the driver from ports? Did you recompile the port? --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 10:52:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65B27106564A for ; Sat, 4 Jul 2009 10:52:42 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 257DB8FC12 for ; Sat, 4 Jul 2009 10:52:42 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MN2rI-0000Ec-9t; Sat, 04 Jul 2009 12:52:40 +0200 Message-ID: <4A4F3477.5070201@gwdg.de> Date: Sat, 04 Jul 2009 12:52:39 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Hans Petter Selasky References: <49AAA35F.3080805@gwdg.de> <200907041143.15598.hselasky@c2i.net> <4A4F31B7.2090501@gwdg.de> <200907041243.00578.hselasky@c2i.net> In-Reply-To: <200907041243.00578.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: Logitech QuickCam 9000 Pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 10:52:42 -0000 On 04.07.2009 12:42 (UTC+2), Hans Petter Selasky wrote: > On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: >> Hello Hans Petter, >> >> thank you for answering. I am working with newest 8.0-CURRENT. >> >> Your latest changes in our post were at: >> >> http://p4db.freebsd.org/chv.cgi?CH=158563 >> >> >> After that patches, I got the following output >> >> # usbconfig >> ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH >> (480Mbps) pwr=ON > > Are you compiling the driver from ports? Did you recompile the port? No, that is without any driver from ports (which driver do you mean?). My report relates to the (new) usb stack from system, I think. Actually I get the following message when using usbconfig: # usbconfig ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON Rainer From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 11:21:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D344D106564A; Sat, 4 Jul 2009 11:21:13 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id ADB528FC0C; Sat, 4 Jul 2009 11:21:12 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 247638437; Sat, 04 Jul 2009 14:21:09 +0300 Message-ID: <4A4F3B18.5010905@FreeBSD.org> Date: Sat, 04 Jul 2009 14:20:56 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Mike Tancsa References: <4A4517BE.9040504@FreeBSD.org> <200906272303.n5RN3rTi070177@lava.sentex.ca> <4A471F44.7010108@FreeBSD.org> <200907021859.n62IxghN009931@lava.sentex.ca> In-Reply-To: <200907021859.n62IxghN009931@lava.sentex.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , scottl@FreeBSD.org Subject: Re: RFC: ATA to CAM integration patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 11:21:14 -0000 Mike Tancsa wrote: > On the ich10 board, its trying to boot up now, but I am getting > > uhub8: 4 ports with 4 removable, self powered > (probe2:ahcich2:0:0:0): SIGNATURE: eb14 > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > ahcich2: Timeout on slot 4 > run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config > ahcich2: Timeout on slot 5 > run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config > ahcich2: Timeout on slot 6 > run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config > ahcich2: Timeout on slot 7 > run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config > ahcich2: Timeout on slot 8 > ada0 at ahcich1 bus 0 target 0 lun 0 > ada0: ATA/ATAPI-8 SATA 2.x device > ada0: 300.000MB/s transfers > ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) > ada0: Native Command Queueing Enabled I've found how to make this DVD work. It refused to process PACKET command until I have explicitly set it's PATA-legacy transfer mode to the maximal supported. %camcontrol devlist at scbus0 target 0 lun 0 (pass0,ada0) at scbus2 target 0 lun 0 (cd0,pass1) Patch committed to P4. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 11:49:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C56B910656F2 for ; Sat, 4 Jul 2009 11:49:26 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 4E69A8FC14 for ; Sat, 4 Jul 2009 11:49:25 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=j8g923rwbOVEo6--znkA:9 a=30J7VNtpoCWZQlofpQjnggBrey8A:4 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1271630738; Sat, 04 Jul 2009 13:49:24 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 4 Jul 2009 13:48:59 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <49AAA35F.3080805@gwdg.de> <200907041243.00578.hselasky@c2i.net> <4A4F3477.5070201@gwdg.de> In-Reply-To: <4A4F3477.5070201@gwdg.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907041349.00734.hselasky@c2i.net> Cc: Subject: Re: Logitech QuickCam 9000 Pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 11:49:30 -0000 On Saturday 04 July 2009 12:52:39 Rainer Hurling wrote: > On 04.07.2009 12:42 (UTC+2), Hans Petter Selasky wrote: > > On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: > >> Hello Hans Petter, > >> > >> thank you for answering. I am working with newest 8.0-CURRENT. > >> > >> Your latest changes in our post were at: > >> > >> http://p4db.freebsd.org/chv.cgi?CH=158563 > >> > >> > >> After that patches, I got the following output > >> > >> # usbconfig > >> ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH > >> (480Mbps) pwr=ON > > > > Are you compiling the driver from ports? Did you recompile the port? > > No, that is without any driver from ports (which driver do you mean?). > My report relates to the (new) usb stack from system, I think. > > Actually I get the following message when using usbconfig: > > # usbconfig > ugen1.2: at usbus1, cfg=0 md=HOST > spd=HIGH (480Mbps) pwr=ON > Ok, now I get it. You need to add the "USB_VERBOSE" option to the kernel config. Verbose output is not compiled by default any more. --HPS From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 12:56:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 42C841065672 for ; Sat, 4 Jul 2009 12:56:20 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id 02D6C8FC0C for ; Sat, 4 Jul 2009 12:56:19 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=lt011.nfv) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MN4mv-00046o-MQ; Sat, 04 Jul 2009 14:56:18 +0200 Message-ID: <4A4F5167.8080601@gwdg.de> Date: Sat, 04 Jul 2009 14:56:07 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Hans Petter Selasky References: <49AAA35F.3080805@gwdg.de> <200907041243.00578.hselasky@c2i.net> <4A4F3477.5070201@gwdg.de> <200907041349.00734.hselasky@c2i.net> In-Reply-To: <200907041349.00734.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: Logitech QuickCam 9000 Pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 12:56:20 -0000 On 04.07.2009 13:48 (UTC+2), Hans Petter Selasky wrote: > On Saturday 04 July 2009 12:52:39 Rainer Hurling wrote: >> On 04.07.2009 12:42 (UTC+2), Hans Petter Selasky wrote: >>> On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: >>>> Hello Hans Petter, >>>> >>>> thank you for answering. I am working with newest 8.0-CURRENT. >>>> >>>> Your latest changes in our post were at: >>>> >>>> http://p4db.freebsd.org/chv.cgi?CH=158563 >>>> >>>> >>>> After that patches, I got the following output >>>> >>>> # usbconfig >>>> ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH >>>> (480Mbps) pwr=ON >>> Are you compiling the driver from ports? Did you recompile the port? >> No, that is without any driver from ports (which driver do you mean?). >> My report relates to the (new) usb stack from system, I think. >> >> Actually I get the following message when using usbconfig: >> >> # usbconfig >> ugen1.2: at usbus1, cfg=0 md=HOST >> spd=HIGH (480Mbps) pwr=ON >> > > Ok, now I get it. > > You need to add the "USB_VERBOSE" option to the kernel config. Verbose output > is not compiled by default any more. I added 'options USB_VERBOSE' to my kernel config file. The kernel build stops with 'unknown option "USB_VERBOSE". Any hint? Rainer From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 14:30:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C07E9106566C for ; Sat, 4 Jul 2009 14:30:57 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id 2DB758FC0C for ; Sat, 4 Jul 2009 14:30:56 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from apollo (78-32-77-91.static-adsl.entanet.co.uk [78.32.77.91] (may be forged)) by hydra.fletchermoorland.co.uk (8.14.3/8.14.2) with ESMTP id n64EUs1E029080; Sat, 4 Jul 2009 15:30:54 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-Id: <200907041430.n64EUs1E029080@hydra.fletchermoorland.co.uk> From: "Paul Wootton" To: "'Pegasus Mc Cleaft'" Date: Sat, 4 Jul 2009 15:30:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <200907022136.04164.ken@mthelicon.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acn7VRPQ4X6IepTRTjeQRF1pvhhk8QBXm/nA Content-Disposition: inline X-Scanned-By: MIMEDefang 2.64 on 192.168.0.1 Cc: freebsd-current@freebsd.org Subject: RE: Has anyone been able to actually boot the AMD64 kernel afterr194958? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 14:30:58 -0000 Hi Peg, Yes I do have an r600 series graphics card. Trying John Baldwin's from patch the "panic on acpi_cpu_c1()" thread at http://www.FreeBSD.org/~jhb/patches/msi_assign.patch fixed the boot issues from me Paul -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Pegasus Mc Cleaft Sent: 02 July 2009 21:36 To: freebsd-current@freebsd.org Cc: Thomas Backman; current@freebsd.org; Paul Wootton Subject: Re: Has anyone been able to actually boot the AMD64 kernel afterr194958? On Thursday 02 July 2009 15:50:31 Paul Wootton wrote: > > With you saying this, I decided to try GENERIC kernel configuration and > that builds and runs just fine. I suspect that Peg and myself have > something in our kernel conf files that is causing an issue. I'll have a > go later on and see if I can narrow it down a little bit more > > Paul > Hi Paul, I think I may have tracked down the trigger, although I dont know how to pin- point the cause. It looks like compiling in the radeondrm driver into the kernel is the culprit. if I omit that line from my kernel config, the latest kernels will compile and boot properly on my machine. I'm using a R7xx (but it load the R6xx code) radeon HD card. From talking to you, I know you are using a proper R6xx card. Strangely I can kldload the driver after the machine has booted and all is well, it just seems to hate being compiled into the kernel. Can you see if this is the same on your machine? Peg _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" ---------------------------------------------------------------------------- ------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk ----------------------------------------------------------------------------------- Fletcher Moorland Limited is a company registered in England and Wales. Registration number: 2984467. Registered office: Elenora Street, Stoke on Trent, Staffordshire, ST4 1QG. VAT Registration number: 478730606 Telephone: 01782 411021 | Fax: 01782 744470 | http://www.fletchermoorland.co.uk From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 14:43:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9B671065673 for ; Sat, 4 Jul 2009 14:43:45 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from smtp.lamaiziere.net (net.lamaiziere.net [91.121.44.19]) by mx1.freebsd.org (Postfix) with ESMTP id 8871F8FC15 for ; Sat, 4 Jul 2009 14:43:45 +0000 (UTC) (envelope-from patfbsd@davenulle.org) Received: from baby-jane.lamaiziere.net (105.10.87-79.rev.gaoland.net [79.87.10.105]) by smtp.lamaiziere.net (Postfix) with ESMTPA id 8B26163352C; Sat, 4 Jul 2009 16:43:44 +0200 (CEST) Received: from baby-jane.lamaiziere.net (localhost [127.0.0.1]) by baby-jane.lamaiziere.net (Postfix) with ESMTP id 5059CB927; Sat, 4 Jul 2009 16:43:42 +0200 (CEST) Date: Sat, 4 Jul 2009 16:43:41 +0200 From: Patrick Lamaiziere To: freebsd-current@freebsd.org Message-ID: <20090704164341.0acd0271@baby-jane.lamaiziere.net> In-Reply-To: <200907040945.41153.hselasky@c2i.net> References: <20090703172600.1971111e@baby-jane.lamaiziere.net> <200907040945.41153.hselasky@c2i.net> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.16.2; i386-portbld-freebsd7.2) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hans Petter Selasky Subject: Re: ulpt problem (USB_ERR_IOERROR) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 14:43:46 -0000 Le Sat, 4 Jul 2009 09:45:40 +0200, Hans Petter Selasky a =E9crit : > > ulpt_write_callback:220: state=3D0x1 actlen=3D2889 > > ulpt_write_callback:220: state=3D0x1 actlen=3D3023 >=20 > These two lines are interesting. Are these printed when doing the > same job? Yes. =20 > If the actlen is not a factor of 64 in your case, the printer will > think that the document has ended. Could you verify that, that cups > is feeding too little data into the ULPT port? Sometime cups writes only a litle amount of datas: [Job 40] Read 161 bytes of print data... [Job 40] Wrote 161 bytes of print data... [Job 40] Read 251 bytes of print data... [Job 40] Wrote 251 bytes of print data... [Job 40] Read 162 bytes of print data... [Job 40] Wrote 162 bytes of print data... [Job 40] Read 86 bytes of print data... [Job 40] Wrote 86 bytes of print data... [Job 40] Read 3292 bytes of print data... [Job 40] Wrote 3292 bytes of print data... [Job 40] Read 43 bytes of print data... [Job 40] Wrote 43 bytes of print data... [Job 40] Read 4096 bytes of print data... [Job 40] Wrote 4096 bytes of print data... Cups uses a select() on the input file to print, reads the datas and writes them to the usb port until the input file is empty.=20 There is no warranty that the amount of datas will be a factor of 64 bytes. From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 18:25:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFE8A106566C for ; Sat, 4 Jul 2009 18:25:07 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.swip.net [212.247.154.193]) by mx1.freebsd.org (Postfix) with ESMTP id 5EA4A8FC0C for ; Sat, 4 Jul 2009 18:25:06 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=cJZgS34t9bxdvM5chpUA:9 a=67_mxkp8M7pnJa-GjBEA:7 a=ByFhreoei3DMBWzewX6M7wt5e1kA:4 a=SV7veod9ZcQA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe07.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 1268825607; Sat, 04 Jul 2009 20:25:05 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Sat, 4 Jul 2009 20:24:37 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-CURRENT; KDE/4.2.4; i386; ; ) References: <49AAA35F.3080805@gwdg.de> <200907041349.00734.hselasky@c2i.net> <4A4F5167.8080601@gwdg.de> In-Reply-To: <4A4F5167.8080601@gwdg.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907042024.39770.hselasky@c2i.net> Cc: Subject: Re: Logitech QuickCam 9000 Pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 18:25:08 -0000 On Saturday 04 July 2009 14:56:07 Rainer Hurling wrote: > On 04.07.2009 13:48 (UTC+2), Hans Petter Selasky wrote: > > On Saturday 04 July 2009 12:52:39 Rainer Hurling wrote: > >> On 04.07.2009 12:42 (UTC+2), Hans Petter Selasky wrote: > >>> On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: > >>>> Hello Hans Petter, > >>>> > >>>> thank you for answering. I am working with newest 8.0-CURRENT. > >>>> > >>>> Your latest changes in our post were at: > >>>> > >>>> http://p4db.freebsd.org/chv.cgi?CH=158563 > >>>> > >>>> > >>>> After that patches, I got the following output > >>>> > >>>> # usbconfig > >>>> ugen1.2: at usbus1, cfg=0 md=HOST > >>>> spd=HIGH (480Mbps) pwr=ON > >>> > >>> Are you compiling the driver from ports? Did you recompile the port? > >> > >> No, that is without any driver from ports (which driver do you mean?). > >> My report relates to the (new) usb stack from system, I think. > >> > >> Actually I get the following message when using usbconfig: > >> > >> # usbconfig > >> ugen1.2: at usbus1, cfg=0 md=HOST > >> spd=HIGH (480Mbps) pwr=ON > > > > Ok, now I get it. > > > > You need to add the "USB_VERBOSE" option to the kernel config. Verbose > > output is not compiled by default any more. > > I added 'options USB_VERBOSE' to my kernel config file. The kernel build > stops with 'unknown option "USB_VERBOSE". Any hint? > You need to edit: src/sys/conf/options And change: USBVERBOSE opt_usb.h Into: USB_VERBOSE opt_usb.h --HPS > Rainer > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 18:45:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4053106564A for ; Sat, 4 Jul 2009 18:45:03 +0000 (UTC) (envelope-from rivanr@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 61A798FC13 for ; Sat, 4 Jul 2009 18:45:03 +0000 (UTC) (envelope-from rivanr@gmail.com) Received: by fxm18 with SMTP id 18so2463091fxm.43 for ; Sat, 04 Jul 2009 11:45:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=qfYQcFS1XSqRjyZRMRl4xdJMucVr+tAnNgUdvTIJeNo=; b=FgHHR2c998Y/yncOElRM2xyLJVj6CA88jhsOe3fjX9ynwr99UMXDQ+NXF9biZGGWcR wMKWVNJrof1CkTXtYwqVNgIoAdF1LIsHX2Wr/U8+uNZC/MZc6rA9kG/mTJM/RUTAucCM x4+yuFd9/Oe5BWOyzhj3YDRjzS7vMDJ2OoBEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=IpeNbxoIErVTtJXN45CRWZY+SGCmFo3wdTOGrLhuEZ71iKjBjNLu1rN1pQHAiiQ+6T Hqw6P6wTuwrRkzML5asKZkoFFkM0WrEJtkgwSuPXraqdYEh8YyDUJCLmc7wWD6A3eXaR BtzcH4CZ8mig1cz3SpFco6UFHlO2pt2v7vB+k= Received: by 10.103.24.17 with SMTP id b17mr1535579muj.89.1246731460764; Sat, 04 Jul 2009 11:17:40 -0700 (PDT) Received: from ?95.180.33.218? ([95.180.33.218]) by mx.google.com with ESMTPS id s10sm24228940muh.57.2009.07.04.11.17.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 04 Jul 2009 11:17:40 -0700 (PDT) Message-ID: <4A4F9CC0.70603@gmail.com> Date: Sat, 04 Jul 2009 20:17:36 +0200 From: Ivan Radovanovic User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Weird installation issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 18:45:04 -0000 Hello, I recently wanted to update FreeBSD on my computer to latest version, but now I am facing weird problem. After completing installation from dvd I can't boot into BSD. I naturally assumed this is some boot manager/boot sector issue, and since I am using Vista also (but on the other hard disk) I first overwrited its boot manager with FreeBSD's but without any luck (when I press F2 to start BSD machine either stops to respond or prints # for any keypress, no any messages from BSD bootloader). After that I tried to make BSD entry in grub from open solaris but with the same symptoms (freezing without any message on the screen). I also tried installing GAG boot manager but with the same results. When I open BSD's partition using some hex editor boot sector seems written correctly. Also if I boot fixit prompt from dvd I can mount partition from hard disk (I tried only mounting a partition where is /) everything looks written correctly. However if I escape to loader prompt at dvd during boot and set currdev to "disk1s1a:" when I issue ls everything freezes. I believe this is some booting issue on my machine, but I am loosing ideas what can I try next. Please advise what I should try (FreeBSD is my first choice for UNIX and now I am stuck with open solaris) Ivan From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 19:14:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 214DD106566C for ; Sat, 4 Jul 2009 19:14:10 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from amailer.gwdg.de (amailer.gwdg.de [134.76.10.18]) by mx1.freebsd.org (Postfix) with ESMTP id A93C68FC14 for ; Sat, 4 Jul 2009 19:14:09 +0000 (UTC) (envelope-from rhurlin@gwdg.de) Received: from p578b68b8.dip0.t-ipconnect.de ([87.139.104.184] helo=krabat.raven.hur) by mailer.gwdg.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MNAgZ-000286-24; Sat, 04 Jul 2009 21:14:07 +0200 Message-ID: <4A4FA9F6.7070304@gwdg.de> Date: Sat, 04 Jul 2009 21:13:58 +0200 From: Rainer Hurling User-Agent: Thunderbird 2.0.0.22 (X11/20090630) MIME-Version: 1.0 To: Hans Petter Selasky References: <49AAA35F.3080805@gwdg.de> <200907041349.00734.hselasky@c2i.net> <4A4F5167.8080601@gwdg.de> <200907042024.39770.hselasky@c2i.net> In-Reply-To: <200907042024.39770.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated: Id:rhurlin X-Spam-Level: - X-Virus-Scanned: (clean) by exiscan+sophie Cc: freebsd-current@freebsd.org Subject: Re: Logitech QuickCam 9000 Pro X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 19:14:10 -0000 On 04.07.2009 20:24 (UTC+2), Hans Petter Selasky wrote: > On Saturday 04 July 2009 14:56:07 Rainer Hurling wrote: >> On 04.07.2009 13:48 (UTC+2), Hans Petter Selasky wrote: >>> On Saturday 04 July 2009 12:52:39 Rainer Hurling wrote: >>>> On 04.07.2009 12:42 (UTC+2), Hans Petter Selasky wrote: >>>>> On Saturday 04 July 2009 12:40:55 Rainer Hurling wrote: >>>>>> Hello Hans Petter, >>>>>> >>>>>> thank you for answering. I am working with newest 8.0-CURRENT. >>>>>> >>>>>> Your latest changes in our post were at: >>>>>> >>>>>> http://p4db.freebsd.org/chv.cgi?CH=158563 >>>>>> >>>>>> >>>>>> After that patches, I got the following output >>>>>> >>>>>> # usbconfig >>>>>> ugen1.2: at usbus1, cfg=0 md=HOST >>>>>> spd=HIGH (480Mbps) pwr=ON >>>>> Are you compiling the driver from ports? Did you recompile the port? >>>> No, that is without any driver from ports (which driver do you mean?). >>>> My report relates to the (new) usb stack from system, I think. >>>> >>>> Actually I get the following message when using usbconfig: >>>> >>>> # usbconfig >>>> ugen1.2: at usbus1, cfg=0 md=HOST >>>> spd=HIGH (480Mbps) pwr=ON >>> Ok, now I get it. >>> >>> You need to add the "USB_VERBOSE" option to the kernel config. Verbose >>> output is not compiled by default any more. >> I added 'options USB_VERBOSE' to my kernel config file. The kernel build >> stops with 'unknown option "USB_VERBOSE". Any hint? >> > > You need to edit: > > src/sys/conf/options > > And change: > > USBVERBOSE opt_usb.h > > Into: > > USB_VERBOSE opt_usb.h Ok, now I get the full message back: # usbconfig ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON But what was the intention to print this message less verbose? And one other question: Do you know a working driver in the ports system for the Quickcam Pro 9000? Thanks for all, Rainer From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 21:00:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E39F106564A; Sat, 4 Jul 2009 21:00:07 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: from mail-vw0-f199.google.com (mail-vw0-f199.google.com [209.85.212.199]) by mx1.freebsd.org (Postfix) with ESMTP id CA7EA8FC08; Sat, 4 Jul 2009 21:00:06 +0000 (UTC) (envelope-from gelraen.ua@gmail.com) Received: by vwj37 with SMTP id 37so267369vwj.3 for ; Sat, 04 Jul 2009 14:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=xU7/VmiD7xXR7PpOR1KodphboD3AvnoYJW6PizIP4Bw=; b=VQR65CF527H16woECFbtw/sf78Xo98bKPDXP438oEsG0MD7oFBUhPqycsWo3SlFXQ1 3Lte6oNjb6ITG6H0sanaTaHYtHFlBr4lYHLupqNI+yUId7tS+5OVXuCTrpHvlns4E+X/ fi2Tj1Mob3mFF1oKzITNvJZ2XCaAXv27kl+fI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=PoKA1jHYoT5EZuFxEi7zfldZdrsBoupHgIPqD5wxgYW/N/ufExVD+CVTWd1TQ3/2E4 kMtS6h6JFqSSD6WdvbF+9ZZaNSFxknbrlOrwHAXtv1+/dmzeVZu1ICpRcazRzYKkAyCO 1N3gScSlf9YX/DaXooMDEiDSRkAh5Joz3x9dQ= MIME-Version: 1.0 Received: by 10.220.90.199 with SMTP id j7mr6082383vcm.24.1246741206121; Sat, 04 Jul 2009 14:00:06 -0700 (PDT) In-Reply-To: <4A4D3665.3060502@FreeBSD.org> References: <20090628034654.bdb728c4.nork@FreeBSD.org> <4A47A681.3040100@iae.nl> <86bpo8b3y8.fsf@gmail.com> <1246220306.1759.43.camel@balrog.2hip.net> <4A4D3665.3060502@FreeBSD.org> From: Maxim Ignatenko Date: Sat, 4 Jul 2009 23:59:46 +0300 Message-ID: To: John Baldwin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Anonymous , Hans Ottevanger , Norikatsu Shigemura , Robert Noland , freebsd-current@freebsd.org Subject: Re: panic on acpi_cpu_c1() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 21:00:07 -0000 2009/7/3 John Baldwin : > Maxim Ignatenko wrote: >>> >>> Fatal trap 30: reserved (unknown) fault while in kernel mode >>> cpuid =3D 3; apic id =3D 03 >>> instruction pointer =C2=A0 =C2=A0 =3D 0x20:0xffffffff804bce56 >>> stack pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x20:0xffffff80000= 39b60 >>> frame pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x20:0xffffff80000= 39b70 >>> code segment =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D base 0x0, lim= it 0xfffff, type 0x1b >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =3D DPL 0, pres 1, long 1, def32 0, gran 1 >>> processor eflags =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D interrupt enabled, IOPL= =3D 0 >>> current process =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 11 (idle: cpu3) >>> [thread pid 11 tid 100003 ] >>> Stopped at =C2=A0 =C2=A0 =C2=A0acpi_cpu_c1+0x6: =C2=A0 =C2=A0 =C2=A0 = =C2=A0leave >>> db> bt >>> Tracing pid 11 tid 100003 td 0xffffff8001863720 >>> acpi_cpu_c1() at acpi_cpu_c1+0x6 >>> acpi_cpu_idle() at acpi_cpu_idle+0x20c >>> sched_idletd() at sched_idletd+0x123 >>> fork_exit() at fork_exit+0x117 >>> fork_trampoline() at fork_trampoline+0xe >> >> As for me, r194984 runs normally, but when I tried to boot with >> r194985 at second try it paniced with backtrace very similar to shown >> in first message, and at first try even earlier: in sched_ideltd and >> again on instruction that uses %ebp when ebp =3D 0. >> First time I stepped on this panic after updating to r195130: >> >> Trying to mount root from ufs:/dev/ufs/root >> >> >> Fatal trap 30; reserved (unknown) fault while in kernel mode >> cpuid =3D 1; apic id =3D 01 >> instruction ponter =C2=A0 =C2=A0 =C2=A0=3D 0x20:0xc09252c5 >> stack pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x28:0xc4ecec94 >> frame pointer =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 0x28:0xc4ecec94 >> code segment =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D base 0x0, limi= t 0xfffff, type 0x1b >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0=3D DPL 0, pres 1, def32 1, gran 1 >> processor eflags =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D interrupt enabled, IOPL = =3D 0 >> current process =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D 11 (idle: cpu1) >> [thread pid 11 tid 100003] >> Stopped at =C2=A0 =C2=A0 =C2=A00xc09252c5 =3D acpi_cpu_c1+0x5: =C2=A0 = =C2=A0popl =C2=A0 =C2=A0 %ebp >> db> bt >> Tracing pid 11 tid 100003 td 0xc5176af0 >> acpi_cpu_c1(1,c4ececa8,1,0,c4ececc0,...) at 0xc09252c5 =3D acpi_cpu_c1+0= x5 >> acpi_cpu_idle(c4ececd4,c093c0ab,0,c4ececf4,c066fdec,...) at 0xc04acf37 >> =3D acpi_cpu_idle+0x107 >> cpu_idle_acpi(0,c4ececf4,c066fdec,0,0,...) at 0xc093d5bb =3D >> cpu_idle_acpi+0x1b >> cpu_idle(0,0,c5176af0,c4ececf4,202,...) at 0xc093c0ab =3D cpu_idle+0x1b >> sched_idletd(0,c4ececd38,a4108400,2c0a0e,7022d00,...) at 0xc066fdec =3D >> sched_idletd+0x1c >> fork_exit(c066fdd0,0,c4eced38) at 0xc0623aa1 =3D fork_exit+0x91 >> fork_trampoline() at 0xc0930c80 =3D fork_tramoline+0x8 >> --- trap 0, eip =3D 0, esp =3D 0xc4ececd70, ebp =3D 0 --- >> >> >> P.S.: i386, dual-core, drm and radeon compiled as modules >> When I'm trying to boot w/o ACPI support all seems work fine, but >> system hangs just before starting kdm > > Please try http://www.FreeBSD.org/~jhb/patches/msi_assign.patch > Seems to work fine, thanks! From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 21:37:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 512331065674; Sat, 4 Jul 2009 21:37:30 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from atmail-8.bnguk.net (atmail-8.bnguk.net [80.74.253.5]) by mx1.freebsd.org (Postfix) with ESMTP id 06C408FC08; Sat, 4 Jul 2009 21:37:29 +0000 (UTC) (envelope-from freebsd-current@chrishedley.com) Received: from [194.247.53.233] (helo=mail.chrishedley.com) by atmail-8.bnguk.net with esmtp (Exim 4.69) (envelope-from ) id 1MNCvI-0000Ne-6Y; Sat, 04 Jul 2009 22:37:28 +0100 Received: from localhost (localhost [127.0.0.1]) by mail.chrishedley.com (Postfix) with ESMTP id 6B044932E6; Sat, 4 Jul 2009 22:37:27 +0100 (BST) X-Virus-Scanned: amavisd-new at chrishedley.com Received: from mail.chrishedley.com ([127.0.0.1]) by localhost (mail.chrishedley.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wg9AQrb41w3z; Sat, 4 Jul 2009 22:37:24 +0100 (BST) Received: from teapot.cbhnet (teapot.cbhnet [192.168.1.1]) by mail.chrishedley.com (Postfix) with ESMTP id 0D5AC932CB; Sat, 4 Jul 2009 22:37:24 +0100 (BST) Date: Sat, 4 Jul 2009 22:37:23 +0100 (BST) From: Chris Hedley X-X-Sender: cbh@teapot.cbhnet To: Gary Jennejohn In-Reply-To: <20090630175731.4c589f80@ernst.jennejohn.org> Message-ID: References: <4A2C124A.1050707@freebsd.org> <3c1674c90906291830g1c79c80bq42ce99f44588e968@mail.gmail.com> <20090630113544.3e2bef31@ernst.jennejohn.org> <20090630175731.4c589f80@ernst.jennejohn.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: New builds won't boot (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 21:37:30 -0000 On Tue, 30 Jun 2009, Gary Jennejohn wrote: > Ah, yes. Now that I think about it again, you're right. That's also > when I started seeing it. > > I'm now running mav's ata-cam patches and took ATA_STATIC_ID out of > my config file. I'd sort of forgotten when/why I'd done it. > > Sorry for the confusion. No problems, I may have a look at the ata-cam patch myself to see if that's any more successful. So thanks for the idea. :) On a completely different subject (and unrelated to the kind souls who have helped out), I'm a bit miffed to find these messages have been gated onto the web by freebsd.org, kerneltrap.org et al with complete, intact email addresses making them easily available to every spammer, 419er and other miscreant on the net. I was wondering why the amount of spam I was getting had tripled in the last fortnight. >:( From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 23:24:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5044D106566C for ; Sat, 4 Jul 2009 23:24:08 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail4.es.net [IPv6:2001:400:6000:6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 04B1B8FC1C for ; Sat, 4 Jul 2009 23:24:07 +0000 (UTC) (envelope-from oberman@es.net) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id n64NNLml001497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 4 Jul 2009 16:23:21 -0700 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 2D0991CC09; Sat, 4 Jul 2009 16:23:17 -0700 (PDT) To: Aragon Gouveia In-reply-to: Your message of "Fri, 03 Jul 2009 22:48:52 +0200." <4A4E6EB4.9000000@phat.za.net> Date: Sat, 04 Jul 2009 16:23:17 -0700 From: "Kevin Oberman" Message-Id: <20090704232317.2D0991CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-07-04_01:2009-07-03, 2009-07-04, 2009-07-03 signatures=0 Cc: freebsd-current@freebsd.org, Anton Shterenlikht Subject: Re: nice work on ntp.conf! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 23:24:08 -0000 > Date: Fri, 03 Jul 2009 22:48:52 +0200 > From: Aragon Gouveia > Sender: owner-freebsd-current@freebsd.org > > Anton Shterenlikht wrote: > > ntp.conf update from 2009/06/07 is very welcome, > > works great straight out of the box, much better than before! > > > > many thanks to whoever worked on this. > > Agreed, thanks! > > Just wish there were a simple solution to the restriction directives... Really nice, although I feel uncomfortable about the use of LOCAL. It is a great opportunity for foot shooting and, since most systems running NTP are not used as serves, I think that it should be left commented out in the default case. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Sat Jul 4 23:54:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C1BF106566C; Sat, 4 Jul 2009 23:54:50 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from host.omnilan.net (host.omnilan.net [62.245.232.135]) by mx1.freebsd.org (Postfix) with ESMTP id 23B638FC14; Sat, 4 Jul 2009 23:54:49 +0000 (UTC) (envelope-from h.schmalzbauer@omnilan.de) Received: from titan.flintsbach.schmalzbauer.de (titan.flintsbach.schmalzbauer.de [172.21.1.150]) (authenticated bits=0) by host.omnilan.net (8.13.8/8.13.8) with ESMTP id n64Nsi66093590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Jul 2009 01:54:48 +0200 (CEST) (envelope-from h.schmalzbauer@omnilan.de) Message-ID: <4A4FEBBC.30203@omnilan.de> Date: Sun, 05 Jul 2009 01:54:36 +0200 From: Harald Schmalzbauer Organization: OmniLAN User-Agent: Thunderbird 2.0.0.21 (X11/20090425) MIME-Version: 1.0 To: Alexander Motin References: <4A4517BE.9040504@FreeBSD.org> In-Reply-To: <4A4517BE.9040504@FreeBSD.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF1423B8DDD8572D0B7AEE38B" Cc: FreeBSD-Current , scottl@freebsd.org Subject: Re: RFC: ATA to CAM integration patch (and gjournaled previuos nodes) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 23:54:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF1423B8DDD8572D0B7AEE38B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Alexander Motin schrieb am 26.06.2009 20:47 (localtime): =2E.. > I would like to present for testing and feedback present state of my an= d > Scott work on extending CAM subsystem to support ATA in addition to > SCSI. At this moment we have: =2E.. > - patch your recently updated 8-CURRENT with this patch: > http://people.freebsd.org/~mav/cam-ata.20090626.patch > - rebuild and install world and kernel; > - read new ahci man page; > - make sure that you will be able to boot if your SATA disk devices=20 > name change from some ad4 to ada0; =2E.. > Waiting for your feedback. Late, but now I'd like to jump in. I have a gournaled FS whoch lists it's consumer as ad12p6 Otherwise I only use labels (ufs) for quiet some time, so I thought=20 testing would be painless... Can I safely remove glabel from the unmounted fs and relabel the new devi= ce? Any Experiences? Thanks, -Harry --------------enigF1423B8DDD8572D0B7AEE38B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpP68QACgkQLDqVQ9VXb8jbAACbB9TrvzaX9VCUzNW8PjVy9Ajm eQYAn2m8Dw6K8RI5y/vJrfyYE62Wpnuy =3UBF -----END PGP SIGNATURE----- --------------enigF1423B8DDD8572D0B7AEE38B--